Slashdot Mirror
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."
But it's true, most people loooove that javascript. I can't stand it, myself, and only enable it when I absolutely have to.
You should probably consider upgrading from a 486.
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?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
As an example, let's assume that one of those shaky "Your the 999,999th visitor" ads pins the CPU at 100%. Unless you only one web browser window/tab open (if you read
Dual core systems could help... but it won't be long before an SMP process can do the 100% pinning as well.
P.S. If you hear whooshing, you probably want to wear eye/head protection.
Firefox should kill any bad javascript automatically.
If it hogs cpu then it will wait for a period of time then ask you what to do with it.
For now, bind9 does not support this. See the relevant thread.
If you read the original article, you will note that they generated exploit stats by utilizing an ad network. You don't need to visit a "bad" website, you just need a "bad" ad while visiting a normal website. Cool! What server do you use, and how did you configure it to do this?
OpenDNS ( http://www.opendns.com/ ) works pretty well. I typically go internal cache, external ISP, openDNS on my systems. Keeps Windows boxes in line, especially.
-theGreater.
1) run your own nameserver
2) use a new subdomain for every request
3) ???
4) profit
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Change dom.max_script_run_time to a smaller (or larger) number of seconds.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON