Slashdot Mirror

The technical details are not complicated -- Conficker, in all its variants, makes NetpwPathCanonicalize() work quite a bit differently than either the unpatched or the patched MS08-067 version -- but I'll let Tillmann and Felix describe this in full in their "Know Your Enemy" paper, due out any day now with all sorts of interesting observations about this annoying piece of code. (We didn't think it made sense to hold up the scanner while finishing up a few final edits on the paper.)

The money involved is billions. Lets not forget it. The Kaminsky flaming seems to come from jelousy, the .edu "mafia" and the fact that guy found some kind of security hole that it is there for 3 decades.

It's just another DNS cache-poisoning attack. I see no need to flame Kaminisky, but deifying him for being able to read an RFC seems a bit much.

If you want to hero-worship Kaminsky, may I point out that he wrote pakketto keiretsu? That's actually rather impressive.

Go check out Kaminsky's powerpoint of the whole thing. It's actually a very, very serious bug. I warn you, its 107 slides, but a few dozen into it and you'll see the danger he uncovered.

Here's Kaminsky's powerpoint given at the Black Hat conference. (106 slides but thorough) This Wired article and the powerpoint is enough to make me panic. He literally broke the internet; unlock any website and spoof any logs. Now I see why there was so much panic in the article.

I was as confused as you were by all this, since the article didn't say what the actual attack is. I eventually found something that explains it.
http://www.doxpara.com/DMK_BO2K8.ppt linked from http://www.isp-planet.com/equipment/2008/nominum+vantio.html

  See slide 17 in the presentation. But the trick is, your forged reply to a query for 83.foo.com is:

83.foo.com IN NS www.foo.com (83.foo.com is a subdomain, whose name server is www.foo.com)
www.foo.com IN A 6.6.6.6 (glue)

  So I guess I still agree with you, that BIND must be trusting more than it needs to. Caches could distrust any glue except when it has to. (I think the glue is only necessary when the name server is part of the domain it's serving. e.g. The glue would be needed if the name server was ns1.83.foo.com. Otherwise why not ask the .foo.com server for www.foo.com's A record, or use a cached one, instead of trusting the glue?)

  IIRC, djbdns is skeptical of glue. I remember reading a big rant about glue on DJB's web site years ago. I'm not sure if that's why it's not vulnerable, or if it's because it already did source-port randomization.

  Anyway, that presentation seems to cover a lot of what I wanted to know. In the worst case, you have a cache that trusts glue, and you can poison it by guessing a 16bit ID. In the even worse case, multiple requests for the same name leave the cache willing to accept more than 1 ID for a single response, leading to a birthday attack.

    The trick is to generate lots of DNS queries for names you choose when the server isn't run by idiots (accepting recursive queries from the whole Internet). Web log analyzers are one possible vector. Otherwise if you can feed HTML to something that will resolve names for IMG tags, or presumably javascript could go nuts...

That sounds like a variant of Paketto Keiretsu's SCANRAND, which puts an encrypted token in the IP sequence number field so as to scan without having to remember "I sent a packet to X". If that's really what it is (just with TCP connections instead of port scanning), then this attack is old indeed.

Dan's shot this nonsense down pretty comprehensively on his blog.

Kaminsky has an interesting rebuttal here.

You mean like this? (Thanks to Dan Kaminsky's blog for the reference. I highly recommend reading his summary of SIGGRAPH; there's a lot of cool stuff there.)

It may be a good idea to check your DNS server to see if it is vulnerable. Dan Kaminsky has a tool that shows vulnerability on his blog.

I did think about it, and I don't see your point.

You seem to think that a NAT doesn't help security in the least and that a firewall is the be-all, end-all of security.

Fact is, when you say a NAT is not an alternative for a firewall you are just showing that you haven't thought it through yourself. NATs add security. That their security isn't perfect doesn't mean it isn't worthwhile. That it doesn't match a firewall exactly doesn't mean it isn't worthwhile. That they mean that I have 1 IP address for the 3 - 12 devices in my house is a win. IPv6 doesn't give me anything that my IPv4 NAT doesn't except extra work that I don't need.

The most time I'll waste on IPv6 is posting to slashdot. IPv6 offers me nothing, it is stupid (yes, you love to hate him, but again he's right), and that's it.

