On a recent web application penetration test, I identified a classic server-side request forgery (SSRF) vulnerability that used a Denylist in an attempt to prevent active exploitation. This post details a quick and easy method for bypassing this type of control when exploiting an SSRF vulnerability.
The application I was testing allowed you to create a “Connection Profile” to integrate the application with third-party APIs, but it allowed users to configure the remote host, port, path, and include Basic authentication.
Screenshot of configuring a test server in the Connection Profile to verify the SSRF:
Setting a listener on my server on port 9999 verified the connection was made server-side, and the full response body was returned in the application, resulting in a full SSRF vulnerability.
Analysis of the application revealed it was hosted in the Azure cloud, so the Azure metadata API was a prime target. The Azure metadata API requires the header to be set to prevent this type of vulnerability, but the target application additionally allowed arbitrary headers to be added to the request. The connection profile was set to “http://169.254.169.254/metadata/instance?api-version=2021-02-01” and the “Metadata: True” header was added to the connection profile:
Firing off the request with the above configuration resulted in an error message noting the application used a denylist to prevent access to the cloud metadata address (169.254.169.254).
Screenshot shows the application forbade connecting to the metadata IP:
Bypassing SSRF Control
I tried a few options to bypass the denylist without any luck. Finally, I decided to set an external domain name to the metadata IP. Using GoDaddy DNS management for my test domain, I set the metadata subdomain to point to 169.254.169.254:
After verifying the DNS entry for the new subdomain had propagated, I used the subdomain for the connection profile. This successfully bypassed the denylist and allowed access to the cloud metadata!
Bypassing SSRF Conclusion
This is an easy and effective way to bypass denylist-based protections for SSRF vulnerabilities. Upon further research, it appears that some applications will even go so far as to resolve the domain name before checking against the denylist, which would result in this technique failing. However, this blog details the use of DNS rebinding to trick the application in this situation. This essentially rapidly changes the DNS entry from something innocuous that bypasses the filter to the actual metadata IP address for subsequent attempts.
These types of bypasses are an excellent example of why denylist-based protections against SSRF vulnerabilities are often insufficient.
MORE FROM OUR TECHNICAL BLOG
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
