Internal Hostname disclosure from multiple Apache servers via blank host header method
Team Summary
Official summary from Ping Identity
This vulnerability was due to a general misconfiguration of Apache servers; this is a good example of the importance of "Secure Defaults" in open-source projects. An example of a generic request and response would be: openssl s_client -connect apache.example.com:443 GET apache.example.com/foo HTTP/1.0 Host: Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3 Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 HTTP/1.1 400 Bad Request Date: Thu, 3 Feb 2020 13:14:15 GMT Server: Apache Content-Length: 335 Content-Type: text/html; charset=iso-8859-1 Strict-Transport-Security: max-age=15768000; preload; X-Content-Type-Options: nosniff Connection: keep-alive <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> <hr> <address>Apache Server at aws-ec2.example.internal Port 443</address> </body></html> closed As reported by the researcher: Summary: I found 3 subdomains vulnerable to a method that essentially "tricks" websites into leaking their own internal hostname. Vulnerability Description This is the "very detailed" explanation, if you just want to test/reproduce it, just scroll past this to "Steps to Reproduce" Now I'll explain the issue that leaks these internal hostnames. Essentially, it has to do with website behavior towards empty host headers. So the original method comprises of setting up a GET request to the website, just the main directory. Next, you test it for typical host header injection by changing the Host header to anything like foo.com. Send this request, and if the response contains foo.com anywhere, it may be vulnerable to blank host header info. leakage. However when I was testing your site, I noticed it simply gave a 302 and tried to redirect back to the correct host. I found a way to bypass this though; setting up the request to a nonexistent directory, and including the CR character, like this: /foo%0A, makes it give a 404 and return the host header at the bottom of the page. Now that we have host header injection, here's where you use that to leak the internal information. Firstly, change the protocol from HTTP/1.1 to HTTP/1.0 (this is to allow blank host headers). Next, remove the host header and send the request. Look in the same spot that the host header was displayed previously, and the internal hostname/ip will be displayed there. Suggested Remediation To prevent this, you need to prevent host header injection, or at least prevent the host header from being returned anywhere in the response. The best way to do this is using something like Cloudfront protection, which prevents host header injection. Impact It is a bad idea to leak internal hostnames, as they can be used by attackers to exploit the network or server. They can chain issues to launch specific attacks against the internal infrastructure; in other words, leaking internal IPs or hostnames leads to normally non-issues becoming vulnerabilities.
Report Details
Additional information and metadata
State
Closed
Substate
Resolved
Bounty
$150.00
Submitted
Weakness
Information Disclosure