The DNS rebinding issue has been around for a while. There is something called "same-origin policy,"
The developers of Netscape Navigator 2.0, who put JavaScript into web browsers for the first time, realized that scripting was very powerful. When you went to a website and downloaded a page which contained JavaScript, this JavaScript was going to run in the browser, and it could do lots of things. What they wanted to prevent was it doing anything to other websites on behalf of the user. They wanted to constrain the scripting so that it's not going to get up to any other mischief. And they let the script only deal with the same site, that is, the site that it came from is the only server domain name that it's able to access. And so this notion of same-origin policy, that is, the origin where the script originated, the origin of the script is a constraint that all browsers since then have imposed. Some of them do it to different degrees.
For example, origin is supposed to mean the same domain and port and protocol. So, for example, if you got a document over
https://amazon.com, then the script could not do anything to http:// because that's a different protocol, HTTPS versus HTTP. So it's got to be the same protocol. Also the same port, although it turns out IE doesn't enforce the port side. And, for example, cookies don't obey the protocol side. So cookies that you transact over HTTP will also be transacted over HTTPS as long as the domain is the same.
So these things are understood. And this has been sort of evolving along for some time. The problem is that DNS creates a relatively weak link or, to use the fancy term, "binding," a weak binding between the domain name and the IP. That is, that's what DNS does is it binds a domain name to an IP so that, as we know, you ask DNS on the Internet, wherever it is, what's the IP for this domain name, and some sort of a process goes about resolving that domain name into the IP, and you get an answer.
So it's been understood, though, that there are some problems created with this. And this has also been known since about 14 years. It was in 1996 that the first DNS rebinding attack was first seen. And it was used against the Java Virtual Machine. The idea there was that, and we discussed this briefly a couple weeks ago, when you ask for the address, the IP address of a DNS domain, you can receive more than one IP address in return. This is often used for load balancing. For example, I think if you ask - I'm trying to think, I think like the IP for Amazon, you don't get one, you get, like, three or four, or Microsoft. And every time you ask, the server rotates them so that the one that's sort of first in line is what the browser will use. But the point is, if there's a problem, if that server's overloaded, or it can't make a connection, it'll go to the next one.
Well, what some clever hackers realized was that they could return the actual IP address for a malicious site as the first address, and a local IP like 127.0.0.1, which is the localhost IP, for the second address. So when the browser attempted to get another resource from the malicious server, it would send a reset packet. It would send a TCP reset packet back to the browser, denying that connection on the IP that it wanted to use. Well, since the browser had received a number of IPs, or at least two, it would go to the second one, which in this case was 127.0.0.1, which is sort of universal. It's called the localhost IP. It's always used to refer to that own machine.
And what that did was that gave Java, the Java Virtual Machine, something by design it should never have, which is socket-level, network-level access to your own machine. Which hackers had all kinds of fun with until it was understood that this was causing a real problem. So what happened that got this into the news just recently is that another new vulnerability was discovered in routers that hadn't been suspected before, which was, okay, now get this. The router will obey connections aimed at its WAN IP from the LAN.
So the idea is that, normally when you connect to your browser, like you want to do administration on your browser, you typically use its gateway address, 198 or 192.168.0.1 or 1.1 or whatever, which is typically the same IP that it uses for its gateway. It has a web server running in it. And so you point your browser at that IP, and that brings up its admin interface. Well, because rebinding is a problem, there have been protections put in place historically against - by browsers against being fooled by having the script able to use local IPs to access your browser.
So let's step back a little bit and understand how that works first because the idea would be you browse to a malicious site. You don't need to press any buttons, click any links, do anything. You just download a page from the site. Or what's even more disturbing, a web ad is served by a malicious site. So you don't even have to go to a site. You can simply be surfing around benignly on the Internet, and a web ad is displayed which is, after all, a browser document. And we know that those can contain scripts because they often are Flash, which has got some script running to show you a Flash ad. It can also be JavaScript.
So the idea is, when your browser asked for the IP address of attacker.com, it received a valid IP address the first time it asked. Then, in running the script, the script says, oh, I need something else from attacker.com. So what happens is your computer makes another request for the IP address of attacker.com. The reason it does that is that your browser has its own DNS cache, but plug-ins like Flash have their own. So even though your browser knew the IP address of attacker.com, Flash, the Flash plug-in, technically the term is they have separate DNS name spaces. So the Flash plug-in, or Java, or Silverlight or whatever, they're not privy to, for example, Firefox's DNS cache or even your system's DNS cache. They've got their own. So they'll make a request.
When that second request is made, instead of returning the IP address of the site, it returns an IP address that is probably your router's gateway, like 192.168.0.1. So now what happens is this same-origin policy we were talking about, which prevents a script from having access to different domains, now what it has is it says it asked for attacker.com, which it's just been told is 192.168.0.1. But attacker.com is where the script came from because that's where the browser originally loaded it from. Which means that the script came from attacker.com. Now this Flash plug-in believes that attacker.com is your gateway, is your router.
Which means it has full permission within the same-origin policy to do anything it wants. And so it's able to establish a web browser session, a web connection to your router, login without you knowing it,
assuming that you didn't change your username and password. It can typically identify the brand, make, and model of your router from the greeting page, the login page that tells it what kind of router you have, make and model. It then looks up in its own little dictionary the default username and password. And more often than not, about half the time apparently, it's able to log on. And so that's the way same-origin policy is broken.
Now, some browsers and plug-ins protect against this because this, again, has been known for a long time. They block 192.168 dot anything dot anything. They block 10-dot anything anything anything. And the 172.16 through 172 dot what is it, 24? 29? I can't remember what the second byte of that is. But basically the RFC 1918 is where those define. Those three networks, they're smart enough not to allow that. So this problem was believed to have gone away.
It turns out it crept back in, in a different form. And that's what this hacker revealed last weekend at Black Hat, which is, not only can you browse to your router's web browser using the private gateway IP, 192.168 dot whatever dot whatever, or whatever it is; you can, believe it or not, also get there using its public IP, that is, the WAN IP, the public IP of the browser, even if it has been disabled, even if you've specifically configured your router not to allow WAN-side access. The way the stacks are written in the DD-WRT and OpenWrt browsers, these aftermarket firmwares, and some of the standard manufacture firmware, will still allow the browser to respond from inside the network, if you use the IP from outside the network.
And so the next-generation attack that was revealed last week, which I'm sure all of the various firmwares are in the process of scrambling around to fix right now, solves, well, what it does is it gets around the blocks against internal LAN access IPs by using your public IP. And of course the remote DNS server gets your public IP because that's the IP from which the request comes to it. It's emitted by your computer, asking for the IP address of attacker.com. Well, that comes from your public IP. So it's able to return the public IP to the script running in a plug-in, which then knows how to get around the use of private IPs on the LAN to access your router.
So, I mean, this is the kind of complexity we're dealing with in this day and age because we've made our systems so complicated. It's, I mean, it's just like one more little hole that's been found that we now have to scramble around and patch.
Now, I mentioned a couple weeks ago that NoScript had some built-in protection for this, that is, for prior types of attacks like this. They're very, very close to releasing v2.0 of NoScript. I think we're at 1.9.9.96. We're just about to roll over to v2.0. And 2.0, I was looking at the release candidate log at RC7 and then 8. They've just added a new feature which will block this next type of attack, as well.
There's something very cool that I never really looked at in
NoScript called ABE, stands for Application Boundaries Enforcer. And if you go into NoScript Options and then Advanced, under the Advanced tab there's an ABE subtab. And there's actually a little rule-based firewall that there's a page of documentation about it. On the 'Net you can go to
noscript.net/abe and learn about this. But this is built into NoScript, and it allows some interesting restrictions to be put on what your browser is able to do. They're not normally enforcing very many rules. There's a default rule that prevents this kind of problem, the first-generation type of rebinding attack that your browser would launch against any other machines in your local network.
And by the way, this doesn't only have to be launched against your router. Essentially, what these rebinding attacks allow is your computer to serve as a proxy that's then operating inside your network and, with script running in it, that potentially has access to any of the machines in your network. Even, for example, to Windows filesharing, where behind your router you might believe that filesharing is safe because your router is going to protect you. But if something has set up a beachhead in your browser which then has access to your network, and this is specifically what same-origin policy is designed to prohibit, if that's broken, then you've got something running in your browser that has visibility into your entire LAN. Which is frankly terrifying.
So we have essentially this DNS problem which DNSSEC doesn't protect us from. It takes advantage of the fact that our systems have gotten complex, so that they're sort of all doing their own DNS fetches and not taking advantage of the DNS knowledge that different pieces of the system have, which allows the same domain to be known by multiple IPs. And if some of those IPs are within your network, then scripts which have been deliberately restricted against having access to anything but the domain they came from, well, they then believe that the domain they came from is whatever machine inside your network they want access to. This makes it possible. And Flash and Java both have socket-level capabilities, meaning they can open connections, low-level network connections. They're not constrained to just web-based accesses. They can open network-level connections to, for example, email servers within your network, and then use your email server to send spam out, or do whatever it is they want to. And they can have a persistent connection to a remote attacker who's got now persistent access to your machine, essentially using your machine like a proxy into your network. So, frightening stuff.