IMHO.

And yes, printable IPv6 addresses are ridiculous. Admins will have to get used to trusting DNS (or /etc/hosts) when configuring stuff .. :)

Yes, because DNS is absolutely trustworthy, and it won't be necessary for humans to worry their pretty little heads about addressing. I'm sure you think that the Windows Registry was a brilliant piece of engineering from an ease of troubleshooting perspective too.

True, technology books ARE always out of date, but whilst it's a truism that things are always changing, it's also true that there's an linear relationship with the degree to which they stay the same. (I believe the French have a neat saying that encapsulates this notion.)

The MULTICS pentest paper and it's review 30 years later are cases in point. See also Thompson, K., "Reflections on Trusting Trust", a matter which Kaminsky, D., has recently demonstrated is as true today as it was then (in a context which is completely different, yet exactly the same.)

You aren't misinterpreting -- from Dan Kaminsky's blog:

After evaluating several options, one approach was clear -- and, I must admit, somewhat embarassing to Paul [Vixie, primary architect of BIND].

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got âoeluckyâ here â" he ended up defending himself against an attack he almost certainly never encountered.

Note the weasel words here, that DJB got lucky and ended up defending against an attack he never encountered. Even while crediting him for being right, Kaminsky won't admit that Bernstein anticipated these attacks several years ago, documented them clearly, and designed djbdns to deal with them as best the broken protocol allows.

In all of Kaminsky's self-congratulatory hype about finding the bug and coordinating the patch effort, he never once suggests the obvious -- that people at least consider using the most secure DNS software available by switching to djbdns.

Steve Friedl is better at crediting Bernstein -- way down near the bottom of the excellent An Illustrated Guide to the Kaminsky DNS Vulnerability Friedl says this:

DJB Was Right

One nameserver is notable for having gotten both the query-id and source-port randomness right from the start: DJBDNS by the legendary Daniel J. Bernstein.

Though long a lightning rod for controversy, he's clearly walked the walk on security: there's never been a security vulnerability in DJBDNS.

The notion that Bernstein drives people crazy and has been a lightning rod for controversy stems from his appropriately harsh and blunt assessments of poorly designed software, particularly Sendmail and BIND. But Bernstein's critics are essentially admitting that for them, correctness is less important than not having one's feelings hurt.

SSL is not the panacea it would seem to be

In fact, SSL certs are themselves dependent on DNS

Also, the site has a video and even a DNS checker to see if you are vulnerable.

Check your DNS here!

Kaminsky's presentation from Black Hat makes it abundantly clear that still we have a long way to go in terms of DNS remediation. Until then, man-in-the-middle attacks continue to be quite easy to accomplish.

Relax on Apple

"Apple fixed their server. There are scenarios in which the clients are vulnerable, but it's servers we need to worry about right now, and Apple did right by fixing their server."

DAN KAMINSKY

http://www.doxpara.com/?p=1198

Check your DNS there too.

Your name server, at 001.02.03.04, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).

Click on the last period in his post (eggish) :-)

It's interesting to see how widespread this exploit has become. I've checked my home and office connections using Dan Kaminsky's handy DNS Checker and it appears that my ISPs have taken measures to avoid this problem.

Unfortunately, I also travel a good deal for work, and it's hard to be sure that the ISP used by whatever-hotel-I'm-staying-at-this-week will be as proactive.

The guys in TFA got pwned by being redirected to a bogus Google look-alike page. As I understand it, this kind of attack would be noticeable when attempting to use a secure (HTTPS) web connection, because the browser should throw up a certificate error. Is this true? What other ways might be used to detect this problem?

http://www.doxpara.com/ They have a dns checker on the right hand side. This is linked from the original /. article on this topic.

Dan Kaminski's website has a DNS checker on it.

Click here.

Dan Kaminski's website has a DNS checker on it.

There's a tool on the site below that apparently checks if the DNS you're currently using is vulnerable to such an attack. I checked my work DNS and my home DNS - both were fine. Apparently OpenDNS is secure as well, so there's probably nothing to worry about.

http://www.doxpara.com/

