Slashdot Log In
Kaminsky's DNS Attack Disclosed, Then Pulled
Posted by
Soulskill
on Mon Jul 21, 2008 06:00 PM
from the can-of-worms dept.
from the can-of-worms dept.
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak."
Reader Time out contributes a link to coverage on ZDNet as well.
Related Stories
[+]
Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
Submission: Kaminsky's DNS Attack Disclosed, Then Pulled by Anonymous Coward
[+]
Attack Code Published For DNS Vulnerability 205 comments
get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."
[+]
Patch DNS Servers Faster 145 comments
51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.
[+]
Apple Still Has Not Patched the DNS Hole 296 comments
Steve Shockley notes an article up at TidBITS on Apple's unexplained failure to patch the DNS vulnerability that we have been discussing for a few weeks now. "Apple uses the popular Internet Systems Consortium BIND DNS server, which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date."
[+]
DNS Poisoning Hits One of China's Biggest ISPs 86 comments
Support Code writes "ZDNet's Zero Day blog is reporting that a DNS server of one of China's largest ISPs has been poisoned to redirect typos to a malicious site rigged with drive-by exploits. The DNS poisoning attacks are affecting customers of China Netcom (CNC) and are using a malicious iFrame to launch exploits for known vulnerabilities in RealNetworks' RealPlayer, Adobe Flash Player and Microsoft Snapshot Viewer. In this interview with CNet, Dan Kaminsky confirms that attacks are definitely going on in the field."
[+]
DNS Inventor Tackles Flaw 101 comments
nk497 writes "Dr Paul Mockapetris is looking to fix the flaws in the Domain Name System he helped invent. 'It was never meant to be the only security mechanism for naming data on the internet, but was intended for additional security measures to be added to it later.' The flaws, first uncovered by security researcher Dan Kaminsky over the summer, lets attackers redirect genuine URLs to malicious ones — a problem Mockapetris believes could be solved using digital signatures."
[+]
Technology: Kaminsky Bug Options Include "Do Nothing," Says IETF 134 comments
netbuzz writes "Meeting in Minneapolis this week, the Internet engineering community is debating whether to aggressively fashion and apply fixes for the so-called Kaminsky bug in the DNS discovered this summer, or to simply let its threat stand as motivation for all to move with greater speed toward DNSSEC, which is considered the best long-term security solution. Problem with the latter approach is that DNSSEC has been in the works for a decade already, no one is confident it will be universally embraced, and the Kaminsky flaw is causing real problems today.
[+]
Technology: DNSSEC Implementation Held Up By Tech Delays 57 comments
Jack Spine writes "VeriSign has said that the main obstacle to DNSSEC implementation has been technical delays. The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC, according to VeriSign vice president of naming services Pat Kane. Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory. The problem of DNS cache poisoning was thrown into sharp relief by researcher Dan Kaminsky last year."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The push for DNSSec (Score:5, Interesting)
Kinda makes you wonder what they're getting out of it.
Re:The push for DNSSec (Score:5, Funny)
Parent
Re:The push for DNSSec (Score:5, Funny)
Fame? Notorioty? Unstoppable attractiveness to women?
Hey, you all are laughing now, but I tell you, there's a whole throng of us women just waiting for the right guy to secure our DNS!
Parent
Re:The push for DNSSec (Score:5, Funny)
Whereas us lesbians can secure our own DNS just fine, but would still prefer to have some nice girl do it for us. :)
Parent
Re:The push for DNSSec (Score:5, Funny)
Parent
Hottest? (Score:5, Funny)
This is sad.
Parent
Re:Hottest? (Score:5, Funny)
Parent
Re:Hottest? (Score:4, Funny)
Parent
Re:The push for DNSSec (Score:4, Funny)
Parent
Re:The push for DNSSec (Score:5, Informative)
Sorry for the threadjack (thank you for ensuring that 99% of the slashdot crowd is looking intently upon the thread), but here's soem relevant info that should be near the top.
As of the time of my post, the original text of the article (at least I -THINK- it's the original text) is available here [buanzo.com.ar]
Slashdotters may resume the lesbian thread now, thank you for your time (hope I didn't kill anyones chubber).
Parent
Re:The push for DNSSec (Score:4, Funny)
On the contrary...
Parent
Re:The push for DNSSec (Score:5, Insightful)
DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).
Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.
DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.
Parent
Re: (Score:3, Interesting)
Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.
Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.
Re:The push for DNSSec (Score:5, Interesting)
Not to be paranoid, but the argument of "no-one can do this" is often weak in the light of it being governments or intelligence agencies who are trying to mess with your internet access.
Is he scared of his government?
Or concerned about what his government may be doing to others in the world?
The problem is not necessarily on the "some attacker half way across the world on another AS", but may be much closer to home.
Parent
Re: (Score:3, Interesting)
To be blunt, "the government" can crack your DNSSEC keys as well.
LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.
Where is your god then?
Re:The push for DNSSec (Score:5, Insightful)
BGP routes are filtered when they're exchanged between eBGP routers. If you don't filter, you're an idiot. This I agree with.
You're not talking about BGP route filtering, though; you're talking about some kind of reverse path filtering (making sure that a route to the source address exists on the interface that you received the packet from). In practice, you almost never do this on BGP routers, as RPF makes some (somewhat naive) assumptions about the symmetry of Internetwork traffic.
Most people who have some kind of RPF deployed have it on a customer-facing device, as you generally only have one route per customer (and can make assertions about traffic NOT coming via that route, AND traffic COMING via that route.)
That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.
Parent
Re: (Score:3, Insightful)
Actually, for multihomed sites it's even easier.
Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.
In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render
Re:The push for DNSSec (Score:5, Informative)
It's a hard call in some cases. There's an argument that most (any?) multihomed customers should be able to send packets asymmetrically. That said, nobody with even half a brain should be running a NAS/LNS with single-homed customers WITHOUT RPF, although the (admittedly, in .au) number of people i've crossed paths with who are doing it wrong is staggering.
Conversely, if i'm peering with you and six other guys, and happen to be carrying traffic to your network (but not advertising a route back to some of MY peers, for e.g. traffic engineering reasons) across a given link, you have no business dropping that traffic.
RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.
Parent
Re: (Score:3, Informative)
BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.
This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web
I've been deeply worried (Score:4, Funny)
A: Because it breaks the flow of a message (Score:5, Funny)
Parent
Re:A: Because it breaks the flow of a message (Score:5, Insightful)
Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.
Parent
Subject lines tell me how to mod (Score:3, Interesting)
Interesting you say that. Whenever I get mod points, the subject line is one of the things I look at to see where to grant my mod points.
Reading every posting to see which ones are worth modding up would be too much work. I look for replies in a thread where the author has taken
Doxpara.com also updated. (Score:5, Informative)
Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated. [doxpara.com]
In case of Slashdotting, here's the full update;
Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.
You can play with the search query (Score:3, Interesting)
Use Google search snippets to expose little details of the document...
I'm guessing some persistent folks will eventually be able to piece the bits together.
i.e. see how much you can piece together from the summary with the result shown by google. Adjust your search by including unique words towards the end of the snippet in one search to try to get the text that follows.
1 [google.co.uk]
2 [google.co.uk]
21 Jul 2008 ... One of them involves mucking about with the QID in DNS packets and the ... The QID is the only thing protecting the DNS from Mallory (me). ...
21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then thereâ(TM)s that other set of ...
21 Jul 2008 ... Then thereâ(TM)s that other set of DNS vulnerabilities. ... Then letâ(TM)s set up an evil server with it, and register it as EVIL.COM. ...
21 Jul 2008 ... EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the .... EVIL.COM and slipping strychnine into his ham sandwich, ...
21 Jul 2008 ... This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when ...
21 Jul 2008 ... Which sends back a response with an unexpected (evil) Additional RR. ... Weâ(TM)ll come back to it. Alice has an advantage in the race, ...
21 Jul 2008 ... Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Aliceâ(TM)s advantage is not insurmountable. ...
21 Jul 2008 ... Aliceâ(TM)s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. ..
21 Jul 2008 ... Frequently, that server has to go ask another, and so on. .... And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! ...
21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW .... COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! ...
21 Jul 2008 ... Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. ... Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. ...
21 Jul 2008 ... COM was: 6.6.6.0. Every resolver that points to that name server will now ... COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact ...
That's it (Score:4, Funny)
The significance of the attack... (Score:4, Informative)
...is not just that you can race legit DNS servers for legit queries, is that you can request recursive resolution for bullshit DNS servers, while submitting fake answers WITH malicious informational records that let you poison second-level domains. So by requesting xxjk3j.google.com while submitting your own coolly crafted answer, you can make the victim DNS use YOUR DNS as authoritative for the future google.com replies.
THAT is the significance of the attack. THAT is what matasano pulled.
Re:The significance of the attack... (Score:4, Insightful)
Posted it on: http://rudd-o.com/archives/2008/07/21/the-dns-fiasco/ [rudd-o.com]
Parent
Better Speculation (Score:5, Informative)
Alright, so I'm not even someone who does DNS/networking stuff even for a hobby (just a math grad who skimmed the RFCs once or twice) so if I can figure this out from what's up now then any competent bad guy can as well.
Anyway my guess is that it involves a combination of the birthday attack and the request for multiple nonexistant nameservers. That is as the attacker you trick poisontarget.com into trying to resolve the following locations.
AAA.google.com ....
AAB.google.com
XXX.google.com
Now you forge a single response packet that works for all of these requests and send many different copies with different TXIDs. Thus to succeed you need only hit ONE of the TXIDs used in the real requests.
In these forged responses you also have a forged glue record (as suggested in some of the links) which gives you control of lookups for all of google.com at poisiontarget.com after a single success.
Then again maybe I missed something basic which means this doesn't work.
It's okay... (Score:3, Interesting)
GoogleReader caching FTW (Score:5, Informative)
y ecopeland
0.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
1.
Pretend for the moment that you know only the basic function of DNS -- that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob's unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice -- once when he is called to the counter to place his order and again when he's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions.
If you've got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It's called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
First, QIDs.
Bob's a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won't match. The QID is the only thing protecting the DNS from Mallory (me).
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here's a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded --- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going.
Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob's request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.
But there's a bunch more problems here:
*
If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*
If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she'll break the RNG and be able to predict its outputs.
*
16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008.
Your computer's resolver is probably a stub. Which means it won't really save the response. You
I have the whole thing reasonably well formatted (Score:4, Informative)
See http://thefrozenfire.com/data/dnspoisoning.html [thefrozenfire.com] for the whole deal, without the pastebin RAW formatting ;)
Full Text of Article Here (Score:3, Informative)
Okay quick question. (Score:3, Interesting)
Okay, I don't dabble deep in DNS but I have a few quick questions. The RR thing is nasty because sub-domain authority implies domain authority. That's just silly and I'm stunned that something so simple is still true. I imagine there are a million and one "good" reasons for it, but it appears to be a gaping hole that could easily have been removed.
However, on the "let's spoof a DNS response" front - if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end? This is the solution surely, even if you can send millions of packets with incorrect QID's and similar identifiers at a DNS server, like any other service at some point it has to say "you're trying to be naughty" and blacklist any packets, sound an alert, get the upstream filters to block such traffic etc. (This is, of course, assuming that there are at least some systems in place to stop or limit source-IP forgery in the first place). It might even be a good idea, at this point, for such servers to not trust their data, and constantly compare their copies with those available from the nameservers. If "fluctuation" of the data (between real and spoofed responses) is detected, then sound an alert on that domain.
How many responses does an average DNS server get that are invalid because of purely accidental causes (e.g. corrupted packets, mis-configured routers etc.)? Surely it's so few that it can instantly blacklist any suspicious activity, like trying to poison recursive caches in this manner.
I imagine that most home routers are extremely stupid and can't stop such things because they rely almost exclusively on the ISP's DNS servers to do their job and a flood of fake packets will not be picked up (this is, however, one of the reasons that I've always used "DMZ" or PPP half-bridge settings on ADSL routers to throw all external packets towards a real server rather than relying on some VxWorks firmware to handle IP-based attacks). But the servers? They *should* be filtering, cleansing and blacklisting packets even before you get into whether they have the most up-to-date patches, and a security fix to enhance the randomness of X etc.
It seems that the DNS servers are too trusting of "correct" packets that come as part of packet-floods of incoming data that is *obviously* false. DNS clients accepting data appearing to come from a trusted host is not nice, I agree, but recursive DNS servers should know better.
Or have I missed something incredibly obvious here?
I don't really care because my ISP wasn't vulnerable to this attack when I first tested it about 10 minutes after the first posting about its potential on the blog, and I'm pretty sure that they wouldn't have had any more advanced warning than anyone else.
Having said that, the DNS servers provided by LGfL's broadband supplier are, apparently, vulnerable. (London Grid for Learning, a London-wide schools extranet that virtually every London school, of which there are hundreds, use for their Internet connection, DNS servers, content filtering, etc. as well as their external content host). But, knowing LGfL and the way UK IT operations that are in any way involved with government work, that's not surprising at all.
Re:I got this much (Score:5, Informative)
Found this while google screwing. Someone got it!
http://pastebin.ca/1078776 [pastebin.ca]
1.
Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
2.
from Matasano Chargen by ecopeland
3.
0.
4.
5.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
6.
1.
7.
8.
Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
9.
10.
Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.
11.
12.
If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
13.
2.
14.
15.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
16.
17.
First, QIDs.
18.
19.
Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
20.
21.
It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).
22.
23.
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. M
Parent
Re: (Score:3, Funny)
From reading the f'ing article, I now know that I should never try to resolve WWW.VICTIM.COM [slashdot.org].
Re:Here's the whole post (Score:5, Informative)
Ok, here's the gist: It's difficult to spoof a response for the right domain name, because of the random query IDs. You need too many requests and caching servers don't usually ask for the same name very often. But it's easy to get a caching server to ask for many different names in a subdomain, so do that and send your fake answers. One of them is going to get accepted sooner or later. Include spoofed glue for the real subdomain (www...) in your answers. Because the glue is for the same domain, it is accepted. Tadaa, poisoned DNS.
Parent
Even worse... (Score:3, Interesting)
Re: (Score:3, Informative)
Well that would work, although since VeriSign's "SiteFinder" stunt some DNS servers (including bind) have an option to denote a zone as being "delegation only" zone, which would stop this attack from working. I don't know how widespread use of this option would be, though.
Assuming it's not, than poisoning .com would make it much easier: with one successful attack you could poison dozens of popular domains.
What could be interesting is combining this attack with zombies -- that way you don't need to trick a u
Re:Even worse... (Score:4, Informative)
Parent
Re: (Score:3, Informative)
You don't need the address for the NS server as you're getting a result already. If you didn't ask for the information then it shouldn't be in the reply - if it is just discard the entire packet as bogus and keep listening for the real one.
Re: (Score:3, Informative)
Just another example of how you can't erase knowledge once it's been disseminated.
BTW, the method of attack really is quite clever. And pretty trivial.
Re:No details? (Score:5, Funny)
... it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post.
They fail. If they've removed it with no intention of making it available again it should be 410 Gone [w3.org], not 404 Not Found [w3.org]. Am I the only person who reads the HTTP spec? It's not exactly hard to understand...
Parent
Re:No details? (Score:4, Funny)
Actually you have the answer within your own post. As you said "If they've removed it with no intention of making it available again". According to the spec "If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead." It is quite possible that the page was only taken down temporarily, with the intent to restore it on the official disclosure date. So use of code 410 which would be in violation of the spec, and 404 the proper reply code.
Tag: geek humor
-
Parent
Re:Ridiculous armwaving... (Score:5, Informative)
Parent
Re: (Score:3, Informative)
The responsible thing at this point would be for the vulnerability to be published. By now the bad guys surely already have the details and are in the process of selling exploit code to each other.
While the pro-security community is being left in the dark.
He may have considered new modes of attacks that had not yet been concerns.
For example... phishing wasn't such an issue back in the earlier 1990s when the original weakness was noted.
A DNS hijacker attempts to poison a particular domain on a DNS c
Re: (Score:3, Informative)
The pro-security community has always been safe; DJBDNS and derivatives are immune to this attack and always have been.
Re:Ridiculous armwaving... (Score:4, Informative)
Just because it has "security" in the name, doesn't make it secure, Alice.
The patches make it clear that ADDITIONAL-section processing is to blame- just as it has been numerous times over the last twenty or so years. DJBDNS doesn't do ADDITIONAL-section processing and so it immune. BIND tries to do a lot of hand-waving to continue doing ADDITIONAL-section processing even though it's clearly a bad idea- in order to protect egos.
So the guy who rejects advise from the security community on src port randomization and ADDITIONAL-section handling; the guy who has had countless vulnerabilities, and the very same guy who has lied about BIND8 and BIND9's complete rewrites, that's the guy you're taking at his word regarding the security of DNSSEC?
By the way, DJBDNS supports all RR types- including those that haven't been invented yet, simply because it has an extensible data format.
Parent
Re: (Score:3, Informative)
Re: (Score:3, Informative)
That is different - that's just advertising and silliness off the way the wildcard matching works for WHOIS.
The issue is when you can force the target to resolve blah.google.com to poison www.google.com and then include a glue response for www. in with the blah. response which is then accepted because the domains match at to the right of that level.