Dan Kaminsky's Blog

“You have no privacy. Get over it.”

Oh, Scott McNealy caught alot of heat for that one. Formerly the CEO of Sun Microsystems, his observation — all the way back in 1999 — set off a huge firestorm. How dare the CEO of Sun, whose machines store terabytes and terabytes of private information, say openly that this information is bound to leak! The reaction was pretty much uniformly either…Denial or Anger.

That doesn’t mean he wasn’t right.

So the Chairwoman of HP’s board got caught with her hand in the metaphorical privacy cookie jar. Maybe she’ll lose her job, maybe she won’t. But the fact that she had the cookie jar, sitting right there, filled with yummy delicious potentially leak-identifying cookies, is the greatest proof of McNealy’s Law yet.

I hereby dubb it Dunn’s Corollary: Not even board members have privacy. Get over it.

Now, before everyone goes Denial/Anger on me too, please understand. I despise this state of affairs. But to despise a state of affairs is to accept that it exists — and there’s ample evidence that shows that what Dunn has been accused of ordering, is actually pretty common. It’s been almost a year since the Chicago Sun-Times remarked in an investigation (oddly similar to “you can download pirated software online!!!”) that Your Phone Records Are For Sale. Sure was alot of noise back then too, and then…nothing. I mean, how hard would it have been to go and arrest these guys? These aren’t back-alley cash transactions; they’re taking money over the Internet. I do believe we know how to track such things.

Paul Mockapetris says Vista is going to take down the Internet’s DNS infrastructure. Paul is the inventor of DNS; I met him at Black Hat last year and was half starstruck, half relieved he didn’t hate me for the things I’d done to his creation 🙂 Paul knows DNS. It’s his creation. But you’ll note in this story that Joris Evers can’t actually find anyone who agrees with Paul.

There’s a reason.

First, while there are indeed a couple underprovisioned name servers, there’s far more that have lots and lots of slack capacity. You need slack capacity to deal with shock load. The networks that would fail because of Vista’s release, would fail because of a three day weekend.

Second, Vista’s not getting deployed all at once. This is no service pack that’s deployed to a hundred million desktops via Windows Update! Mockapetris is correct in that there will be a noticable increase in DNS traffic, but that increase will be spread out over the course of a couple years. Slow increases like this tend not to cause the sort of catastrophic failure that Mockapetris refers to.

Finally, and most importantly (in the sense that Mockapetris should know better): Most of the work done to service the IPv6 request, is cached and available to service the IPv4. To complete a DNS lookup, you have to locate a particular server, known as the authoritative server for a domain. The same authoritative server that hosts the IPv6 (AAAA) record also hosts the IPv4 (A) record. So even if Vista sends twice the traffic, the upstream nameserver is certainly not experiencing twice the load.

Full disclosure: Microsoft has had me looking at Vista for much of this year, as part of their “Blue Hat Hacker” external pen-testing squad. But then, Mockapetris’s company, Nominum, has written a really impressive name server for his company that can handle about 4x the load of BIND. But this isn’t about who we are; it’s about what is or isn’t going to collapse. There are things to worry about. This isn’t one of them.

A couple of recent stories on BoingBoing, regarding fingerprint readers at Walt Disney World and at a Georgia cafeteria line, have brought back the old canard that biometric “hashes” are irreversable. This is ridiculous, we’ve known how to reverse these “hashes” for years:

• Reversing Fingerprint Hashes
• Reversing Faceprint Hashes

Ultimately, this is a general trait of the technology: The algorithms don’t return “match” or “don’t match”; rather they tell you how far you are from a valid match. So…you take some random image, see how far away it is, and change it a little. If you get closer, change a little more. If you get farther away, revert your change and try something else. Eventually, you find yourself looking at something that, while not exactly identical to the original, is ultimately recognizable.

Gah. Biometrics people, your stuff isn’t bad. Please stop overselling it.

(From Virus Bulletin, Feb 2006).

‘What happens when the creators of malware collude with the very companies we hire to protect us from that malware?’ Bruce Schneier, one of the godfathers of computer security, was pretty blunt when he aired his views on the AVindustry’s disappointing response to the Sony rootkit (for an overview of the rootkit and its discovery see VB, December 2005, p.11). His question was never answered, which is fine, but his concerns were not addressed either, and that’s a problem.

The incident represents much more than a black eye on the AV industry, which not only failed to manage Sony’s rootkit, but failed intentionally. The AV industry is faced with a choice. It has long been accused of being an unproductive use of system resources with an insufficient security return on investment. It can finally shed this reputation, or it can wait for the rest of the security industry to finish what Sony started. Is AV useful? The Sony incident is a distressingly strong sign that it is not.

All things being equal, I’d rather have the AV industry on our side. We take it for granted that there are customers for private computer security services. It didn’t have to be this way: someone had to convince users that they were responsible for their own security. Because of the pioneering work of the AV industry, effective cryptography was non-negotiable, security research could be legitimate, and a free market for security technologies could form. Indeed, even the spread of broadband and WiFi would have failed if users hadn’t been motivated to purchase firewalls to protect their new high-speed networks. The AV industry made sure the users knew they needed to protect themselves, which is why it is such a great problem when the AV industry refuses to protect them.

TAKING CONTROL

Let’s be honest; the AV industry is blessed. What other software producers can depend on the operating system (for home users) or corporate IT departments (for the office) essentially demanding that their product runs on every system? When was the last time you saw a machine banned from a network for not running Photoshop?

