Cenzic 232 Patent
Paid Advertising
web application security lab

Effects of DNS Rebinding On IE’s Trust Zones

I don’t get things like this too often in my inbox, but when I do, wow… It makes me really worry about the concept of single sign-in and the advocates who claim it solves “the problem”. I just think it adds another problem, personally - and that is you are always as vulnerable as the weakest link (in this case, the browser). Need proof? Onto NTLM! This is an email from natron. I think it speaks for itself:

As things always go, I’ve been too busy to really lock this down and get it functioning smoothly, but I have found out some interesting things that I wanted to share. As a reminder to what I had been working on, I was interested in seeing what other effects DNS-rebinding might have, and I was looking for common internal vulnerabilities that are low-risk as long as they remain internal, but may be high-risk if you can hit with DNS rebinding. Specifically, I began to look at ways to hijack NTLM auth over the internet. Here are the few things I’ve uncovered in my spare time over the last few months:

NTLM-over-HTTP occurs automatically if a) the client is a member of a domain and b) the server is in either the trusted zone or the intranet zone. A server is placed in the intranet zone if it does not contain any TLDs, such http://notlocal/. In many (most? all?) configurations, a server is placed in the trusted zone if it ends in the same domain, such as http://notlocal.domain.com, where the user is a member of domain.com.

I’ve been playing with ways to fool the browser into bouncing http://notlocal or http://notlocal.domain.com to an external address through the use of DNS rebound java applets. If you can do this, you can steal NTLM credentials over the internet.

Getting a client to accept spoofed NBNS responses is pretty easy:
• Acceptance of an NBNS (e.g. WINS) response is the same as DNS; it only requires a transaction ID that matches the request.
• Sane devices, such as network appliances and printers, randomize the request’s transaction ID so it is (at least upon cursory examination) unpredictable.
• The Windows XP machines I’ve come across don’t do any randomization. At boot, it starts at 0×8000 and iterates upwards by 1-4 per request (e.g. 1st is 0×8000, 2nd is 0×8003, 3rd is 0×8004, ad infinitum).
• A java applet can spam the requesters IP address (identified by a call to getlocalhost() or whatever the java function is) with spoofed NBNS responses, iterating up from 0×8000 to whatever you want. This is incredibly fast without hogging very many system resources. You can effectively let it loop from 0×8000 to 0×9ffff without causing a noticeable impact on the browser; it can merely look like it’s still waiting to load.
o On my client networks that I’ve been paying attention to since noticing this, it’s incredibly rare to see a Windows machine making NBNS requests above 0×9fff. I’m assuming this is because the networks I’m on don’t have very many machines that are left on over night.

Injecting invalid data into AD’s DNS servers is easy, with some prereqs:
• If you know the domain controller’s address, you can create a valid update request that will point the name of your choosing to an arbitrary IP address. This address can be non-local.
o For example, if you were on sectheory’s AD network, you can issue a request to the domain controller that says “register the IP address 123.123.123.123 to imnotreal.sectheory.com”.
o The servers do appear to ignore packets sent to broadcast and multicast addresses, so it requires you to know the internal IP address of the domain controller. I assume any internal domain controller will work, but I haven’t done much checking here yet.

When an AD-authenticated browser issues a request like GET http://notlocal/temp.gif, it does the following:

1. DNS requests for notlocal.sub.domain.com, waits for responses
2. DNS requests for notlocal.domain.com, waits for responses
3. NBNS requests for notlocal, waits for responses

The NBNS response is the easiest to do, because it doesn’t require any previous recon to identify the DNS/AD servers. However, timing is tricky, because it has to pass through all of the previous options before it checks NBNS.

(As an FYI, a computer not authenticated to a domain immediately goes to the NBNS requests, but non-authenticated computers won’t auto-auth to resources in the “Local Intranet” security zone, so I don’t see this as very useful right now. However, you may find this interesting to bypass other security restrictions, as I assume the “Local Intranet” zone is much less secure than the “Internet” zone in default configurations.)

After I confirmed this was working, I switched gears to get metasploit’s ntlm_relay code working through “NTLM-over-HTTP” (it currently only supports SMB). Once that works, I’ll be working on doing the actual DNS rebinding to make it work in a real environment.

Yes, NTLM is useful, but as long as these types of intranet hacking vulnerabilities exist in browser space, I think it’s best to steer clear of them, and that doesn’t just include DNS rebinding. Nice work from natron!

6 Responses to “Effects of DNS Rebinding On IE’s Trust Zones”

  1. natron Says:

    So, how this would work:

    1. User browses malicious website
    2. Browser loads malicious java applet
    3. Browser issues a get request for http://notlocal/example.gif
    4. Java looks up the localhost’s IP address, rebinds to it, and begins spamming NBNS/WINS responses for NOTLOCAL
    5. Browser eventually issues an NBNS request for NOTLOCAL and accepts the response coming from the rebound java applet
    6. Browser places NOTLOCAL in the “Local Intranet” zone.
    7. Browser issues a GET request to the IP address from the spoofed response
    8. Remote server requests and browser begins NTLM authentication.
    9. The server communicates with the rebound java applet to perform a pass-the-NTLM-hash (see http://www.metasploit.com/confs/defcon2007/tactical_defcon2007.pdf and metasploit’s ntlm_relay exploit module for details )
    10. Exploit logs in to the browser’s computer with the NTLM hashes, uploads a payload, and executes.

  2. Mark Goodwin Says:

    I blogged about the implications of IWA with respect to CSRF and DNS rebinding attacks a while ago (http://getahead.org/blog/mark/2007/04/16/integrated_windows_authentication.html). It’s cool to see some more concrete work on this.

  3. n00dles Says:

    “If you know the domain controller’s address, you can create a valid update request that will point the name of your choosing to an arbitrary IP address.”

    Not entirely true, that’s assuming 1) AD integrated DNS is being used and 2) Dynamic DNS is enabled. I have yet to work in a large enterprise where this is the case… very interesting post though.

    Is it a co-incidence that MS07-062 was released today… I know it doesn’t fix the client, but it’s kinda related :-)

  4. Kurt Grutzmacher Says:

    Also, this does open up a lot of issues with ActiveX objects that are set to be trusted inside the Intranet Zone. I have a few private exploits that this could open up to a larger audience.

    After the owasp conference I’ll get on this some more. Great talk Rsnake.

  5. Eric Rachner Says:

    Guys,

    This isn’t DNS rebinding — this is spoofing.

    Also, Mark, your comment about DNS rebinding & windows integrated auth is incorrect. IE will never automatically authenticate to an external/untrusted hostname, regardless of what IP address it happens to be bound to.

  6. RSnake Says:

    @Eric - I think you mis-read, you’re right that this isn’t DNS Rebinding, but natron is working on a future version that does use it “Once that works, I’ll be working on doing the actual DNS rebinding to make it work in a real environment.” You can use your imagination to see how that would be more useful.