Dan Kaminsky is NOT a hero

Before I launch into my rant about all the swirl that's resulted from Dan Kaminsky's recent disclosure of a DNS flaw, I want to make one thing clear: While I do not know him nor have I worked with him, I nevertheless hold Dan's skills in high regard and respect him as a professional. The DNS flaw behind this is indeed serious. Nothing I'm about to say should be seen as a reflection on him or his work, but rather the sometimes-OCD InfoSec community and online media outlets.

Yesterday I read a column by Robert Vamosi, linked off of C|Net, that made me vomit a little bit in my mouth. His comments on Kaminsky would make the reader think that the man just saved the entire world+dog for today and the rest of time from certain doom from some three-headed unstoppable eating machine with minty fresh breath but a bad, bad attitude. Heck, he may just be the second coming. Oh man, that means I'm going to hell for not capitalizing He. Allow me to quote from the article titled - no kidding - The man who changed internet security:

There have been other multiparty patch releases, but never has there been one on such a massive scale.

What he [...] did over the last few months was not only responsible but extraordinary.

all future vulnerability disclosures could benefit from his example.

With the DNS flaw, Kaminsky was in a very weird position. What he found wrong [...] wasn't just within one vendor's product, it cut across various products

He has changed Internet security, and done so for the better of us all.

This is a great amalgamation of all of the idolatry directed at Dan, all in one column. To categorize all of this, many people - professionals in the field (self-proclaimed or otherwise) - seem to be under any combination of the following false impressions:

1. The scope of this issue is without precedent. This is simply not true. Especially in the late 90's and early 2000's as attackers began seriously exploring computer vulnerabilities, there have been a number of widespread service implementation problems - or problems affecting a hugely critical piece of software (think: Bind before many people used MS's DNS server). A recent example is the vulnerability in the implementation of BGP by every major router manufacturer in 2007 which could lead to a spoofed denial-of-service and ZOMG TAKE DOWN THE WHOLE INNERWEBS!
2. Having to coordinate patches between vendors is unusual. While no doubt most vulnerabilities impact only a single vendor, it's also not uncommon to find a second vendor, perhaps borrowing from the same segment of code (I'm looking at you Unix), that is also vulnerable. For an easy example, see (1), or many vulnerabilities found in open source/GPL code over the years.
   
3. This vulnerability is new and completely unexpected. While we won't know for sure until this is discussed at BlackHat, there is evidence suggesting this isn't true. People have pointed out that similar techniques to poison DNS have already been discussed. We can certainly say the severity of the exploit seems new, but beyond that, any responsible discussion on the topic needs to wait until all the facts are in front of the public for peer review. I wouldn't say this is patently false, but I would say to anyone making this assertion, "not so fast there..."
   
4. Responsible disclosure is somehow novel, invented, or revolutionized by Dan Kaminsky. These people either have had their head in the ground since 2000 or so when the debate between full and responsible disclosure first erupted on BugTraq, or they never understood what the term meant. At the time of the writing of this entry, a Google search for "responsible vulnerability disclosure" returned "about" 287,000 pages.
   

To quote his recent blog entry, he's been "the beneficiary of what can only be described as 'redonkulous amounts of press'." To wit, there is plenty of good press discussing the vulnerability and how to fix it - that's obviously not what I'm talking about. Dan's a great professional, I hate to see fanboys like this surface and cheapen - rather than reinforce - his m4d sk1lz.

To Dan: Kudos. To all the fanboys and fangirls: Please to be redirecting your significant energy and time to something a little more productive.

In case you missed it...

In the most recent SANS NewsBites, editor Brian Honan points readers to a great skit on identity theft by British sketch comedians Mitchell & Webb. Hilarious, concise, and satirical-just what you'd expect from British humo(u)r. Worth the 1:55 if you have it to spare.

Malware, defined

The Merriam-Webster dictionary has released a list of 100 new words defined in their dictionary. Among them is the most commonly red-squiggly-underlined word in any document I type, malware. As reported by Die Welt:

Malware (1990): software designed to interfere with a computer's normal functioning.

Differentiating CNA and CNE

The sometimes-subtle difference between espionage and attack in the electronic or digital realm is often completely glazed over in the media. This, I feel, is confusing two very different objectives of adversaries. Without such a distinction, it becomes hard to defend computers, networks, and data, as each requires a very different approach to detection and prevention. As Zach in Rage Against The Machine would tell you, "know your enemy." One must fully understand who is attempting to do what in order to properly align defenses.