Believe it or not, I’m actually pretty sick of complaining about Sony. You just can’t get around the fact that, once they realized the trouble they’d gotten themselves into, they pretty much did everything that was asked of them and then some. Pretty much the only thing I’d like at this point is the actual infection data, so I can better tune my DNS measurement code, but without a court order that’s just not going to happen.

Now, you’d think AV vendors would have this data. They’re always telling us about who’s infected with what. Turns out they just don’t know. I find this…interesting.

Some problems go away — Sony isn’t likely to release another rootkit anytime soon. But others fester. The antivirus industry has a problem — they actively supported Sony’s actions, and haven’t exactly apologized for supporting code that even its authors disavow. And so, Virus Bulletin, the premiere magazine for the AV industry, asked me to submit an editorial questioning the AV industry’s involvement in supporting Sony’s now-discredited rootkit.

That editorial (a newer version than was actually posted here recently, actually) may be found here:

• PDF

You other hackers can’t deny…when a packet routes in with an itty bitty length and a huge string in your face you get sick…cuz you’ve fuzzed that trick…

h0h0h0! I bring Christmas presents! Lots of new Sony data is about to drop, but for now please enjoy Xovi, my streaming graph visualization framework. Based on the excellent Boost Graph Library, and written with the generous assistance of Boost’s Doug Gregor, Xovi is my attempt to make complex networks at least partially comprehensible. There’s lots of work left to do — but, oooh. Pretty.

• Xovi 0.2
• Anonymized Backbone Trace Data

It was the best of times, it was the worst of times.

So Matt Blaze‘s wiretap hacking paper is finally out. Huzzah, this was one of the coolest talks I’ve seen in years. Matt, who gained all sorts of notoriety last year for effectively cryptanalyzing physical lock infrastructures, took on wiretap equipment this time. The results were pretty brutal. (New York Times article)

Here’s a basic summary of what Matt found:

1. Telephone systems depend on an analog encoding for touch tones that is referred to as DTMF. (Unknown: Is pulse encoding still supported anywhere?) At some point in the CO (Central Office — the other side of where your phone is plugged in), those analog frequencies are converted into digits — 1, 2, 3, and so on. But which tones go to which numbers? Matt realized that there’s an infinite range of possible tonal frequencies and mixes, and that by deviating farther and farther from the specification, he could eventually determine the precise boundries of what his CO would accept as a given digit. Why would this be useful? Because it’s quite unlikely that any other device inserted inline (read: wiretap) would have the exact same tolerances. Matt could send a series of digits, some within tolerance, others slightly outside. From here, two things were possible:
   1. Too conservative: The wiretap would demand tighter adherence to DTMF specifications than the CO, and would thus reject numbers the CO was willing to route.
   2. Too liberal: The wiretap would be allow even more digits than the CO would — and thus, all those noise digits ignored by the CO would pollute the logger.

   Either way, the pen register (number logger) loses.

   There’s a bit more, but I don’t know if I’m OK to tell the coda to this story. Needless to say though, Matt Blaze has cojones of diamond-coated steel. I think it’s fair to say that, if we do expect law enforcement to be able to monitor telecom with a warrant, they’re going to need some better tools to do so reliably.

   On another note, somehow we’re hearing talk about how aliens might hack us through SETI. I’m sure Richard Carrigan is a nice guy, but I don’t think he understands just how … extraordinary … his claims are. Not many things in security are mathematically provable, but I do believe summarization functions (such as SETI’s FFT’s, and those scary stats class “averages” and “standard deviations”) qualify. SETI’s FFT’s have a known range of outputs with a known range for each output — this does not, even in the slightest, align well with a hacker’s desire for unknown outputs into unexpected memory ranges. Indeed, if SETI is hackable, what we would really have to worry about is attacks against compression engines, such as MP3 or (most usefully) G.729a/b. You’d have to have a signal that, when processed, overflowed some bound and got controllable values into memory used for execution flow. Now, there are certain encoder designs where I can vaguely imagine this, but if it hasn’t happened yet for such high value targets, or as far as I know, for any encoder, I don’t think there’s even the slightest reason to believe even a highly motivated human could hit SETI’s analyzers, let alone “aliens”.

New images from the Sony Rootkit Research front:

• USA
• Europe
• Japan

Red signifies evidence of First4Internet accesses; Green signifies accesses to Sony’s enhanced CD site (included with the rootkit, but also elsewhere). Most links are yellow, though: Over 3/4ths of networks found resolving Sony during the sampling period also resolved First4Internet. The geographic evidence lines up pretty nicely as well (Sony | F4I).

What does this signify? Interesting question. Originally, it appeared that the rootkit itself issued queries against First4Internet. It may, it may not, we’re not entirely sure yet. Yet First4Internet exhibits remarkably high popularity, weeks into the controversy, for a site not automatically connected to. I suppose it cannot be too surprising to see high correlation between names exhibiting potential for infection and names implying desire for disinfection/uninstall, but I’d like to know more. Ultimately, as I have said from the start — I simply do not have enough information to determine/imply/”guesstimate” how many hosts have been compromised.

Only Sony does.

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…

Sony.

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 http://deluvian.doxpara.com.

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 — updates.xcp-aurora.com has a lifespan of an hour, but xcp-aurora.com’s NS link to resolver1.first4internet.co.uk 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.