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

DNS response and error types

In this post we explore common DNS response codes. We will cover the following responses: NOERROR SERVFAIL NXDOMAIN NODATA REFUSED Throughout article we’ll refer to the following RFCs: RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE) RFC 8914 - Extended DNS Errors Response Codes - RCODEs The DNS RCODES are best defined in RFC2316 .  They signify what type of response was sent by the server. “RCODE   Response code - this four bit field is undefined in requests and set in responses.”   The table below shows the summary of the currently defined RCODEs. Mnemonic Val Description NOERROR 0 No error condition.

DNS blocking in Indonesia

DNS based censorship and domain blocking in Indonesia is very inconsistent among ISPs. There’s a government mandated black list which the ISPs operating in the country should enforce. However, Indonesia lacks centralised internet infrastructure and has many separate ISPs. In addition, the Indonesian government granted ISPs the authority to block content at their own discretion. All of this leads to a very inconsistent DNS blocking in Indonesia. Official DNS domain blacklist in Indonesia The Government mandated DNS blacklist is published in a redacted form and can be downloaded here: https://trustpositif.kominfo.go.id/ . This is where the blocked domains get redirected to. We can search the database and check if a domain is blocked. In the screenshot below we can see that a popular cryptocurrency exchange is blocked (Ada) and that wikipedia.org is not (Tidak Ada) - thanks to Google Translate. Examples of blocked DNS queries dig binance.com @182.253.45.122 ;; global options: +cmd ;; Got