My 100th blog post, and why my blog entries never have titles.


Hey all, this is my 100th blog post. And again, it has no title. This is not due to me feeling too cool to provide one, it's simply a matter of my "create" window in blogger not having a title field. I don't know why.

Anyhow, the real reason for the blog post: As of today, I'm done with my exams. Which makes me very happy, and will hopefully mean I will get around to blogging more often.

I think everybody should read FX's excellent post.

A few short notes on what's being reported:

It seems that after my previous speculation, a few unforeseen things happened:

• Apparently, my post, while partially incorrect, was somewhere close to the truth
• A third party accidentally posted full details on the issue, which corrected my mistakes. Shortly after posting these details, the post was pulled down again, but was archived by search engines (and those that had subscribed to the blog where it was posted).

There have been a number of slightly incorrect press reports which I'd like to clarify:

• I posted a partially incorrect, but close, guess on what the DNS issue might be. That is not the same as "publishing a reliable way to poison DNS". It is guessing how it might be done.
  
• I did not pull down any posts from my blog.
  

I do not think anything I have posted takes away from Dan's superb work on this issue. Some people are of the opinion that I "stole his thunder" for his Blackhat talk, and I disagree strongly: Dan's talk is a full hour on DNS, and all the interesting things within DNS. My post was a vague guess.

Imagine: A world-renowned particle physics expert decides to give a one-hour lecture in your hometown, and on your way there some guy on the street tells you "I think he will talk about (...30 seconds of physics here...)". Would you decide that listening to the physics expert talk is no longer necessary because the guy on the street told you everything ?

Also: Guessing how something is done knowing it can be done is easy. Dan did the hard part: Coming up with a clever attack in a protocol that is relied on everywhere. My guess doesn't come close to comparing to what Dan has done: He spotted something that everyone else missed beforehand. He also handled the entire situation with a lot of endurance, patience, and determination. We disagree on whether people have a right (or even duty) to discuss what the issue might be, but that doesn't mean that I do not have the greatest respect for Dan. And his talk will contain much more of interest than my silly 30 lines.

I think (German news site) Heise summed it up well:
"In fact, all of Dullien's hunches had already been sketched out the day that US-CERT published a vulnerability note on the security hole."

I guessed. I was close, perhabs closer than others, but no cigar.

On Dan's request for "no speculation please"

I know that Dan asked the public researchers to "not speculate publicly" about the vulnerability, in order to buy people time. This is a commendable goal. I respect Dans viewpoint, but I disagree that this buys anyone time (more on this below). I am fully in agreement with the entire way he handled the vulnerability (e.g. getting the vendors on board, getting the patches made and released, and I understand his decision not to disclose extra information) except the proposed "discussion blackout".

In a strange way, if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves. Consider the following:

Let's assume that the DNS problem is sufficiently complicated that an average person that has _some_ background in security, but little idea of protocols or DNS, would take N days to figure out what is problem is.
So clearly, the assumption behind the "discussion blackout" is that no evil person will figure it out before the end of the N days.

Let's say instead of having an average person with _some_ background in security, we have a particularly bright evil person. Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days.

By asking the community not to publicly speculate, we make sure that we have no idea what N actually is. We are not buying anybody time, we are buying people a warm and fuzzy feeling.

It is imaginable that N is something like 4 days. We don't know, because there's no public speculation.

So in that case, we are giving people 29 days of "Thank us for buying you time.", when in fact we have bought them a false perception of having time. The actual time they have is N/4th, and we're just making sure they think that N/4th > 30. Which it might not be. It might be ... 1.

It all reminds me of a strange joke I was told last week. It's a russian joke that makes fun of the former east german government, so it might not be funny to everyone. I apologize up front: I am both german and a mathematician, so by definition the following can't be funny.

"Lenin travels with the train through Russia, and the train grinds to a halt. Engine failure. Lenin sends all workers in the factory that might be responsible to a labor camp.

Stalin travels with the train through Russia a few years later, and the train grinds to a halt. Engine failure. Stalin has all workers in the factory that might be responsible shot.

Honecker (the former head of State of the GDR) travels with the train through Russia. The train grinds to a halt. Engine failure. Honecker has a brilliant idea: "The people that are responsible should be forced to rock the train, so we can sit inside and feel like it is still running." "

It feels like we're all trying to rock the train.

If there was public speculation, we'd at least get a lower boundary on the "real" N, not the N we wish for.

So I will speculate.

The last weeks I was in the middle of preparing for an exam, so I really didn't have time to spend on the DNS flaw. I couldn't help myself though and spent a few minutes every other evening or so reading a DNS-for-dummies-text. I have done pretty much no protocol work in my life, so I have little hope for having gotten close to the truth.

As such, anyone with a clue will probably laugh at my naive ideas. Here's my speculation:

Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver
for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244.

Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com.
ns.polya.com doesn't have these requests cached, so it asks a root server "where can I find the .com NS?"
It then receives a referral to the .com NS. It asks the nameserver for .com where to find the nameserver for ulam00001.com, ulam00002.com etc.

Mallory spoofs referrals claiming to come from the .com nameserver to ns.polya.com. In these referrals, it says that the nameserver responsible for ulamYYYYY.com is a server called ns.gmx.net and that this server is located at 244.244.244.244. Also, the time to live of this referral is ... long ...

Now eventually, Mallory will get one such referral spoofed right, e.g. the TXID etc. will be guessed properly.

ns.polya.com will then cache that ns.gmx.net can be found at ... 244.244.244.244. Yay.

The above is almost certainly wrong. Can someone with more insight into DNS tell me why it won't work ?

*Blogspam*
Advanced Reverse Engineering Trainings Class