This issue has annoyed me for a long time, and I've found it somewhat hard to articulate the significance of this delineation. Finally, it seems, someone is getting the word out - and in a way that's easy to understand. In a hearing before congress on May 20th of this year, Col. McAlum, director of JTF-GNO, stated the following:

I would also point out on this slide that it's really important to get the lexicon right. In the open source media and other forums, you hear the term "cyber attack" used rather liberally, and you won't hear anyone in the Department of Defense use that term in the context of cyber reconnaissance or network intrusions. What we are seeing today are network intrusions.

Some people might classify that as a form of cyber espionage. I would not have a problem with that characterization, but the terms "attack" and "intrusion" are very different and the differences are significant in many cases. So, for example, someone breaking on to an Air Force base with a camera and a backpack is a serious event, very serious, and is going to get the security forces and a lot of leadership's attention.

However, that's much different than someone breaking into an Air Force base with a satchel charge ready to plant it somewhere and blow something up. Those are sort of the nuanced differences that I think the lexicon discussion has to take into account.

This is one of many very interesting comments on this hearing, titled "CHINA’S PROLIFERATION PRACTICES, AND THE DEVELOPMENT OF ITS CYBER AND
SPACE WARFARE CAPABILITIES." If you take an interest in all the recent press about these topics, you will find this a very good read.

Readying children for a police state

A coworker sent me a link to this wiretap kit for children ages 10-14 being sold by Toys-R-Us. This is just terrifying on so many levels...

Enabling security through effective interface design

Kudos to the Mozilla Firefox team. I upgraded to Firefox 3 today, and shortly thereafter went to Travelocity to schedule a trip. To my great pleasure, I noticed that the SSL certificate is provided in the URL bar, with a green background to indicate it's trusted.

This information has always been available to users, but how to access it - or even the need to - wasn't something intuitively obvious. The little lock showed up, so everything is encrypted, meaning I'm fine, right? With this interface, you not only clearly see that the certificate is valid, but who it has been issued to. This required a bit of clicking around before - something few were willing to do. Admit it, how often did you check?

Not only that, but the most important details appear at the click of a button, not in a separate window but as a pop-out. Of course, the complete details are also available.

This is precisely how the industry can empower users to act securely and make the right decisions without a second thought. More integration of security features into interface design is exactly what we need, and I'm glad to see the Mozilla team start to walk that path.

Reducing malware analysis with code comparison techniques

This is another topic that I file under "someone must have certainly done this already"...

We're struggling with the influx of custom malware that has exploded since 2006. The skills necessary to reverse engineer code are hard to find, and expensive when they surface. As a result, bandwidth is always limited for an organization faced with the need to understand the inner-workings of malware to assess damage, scope, and impact of a system compromised by custom code.

There have been a few discussions within my team recently about how these valuable skills can be focused. For years we've worked to reduce the set of malware that necessitates deep analysis by identifying techniques that enable us to make inferences about the unknown code by comparing it to similar known code, or making assumptions based on its context. Discussion has heated up on this topic of late, especially since a colleague began using an intriguing, if unproven, statistical technique to group malware.

The first question that should come to the reader's mind is, "haven't the anti-virus companies already solved this problem?" They should have. But we've seen first-hand that if they know how to solve this problem, it is either ineffectively implemented or not implemented at all in their code. I could tell stories, but that's not the point of this entry.

The technique that keeps coming to my mind as promising is an analysis of code which represents its flow control as a graph, and then searches for isomorphisms in other code flow graphs to identify identical or similar executables. Identifying complete isomorphisms between graphs is a well-studied problem. For one such example, this paper discusses its utility with VLSI hardware, comparing circuit diagrams to chip layout. It stands to reason that a similar technique could be used with what I'll call the identical software flow problem.

Those with an interest in computational complexity theory would find the following both relevant and intriguing: the graph isomorphism problem has not been proven to be NP-complete, nor is it known to be solvable in polynomial time, meaning it is only NP. Special thanks to Wikipedia for this link (huge PDF), which discusses solving the graph isomorphism problem efficiently despite being NP.

The problem of identifying similar pieces of code, which I'll call the software flow similarity problem, is much more involved and from what I can tell much less studied. In this case, flow control graph subsets would be compared between pieces of code. Some key questions here are:

1. How big or complex must the subset be, as compared to the complete flow graph, to be meaningful?
2. How many matches of graph subsets must be identified to confidently call code segments similar?

This is but one technique, and determining software similarity is likely to involve a number of other techniques - computed, observed, statistical, or what have you. I feel this approach would be a very strong indicator on its own, although it would be far more difficult to implement and study than some other heuristic approaches. I'm going to continue searching for papers which discuss these techniques; it seems hard to believe no one has done this before.