Cloud Metadata Potentially Exposed - 90034

Kish V

unread,

Mar 1, 2023, 5:53:00 PM3/1/23

to OWASP ZAP User Group

Hello,

Have an application running on Elastic Beanstalk on AWS and the OWASP ZAP running as a containerized application on EC2 and running into an issue which seems like a bug after reviewing the code.

Scan:
- owasp/zap2docker-stable container running on EC2. Per the docker file the release version is v2.12.0 that included the cloud metadata attack rule.

- Application running on EB using the default nginx configuration with custom override for nginx configuration exclusion with server_tokens off;

- OWASP ZAP scan reports Cloud Metadata Potentially Exposed on the initial scan with error code of 90034 and riskdesc of High (Low).

Remediation:

- Updated nginx config to respond with 401 when the request matches the path of /latest/meta-data

- Validated the response header as the following with the associated response:

- Header:
HTTP/1.1 401 Unauthorized
Date: Wed, 01 Mar 2023 21:34:41 GMT
Content-Type: text/html
Content-Length: 172
Connection: keep-alive
Server: nginx
- Response
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx</center>
</body>
</html>

- Ran the scan again with the same error

Code:

Per the code for ascan rules and the linked code this should come back as negative after the change described above based on the status code.

Request:

Can someone please review and provide some guidance on what version of the zap-extensions is bundled with the owasp/zap2docker-stable and if there is an active bug on this issue or if a new one needs to be filed ?

Thanks

kingthorin+owaspzap

unread,

Mar 1, 2023, 9:12:14 PM3/1/23

to OWASP ZAP User Group

Without specifics of the request/response ZAP is reporting on it's hard to say.

Might be related to/same as: https://github.com/zaproxy/zaproxy/issues/7710

Kish V

unread,

Mar 2, 2023, 7:44:24 AM3/2/23

to OWASP ZAP User Group

More details below, redacted the actual URL.Based on the request/response this should come back as non-issue but ZAP OWASP response with the below alert.

If you need to recreate this deploy the sample Java App on EB and deploy the OWASP ZAP stable release container (release versioned above). You will need to add the nginx configuration - location /latest/meta-data {return 401} to EB config. Run the scan with the ALB URL and you will see the same issue as below. Reviewing the code and unit test code this should not be an issue but not entirely sure the version of the zap-extensions and the drift in code that is causing this issue.

Let me know what additional details are needed.

  Request(Based on ZAP Scan code):
    curl -v http://example.region.elb.amazonaws.com/latest/meta-data/ -H "Host: 169.154.169.254"

  Response Header:

    HTTP/1.1 401 Unauthorized
    Date: Wed, 01 Mar 2023 21:34:41 GMT
    Content-Type: text/html
    Content-Length: 172
    Connection: keep-alive
    Server: nginx

  Response:
    <html>
    <head><title>401 Authorization Required</title></head>
    <body>
    <center><h1>401 Authorization Required</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>

  JSON Response from OWASP:
    curl "$OwaspZapURL/OTHER/core/other/jsonreport/?apikey=$OwaspZapApiKey"  | jq
      {
          "@name": "http://example.region.elb.amazonaws.com",
          "@host": "example.region.elb.amazonaws.com",
          "@port": "80",
          "@ssl": "false",
          "alerts": [
            {
              "pluginid": "90034",
              "alertRef": "90034",
              "alert": "Cloud Metadata Potentially Exposed",
              "name": "Cloud Metadata Potentially Exposed",
              "riskcode": "3",
              "confidence": "1",
              "riskdesc": "High (Low)",
              "desc": "<p>The Cloud Metadata Attack attempts to abuse a misconfigured NGINX server in order to access the instance metadata maintained by cloud service providers such as AWS, GCP and Azure.</p><p>All of these providers provide metadata via an internal unroutable IP address '169.254.169.254' - this can be exposed by incorrectly configured NGINX servers and accessed by using this IP address in the Host header field.</p>",
              "instances": [
                {
                  "uri": "http://example.region.elb.amazonaws.com/latest/meta-data/",
                  "method": "GET",
                  "param": "",
                  "attack": "169.154.169.254",
                  "evidence": ""
                }
              ],
              "count": "1",
              "solution": "<p>Do not trust any user data in NGINX configs. In this case it is probably the use of the $host variable which is set from the 'Host' header and can be controlled by an attacker.</p>",
              "otherinfo": "<p>Based on the successful response status code cloud metadata may have been returned in the response. Check the response data to see if any cloud metadata has been returned.</p><p>The meta data returned can include information that would allow an attacker to completely compromise the system.</p>",
              "reference": "<p>https://www.nginx.com/blog/trust-no-one-perils-of-trusting-user-input/</p>",
              "cweid": "0",
              "wascid": "0",
              "sourceid": "79"
            },
          ]
        }

Reply all

Reply to author

Forward

Cloud Metadata Potentially Exposed - 90034 - Bug ???

Kish V

kingthorin+owaspzap

Kish V