Dec 21, 2016
PermaNulled

Hijacking a Victim’s DNS with DNS-Rebinding

OSSEC CVE(s)

Thanks to Kurt over at DWF I was able to get a CVE assigned for the OSSEC SQL-Injection detailed in my previous post CVE-2016-1000266 / CVE-2016-1000265

Was happy to help the guys over at OSSEC patch the problem and I’m glad it’s getting some acknowledgement.

Hijacking a Victim’s DNS with Anti DNS-Pinning(DNS Re-binding)

Last night I got on the kick of router/modem security considering the recent attacks we’ve had going on I thought it might be nice to jump on the bandwagon of researchers and check it out for myself.

With this I thought I’d simulate an attack I was able to perform in a penetration test because a router had remote management enabled, which was hijacking the victim’s DNS requests via DNSChef and getting a MITM to steal the victim’s credentials as they logged into a specific website.

That was all achieved by simply changing the victim’s DNS settings on their router,

So the question became what’s stopping me from doing this to my own modem via a web browser on an internet facing URL.

Immediately I started looking for any code which may not enforce the Same-origin policy to explain briefly the Same-origin policy was created to protect against attacks where web code attempts to make a request to a server where it’s unauthorized to do so (meaning local network resources as well like modems and routers).

While researching this I had come up with blanks due to my specific use case,

  • img tag to pull URL allows to perform a get request
    • This doesn’t allow us to retrieve page content, and DNS cannot be changed via a get request.
  • form tag with javascript to for the submission
    • Could work, but there’s a CSRF token in place (on the DNS page)
    • This can actually be used to login as the login form does not require a CSRF token.
  • iframe capture – Maybe I could CSRF login with a forced POST to login then grab the token from the DNS page via a iframe on it and capturing content with javascript out of the iframe
    • SOP (Same Origin Policy) – prevents you from obtaining information from the iframe.
  • SVG scripting?
    • I actually did not look too deeply into this, though I recall there was some recent commotion in regards to the way a few popular websites handle the sand-boxing of it.
  • Websockets?
    • They use their own protocol so to my knowledge this wouldn’t have allowed me to simulate HTTP over the port 80 on the modem which was my goal.
  • Flash sockets?
    • I was always intrigued by an ‘underground’ paper  I was sent from a zine/group called SSH(Secret Society Hackers) in about 2007-2008 which used Flash sockets to port scan local networks when an victim was to browse it, since then though I’ve discovered Adobe was wise and implemented security restrictions on how the sockets are able to be used now leaving this attack useless for what I was trying to accomplish.
  • Chrome – chrome.sockets.tcp
    • It’s my understanding there’s no way to trigger this from an actual site and that it would have to be developed into an extension because of such I did no further research on whether or not it would’ve allowed me to make requests with no security policy in place on the target of the request, as my goal was to simply have a page load to attack the router not require extension downloading or etc.
  • Firefox –TCPSocket
    • Would also not only require additional user interaction but it seems certification or ‘trust’ form the Mozilla Organization, not what I was looking for.
  • WebRTC
    • No ability to make raw connections.
  • Exhausted for options, I’d looked into every capability to establish any kind of network connection (including HTML 5 methods, proposed W3C Sockets)
    • Not one seemed to achieve what I was looking for.
    • There may be other options still HTML Imports?, “Iframe in an Iframe” – http://blog.cakemail.com/the-iframe-cross-domain-policy-problem/

At this point I was out of ideas I could make the browser login to the modem but I couldn’t bypass the CSRF token I had to go back to the drawing board,

This was when the idea hit me that maybe I could bypass SOP by simply “racing” my DNS or rather what I later came to discover was already called “Anti-DNS Pinning” and “DNS Re-Binding”,

Essentially I had thought I can load my original page within my sub-domain which contained some JavaScript which did nothing more then get the content of the DNS page as a Proof of Concept to demonstrate to myself I would be able to at the very least retrieve the CSRF token I needed to be able to submit new DNS settings.

With a bit of time I was able to do exactly this,

  • PHP Script which when loaded adjusted DNS settings to point at modem.
  • PHP Script echoed Java-script which persisted on the client side.
  • Java-script waited a period of time for the DNS change to take affect and then attempted loading /RgSetup.asp (My Modem’s DNS page)
  • Pwned, I was able to get the CSRF token from the returned data bypassing SOP because it was the same domain just a different IP.
    • My first thought was why wouldn’t SOP also validate IP but this would break in many cases where people achieve Load balancing with a round robin configuration.
    • And I’m sure there are also other issues that it could cause, I just personally couldn’t think of any while writing this article.

Now I was surprised this was even possible and I had to research it,

It was such a simple method there was no way someone hadn’t discovered it before…

The questions ran through my head over and over again

  • Why is this still possible?
  • Why has no one reported this yet?
  • Why didn’t this turn up in my google searches for “Bypass same-origin policy”, “Javascript access external domains”, “HTML5 access external domains”, etc.

Well to let myself down it turns out this was actually covered several times and was even used in attacks against other services and systems not just modems/routers.

I managed to find a few resources which referred to it both as “DNS Re-binding” and “Anti DNS Pinning” the original attacks against this seem to originate back to 1997 when it was first reported by Princeton “Java Security: From HotJava to Netscape and Beyond”.

So now the question was how is it that I’m still vulnerable to this if it’s so widely known why have browser developers done nothing to protect against this attack?, In-fact it was reported to both Chrome and the Mozilla foundation…

Basically after gathering further research I guess what the Browser developers had decided was it was up to vendors/sysadmins to resolve the issue by implementing checks against the Host header, the scary part is the fact as we’re realizing today Router/Modem vendors are completely irresponsible and ignore security flaws like this.

Now it sucks I discovered something on my own which seems to have been abused since the beginning of time,

But at the same time it’s great that I’m aware of the problem now and have always been curious if it’s possible for me to overwrite my router configuration with nothing more then a  snippet of javascript.

The interesting part is the different methods that have been used to attempt protecting against this,

Like not allowing DNS responses to contain rfc1918 for domain names, Some saw this as an inconvenience or a problem due to the fact they were serving up internal portals using sub-domains of their corporate domain (I actually encountered this with a client).

The problem there is serving internal DNS records over a WAN facing server this is never a good idea and DNS forwarders should be used internally to serve these kinds of requests.

So at the end of the day what did I take home and learn from this?

  • DNS Re-binding is an extremely old attack dating back to 1996
  • DNS Re-binding has been re-used and abused in talks.
  • So far there has been no active malicious exploitation seen of it.
  • It’s not necessarily common knowledge to the newer security researchers.
    • I’ve asked a few different people if they’ve heard of this attack vector only to learn not many had.
  • Browser developers refuse to protect against it.
  • There are still websites configured which do not check the Host header and allow users to connect via the dedicated IP assigned to the site.
  • Router/Modem vendors STILL aren’t protecting their devices appropriately.
    • Even if I wasn’t able to determine the username/password for my device, the modem kept me authenticated by either IP address or MAC for a specific period of time, meaning I did not need to steal cookies or etc as long as the ‘victim’ was logged in before accessing the page.

I’ll be writing an additional article with a release of proof of concept code and a video demonstration within a few days against a few different routers,
In the mean time I’m attempting to contact the vendor of my modem to see I can’t get them to implement the appropriate host header check into their stuff.

What can you do to protect yourself?

The problem I see with most of the protection is it’s still not resolving the root problem which is very simple (Verifying the Host header)

Leave a comment