Kaminsky posted a test to see whether your DNS server is still vulnerable (it seems that you'll need to allow scripts from toorrr.com). If the server is vulnerable, he appears to be recommending OpenDNS as a stopgap measure. Their nameservers are 208.67.222.222 and 208.67.220.220 .

If you're really paranoid, switch to OpenDNS first before running the test...

On a related note, doxpara.com = 66.240.226.139 , but I can't get anything but a 404 at the IP address. Should I be nervous?

Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated.

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.

I'm having trouble with Paul Vixies' line:

Q: "This is the same attack as described way back in ."
A: No, it's not.

When Dan Kaminsky states in his blog.

"DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."
and
" 1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?

It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).

If you visit Dan Kaminsky's blog, there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.

From this posting: "DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."

But I'm sure his acting like a jerk still means that nobody should ever take his criticisms of software design seriously. Heck, the BIND folks didn't, and it's not like people are going to stop using BIND.

http://www.doxpara.com/

stand by the wordpress it likes to have the cache

Uh... not vulnerable then?

http://www.doxpara.com/

Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.

Sweet!

OK, it's pretty damn cool to see people 'round here referencing my work on Javascript MD5 collisions :)

The relevant links are:

http://www.doxpara.com/research/md5/t1.html
http://www.doxpara.com/research/md5/t2.html ...and the original paper:

http://www.doxpara.com/research/md5/md5_someday.pdf

I'm pretty sure I talked about third party attestation in that paper.

A more interesting point was made to me just the other day, which is that there's always enough ambient entropy in any real world system to deviate between trusted and untrusted behavior. In other words, for a turing complete app, you *can't* create a meaningful hash, because you aren't capturing all bits that will drive the execution flow. So, getting code signed really doesn't assert anything other than a business relationship. App signatures don't actually work, for any arbitrarily good hash.

OK, it's pretty damn cool to see people 'round here referencing my work on Javascript MD5 collisions :)

The relevant links are:

http://www.doxpara.com/research/md5/t1.html
http://www.doxpara.com/research/md5/t2.html ...and the original paper:

http://www.doxpara.com/research/md5/md5_someday.pdf

I'm pretty sure I talked about third party attestation in that paper.

A more interesting point was made to me just the other day, which is that there's always enough ambient entropy in any real world system to deviate between trusted and untrusted behavior. In other words, for a turing complete app, you *can't* create a meaningful hash, because you aren't capturing all bits that will drive the execution flow. So, getting code signed really doesn't assert anything other than a business relationship. App signatures don't actually work, for any arbitrarily good hash.

OK, it's pretty damn cool to see people 'round here referencing my work on Javascript MD5 collisions :)

The relevant links are:

http://www.doxpara.com/research/md5/t1.html
http://www.doxpara.com/research/md5/t2.html ...and the original paper:

http://www.doxpara.com/research/md5/md5_someday.pdf

I'm pretty sure I talked about third party attestation in that paper.

A more interesting point was made to me just the other day, which is that there's always enough ambient entropy in any real world system to deviate between trusted and untrusted behavior. In other words, for a turing complete app, you *can't* create a meaningful hash, because you aren't capturing all bits that will drive the execution flow. So, getting code signed really doesn't assert anything other than a business relationship. App signatures don't actually work, for any arbitrarily good hash.

Dan Kaminsky has done some research into this. If you combine Flash with a DNS rebinding attack, interesting things can happen that wouldn't happen without Flash (which is to blame for a fire, the fuel or the air?).

Scary web threats (HTML version)
Scary web threats (Powerpoint)

How confident can we be that there are no more remote command execution vulnerabilities in the Flash player?

The designed security measures are only part of the puzzle when something is in the field.

This site has maps of the spread of the rootkit. It looks like they were sold in the US and western Europe, with stray copies spread around the wordl.

There seems an overall very differnt adoption rate in GNU/Linux and FOSS arround the world.
For example at least following my recognation (worked for a UK company) the UK lacks adoption and is still a M$ Stronghold in Europe. Does anyone can explain this further?

The Sony Rootkit Map may also show difference in Linux addoption. ;-)
        * USA
        * Europe
        * Japan

There seems an overall very differnt adoption rate in GNU/Linux and FOSS arround the world.
For example at least following my recognation (worked for a UK company) the UK lacks adoption and is still a M$ Stronghold in Europe. Does anyone can explain this further?

