Thursday, February 23, 2006

Sony DRM Debacle Part 2

It’s a bit technical but this is a follow up to my post on the 11th of November last year about the Sony DRM rootkit.

Basically this article talks about how they have managed to externally query Sony’s cache servers to determine where in the world has been affected by the Sony DRM Rootkit.

Look at the Europe picture here http://drm_sony_europe.JPG

So now the hackers dont even need to do wide scale internet 'trawling' for computers that have been infected by the root kit installation, they can now query the Sony cache servers and look up your ip addresses directly and head straight for your computer to hack in via the gaping unprotected hole Sony installed.

If you haven't uploaded the patch by now you deserve what you get, you have been warned.

This has to go down in history as one of the ‘mistakes of the internet’ like the purchase of


They're Here...
Submitted by Dan Kaminsky on Wed, 2005-11-16 02:27.
Some pretty extensive, even mainstream coverage (New York Times, Washington Post, USA Today, Wired News) on this whole Planet Sony Rootkit Metrics project. Cool! Now, if only I could get the chance to look through the actual logs...

Welcome To Planet Sony
Submitted by Dan Kaminsky on Tue, 2005-11-15 09:28.


Sony has a rootkit.

The rootkit phones home.

Phoning home requires a DNS query.

DNS queries are cached.

Caches are externally testable (great paper, Luis!), provided you have a list of all the name servers out there.

It just so happens I have such a list, from the audits I've been running from .

So what did I find?
Much, much more than I expected.

It now appears that at least 568,200 nameservers have witnessed DNS queries related to the rootkit. How many hosts does this correspond to? Only Sony (and First4Internet) knows...unsurprisingly, they are not particularly communicative. But at that scale, it doesn't take much to make this a multi-million host, worm-scale Incident. The process of discovering this has led to some significant advances in the art of cache snooping. Here are some of the factors I've dealt with:

Just because you *request* the disabling of recursion, doesn't mean it'll actually happen. A full 353,200 name servers had to be excluded from the final tally because not only would recursive queries emit from them whether or not they were desired, but they'd also notify their neighbors of the results.

Low TTL names exist, and are rather difficult to catch by cache snooping (they expire before you can find proof of life). However, they may be hosted by names that last much longer -- has a lifespan of an hour, but's NS link to will last 150,000 seconds.

Some hosts lie -- captive portals, I'm looking at you. Simply filtering TTL's that are divisible by 100 has a way of eliminating most of them; after that, you're left with surprisingly few NS's that lie about IP.

I also have an IP->Geographic data, courtesy of Mike Schiffman's libipgeo and the fine folks at IP2Location, who have a very impressive database. So, the first thing I did was geolocate the data. After dispensing with the raw stats gather...

What can I say? Pretty pictures. Ugly data, but pretty pictures!

And the tool used to make this? Welcome To Planet Sony! (based on Partiview in general and the always awesome PlanetLab's work in particular)

No comments:

Post a Comment