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 1

We all know since at least 1990 that the DNS protocol is insecure. Yet DNS is still the basis of almost all Internet communication. The biggest problem with DNS is that a malicious attacker can redirect victims, where victims try to connect to, e.g. safesite.com, but instead of this, they relate to the attacker's website. There are a lot of different ways to achieve this attack.

DNS cache poisoning the DNS server, "Da Old way."

The attacker forces the victim's DNS server to resolve a domain where the attacker is the authoritative name server, and the attacker sends additional information to the DNS server that he is also the authoritative name server for safesite.com. This information is cached and used later when the victim resolves safesite.com.

It is easy to protect against this attack, any decent DNS server should be able to protect against this attack by dropping this additional information from DNS responses.

DNS cache poisoning, "Da Kaminsky way"

An attacker can initiate queries to the victim's DNS server, and in the meantime, "flood" the DNS server with fake responses. The server will accept the fake response if the following conditions are right: 

• the DNS server receives the answers on the same IP as it expects (this is not an attack limitation), 
• the DNS server receives the answer to his question (again not a limitation, an attacker knows what he wants to attack),
• the random(?) port used to send the query matches the answer, 
• the random(?) 16-bit(!) unique transaction number in the answer matches with the query.

If the last two are not random, an attacker can easily poison the server in a matter of seconds. Or if your DNS server is behind NAT, the NAT can remove the randomness :-O

To protect yourself against this, you should randomize the source port and unique identifier better, and disable your DNS server as being an open recursive resolver.

Rogue DNS server via malware

This is pretty common in both banking trojans, adware, etc. The malware reconfigures the users configured DNS server to use a malicious one, either in the local OS settings or in the home router.

To protect against this: don't let malware in your environment ;)

ISP hijack, for advertisement or spying purposes

This is the worst of all. ISP's hijack non-existing domains, and display advertisements. And because they broke the RFC, it will break a lot of your applications. I bet ISPs still think about this as a good idea :(

Sometimes the ISP hijacks your connection because the government wants to spy on your communication or divert it. Use TOR wisely if you don't want to be a victim.

Captive portals

Sometimes captive portals use DNS hijacking to redirect the users to the default login page. Although it breaks things, it is still better than the ISP solution, because it is only a problem at the beginning of the connection, and not permanently.

Pentester hijacks DNS to test application via active man-in-the-middle

Although this is not malicious at all (developers might think otherwise), but a lot of application security tests (thick clients, mobile applications) can only be carried out via DNS spoofing. Application security testers can easily make this attack because they can place the host machine in a network segment where they can make an active man-in-the-middle attack and respond to DNS queries sooner as the official DNS server. Or simply set the DNS server to their own DNS server.

Malicious attacker hijacks DNS via active MITM

This is similar to the previous one, but the goal is different. Although an attacker with active man-in-the-middle position can attack the victim in 1000 different ways (like SMB relaying, capturing LM/NTLM network hashes, modifying clear-text traffics, etc...), DNS spoofing is one of them.

Having access to the DNS admin panel and rewriting the IP

I believe this is going to be a new trend. This attack is the most effective one, and the hardest to prevent. Usually, it is not the admin panel that is being hacked, instead an admin's password gets stolen, or the password reset is hacked.

You, as a client, can do three things to protect against this attack:

1. Choose a decent provider and prey :)
2. Put a registry lock on your DNS settings (serverDeleteProhibited, serverTransferProhibited, and serverUpdateProhibited). Although this additional layer is good enough today, I bet some motivated attackers will be able to successfully attack this. The attacker only has to:
   • know the phone number of the client, which will be called by the registrar
   • hijack the call (social engineering the phone company)
   • provide an individual security phrase (social engineering the client)
3. Or run your own DNS server (this is not a solution for everybody)

Conclusion 

Although almost all attacks can be mitigated one way or another, there was a desperate need to solve this DNS spoofing issue once and for all. And so it begins, DNSSEC has been developed.

In part 2, we are going to investigate DNSSEC, what you can expect from it, and what you can't.