The Sony Rootkit Map may also show difference in Linux addoption. ;-)
        * USA
        * Europe
        * Japan

There seems an overall very differnt adoption rate in GNU/Linux and FOSS arround the world.
For example at least following my recognation (worked for a UK company) the UK lacks adoption and is still a M$ Stronghold in Europe. Does anyone can explain this further?

The Sony Rootkit Map may also show difference in Linux addoption. ;-)
        * USA
        * Europe
        * Japan

There seems an overall very differnt adoption rate in GNU/Linux and FOSS arround the world.
For example at least following my recognation (worked for a UK company) the UK lacks adoption and is still a M$ Stronghold in Europe. Does anyone can explain this further?

The Sony Rootkit Map may also show difference in Linux addoption. ;-)
        * USA
        * Europe
        * Japan

OK I typed way too fast and my calculator converted these fines to exponential notation, so i got some numbers slightly (ha!) wrong.

24 Million times 1000000 is 2.4 Trillion not 2 Trillion.

But that is irrelevant because I did more/better research and the lower bound is 568,000 CDs (based on Dan Kaminsky's network DNS cache analysis) http://www.doxpara.com/?q=sony

A good conservitive higher bound is 2.1 Million sold (based on Sony's statements)http://www.nytimes.com/2005/11/14/busin ess/14rights.html>

The revised maximum fine numbers would then be $3,362,560,000 to $14,208,000,000.

So its just $3 to $14 Trillion in potential fines.

Sony has total corporate value (Market Cap) of $36,358,000,000. http://money.cnn.com/quote/quote.html?shownav=true &symb=SNE

My guess is that having a fine of (approx) 40% of your net worth hanging over your head is not gonna be good. Of course this is just Texas we're talking about here, 49 more states to go (and many many countries).

http://www.doxpara.com/?q=sony/ Has some VERY interesting information as to just how far this little beastie has spread. You see it turns out this code actually phones home somehow and by doing so it touches DNS servers - and this information can be found out. The author of that page has done some VERY interesting things in the past with DNS and his sessions at DEFCON are always interesting. If his conclusions are true then this is FAR more than "thousands" and likely edging into the millions range. He has some nice pictures too thanks to the GeoIP folks but I wouldn't trust that the locations are tooo accurate

Since I'm whoring :-) Check out this Wired article concerning this as well http://www.wired.com/news/privacy/0,1848,69601,00. html?tw=rss.TOP/> This draws some pretty interesting conclusions regarding how fast the various anti-virus people and Microsoft responded to this piece of software. NOT COOL!

I somehow find it hard to believe that US imported CDs alone would have accounted for that much spread, it looks like Sony sold CDs with the XCP rootkit on them in the UK but realizes admitting it would be a Very Bad Thing (tm) (not that they don't have enough bad things to worry about already.)

It seems as though Greenland seems completely immune to this rootkit (and bad music for that matter)

Yes, replace the 'usa' by 'europe' or 'asia' in http://www.doxpara.com/planetsony_usa.JPG.

This researcher has probed the caching on DNS servers to see how many requests are made for the www addressed used by the rootkit. He's gone a generated some nice geospatial plots of the results. The West is burning!

This researcher has probed the caching on DNS servers to see how many requests are made for the www addressed used by the rootkit. He's gone a generated some nice geospatial plots of the results. The West is burning!

"Of course, if it's the cable companies they'll probably be working on trying to block streaming video."

And I wish them much friggin' luck with that. It would be the start of a tunneling arms race which they would probably lose, in the case of clever people who really wanted to evade those filters. Security researcher Dan Kaminsky demonstrated tunneling video over DNS in 2004. See: http://www.doxpara.com/slides/BH_EU_05-Kaminsky.pd f

This sort of thing will rapidly improve if cable companies provide a reason. I doubt it will come to this, though, for the reasons stated above by Godeke.

This article covers whois. Nothing more exciting right? *rolls eyes*

It is nothing new or particularly insightful. This does bring up 3 questions though

1 - Is the slashdot crowd so amazed by something so old as whois?
2 - How much will IP geolocation amaze then?
3 - Who let this even get posted?

Two pages, same hashes, etc. (This is the guy who wrote the MD5 someday paper.)

http://www.doxpara.com/t1.html
http://www.doxpara.com/t2.html