DNS Rebinding Attacks, Multi-Pin Variant

Morty writes "DNS rebinding attacks can be used by hostile websites to get browsers to attack behind firewalls, or to attack third parties. Browsers use "pinning" to prevent this, but a paper describes so-called multi-pin vulnerabilities that bypass the existing protections. Note that, from a DNS perspective, this is a "feature" rather than an implementation bug, although it's possible that DNS servers could be modified to prevent external sources from being able to point at internal resources."

Fox?

Is this a new FOX special?

We are now checking your browser...

We are now checking your browser for DNS rebinding vulnerabilities.

Not without Javascript you aren't!

But it's true, most people loooove that javascript. I can't stand it, myself, and only enable it when I absolutely have to.

Re:Ask Slashdot: Pause a running Javascript

CPU-sucking JS animation loop.. Any ideas?

You should probably consider upgrading from a 486.

In about:config

Change dom.max_script_run_time to a smaller (or larger) number of seconds.

Re:We are now checking your browser...

We are now checking your browser for DNS rebinding vulnerabilities.

Not without Javascript you aren't!

Heh, my boy, you just summed up the Web's great affliction in a nutshell.

This particular exploit vector is especially troublesome because turning off the ability to point a name at multiple IPs would break a large part of the Internet. But it wouldn't be an issue for web browsers if we didn't see the need for the Web to be dynamic and interactive. Dynamism and interactivity are really not built into HTTP. It would be more accurate to say that HTTP was designed to be just the opposite.

Website designers and software makers have been trying to turn the Web into a collection of desktop applications since about the time the Web was invented. This runs counter to what Tim Berners Lee intended. HTTP is stateless for a reason. I honestly don't think he made HTTP stateless because he envisioned the havoc that malicious websites could cause, but the principle of agnosticism (i.e. providing content without knowing anything about the requester's capabilities) that's implicit in the protocol is inherently more secure than the desire of many to make websites into remotely-accessed desktop apps.

Unfortunately, this particular horse bolted from the barn in the earliest days of the web, and there's no easy way to get it back in. A wise web developer will nonetheless read and understand the HTTP protocol. Its statelessness and agnosticism can be strengths when considered in the proper light....

...Yeesh, that last sentence makes me feel like Yoda counselling young Luke.... 8^/

Flashback

If you haven't read the article, I'll summarize it for you: its another critical vulnerability in java/javascript. The sandboxed script in the web browser alternately makes GET and POST requests the "same" server with each POST containing the contents of the prior GET... Only the IP address associated with the server's hostname keeps alternating between a server inside your firewall and the attacker's real server outside it. Oops.

At times like these, I tell a story about 1988 when I wrote a BBS terminal emulator for the Commodore 64 which cleverly allowed the BBS to send and run new code on the caller's machine. Another gentleman who didn't much like me noticed the feature and arranged for a number of BBS systems to execute the code at location 64738: system reset.

There is no safe way to run complex sandboxed code on a user's PC and no safe way to allow sandboxed code access to the network. Either you trust the source of the program and let it do what it needs to do, or you don't trust it and don't allow it to run on your PC at all. How many of these vulnerabilities are we going to run through before we finally figure that out?

So where's the beef?

Is this a real threat? If so, how severe is it and how much effort must be expended to fix it?

pinning

What is "pinning" you may ask? From the linked pdf article, it's the caching of DNS lookups:

A common defense [for DNS rebinding attacks] implemented in several browsers is DNS pinning: once the browser resolves a host name to an IP address, the browser caches the result for a fixed duration, regardless of TTL.

But apparently this can be subverted with browser plug-ins, which have a separate "pin database".

Wow. Really amazing...

Did you read the abstract?

It's well written, and has lots of examples of exactly how this vulnerability can be exploited. In short, I could probably sit down and in a single afternoon, write a set of scripts for a webserver and DNS server, post it on a $30/month "virtual host" server, and take out an ad for $100, and end up with a powerful DDOS attack on my host of choice.

All done in less than 24 hours.

Screw the "cyber-terrorists" in Russia, this is REALLY BIG, and is one of many REALLY BIG problems that can be exploited! And the fact that we're here, reading and posting here, is demonstration of the fact that the many vulnerabilities of the Internet are NOT being exploited to anything like their real potential...

So think about it: while we here at Slashdork might know as many as a dozen exploitable vulnerabilities like this one that would be nearly impossible to close, how many of us have actually DONE any of these?

