Friday, February 15, 2008

Internet Facing SEO/Validator Sites vulnerable to Intranet Hacking

While looking for additional data to progress the development of my WebSite Intranet Scanning tool based on RSnake's original paper on Intranet hacking through web sites, I hit the jackpot in terms of finding sites that appear to be vulnerable.

SEO (search engine optimization) site scanners and html/xml/etc page validators generally allow anonymous users to specify URI's to be scanned and validated. Unfortunately, almost NONE of these sites I found appear to validate these user supplied URI's before fetching and performing whatever analysis they do.

Some screen shots for your viewing pleasure.
The first site allowed us to scan http://127.0.0.1 revealing all sorts of good stuff about whats running on the server, as well as the fact that cPanel control panel is hosted on this address.

Since these sites work by sending a simple HTTP GET for the user specified URI, we could probably leverage known cPanel vulnerabilities against this site, and possibly own the box from the inside.

The second screen shot is from another site and shows more of the same.

What is really interesting about these sites versus the ones I've found before is that many of them actually spit the content back out at you. I'd been focusing on using timing to determine if hosts/ports are listening, but these applications will give you the content served, or if the host is not up, give you a nice error message saying so.

I thought about responsibly disclosing these problems to the web site owners, but I'd be doing that until my fingers fall off since there are so many of them. So consider this my responsible disclosure.

How can this be prevented? Easy: validate user supplied input. Don't allow users to submit URI's with 127.0.0.1, localhost, and addresses in your local address space. It's probably not too hard to make a decent white list regex to allow FQDN's and public IP ranges.

Some sites actually did block the request. Funnier still, some sites with multiple scanners/validators had mixed results, with one scanner being vulnerable and another not.

No comments: