Skip to main content

Types of DNS poisoning attacks

DNS poisoning attacks are commonly referred to as DNS cache poisoning attacks. In reality DNS cache poisoning is only one class of DNS attacks. I have handled many real word DNS poisoning attacks but I have never observed actual cache poisoning attacks in the wild.
 
In this post we will cover the different types of DNS poisoning attacks, explain why they should not be referred to as DNS cache poisoning and make the case for a more relevant name for this class of internet censorship tactics.  
 
For brevity, this will be a high level overview of the types of DNS attacks. Each will be covered in
detail separately in a dedicated blog post.
 
I distinguish three types of network/server side DNS attacks:

1. DNS Cache Poisoning
2. DNS injection
3. Rogue DNS server  

The above attacks don’t require any modification of the DNS client’s OS or the last mile router/modem.

While outside of the scope of this article, for completeness client side based DNS attacks can be divided into the following:

 
1. OS modification  
  •     malware adding host entries  
  •     malware changing the DNS settings
2. Router modification   
  •     Local malware changing the DNS settings on the router  
  •     External changes to the router’s DNS settings (for example using UPnP or exposed administrative interfaces)

What’s a DNS cache?

In order to understand why most DNS poisoning attacks are not cache poisoning attacks firstly let’s cover what the DNS cache is.

DNS is a distributed hierarchical database. Parts of DNS data are distributed and spread across many globally distributed servers. Each DNS record has a Time To Live (TTL) value. TTL specifies (in seconds) how long a DNS record can be cached for. As a side note, some DNS servers do not respect the TTL and overwrite it but we will explore it in a different post.

In order to reduce the load on the servers and speed up the resolution process valid responses are cached in memory (the DNS cache) for the duration of the TTL.

When a recursive DNS resolver (see What's a recursive DNS query?) resolves a name for a DNS client, it caches the name in its cache. When the resolver is queried for the same name within the duration of the TTL, it instantly returns the record from its cache. The client caches the result in its cache too.

Now that we know what a DNS cache is…

DNS Cache Poisoning attack

In this attack, malicious dns records are inserted into the DNS server’s cache. Once cached, the server will return the data from its cache for the duration of the TTL.

This attack relies on timing. The attacker queries the resolver for the target domain name and the attacker itself returns a spoofed result to the resolver.

High level steps are as follows:

  1. Attacker queries the target resolver for target.example.com
  2. Resolver issues an iterative query on behalf of the client for target.example.com
  3. Attacker sends a spoofed DNS response to the resolver pointing target.example.com to the IP address of attacker’s choosing
  4. Resolver receives the spoofed response and inserts it into its cache
  5. Resolver’s cache has been poisoned

Simple in theory, but extremely difficult and impractical to pull off. The attacker needs to get many things right for this to succeed and he must do all of it before the real answer arrives - which is usually measured in milliseconds.

I have personally never seen this happen in the wild and I consider this largely a theoretical attack nowadays.  

DNS injection attack

In this type of DNS attack, a network traffic monitoring device injects spoofed responses.

This attack is relatively easy to carry out (assuming the attacker controls the network) because DNS uses the UDP protocol.

When a monitoring device detects a DNS query for a censored domain, it forges a fake response and sends it to the client.  This attack can be implemented by an in-path or an off-path device. This technique is used by state actors to implement country based censorship.

For example in China, the Great Firewall of China (GFW) injects the fake response however it doesn’t block the original query nor it drops the real answer. It relies on its logical proximity to the DNS clients to ensure the fake responses arrive faster than the valid ones.

We will look at this behaviour in detail in a post dedicated to DNS injection attacks where we’ll break it down by country. 

Rogue DNS server attack

In this type of attack a legitimate DNS server is configured to return fake responses. This attack can be carried out by an external actor (someone hacking a DNS server) or an internal actor (for example someone at an ISP).

In my research I have seen this attack affecting single servers, ISP in a specific region of a country and a whole ISP.

Summarising

In this very high level post we’ve outlined three types of DNS attacks. We covered what the DNS cache is and explained why only one of the attacks actively targets the servers’ cache.

Comments

Popular posts from this blog

x.509 Certificates - Critical vs non-critical extensions

Extensions are used to associate additional information with the user or the key.  Each certificate extension has three attributes - extnID, critical, extnValue extnID - Extension ID - an OID that specifies the format and definitions of the extension critical - Critical flag - Boolean value extnValue - Extension value  Criticality flag specifies whether the information in an extension is important. If an application doesn't recognize the extension marked as critical, the certificate cannot be accepted. If an extension is not marked as critical (critical value False) it can be ignored by an application. In Windows, critical extensions are marked with a yellow exclamation mark,  View certificate extensions using OpenSSL: # openssl x509 -inform pem -in cert.pem -text -noout (output abbreviated)         X509v3 extensions:             X509v3 Key Usage: critical                 Digital Signature, Key Encipherment             X509v3 Subject Key Identifier

Cisco ASA Certificate Revocation Checking

ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP. Revocation checking using CRL: Over HTTP: ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-crl)# protocol http By default ASA will use address listed in CDP extension of the certificate that is being validated.  To override default behaviour we need to add the following in the CRL configuration context. ciscoasa(config-ca-crl)# policy static ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl Over LDAP: Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved.  ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# crl configure ciscoasa

Count number of lines - 'findstr'

How do I count number of lines in a command output? findstr /r/n "^" | find /c ":" Above commands will display number of lines output by whatever command (well, nearly whatever) you specify in the front.  For example:  C:\>ping localhost | findstr /r/n "^" | find /c ":" FINDSTR: // ignored 12 This comes handy if you want to find out how many OUs you have in Active Directory: dsquery ou  -limit 0 | findstr /r/n "^" | find /c ":" How many user accounts there are: dsquery user -limit 0 | findstr /r/n "^" | find /c ":" Computers: dsquery computer -limit | findstr /r/n "^" | find /c ":"