And that, folks, is why security will NEVER be 100% technical, and there will always be a social mechanism involved - there really is an amazing amount of security in simply knowing that if you do, really bad stuff could really happen to you.

Not will happen, not even likely to happen. Just could happen is enough.

Besides, there's a funny paradox at work here: those who have the skills to pull off an attack like this also have the skills to earn an income that's legitimate, without all the risks. I'm tempted from time to time to make use of my skills in a bad way when I think about how easy it is for me to wreak havoc - but the risks of doing so have always stopped me far short. I enjoy my day job, since its nature is fundamentally altruistic. So I'm harmless.

As a case in point, I was chatting with my flight instructor and a staff member at the local FBO (an airport for small planes) and the staff member mentioned something about an annoying ex-boyfriend who kept calling her.

Without thinking, I mentioned the possibility of writing a quick script to send him 100,000 text messages that would say "Leave me the freak alone!". I imagined a two-line script that would take all of about 10 seconds to write, and I could use the hotspot at the FBO to do it.

100,000 isn't even a particularly big number for me - I routinely deal with datasets in the millions of records - so it didn't really occur to me right away what a blow that would be. But 100,000 times 5 cents adds up to $5,000 worth of text messages! And I'm sure that his cell company would limit the number of messages to be sent, but it's pretty certain that quite a few WOULD get through.

It was surprising to me what a staggering blow this would be. I was actually a bit embarrassed at having mentioned it.

Don't underestimate the power of social mechanisms to ensure our security!

Seems they forgot a few things

I did RTFA, and it seems to me they made an oversight in the fact that most ISP/corp sites use a caching DNS server. A repeated lookup to the same domain will return the cached result. Their POC depends on the client doing another lookup and getting a different result. This would attack would depend on the client being able to the attacker's DNS.

Now they do say that the attacker DNS returns more then one A record for each request. But they are ignoring the fact that the serial number of the zone would have to change for a refresh to not get cached. And even if they did create a new zone record for each visit, with the target's IP (seems unlikely), all the servers back to the client would need to respect it. Again, my ISP Qwest, has a bad habit of ignoring the TTL in my zone files.

example 1:

target lookup (T0) -> www.attacker.com
www.attacker.com -> 192.168.0.1

target lookup (T1) -> www.attacker.com
ISP/site cached reply -> 192.168.0.1 (attack failed)

Example 2:
target lookup (T0) -> www.attacker.com
www.attacker.com -> 192.168.0.1

target lookup (T1) -> www2.attacker.com
attacker's ISP cached reply -> 192.168.0.1 (attack failed again)

The only case I can see this working if the zone records contain an IP for some third party source that they want to try and abuse. So say www2.attacker.com points to 10.0.0.1 and that number is static in their zone record. Which appears to be much less efficient zombie scan with IP spoofing.

And finally, this is all dependent on the attacker tricking the client into loading Flash/Java/Javascript from their box. Another win for noscript.

Backup DNS Servers?

Where can I find lists of DNS servers I can use instead of my cablemodem's default from my ISP? Servers that will let me point at them, that are fast and reliable.

There are far easier ways to exploit people

There are plenty of other exploits that allow far greater control over all the IE users on the Internet than this. It still relies on the user going to a malicious website in the first place. If you can draw users to that web site, you might as well just fully exploit their browser and get some real code on the machine, then use it rather than bouncing crap around with javascript and constantly changing DNS entries.

And considering that I've already (after reading the article mind you) changed my DNS servers to not return results matching our internal address range for lookups resolved from external hosts, its ever less useful.

I'm glad they've brought this up, and its a hard one to really secure in modern browsers do to the cross-plugin problems, but its certainly not something that worries me. Not nearly as much as the users I have that click on the stupid 'You have a postcard from a neighbor' spams that always manage to get through our spam filters.

We need this, now!

... so that we can redirect links to the paper explaining all to a server that isn't slashdotted...

Multi-pin?

Multi-Pass!

(Sorry, it was the first thing that came to mind.)

Re:Bind9

For now, bind9 does not support this. See the relevant thread [google.com].

Re:The best defense:

Slashdot has javascript?
Can't say I've noticed any loss of functionality, but then I wouldn't, would I.
I run in LightHTML mode with Web Developer's "Disable Page Colours" enabled.

Black & White for me baby!