Roland started off by explaining the basics of DNS Cache poisoning and the details of the trick discovered by Dan Kaminski last year. Explaining why you don’t have to wait for the answer to expire to in order to poison the cache.

Quite a bit of the patching done after the Kaminski attack became public is actually been undone by NAT-ing firewalls, who do not randomize the source ports the use to keep track of their NAT table.

The DNS resolvers put up by Rick and his team at HAR where attacked, but nobody was able to poison it as projected by Bert Hubert.

DNSSEC uses public/private key cryptography to sign DNS records. Because this makes the packets larger, you do not need a DDoS attack to cause a DoS, but you can do it with a single computer.

DNSSEC uses a two tiered key model. There is a key signing key (>= 2048 bit RSA) and a zone signing key (>= 1024 bit key). DNSSEC users additional resources records. For keys: DNSKEY, DS, Signatures: RRSIG and for authenticated denial-of-existance: NSEC or NSEC3. This will make zones quite a bit larger.

So how is the signature validated? Each answer has a signature in it. So we need to get the key in a way we can trust. The hash of the key of each domain is signed by the key of the domain below it.

DNSSEC on .com and .net will be signed by 2011. Signing of the root (.) zone is expected by the end of this year. Since only a few zones are signed we have islands of trust each with a trust anchor. There are interim solutions for this like https://itar.iana.org and ISC “DNSSEC look-a-side validation”. These solution all have their own trust issues like SSL or their reliance on DNS.

There is a lot of work going on at the moment because root zone signing is there.

Even tough there are a lot of problems with DNSSEC, but even the critics agree that it is the only solution we have available at the moment. The biggest lack at the moment is easy to use tools. Luckily a lot a people are working on this.

The alternatives to DNSSEC are maybe worse. Patching against vulnerabilities is an arms race. SSL and TLS is too heavy for the lightweight DNS protocol is not an issue, and SSL has its own issues. TSIG does not scale because it relies on shared secrets and DNScurve is just not available.

Surfnet has implemented DNSSEC for their resolvers and was able to validate 1% of the answer. 1% is a higher adoption rate then IPv6.

You can help by helping open source projects like PowerDNSSEC or OpenDNSSEC.

Bert Hubert introduced us in the world of DNS. He opened by stating that “DNS is Scary and complex” and “DNS it is everywhere”.

Why is DNS scary and complex. DNS answers consist of a single UDP packet with binary variable length fields. It is a common misperception that DNS answers end in a NULL character. E.g. \3www\9my\0domain\3com\0 is a valid answer for www.my\0domain.com so same bug that is present in may SSL implementation may also exist in DNS.
DNS compression also causes issues, because it allows you to use pointers to refer to other parts of the answer. This other part of the answer can contain a pointer as well which means you can cause a loop. Some DNS implementations will follow these endless loops very fast.

In order to have a secure and stable DNS implementation you need to do each and everything right

DNS is everywhere and there is more and more devices containing DNS like 20 euro ADSL routers who interfere with your DNS queries, camera’s, phones. DNS also has more and more alternative uses like anti-virus, advertising and also censorship.

What are the threats to DNS?
The main risks are around availability. If there is no DNS, “The Internet is Down”. A single resolver may be servicing anything from 1 to more then 100,000 users. The largest authoritive DNS server hosts more then 8,000,000 zones.

Exploitation is also a risk. If you owning a DNS you own the internet for the users trusting that DNS, also if you own the DNS server you usually own the box the DNS is running on.

Another further interesting angle is integrity. If the DSN sends you the wrong way, your traffic goes to the wrong server and your money will follow.

When you talk about availability, the situation is not very good, it is extremely easy to kill a DNS server. It only takes about 10,000 well designed queries per second to kill a resolver. If you can generate about 50,000 queries per second you will be able to kill an authorative server. This is why large companies like akamai and large provider have stacks and stacks of DNS servers.

Exploitation is also a risk, typical resolver routines in common OS-es and appliances have very old DNSSEC code of 1984 in it. The most scaring part is that nobody seems to care, the original windows XP used ’1′ or ’2′ as its random DNS transaction ID.

Integrity however is the biggest issue. The whole internet is built on top of DNS. From a technical perspective DNS spoofing is easy: anybody can answer a DNS query if they have the right source IP, destination port and transaction ID and the right name on it and should arrive before any other answer.
Luckily changes of doing this successfully are 1:2,000,000,000, before people stated to patch for the Kaminski code, the changes was 1:65535. By randomizing the source port the time to get a 50% change of spoofing DNS increased from 10 seconds to 10 hours.

Currently in order to successfully spoof DNS you need to create too much traffic. This traffic will kill the DNS servers and “People notice that”.

But what if we are patient and start a slow attack? If we regenerate 100 queries per second, we have a 50% change of succeeding after trying for 6 weeks. However if you spoof . (the root zone) 6 weeks it not that long to wait. Because once I can spoof the root zone, I own the DNS for that resolver.

The details of this technique is kept quiet because it works very well. The countermeasures against it don’t work or these measures break too much stuff.

What are the medium term solutions?
Why not do DNS over TCP? Most people will tell you that this is not performing well enough, but this is mainly because the RFP states that there should be a 2 minute timeout.
Another solution might be to send every DNS query three times and pick the majority answer. However round-robin servers or servers like Akamai will actually give you an different answer for every query.
The speaker has proposed an alternative solution, EDNS-PING, and extra 16 bit number added to DNS.

What are the long term solutions?
DNSSEC does solve all spoofing risks, unfortunately it increases the packet size and thus increases the DoS risks. Also DNSSEC only works if everybody uses DNSSEC.

The speaker believes that DNSSEC is way too complex. That is why he created PowerDNSSEC, because “if we use DNSSEC it should be easy”.

In summary:
•    DNS security is hard to get right, which is bad because it is everywhere.
•    Slow DNS attacks are worrying and there are no real countermeasures.
•    If DNSSEC is not done right it will only make it more complex.

Moxie developed a tool and technique called SSLSNIFF which is able to do undetectable Man in the Middle attacks on SSL connections exploiting the possibilities null terminated certificates offer. He defined three possible counter measures against his attack. Certificate validation, software updates and extended validation certificates. Unfortunately he was able to defeat two of these three measures.
Certificate validation these days is handled mostly by the OCSP, the Online Certificate Status Protocol. Marlinspike found a flaw in the protocol. On of the statuses the OCSP can send back is “Try later…”, represented by the number 3. Such a reply does not need to be signed by the CA an causes the browser to fail open, or as Moxie put it: “OCSP is defeated by the number 3”.
Software updates can be another issue. At the time of the presentation, these bugs where only fixed in Firefox 3.5, so how do you prevent people from updating to this version? Most browsers these days have a so called auto update function, this function searches online for a more recent version of the browser, addons or plugins. In order to ensure that no malicious content is installed, the browsers rely on SSL, the same SSL that was broken by Marlinspike’s SSLSNIFF.

But there is more trouble in paradise. Marlinspike also demonstrated a technique het called ssl stripping. Ssl stripping does not attack SSL itself, instead it actually attacks, what Moxie described as the bridge between http and https. “Https is today’s world is not often encountered directly. Users don’t often type https:// in the address bar themselves. In stead they get redirected to an https site or click on a link to it”. By performing an man in the middle attack on the http connection and carefully rewriting all https requests to http requests, Marlinspike was able to create near exact copies of the login pages for services such as gmail and paypal. The user would only know something is wrong, if they notice that the https prefix is not there or that the padlock symbol is missing.

Dan Kaminski was also able to exploit the common name field to get certificates he should not be getting. Different implementations of certificate validation routines have flaws when it comes to handling certificates with multiple common names in them. By requesting a certificate with three common names: CN=www.ioactive.com, CN=www.bankofameric.com and CN=* Kaminski was able to get a certificate that would perceived as follows; the CA would sees the certificate as an www.ioactive.com certificate, which Kaminski is allowed to request. Internet Explorer will interpret the certificate as a www.bankofamerica.com certificate and Firefox will allow the certificate to be used for any url.

Besides the common name abuse, Kaminski also showed us that there is still an MD2RSA signed root certificate present in all browsers. While practical exploitation is not possible at the moment, it is very likely that this possible in the near future. Most browser vendors are working to fix the issue right now, but Kaminski kindly requested his public to “please, do not hack MD2 in the next six months.”

The last talk I attended was Mike Zusman’s “Criminal Charges not Pursued, Hacking PKI”. Mike used another technique to get “interesting” certificates. By exploiting a flaw in the web application of a CA, he was able to request certificates for pretty much any domain he wanted.

One of the solutions seems to be popping up is Extended Validation, which in a sense takes us back a couple of years. A few years back, the only way to buy a certificate was to provide legal evidence that you had control over a domain via an out of band mechanism to a human, but then these persons at the CA’s where replaced by an online application with an automated validation process and the fun started.

Extended Validation changes this by enforcing standards for validation and requiring validation by a human before the certificate gets issued. Extended Validation (EV) CA’s are hard coded in the browser to prevent the addition of malicious CA’s. But EV certificates get trusted just as much as classic certificates.

Mike Zusman was able to perform a man in the middle attack PayPal, which uses an EV certificate to protect its site. What his program does is only redirect a small portion of the traffic, the actual login, to his own malicious website which has a non-EV www.paypal.com certificate obtained via on of the methods described earlier. The only side effect visible to the user is a brief flickering of the green address bar. But will a user notice or care?

Obviously dual factor authentication, like PayPal’s security key, will reduce the risk, but what can we really do?

I was able to share a beer with Mike after he presentation and it looks like there are fundamental underlying problems with the current certificate structure. Here we have architecture of trust, yet its foundations are built on the known insecure DNS database. Browser vendors claim they have this set of rules that should be obeyed in order for a CA to be included in the browser, yet practice shows that certain CAs that have not followed these rules are still in the browser, while on commercial CAs, like CAcert are having a hard time getting included in browsers for what seems to be political reasons.
It is time to ask ourselves fundamental questions like: Is it a good thing that a browser vendor determines who’s assertion of identity to trust. There is a trend that browsers make it harder to accept invalid certificates. Mike said: “It currently takes more clicks to accept an invalid certificate, then to import a new CA”. Is this a good thing?

Both Zusman and Kaminski agree that is would be a good thing if we had a trustworthy DNS structure that we could just to, e.g. store the fingerprints of certificates that are valid for our domain. Unfortunately DNSSEC is currently in a status quo. The current implementation still got issues, but until the root servers are going to be signed nobody will be motivated to fix these issues.