Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Kaminsky's DNS Attack Disclosed, Then Pulled

Soulskill posted more than 6 years ago | from the can-of-worms dept.

Security 281

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.

cancel ×

281 comments

Sorry! There are no comments related to the filter you selected.

The push for DNSSec (4, Interesting)

QuantumG (50515) | more than 6 years ago | (#24281743)

Kinda makes you wonder what they're getting out of it.

Re:The push for DNSSec (4, Funny)

dintech (998802) | more than 6 years ago | (#24281785)

Fame? Notorioty? Unstoppable attractiveness to women?

Re:The push for DNSSec (5, Funny)

snowgirl (978879) | more than 6 years ago | (#24282081)

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!

Re:The push for DNSSec (0)

Anonymous Coward | more than 6 years ago | (#24282169)

From Russia, with love!

Re:The push for DNSSec (5, Funny)

geekgirlandrea (1148779) | more than 6 years ago | (#24282301)

Whereas us lesbians can secure our own DNS just fine, but would still prefer to have some nice girl do it for us. :)

Re:The push for DNSSec (5, Funny)

Yeff (1108747) | more than 6 years ago | (#24282377)

Hottest. Slashdot Thread. Ever!

Hottest? (5, Funny)

Rudd-O (20139) | more than 6 years ago | (#24282389)

This is sad.

Re:The push for DNSSec (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24282811)

tip: some girls are "lesbian" to turn on guys. The others are fat, ugly, or look like men.

Re:The push for DNSSec (4, Funny)

Element119 (1237726) | more than 6 years ago | (#24282451)

if only i were a female, i'd be a lesbian for sure.

Re:The push for DNSSec (5, Informative)

neomunk (913773) | more than 6 years ago | (#24283299)

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).

Re:The push for DNSSec (0)

Anonymous Coward | more than 6 years ago | (#24281797)

Secure DNS hopefully, so that we can put the DNS forging ISPs and DNS "services" behind us.

Re:The push for DNSSec (4, Insightful)

gatekeep (122108) | more than 6 years ago | (#24281987)

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.

Re:The push for DNSSec (2, Interesting)

mrsbrisby (60242) | more than 6 years ago | (#24282599)

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 (4, Interesting)

0xygen (595606) | more than 6 years ago | (#24282759)

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.

Re:The push for DNSSec (4, Insightful)

Michael Hunt (585391) | more than 6 years ago | (#24282975)

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.

Re:The push for DNSSec (1)

0xygen (595606) | more than 6 years ago | (#24282727)

Not to state the obvious, but possibly a secure DNS system?

Although, it has been mentioned that there are a number of competing similar commercial solutions available from the big routing / switching manufacturers. However then you would expect them to want to delay DNSSec as much as possible.

No details? (1)

TobyMurray (1330191) | more than 6 years ago | (#24281783)

What sort of tease posts this story without the details contained in the pulled Matasano post?

Re:No details? (2, Informative)

flosofl (626809) | more than 6 years ago | (#24282001)

I still have it in my RSS reader. I sent the others in my security group the link referenced in the feed, but it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post. It's a bit late for that, as I'm sure I'm not the only one who subscribes to their blog.

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? (1)

neomunk (913773) | more than 6 years ago | (#24283159)

You still have the text? CopyNPaste FTW!

For the mod points too.. I'm sure some kind hearted (or ruthlessly evil, given the content) soul will mod you informative for your troubles. I would, had I not precluded my chance to do so by posting this request.

Re:No details? (4, Funny)

NickFitz (5849) | more than 6 years ago | (#24283171)

... 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...

Here's the whole post (1, Informative)

Anonymous Coward | more than 6 years ago | (#24281811)

Re:Here's the whole post (0)

Anonymous Coward | more than 6 years ago | (#24281873)

Even google scrubbed it from the cache .. maybe there are enough people out there unpatched that this is still a security risk.

Re:Here's the whole post (1)

Tony Hoyle (11698) | more than 6 years ago | (#24281951)

Doesn't sound that complex to fix - just make the checking for additional records a lot more stringent so you can't poison WWW.DOMAIN.COM within a reply to AAAAA.DOMAIN.COM

Re:Here's the whole post (1)

snowgirl (978879) | more than 6 years ago | (#24282207)

Doesn't sound that complex to fix - just make the checking for additional records a lot more stringent so you can't poison WWW.DOMAIN.COM within a reply to AAAAA.DOMAIN.COM

Won't work... the problem is that you're setting NS1.VICTIM.COM while searching for WWW.VICTIM.COM

If you implement the fix you fix the bug, but you just threw out the baby with the bathwater... now everyone needs to double their DNS requests to find out what the address for the NS server is.

Re:Here's the whole post (2, Informative)

Tony Hoyle (11698) | more than 6 years ago | (#24282575)

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:Here's the whole post (1)

0xygen (595606) | more than 6 years ago | (#24282661)

Yes, I agree - reading the article the resolver should only allow responses which are necessary glue for the provided response through and drop all other RRs.

Re:Here's the whole post (3, Funny)

davester666 (731373) | more than 6 years ago | (#24281997)

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 (5, Informative)

Anonymous Coward | more than 6 years ago | (#24282019)

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.

Re:Here's the whole post (1)

mysidia (191772) | more than 6 years ago | (#24282527)

Ok.. if your DNS cache is willing to accept that glue despite the fact a better entry should already be cached, sure.

I wonder if based on that concept a bad guy could try to do poison lookups for millions of TLDs (most of which don't exist). And once successful include spoofed glue for "."....

Re:Here's the whole post (0)

Anonymous Coward | more than 6 years ago | (#24283459)

Yep. this is something I was talking about for a long time (but noone listens). No DNS server should EVER accept any answers to anything it has not explicitly asked for. The whole idea of these "apropo" glue records etc is ridiculous and ripe for exploit just like that.

Re:Here's the whole post (0)

Anonymous Coward | more than 6 years ago | (#24282195)

After reading the entire article, my point of view is that assholes that go to delis and order a ham sandwich deserve their strychnine.

I am hopeful that Mallory will succeed in poisoning Bob.

(Whatever happened to Mallory anyway, she was sort of cute, though I would have figured it was Alex who would do the poisoning in that family.)

Re:Here's the whole post (1, Redundant)

spyder-implee (864295) | more than 6 years ago | (#24283023)

Reliable DNS Forgery in 2008: Kaminsky's Discovery from Matasano Chargen by 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 don't want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn't know everything. It can't, and shouldn't, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this "recursion". Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can't poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then there's that other set of DNS vulnerabilities. These require you to pay attention in class. They haven't really been talked about since 1997. And they're hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I'm speaking of course of RRset poisoning. DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly. I just described a QID attack that poisons the name server's cache. This attack requires speed, agility and luck, because if the "real" answer happens to arrive before your spoofed one, you're locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server's cache anyway. To explain it, I will have to explain more about the format of a DNS packet. DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are: * Answer RR's, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4) * Authority RR's, which tell resolvers which name servers to refer to to get the complete answer for a question * Additional RR's, sometimes called "glue", which contain any additional information needed to make the response effective. A word about the Additional RR's. Think about an NS record, like the one that COM's name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That's good to know, but it's not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1. Now, let's party like it's 1995. Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil -- an extra Additional RR with bad information. Then let's set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server. Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR. If Alice's cache honors the unexpected record, it's 1995 --- buy CSCO! --- and you just poisoned their cache. Worse, it will replace the "real" data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also "found out" where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast. 4. It's not 1995. It's 2008. There are fixes for the attacks I have described. Fix 1: The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won't honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess. Fix 2: The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they're asking where WWW.VICTIM.COM is, they're not interested in caching a new address for WWW.GOOGLE.COM in the same transaction. Remember how these fixes work. They're very important. And so we arrive at the present day. 5. Let's try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0. This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we're going to be clever (sneaky). Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice's answer is NXDOMAIN, because there's no such name as AAAAA.VICTIM.COM. Mallory has an answer. We'll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Alice's advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn't just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

FAIL (0)

Anonymous Coward | more than 6 years ago | (#24283641)

You fail at life.

FTA: Please... (1)

cez (539085) | more than 6 years ago | (#24281817)

Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days.

Give an evil genius some credit, 2 hours tops and half that time's spent reading /., most of the other half on other evil online things; like pr0n and goatse.

Isn't it okay to post by now anyways? (1)

perlchild (582235) | more than 6 years ago | (#24281819)

I mean they coordinated this massive "patch" that's supposed to fix it. Now that it's fixed, it's not a secret anymore, or it this one of those cia secrecy where the reputation of those involved is at stake?

Re:Isn't it okay to post by now anyways? (1)

mad_psych0 (991712) | more than 6 years ago | (#24281863)

The recent availability of the patch is hardly reason to believe that everyone's already deployed it, which is I'm sure why there's still so much secrecy surrounding this.

Re:Isn't it okay to post by now anyways? (1)

jd (1658) | more than 6 years ago | (#24282475)

As long as it remains secret, many shops will hold off patching their DNS server, assuming the problem to have been blown out of proportion.

Re:Isn't it okay to post by now anyways? (1)

cez (539085) | more than 6 years ago | (#24281869)

I've heard of certain problems with at least IIS 6's DNS patch breaking certain servers [yeah yeah citations :]... just curious anyone with links to a "certified" fix?

Re:Isn't it okay to post by now anyways? (1)

Vancorps (746090) | more than 6 years ago | (#24282291)

How would patching a DNS server break a web server? My guess is that someone was blaming the patch for a problem that they created themselves.

"Certified" fixes for MS products come from Windows Update or in certain extreme circumstances you have to request the file such as the case with the Exchange 2003 issue with calendar updates to Exchange 2007 systems. The dates get mangled so the server is unable to read further updates. Just an example from my world.

It is quite rare these days unless you're doing something supremely funky that a patch will break your stuff. Doesn't mean you shouldn't test of course.

Re:Isn't it okay to post by now anyways? (0)

Anonymous Coward | more than 6 years ago | (#24283367)

Microsoft DNS is a house of cards.

I've been deeply worried (3, Funny)

smitty_one_each (243267) | more than 6 years ago | (#24281841)

...about these Monsanto DNA attacks for some time...

A: Because it breaks the flow of a message (5, Funny)

DNS-and-BIND (461968) | more than 6 years ago | (#24281895)

Q: Why is starting a post in the Subject: line annoying?

Re:A: Because it breaks the flow of a message (1)

smitty_one_each (243267) | more than 6 years ago | (#24281935)

Fair enough.
Possibly if they defaulted the top-level responses, starting the thought in the subject line would be less tempting.

Re:A: Because it breaks the flow of a message (4, Insightful)

Koiu Lpoi (632570) | more than 6 years ago | (#24283019)

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.

Overkill (1)

Tubal-Cain (1289912) | more than 6 years ago | (#24283563)

Frankly, we should just do away with the subject line entirely.

Or /. could stop adding the Re:*'s for people and force them to type something.

Google Reader FTW! (0)

Anonymous Coward | more than 6 years ago | (#24281853)

i have matasano's blog in my google reader feed and the whole post is still available... very interesting article but i think it's better for Dan to fully disclose it than the matasano team

Doxpara.com also updated. (5, Informative)

gatekeep (122108) | more than 6 years ago | (#24281899)

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.

Been seeing this for a while (0, Offtopic)

Moblaster (521614) | more than 6 years ago | (#24281909)

nono:~ xxxxxxxxxxx$ whois google.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net/ [internic.net]
for detailed information.

GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM
GOOGLE.COM.YAHOO.COM.MYSPACE.COM.YOUTUBE.COM.FACEBOOK.COM.THEYSUCK.DNSABOUT.COM
GOOGLE.COM.WORDT.DOOR.VEEL.WHTERS.GEBRUIKT.SERVERTJE.NET
GOOGLE.COM.VN
GOOGLE.COM.UY
GOOGLE.COM.UA
GOOGLE.COM.TW
GOOGLE.COM.TR
GOOGLE.COM.SUCKS.FIND.CRACKZ.WITH.SEARCH.GULLI.COM
GOOGLE.COM.SPROSIUYANDEKSA.RU
GOOGLE.COM.SERVES.PR0N.FOR.ALLIYAH.NET
GOOGLE.COM.SA
GOOGLE.COM.PLZ.GIVE.A.PR8.TO.AUDIOTRACKER.NET
GOOGLE.COM.MX
GOOGLE.COM.IS.NOT.HOSTED.BY.ACTIVEDOMAINDNS.NET
GOOGLE.COM.IS.HOSTED.ON.PROFITHOSTING.NET
GOOGLE.COM.IS.APPROVED.BY.NUMEA.COM
GOOGLE.COM.HAS.LESS.FREE.PORN.IN.ITS.SEARCH.ENGINE.THAN.SECZY.COM
GOOGLE.COM.DO
GOOGLE.COM.COLLEGELEARNER.COM
GOOGLE.COM.CO
GOOGLE.COM.BR
GOOGLE.COM.BEYONDWHOIS.COM
GOOGLE.COM.AU
GOOGLE.COM.ACQUIRED.BY.CALITEC.NET
GOOGLE.COM

To single out one record, look it up with "xxx", where xxx is one of the
of the records displayed above. If the records are the same, look them up
with "=xxx" to receive a full display for each record.

>>> Last update of whois database: Mon, 21 Jul 2008 19:18:26 EDT

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
nono:~ xxxxxxxxxxx$

Re:Been seeing this for a while (1)

snowgirl (978879) | more than 6 years ago | (#24282255)

Only because someone marked it interesting.

This is not the same. The problem is sub-domains not super-domains.

Does going to your local University and registering mail.google.com.myuni.edu mean that you're going to get a lot of phishing? Yes, but only for people searching with myuni.edu as their default search domain. (likely, only on MyUni's internal network, and then only for people who aren't super-seasoned salt-cured security people who automatically type "mail.google.com." every time)

This problem is that in pining for xxxx.google.com you can potentially ADD information that "Hey! I know what mail.google.com is too!" Since the super-domains match up, the DNS servers would go "right then, update my cache."

Re:Been seeing this for a while (2, Informative)

loxosceles (580563) | more than 6 years ago | (#24282595)

Mod parent down for not understanding the vulnerability.

Re:Been seeing this for a while (2, Informative)

0xygen (595606) | more than 6 years ago | (#24282693)

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.

I got this much (2, Informative)

bluefoxlucid (723572) | more than 6 years ago | (#24281921)

I got this much and am working on extracting more but hitting a roadblock.

Matasano Chargen  Blog Archive  Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery. Well the cat is finally out of the bag. I suspected this was how the

the cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan ... One of them involves mucking about with the QID in DNS packets and
and the other requires you to know the Deep Magic. First, QIDs
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. 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). 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. 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â(TM)s response gets to your computer before the
legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where
where Mallory tells you youâ(TM)re going

Re:I got this much (5, Informative)

bluefoxlucid (723572) | more than 6 years ago | (#24281965)

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. 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â(TM)s response gets to your computer before the legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where Mallory tells you youâ(TM)re going.
    24.

    25.
            Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bobâ(TM)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.
    26.

    27.
            But thereâ(TM)s a bunch more problems here:
    28.

    29.
                    *
    30.

    31.
                        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.
    32.
                    *
    33.

    34.
                        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â(TM)ll break the RNG and be able to predict its outputs.
    35.
                    *
    36.

    37.
                        16 bits just isnâ(TM)t big enough to provide real security at the traffic rates we deal with in 2008.
    38.

    39.
            Your computerâ(TM)s resolver is probably a stub. Which means it wonâ(TM)t really save the response. You donâ(TM)t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesnâ(TM)t know everything. It canâ(TM)t, and shouldnâ(TM)t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this âoerecursionâ.
    40.

    41.
            Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory canâ(TM)t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.
    42.
            3.
    43.

    44.
            Then thereâ(TM)s that other set of DNS vulnerabilities. These require you to pay attention in class. They havenâ(TM)t really been talked about since 1997. And theyâ(TM)re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. Iâ(TM)m speaking of course of RRset poisoning.
    45.

    46.
            DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly.
    47.

    48.
            I just described a QID attack that poisons the name serverâ(TM)s cache. This attack requires speed, agility and luck, because if the âoerealâ answer happens to arrive before your spoofed one, youâ(TM)re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name serverâ(TM)s cache anyway. To explain it, I will have to explain more about the format of a DNS packet.
    49.

    50.
            DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:
    51.

    52.
                    *
    53.

    54.
                        Answer RRâ(TM)s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)
    55.
                    *
    56.

    57.
                        Authority RRâ(TM)s, which tell resolvers which name servers to refer to to get the complete answer for a question
    58.
                    *
    59.

    60.
                        Additional RRâ(TM)s, sometimes called âoeglueâ, which contain any additional information needed to make the response effective.
    61.

    62.
            A word about the Additional RRâ(TM)s. Think about an NS record, like the one that COMâ(TM)s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. Thatâ(TM)s good to know, but itâ(TM)s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.
    63.

    64.
            Now, letâ(TM)s party like itâ(TM)s 1995.
    65.

    66.
            Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil â" an extra Additional RR with bad information. Then letâ(TM)s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server.
    67.

    68.
            Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR.
    69.

    70.
            If Aliceâ(TM)s cache honors the unexpected record, itâ(TM)s 1995 â"- buy CSCO! â"- and you just poisoned their cache. Worse, it will replace the âoerealâ data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also âoefound outâ where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast.
    71.
            4.
    72.

    73.
            Itâ(TM)s not 1995. Itâ(TM)s 2008. There are fixes for the attacks I have described.
    74.
            Fix 1:
    75.

    76.
            The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus wonâ(TM)t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.
    77.
            Fix 2:
    78.

    79.
            The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if theyâ(TM)re asking where WWW.VICTIM.COM is, theyâ(TM)re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.
    80.

    81.
            Remember how these fixes work. Theyâ(TM)re very important.
    82.

    83.
            And so we arrive at the present day.
    84.
            5.
    85.

    86.
            Letâ(TM)s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.
    87.

    88.
            This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, weâ(TM)re going to be clever (sneaky).
    89.

    90.
            Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Aliceâ(TM)s answer is NXDOMAIN, because thereâ(TM)s no such name as AAAAA.VICTIM.COM. Mallory has an answer. Weâ(TM)ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.
    91.

    92.
            Aliceâ(TM)s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0!
    93.

    94.
            Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

Re:I got this much (1)

snowgirl (978879) | more than 6 years ago | (#24282273)

*GASP!*

It's like on the intartoobs nothing is ever gone once published.

It's true people, and well... be careful with what you post. INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

Re:I got this much (1)

bluefoxlucid (723572) | more than 6 years ago | (#24282509)

Yeah, it's there somewhere. Google's cache had the newer version, but their database had the full story. A few people had the full text in their RSS readers too. They dropped the ball.

Also, a girl? On Slashdot? Have we broken 20% yet? The nominal on IRC seems to be 3 boys for every girl, which is just about perfect for a lot of girls....

Re:I got this much (1)

Chris Burkhardt (613953) | more than 6 years ago | (#24283067)

INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

wow (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24281943)

only a handful of posts. i bet if this was about some faggot comic book shit it would be ten times as many. you know why? because the vast majority of slashfags are just a bunch of wannabes. they don't know shit unless it's in a fag comic book or a dungeons and dragons guide. fucking shitfucks. it's disgusting. homos are bitch queers who need their asses kicked.

Re:wow (0)

Anonymous Coward | more than 6 years ago | (#24282663)

they don't know shit unless it's in a fag comic book or a dungeons and dragons guide.

and your point is???

Re:wow (0)

Anonymous Coward | more than 6 years ago | (#24283615)

what? are you one of those fags that like to get pounded up the ass by your dungeon master? do you suck dicks thinking about clark kent? fag.

Everything about this flaw is being kept quiet (0)

Anonymous Coward | more than 6 years ago | (#24281981)

There were other issues regarding this patch that still have never seen the light of day, not even a note in passing.

In the hours after the initial vendor announcement and the following 2 days, the .com.au name servers were returning useless and corrupt answers.

I don't have any output from the issue any more, but I can make it up :P
eg. dig example.com.au NS
; ANSWER
(none)
; ADDITIONAL
(correct A records for the missing NS)

This meant that your normal resolver could not figure out who the MX was for com.au domains unless it still had the information about the NS servers was still in cache. Since I had just updated and restarted all the local named, this cache was gone. It did not show in non-production testing as I didn't check a specific country name server, just google/yahoo.

Did anyone run into similar issues or even know of any news or blog reports on this? It seems to have been completely swept under the carpet.

You can play with the search query (3, Interesting)

mysidia (191772) | more than 6 years ago | (#24282033)

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 ...

Re:You can play with the search query (1)

bluefoxlucid (723572) | more than 6 years ago | (#24282055)

Yep, that's how I got my copy. Then I found a pastebin in the middle of that junk that had the full text :)

Actually (2, Funny)

krkhan (1071096) | more than 6 years ago | (#24282053)

Well, as soon as he had posted that thing he got a Cease & Desist letter from MPAA for disclosing the intellectual property of Wachowski Brothers for The Matrix: Rebuttal. The movie was supposed to answer all the questions pertaining to the first movie and this attack was the secret way that Zion crafts used to hack into the Core. Of course, the Core refused to get its DNS servers patched because they didn't need anyone's help.

Ridiculous armwaving... (1, Informative)

actionbastard (1206160) | more than 6 years ago | (#24282061)

and running around the room screaming that the sky is falling.
An article over at the Register [theregister.co.uk] , states that this 'vulnerability' was discovered three years ago by Ian Green and published in a paper [sans.org] he wrote for the SANS Institute. While Kaminsky does deserve some credit for his organizational skills in getting people to act on this, that's about as far as his role goes. Since this has been known about for three years and we haven't seen anything 'in the wild' -until now that the media bandwagon is careening downhill on fire- just goes to show how hard this is to exploit.

Re:Ridiculous armwaving... (4, Informative)

supersat (639745) | more than 6 years ago | (#24282287)

This isn't even close to the same attack. Newer DNS server have randomized query IDs, so spoofing DNS packets isn't nearly as trivial as it used to be. This attack appears to combine the birthday paradox attack strategy (sending lots of queries and replies so the probability of a spoofed QID matching is much higher) with adding resource records for the actual name you want to poison (under the same domain).

Re:Ridiculous armwaving... (3, Informative)

mysidia (191772) | more than 6 years ago | (#24282397)

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 cache. That's the ordinary attack model a DNS server admin would be concerned about, right?

What if instead, the attacker doesn't care what domain they poison? Instead, they aim to attack major ISPs' DNS cache, or authoritative DNS servers' cache.

Instead of trying to poison one particular domain, they go down a HUGE dictionary of popular domain names, TLDs, etc.

And if their odds of each poison being successful are (1/2^16) based on being able to predict the source port?

They have a good chance of eventual success, by brute force, especially if they can reduce the search space for transaction id, or re-use a legitimate transaction id in an unexpected way.

The attacker doesn't care that his spoofed packets will be wrong or won't get there first for most domains.

Poisoning _just one_ popular domain with a bogus NS record may be a serious attack.

Once one poison is successful, if the future dns transaction ids/source ports are sequential, or even just pseudorandom, an attacker can possibly know that they have succeeded (By testing the success of their poison).

Knowing that they succeeded gives them the state of the RNG; they might also get that querying a domain whose authoritative DNS server is complicit to the attack (and will provide the attacker with the DNS request packet for analysis)

Re:Ridiculous armwaving... (2, Informative)

mrsbrisby (60242) | more than 6 years ago | (#24282499)

While the pro-security community is being left in the dark.

The pro-security community has always been safe; DJBDNS and derivatives are immune to this attack and always have been.

Re:Ridiculous armwaving... (1)

mysidia (191772) | more than 6 years ago | (#24282651)

Except that DJBDNS doesn't support DNSSEC. Which is not pro-security.

And when setting up an authoritative DNS server, it doesn't even properly support SRV records.

In reality there is DNS server software other than DJBDNS, BIND, et al. that have to be secured.

There are other caching DNS servers also. The advisories don't show whether they are considered vulnerable or not.

Re:Ridiculous armwaving... (1)

Ice Station Zebra (18124) | more than 6 years ago | (#24283111)

dnssec is a joke. It still doesn't fix the issue.
djbdns does support srv records http://www.anders.com/projects/sysadmin/djbdnsRecordBuilder/#SRV [anders.com]

Yes, there is other dns software other than bind. But djbdns is small, secure and easy to setup.

Re:Ridiculous armwaving... (1)

QuoteMstr (55051) | more than 6 years ago | (#24283227)

DNSSEC a joke? Hardly. Care to elaborate on your alternate and better proposal?

Re:Ridiculous armwaving... (0)

Anonymous Coward | more than 6 years ago | (#24282691)

Of course he stole it, he is jewish. Thats what they do best.

Long story short (1, Insightful)

losttoy (558557) | more than 6 years ago | (#24282071)

This did occur to me earlier but seemed too simple.

Pick a few hundred ISP name servers. Craft packets with the the source address as that of your victim's name server's IP address and start sending them to the ISP name servers on your list.

Sooner or later, due to the non-randomized tracking number used by DNS requests, your false DNS replies will be accepted by one ISP nameserver. Because you set the TTL for the DNS record to be very high, the record will live in the ISP name server's cache for VERY long. Now all the ISP's customers will come to an IP address of your choosing when they type www.victim.com.

The internet is now 0wned.

What I was thinking is spraying the end users with spoofed DNS responses. Sooner or later, some would use your response to resolve the name but obviously poisoning an ISP name server is more profitable.

If this really is *the* attack then it was lame of the *researchers* to try and hide it. I am sure 1000s would've guessed it by now. The exploit is really simple with dozens of packet crafters out there

Here is hoping that the real vulnerability is a lot harder to exploit.

Re:Long story short (1)

losttoy (558557) | more than 6 years ago | (#24282095)

With proper SSL certificates, savvy users might be able to avoid going to spoofed sites. Browsers like Firefox 3 will alert you of bad certs and all that.

But think of email delivery to wrong MX records .

Re:Long story short (1, Informative)

Anonymous Coward | more than 6 years ago | (#24282547)

That is not it. What you describe would have worked a decade ago, but not today.

I have the entire article (1)

Rudd-O (20139) | more than 6 years ago | (#24282077)

I have the entirety of the text of the article, since it's on my feed reader. You do not need to piece it together. Just ask me for it.

The futility of recalling the article should be a very good example of the stupidity in this "don't speculate about the DNS vuln" moronic exercise that is doing the rounds these weeks.

That's it (4, Funny)

krkhan (1071096) | more than 6 years ago | (#24282113)

I've had enough. From now on, /. isn't /. for me. It's 216.34.181.45. I'm updating all my bookmarks. Wait, why is it redirecting? I have a bad feeling about this. Itsatrick.

What about simple DSL SoHo routers with DNS? (0)

Anonymous Coward | more than 6 years ago | (#24282119)

Do they also require a patch? They act as DNS for the local clients.

Who is ecopeland? (1)

Ancorehraq sis (1330217) | more than 6 years ago | (#24282121)

Did Matasano blog get broken into? "ecopeland" never posted there before [google.com]

The significance of the attack... (4, Informative)

Rudd-O (20139) | more than 6 years ago | (#24282129)

...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... (4, Insightful)

Rudd-O (20139) | more than 6 years ago | (#24282211)

Re:The significance of the attack... (1)

mxs (42717) | more than 6 years ago | (#24283579)

How nice of you to comment on your own website, not in the comment section where we might also read it unhassled.

May your DNS be poisoned.

I thought this wasn't the X attack from Y.. (2, Interesting)

dnsfool (1330219) | more than 6 years ago | (#24282189)

If this is the real deal, there's some bogosity here. This is certainly not a new attack or flaw in the dns protocol, any more than run of the mill dns cache poisoning is. Spoofing responses from the root servers (to hijack a TLD) is difficult; their TTLs are long, there are many of them (more unpredictability), and most DNS servers service so many requests that it's unlikely that your spoofed answer will be the first one to hit the server and thus poison the cache once the TTL for that TLD has expired. Spoofing responses from TLD servers is standard issue cache poisoning, and you cannot use it (any more) to poison a cache with an irrelevant record; BIND is going to ignore any NS, A, SOA, or other records for bankofamerica.com. in the additional or authoritative sections if the request was for some-domain-that-don't-exist.com. I'm back to where I was before; not seeing anything new here except a clever theoretical attack that would work much better if the TTLs for the TLD servers were on the order of minutes or hours rather than days. Either Halver guessed wrong, or the security community has been mislead about the severity of the issue.

Re:I thought this wasn't the X attack from Y.. (1)

Rudd-O (20139) | more than 6 years ago | (#24282293)

The severity is that you can submit your own glue records with the attack. You get to set what DNS server is queried for any second-level domain, get it?

Re:I thought this wasn't the X attack from Y.. (1)

dnsfool (1330219) | more than 6 years ago | (#24282387)

Yes, but that doesn't help in an attack.

If I go make a bunch of links to abcd.bankofamerica.com, bcde.bankofamerica.com, and so on, my intention is to hijack www.bankofamerica.com.

www.bankofamerica.com is not a subdomain of abcd.bankofamerica.com, and thus, any glue related to it that is provided in the above queries should be ignored.

Follow?

BIND may not currently be doing "balliwicking" at this detail, but it should be, and patching it to do so should be rather trivial.

Re:I thought this wasn't the X attack from Y.. (1)

flosofl (626809) | more than 6 years ago | (#24282823)

The way I understood it is that by specify an "Additional" RR packaged with the bogus Reposnse RR. Once I finally get through with xxffgg.bankofamerica.com, I also get my "Additional" RR processed, which in this case would be to point www.bankofamerica.com to my own server. Since I have remained within the baliwick of bankofamerica.com, the change is accepted without reservation and poisons the cache (with an abnormally large TTL). Legitmate requests for www.bankofamerica.com would not go to the authoritative server until the TTL expired. It's actually kind of clever. It actually uses the original baliwick fix against itself. Of course with a *much* better RNG and random source ports, this attack becomes much more difficult. With DNSSEC it becomes damn near impossible.

Apple (1)

Phroggy (441) | more than 6 years ago | (#24282197)

Any idea when Apple might release a patch for Mac OS X Server?

I know compiling BIND from source is always an option, but most admins aren't going to do that.

Re:Apple (1)

Rudd-O (20139) | more than 6 years ago | (#24282275)

Use DJBDNS.

Re:Apple (1)

Ice Station Zebra (18124) | more than 6 years ago | (#24283061)

watch out, you my waken the "DJB is evil because someone told me so" people.

Full post in my RSS feed (1)

joebeastie (662792) | more than 6 years ago | (#24282299)

For what it is worth. I see the whole blog entry in my google reader rss feed for Matasano.

Streisand Effect (1)

Samah (729132) | more than 6 years ago | (#24282429)

I fail to see the point in pulling this information. The only people who will CARE about it are those who know how to exploit it, and they're the exact people who'll be able to find it regardless of if it's removed.
I wouldn't mind betting this will show up on Wikileaks pretty soon (if it's not already).
For those who've not heard of it: http://en.wikipedia.org/wiki/Streisand_effect [wikipedia.org]

Re:Streisand Effect (1)

FlyingBishop (1293238) | more than 6 years ago | (#24282927)

Of course, the little caveat is that this was already big news... there was never any real consideration of stopping the release, just delaying it. And I think this may have bought people who were already preparing for it an extra hour to stay late tonight and patch, or shut down their servers to patch, while redirecting traffic for the evening.

Use djbdns (aka tinydns) (2, Interesting)

Neanderthal Ninny (1153369) | more than 6 years ago | (#24282553)

Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]

djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

Re:Use djbdns (aka tinydns) (0)

Anonymous Coward | more than 6 years ago | (#24283453)

That is not it.

Was that it? (1)

mrbah (844007) | more than 6 years ago | (#24282709)

For all the hype, this attack is hardly groundbreaking. It strikes me as something that was used to coerce vendors into finally patching smaller flaws security people have been nagging about for years.

The register. (1)

smoker2 (750216) | more than 6 years ago | (#24283231)

There is a write up on the register [theregister.co.uk] that suggests that while this may be Kaminskys attack, there is a possibility that it is another separate vulnerability.

Better Speculation (4, Informative)

logicnazi (169418) | more than 6 years ago | (#24283275)

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.

You can read it here (2, Interesting)

Dramacrat (1052126) | more than 6 years ago | (#24283329)

http://beezari.livejournal.com/141796.html [livejournal.com] Ahhh, internet. (Not my journal, nor can I vouch for the veracity of the post-- but it seems to fit with other fragments posted and found)

Nasty tactic (1)

Todd Knarr (15451) | more than 6 years ago | (#24283481)

The described attack's a nasty tactic. I hadn't thought of it, or rather I had but discarded it under the impression that all DNS software had changed years ago to filter out additional RRs that weren't responsive to the actual query to prevent exactly this sort of attack. I hope Dan's patches include such a filter.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>