Cenzic 232 Patent
Paid Advertising
web application security lab

DNS Pinning Just Got Worse

Amit Klein just published a rather interesting article on how anti-anti-DNS pinning techniques can be circumvented (counter counter measures). Namely how you can get around Host: header restrictions by using XmlHttpRequest or by forging headers with Flash. Coupled with Martin Johns’ DNS pinning circumvention technique this marks a sad day for web application security for Intranet applications.

Now from any website in the world that I control, I can read your internal interfaces of your web applications and actually return the entire website. Of course this doesn’t reveal credentials, but it certainly will tell you everything you need to know from an unauthenticated state about what every Intranet page looks like. Ouch.

Amit explains that the common technique of looking for the Host: header on the server will not work against DNS pinning evasion. Previously this wasn’t that big of a deal because you can just go to any website that you want and from an unauthenticated state you can see the webpage. That’s not particularly interesting unless you can’t get to the website (in the case of RFC 1918 non routable address space). Combining these two techniques gives you the ability to read internal addresses. This might not seem easy to exploit because how do you know what a company names it’s internal machines? There are a few ways. First, you can do web searches for logs that may contain referring URLs from intranets. For instance, here are just few intranet servers I found out there:

Google: http://pfe-staging-gfe.prodz.google.com/

Google: http://gwstest.prodz.google.com:8882/

Google: http://lighthouse.prodz.google.com/

Google: http://c4.corp.google.com/

Google: http://merchantdb.corp.google.com/

Google: http://trakken.corp.google.com/

Google: http://gtools.corp.google.com/

Google: http://gweb.corp.google.com/

Google: http://www.corp.google.com/ (add a ~username/ to see specific users)

Google: http://gnome.corp.google.com/

Google: http://epqa71.corp.google.com:19900/

Google: http://newsapps.corp.google.com/

Google: http://adtools.corp.google.com/

Google: http://bugs.corp.google.com/

Google: http://mailman.corp.google.com/

Google: http://alligator.corp.google.com:3128/

Google: http://dogfood.corp.google.com:10000

Google: http://newsapps.corp.google.com/

Google: http://peregrine.corp.google.com/

Google: http://fuzzy.corp.google.com:8000/

Google: http://reactor.corp.google.com/

Google: http://gueda-g2.corp.google.com/

Google: http://columbus.corp.google.com:443/

Microsoft: http://team/

Hi5: http://intranet.hi5.com/

The one that I think is the most interesting is actually Hi5 (even though this is also visible from the Internet-despite it’s name), because I think this is really sestemic of the issue. There are a few very common names for intranet applications that can help you get started in your recon. The first is “intranet” as Hi5 shows us. Being able to read the intranet website can help you locate lots of other servers because intranet applications are designed to be hubs where users go to locate other servers. There are tons of other common names, but I think you are best off finding the intranet application and spidering from there.

So, in review: Locating that the site is there in the first place using Jeremiah’s JavaScript intranet port scanner and then using the DNS pinning attack to read the page itself pretty much seals the deal.

16 Responses to “DNS Pinning Just Got Worse”

  1. countzero Says:

    Is it possible to scrape those pages so we can see what’s on them?

  2. RSnake Says:

    Sure, just leave a trap for someone who comes from those companies in some way and use one of the DNS pinning attacks to read any data you want off of any of those pages using JavaScript XmlHttpRequest.

  3. Matt Says:

    This defeats the point, but if your able to view the intranet pages, would it not also be possible to bring down the servers from the inside, making it look like an internal error? (given that the logs would more than likely indicate and external presence)

  4. RSnake Says:

    It doesn’t defeat the point. There may be very real reasons you may want to bring a server down (specifically one that monitors security or otherwise hinders your ability to do malicious things). So to answer your question, it’s theoretically possible yes, as long as whatever the attack is can be executed via requests that can be originated from a browser (or originated by using the browser as a proxy).

  5. Matt Says:

    Would it not be possible to modify the servers (or contents) for reasons such as spam or phishing? or just to redirect requests from that server(s) to other servers (or pages)?

  6. RSnake Says:

    Just about anything is possible, yes. Some things have limited uses though. Phishing on intranets will only work against the users of that intranet application, but yes, it’s definitely possible, especially if there are XSS vulnerabilities in those applications that allow you to both have the right domain and have your content on it, to both read from the domain (to get the right look and feel) and to put whatever content you like on there.

    I’m not quite sure what you’re asking about spam, as spam is a different protocol, can you elaborate?

  7. Matt Says:

    using the server to distribute spam (assuming of course that the server has access to the internet).

  8. RSnake Says:

    That would work if the server had some sort of email form built into it. I can’t think of anything off the top of my head other than test environments/staging before something launches that might have something like that built in, but I’m sure there are applications where web based forms generate external emails from intranet applications.

  9. Matt Says:

    assuming the server has internet access, as testing purposes, or for company related matters such as should there be a casual Friday, so similar things, any site which has (for example) Microsoft frontpage extensions, can send web generated form data to email addresses, internally or externally…so again assuming the server has an internet connection which can be used (which is the case for most intranet pages that link to external pages), either a form which previously existed can be used or if you modify the contents of the sever a page of your own creation could be used.

  10. RSnake Says:

    Sure, that’s a perfectly valid application for this. It seems like a bit of a waste of such a powerful hack (to send just a few emails from an intranet server), but there may be applications where this is useful. A few examples are sending very targeted phishing/spoof email or getting email to be signed properly if domainkeys or SPF records are an issue.

  11. Matt Says:

    if emails could be made authentic enough for administrators to enter details…such as replying to ‘manager’ requests, then you could open up other servers on the network, or, if its a server of a company which deals with credit card requests or handles them, then details could be cloned or modified.

  12. ha.ckers.org web application security lab - Archive » The Web Application Security Good - oh yah, and Bad and the Ugly Says:

    […] 6) Let’s also not forget HTML Purifier. It’s some of the best code I’ve seen to date to stop XSS. Unfortunately, it can’t protect you against server level hacks, like the Expect vulnerability, or DOM based XSS, or anti-DNS Pinning, the unpatched mhtml issue or other crazy XSS issues. But we have to start somewhere right? […]

  13. maria Says:

    hi ! i have a problem and i want some help. i have an hi5 profile but i don’t like it because i don’t have such views that i want. could you let me know if there is a way to hack the views counter and change the number? thank you

  14. neopunisher Says:

    does the flash exploit to spoof headers still exist?

  15. Grant @ portal software Says:

    You have always been able to fake header info by using CURL in php. It is common practice by the high end bots that can use pools of fake headers.

  16. jim Says:

    Grant : I don’t think you understand the purpose of DNS pinning. Yes, of course you can fake headers with custom software but if you can get custom software to run on the target’s computer then you can just sniff any credentials/intranet addresses and connect to them via their computer yourself.

    The attack has to work from the target computer’s web browser which you don’t have control over.