Okay, like a lot of security guys, I speculated on what Dan Kaminsky was going to announce at Black Hat regarding the current DNS vulnerability.

Here's a quick recap of the problem, courtesy of Wired:

"The DNS flaw that Kaminsky discovered allows a hacker to conduct a "cache poisoning attack" that could be accomplished in about ten seconds, allowing an attacker to fool a DNS server into redirecting web surfers to malicious web sites..."

"A cache poisoning attack allows a hacker to... translate a website's name to a different address instead of the real address, so that when a user types in "www.amazon.com," his browser is directed to a malicious site instead, where an attacker can download malware to the user's computer or steal user names and passwords that the user enters at the fake site..."

My own speculation involved an assumption of stupid levels of randomness. But if Thomas Dullien (aka Halvar Flake) turns out to be right (and as of this writing, most people seem to think that he is), I was off by a force of magnitude - in terms of both stupidity levels and the ease with which this vulnerability can be exploited.

The vulnerability allows hackers to basically take over a DNS cache "in about ten seconds" (see above quote). Wired predicts the first root kits will be in circulation by *tomorrow*. Here's a link to the post from Dullien.

So if the problem is known, why do I say this ended badly? Because it is a systematic problem. Even though vendor patches are available, Internet security - and DNS lookups - are going to be compromised for as long as it takes for everyone to get compliant.

There are an estimated 10 million DNS servers out there. According to the Infoblox DNS Report Card survey in 2006, by the end of 2006, less than two thirds of DNS servers (61%) had been upgraded to BIND 9 - an improvement of barely 3% over 2005 levels.

With no policing forces at work (other than customer complaints and market forces), I predict that it will take years for all servers to be brought compliant. Which means this problem - DNS insecurity - is going to be around for a while.

I wouldn't be doing my job if I didn't point out that our secure transaction service, Authentium SafeCentral, uses an independent system of secure DNS servers linked to a secure client to make sure that every request for a bank or brokerage web site goes to the right place.

Software Development Kits are a big part of what we do at Authentium.


For more than a decade, we have packaged and released system-level tool kits, including Linux and Windows-based antivirus SDKs, personal firewall SDKs, and system-level file-hardening tools.

These tool kits have been used by many industry leaders in the security, SAAS-based managed services, and telecommunications industries to create new products and services.

Based on this experience, we have learned a lot about what tool kits need to offer engineering teams. But first, let's start with a proper definition.

Software Development Kits (SDKs) should enable developers outside of the distributing organization to access and utilize the code/intellectual property in a way that clearly defines both the scope of the intellectual property (IP), and the scope of what is allowed to be done with it.

The commercial model needs to closely match the scope of the toolkit. If your toolkit effectively allows other companies to compete with you, or includes some significant ongoing service commitments (both these are true with respect to anti-virus tool kits, for example), then your model needs to take into account the need to price using a "co-opetition" model and fund the ongoing service costs.

SDKs by definition also need to be well-documented, starting with the licensing schema.

It is extremely important to let developers know up-front what can and can't be done with the code. In my opinion, Firefox does an excellent job of explaining what is covered under general public license (GPL) and what is owned by the third party developer. Knowing what the tool kit owner owns, and what you could potentially own, based on your use of the kit, is important when licensing in code.

Documents designed to inform engineers are the next step. There is nothing worse than "snobby" or badly-written documentation. Engineers face deadlines and have limited time to learn your code. They need to know that your engineers are dedicated to bringing them up to speed and helping them make this deadline - the quality of your documentation reflects this better than anything else.

For me, the first step in testing your documentation should be to ask someone that has never tried your toolkit to build something with it. Does the documentation clearly enable the engineer to create something using your toolkit, without resorting to calling the manufacturer? If the answer is yes, and your legal agreement is clear, proceed.

Features found in the product that a toolkit is based on are often not included in the SDK. In my view, this is wrong - rather than force your partners to "reinvent the wheel" you should present them with features as part of your commercial model. Include them in the code and value them correctly - that way, everyone wins.

The final thing any decent open platform code-base or SDK needs is good support, provided by people who are proud of the code and willing to help. SDK need to be supported either by an interactive, wiki-based community, such as is the case with Linux, PayPal or Firefox, or by a dedicated team of engineers prepared to answer questions from other developers.

In summary, SDKs need precise legal and commercial definitions, an appropriate and understandable commercial model, great documentation, cool features, and solid support. If you have all these, your SDK should be successful.

Note: My thanks to Vladimir Dubovik at US Bank for asking the question that led to this post.

Imagine an attack in which the hacker controls all Internet traffic, and is able to redirect incoming requests for web sites based on the user's intention, a chosen industry category, or a target destination.

This scenario is called a Man-In-The-Middle (MITM) attack, and is achieved when a hacker is successful in "poisoning" or modifying the Domain Name Server cache.

Once a DNS cache is poisoned, it enables intelligent interception and redirection of web site requests to be managed from a point remote from the client (and the destination.) DNS poisoning is, in many ways, a case study in online criminal efficiency.

Next month, as everyone in the security industry now knows, Dan Kaminsky is going to step up to the mic at Black Hat and talk about something everyone already knows is a big problem - DNS insecurity.

So what is Kaminsky going to tell us? The fact that an out-of-sequence patch was issued by Microsoft two nights ago (a patch that apparently kicked users of Zone Alarm firewalls off the Internet) explains where the problem probably lies.

The Register (which refers, accurately, to DNS insecurity as "the mad woman in the attic" and a "peripheral, forgotten issue") added some color today, unearthing a 2005 paper from Ian Green which makes for some interesting reading. Here's a peek at his paper:

