DNSSEC, from an end-user perspective, part 3

In the first post of this DNSSEC series, I have shown the problem (DNS vulnerabilities), and in the second post, the "solution." In this third post, I am going to analyze DNSSEC. Can DNSSEC protect the users against all of the attacks? Or just part of them? What about corner cases?

The following list are the attack types from the first post, where DNSSEC can protect the users:

• DNS cache poisoning the DNS server, "Da Old way"
• DNS cache poisoning, "Da Kaminsky way"
• ISP hijack, for advertisement or spying purposes
• Captive portals
• Pentester hijacks DNS to test application via active man-in-the-middle
• Malicious attacker hijacks DNS via active MITM

The following list are the attack types from the first post, where DNSSEC cannot protect the users:

• Rogue DNS server set via malware
• Having access to the DNS admin panel and rewriting the IP
• ISP hijack, for advertisement or spying purposes
• Captive portals
• Pentester hijacks DNS to test application via active man-in-the-middle
• Malicious attacker hijacks DNS via active MITM

If you are a reader who thinks while reading, you might say "What the hell? Am I protected or not???". The problem is that it depends… In the case where the attacker is between you and your DNS server, the attacker can impersonate the DNS server, downgrade it to a non DNSSEC aware one, and send responses without DNSSEC information.

Now, how can I protect against all of these attacks? Answer is "simple":

1. Configure your own DNSSEC aware server on your localhost, and use that as a resolver. This is pretty easy, even I was able to do it using tutorials.
2. Don't let malware run on your system! ;-)
3. Use at least two-factor authentication for admin access of your DNS admin panel.
4. Use a registry lock (details in part 1).
5. Use a DNSSEC aware OS.
6. Use DNSSEC protected websites.
7. There is a need for an API or something, where the client can enforce DNSSEC protected answers. In case the answer is not protected with DNSSEC, the connection can not be established.

Now some random facts, thoughts, solutions around DNSSEC:

• Did you know .SE signed its zone with DNSSEC in September 2005, as the first TLD in the world?
• Did you know DNSSEC was first deployed at the root level on July 15, 2010?
• Did you know .NL become the first TLD to pass 1 million DNSSEC-signed domain names?
• Did you know that Hungary is in the testing phase of DNSSEC (watch out, it is Hungarian)?
• Did you know that you can also use and test that cool DNSSEC validator?
• Did you know that there are alternative solutions like DNSCrypt?
• Did you know that in the future you might be able to enforce HSTS via DNSSEC?
• Did you know that in the future you might be able to use certificate pinning via DNSSEC?

That's all folks, happy DNSSEC configuring ;-)

Note from David:

Huh, I have just accidentally deleted this whole post from Z, but then I got it back from my browsing cache. Big up to Nir Sofer for his ChromeCacheView tool! Saved my ass from kickin'! :D

DNSSEC, from an end-user perspective, part 2

In our previous blog post, we have discussed some of the threats against current DNS systems, where the result was that the victim landed on a different resource/website as he/she originally supposed to visit.

Since this is not a guide for DNS server operators about DNSSEC implementation, let's jump to the user side and see what you should know if you visit a website where DNSSEC validation fails (like the test site http://www.dnssec-failed.org/) and you use a DNS server which validates the DNSSEC responses (e.g., 8.8.8.8 - Google public DNS server):

So far, so good :-) The malicious attacker's evil plan has failed. But what should you see when the server is protected with DNSSEC, and the DNSSEC response is valid/trusted?

Please note that this "green key" stuff is for experimental purposes only. I hope the users should not have to look for another SSL-like padlock in their browser in the future. The critical thing here is that the site has been rendered by the browser, and the response is protected by DNSSEC, thus eliminating lots of threats.

When you visit a site that is protected by DNSSEC, but your DNS server does not validate the DNSSEC, the site will be served and rendered in your browser. It does not matter if it has untrusted or invalid DNSSEC records. This is the same experience what you have today with no DNSSEC at all:

OK, so we, as end-users, need sites/domains which are protected with DNSSEC, and a DNS server which validates the DNSSEC records. We have the DNS server (thx Google!), so let's find some popular sites which are using DNSSEC!

To demonstrate my 133t h4cking skills, here is a small bash script. You give a file with the list of domains as a first parameter to the bash script, and it will give you back the areas protected with DNSSEC.

#!/bin/bash
dig . DNSKEY | grep -Ev '^($|;)' > root.keys
while read line
do
    if dig +sigchase +trusted-key=root.keys $line. A @8.8.8.8 | grep --quiet "DNSSEC validation is ok: SUCC"; then
        echo $line
    fi
done < $1

Alexa was not kind enough to give me a recent list of top sites in text format, so I have used http://moz.com/top500 for this test.

The results were quite shocking; the first result was at TOP40: gov.uk - but when you visit gov.uk via browser, it is redirected to a subdomain that is not protected with DNSSEC, so this kind of behavior is considered as FAIL.

TOP69: nih.gov  - so ironically, the winner is the National Institute of Health :P

Other interesting one where:

mozilla.org - FAIL 

cdc.gov - FAIL

nasa.gov - FAIL :(

ca.gov  - California homepage, don't mess with Arnie!

noaa.gov - National Oceanic and Atmospheric Administration :)

berkeley.edu - thank god the world of universities is saved

loc.gov - FAIL

whitehouse.gov - FAIL …

I think I have never ever visited these websites before, except the Berkeley one. If you can find a financial institution which website's domain is protected by DNSSEC, let me know. I was not able to find one… For example, paypal.com is a bad example. The main domain is protected with DNSSEC, but not the www.paypal.com.

In the next part of our DNSSEC series, I will write about the threats eliminated by DNSSEC and some other exciting things.