We still have a number of seats in our advanced RE class available. The class
will be held on the following three days:

1. Wednesday the 1st of October
2. Thursday the 2nd of October
3. Friday the 3rd of October

The class will be held in Frankfurt(Main) in Germany.
The class is limited to 17 students and will cover a lot of interesting ground. Amongst the things we will be teaching are:

• What a C++ compiler does and how to recognize these things in a binary:
• How to recover classes and inheritance,
• What templates will do in the binary
• Using the helping hand of MS RTTI to recover classnames and generate inheritance diagrams from the binary

• Getting the most out of the RE-DB SQL schema -- storing disassemblies in a uniform way in a database
• Differential debugging and isolation of security-critical features (e.g. "where in the world is the encryption code again ?")
• Crafting malicious input to reach target program locations
  
• Working on network infrastructure:
  
• Loading ROM images into IDA: IOS, Netscreen etc.
• Generic methods of identifying the base address
• Debugging IOS (and other network infrastructure) using BinNavi and the GDB protocol
  
• Using BinDiff to full advantage:
  
• Patch Diffing
• Porting comments & names
• Porting symbols of statically linked libraries (such as OpenSSL) back into your disassembly
  
• A reverse engineer's guide to static analysis:
• The reverse engineering intermediate language REIL
• Monotone frameworks, lattices, and fun things to do with them
• Lots and lots of fun things to do with Python
  

The class will be taught by me (Halvar Flake), Ero Carrera, and Felix 'Fx' Lindner.

The class will be held in a small Hotel called "Villa Orange" -- which has about 20 rooms, so usually the entire Hotel consists of reverse engineers.

For more info, visit
http://www.zynamics.com/index.php?page=trainings

Cheers,
Halvar
PS: It might be of interest to some readers that the Oktoberfest is from the 20th of September to the 5th of October this year -- this means you can either attend Octoberfest before or after the trainings class (although we recommend the latter).
*End of Blogspam*

Hey all,

> Supplemental note to Halvar & everybody else who has said, in effect, "this
> is why SSL was invented" -- there's more to internet security than the route
> from your computer to your online bank. Have you thought about what this
> bug implies for NTLM? Or every virgin OS installation on the planet? Or
> Google's entire business model?

just to clarify: I did not say this bug wasn't relevant, and I don't want my blog post to be construed
in that manner. What I did say was:

1. The average user always has to assume that his GW is owned, hence nothing changes for him. Specifically: He does not need to worry more than usual. Check SSL certificates, check host fingerprints. Don't use plaintext protocols.
2. For those providing DNS services, it is clearly preferrable to patch. A DNS system without trivial poisoning is preferrable to one with trivial poisoning.
3. In living memory, we have survived repeated Bind remote exploits, SSH remote exploits, a good number of OpenSSL remote exploits etc. -- I argue that the following inequality holds:
4. OpenSSL remote >= OpenSSH remote > Bind remote > easy DNS poisoning
5. I argue this because the left-hand side usually implies the right-hand side given some time & creativity.
   

The net has survived much worse.

So I guess summary is: Good find, definitely useful for an attacker, but we have survived much worse without a need for the great-vendor-coordination jazz.

Cheers,
Halvar
PS: I am aware that my sangfroid could be likened to a russian roulette player, that after winning 4 games concludes: "This game clearly isn't dangerous."
PPS: It seems that we will find many more critical issues in DNS over the next weeks - it's the first time in years that a significant quantity of people look at the protocol / implementations.

All this DNS ...

I am taking a very brief break from my books to write a few thoughts about this entire DNS thing that everybody seems to be writing about. And reading all this, I can't help but feel like the only one in the room that doesn't understand the joke.

So Dan Kaminsky found a serious flaw in the implementation of the DNS protocol, apparently allowing DNS cache poisoning. This is good work.

I fail to understand the seriousness with which this bug is handled though. Anybody who uses the Internet has to assume that his gateway is owned. That is why we have SSL, that is why we have certificates, that is why SSH tells you when the host key changes. DNS can never be trusted - you always have to assume that your ISP's admin runs a broken filesharing server on the same box with BIND.

If it were legitimate to operate under the assumption that your gateway is not owned, you would not need SSH, or SSL. If I could operate under the assumption that my gateway wasn't owned, I could TELNET everywhere, and transmit my credit card details in the clear.

I am not saying that Dan's bug doesn't have utility for an attacker -- it's definitely more comfortable/less time consuming to do DNS poisoning than to own the gateway. But for the user, nothing changes, irrespective of whether the patch was applied or not. The basic assumption is always my gateway is controlled by my opponent.

I personally think we've seen much worse problems than this in living memory. I'd argue that the Debian Debacle was an order of magnitude (or two) worse, and I'd argue that OpenSSH bugs a few years back were worse.

So, let's calm down everybody. And I'd even argue that installing the patches is a lot less time-critical (for the user) than in most other scenarios. If you act under the assumption of "my gateway is owned", this should be no risk to you.

The security book that I'd like to see written (and which I'd buy)

Good security books are few and far between. But IF someone writes the following book, I'll pre-order it immediately, even if it costs a hundred dollars:

"100 UNIX commands to issue on other people's systems"

Generally, I am horrible at all things *nix, and there are few enough good books around which teach you clever things to do with a shell. Unfortunately, there is no book that teaches people what to do with a shell on someone else's box.

Someone from Matasano told me they'd post their favourite commands if I wrote this blog post - so let's see it ! :)

(I'd like to start this by posting, but honestly -- I wouldn't be asking if I knew anything I'd not be embarrassed about. I mentioned above that I suck at all things *nix)