"...as the infamous Mitnick vs Shimomura attack and other subsequent attacks have shown, many weaknesses in network protocols are a result of poor implementation rather than weaknesses in the underlying protocol. In the Mitnick attack, 'IP source address spoofing and TCP sequence number prediction were used to gain initial access'."

Hmmm. Can you can tell what is coming next? Three pages later, post a few hours of research, Green writes, of his target research (the XP DNS Resolver):

"The DNS transaction ID always begins at 1 and is incremented by 1 for each subsequent DNS query; and... the UDP source port of the query (which becomes the UDP destination port of the response) remains static for the entirety of a session (from startup to shutdown)."

In other words, Green has followed Mitnick's advice and found exactly what was predicted: stupid levels of predictability. The DNS transaction ID, which is allowed to be a random number 16 bits long, has been implemented in such a way it can be easily guessed ("n" + 1).

In his paper, Green faults Microsoft's flawed implementation of DNS in XP ("ten years after the Mitnick attack"). The Register article uses this as the basis of a theory about what Kaminsky is going to talk about - a theory that was bolstered by MSFT's out-of-sequence patch this week.

Anyway, let's assume that's right. That leaves us Internet users with a problem. Mitnick first paved the way 13 years ago. Green's paper, which was published by the SANS Institute, came out three years ago, in 2005.

If it turns out this is what Kaminsky is going to talk about, why is everyone assuming the problem will be taken care of quickly?

The truth is, it won't. Only a minority of vulnerable users will hear about this and download and install the patch - leaving lots of room for those folks looking to pull of the perfect Internet crime - the MITM, or Man In The Middle attack.

Note: It would not be proper for me to sign off without pointing out that a solution exists for XP users: Every single DNS request made inside Authentium SafeCentral is handed off to our secure DNS service.

This ensures that even users with totally compromised machines get to where they want to go, without experiencing an MITM.

This morning, the editors of the Hartford Courant took a walk down the Yellow Brick Road and found courage, smarts - and a heart.

In an editorial this morning entitled "Drop The Charges" the Courant challenged Connecticut prosecutors to drop the bogus charges they have lined up against Julie Amero and take the retrial off the books.

In writing the piece, they proved that it is never too late to right a wrong, or claim back some respect.

For anyone unaware of this case, Julie Amero was the schoolteacher who was kicked out of her job after pornographic pop-ups appeared on an un-patched, unprotected school computer in front of several students.

Lots of people have since looked at the exact code she was looking at at the time (thank you archive.com) and found unmistakable evidence that this is probably among the worst cases of injustice ever perpetrated in the short history of Internet-related crimes.

Amero was without any shred of doubt very unjustly punished - there were links in the code that I saw that led to places other than those advertised, popups that aggressively spawned new popups, and let's face it, even if Amero went everywhere the prosecutors claim, why isn't the IT guy at the school attracting attention for not keeping the schools filters up to date?

The whole idea of having filters is so that kids don't get exposed to stuff like this - no matter what actions adults take.

The Courant compares Amero's current dismal state with that of some of the borderline inmates waiting for trial in Guantanamo. This isn't nearly as crazy as it sounds. Amero is also sitting in limbo waiting for prosecutors to get off their buts and admit they don't have anything.

Hartford folks, when your local politicians come to you for re-election, please do all of us a favor and ask them where they stand on the Amero issue. Make it a local issue.

Take a brave action - like the Courant has done today - and vote some prosecutors into place that will make your community worthy again of respect.

IBM, Google and the Swiss Federal Institute of Technology have just come out with a really interesting study. The subject was the relative security of the 1.4 billion users of the four main browsers currently in distribution.


Browser security is the hot area of study right now. Last week I wrote a piece in the blog on man-in-the-browser attacks, describing why it is so important that you use a secure browser. If you haven't read it, you should. But back to the study.

The study looked mainly at two things: the security "holes" or exploits that currently exist, and the effectiveness of the update strategies used by the 1.4 billion users of the four main browser developers - Mozilla (Firefox), Microsoft (IE), Opera (Opera) and Apple (Safari).

Firefox, which uses a completely automated update strategy, won the day with 83.3% of users patched up to the latest version, compared to less than 50% of IE users. IE users chose to ignore patches far more often because of IE's "permanently put-off this update" approach - leaving them more open to browser-based attacks.

As the ArsTechnica overview of the report states:

"Firefox and Opera are both credited for including an auto-update feature, but the team notes that "Firefox's auto-update was found to be way more effective than Opera's manual update download reminder strategy." How effective? way more effective."

We like Firefox at Authentium. Authentium's SafeCentral end-to-end transaction security solution utilizes a specially-hardened version of Firefox 3 in conjunction with our system-level hardening technologies and a secure DNS system.

If you're thinking of downloading FF3, or upgrading, I'd recommend you go over to the site and get yourself a really secure browser.

Note: the ARS article was entitled "40% of Surfers Don't Bother With Browser Security Updates" - for us and all the other people working in risk mitigation, the fact that there are half a billion unpatched browsers out there is one scary fact.

Bank Infosecurity's Linda McGlasson has an excellent post over at her site today on what happened during a real-world, real-person penetration testing exercise at an (unnamed) financial institution.


I had had two discussions this week CSO at banks who said they are becoming overwhelmed with similar real-world security problems, like social engineering of their call-center staff and proper checking of vendors and hosting companies at the front desk.

The bottom line is that a lot of nice people just want to be nice - and that makes them easy targets for people looking to do "walk-in" style attacks. These nice people need to be better trained to understand that sometimes being nice involves being firm and inflexible.

In any case, locking down these vectors is the correct place to start. The correct prioritizing of security efforts involves first locking down the physical premises. Putting in place advanced network security is only effective in conjunction with a robust and wide-ranging set of security policies that includes every potential attack vector.

Linda's blog can be found here.