DNS Cache Poisoning

What?

Ideally, you give a DNS server Name Server a false address record and get it cached. Then, when a user makes a request to that DNS server, the cache is your fake record! Boom, the user, unbeknownst to them, is now a victim.

How did the Attacker do it?

1. At some point, some name server asks for the IP address of some domain.
   1. E.g. ISP sends out request 123 asking for google.com.
2. We (malicious actors) send a bunch of request responses to ISP, trying to brute force the potential request ID’s.
   1. E.g. We (malicious) send 100 requests, from request 80 → request 150, all saying that google.com is at our Evil IP.
3. If any of those hit, then we got our Evil IP cached on the ISP’s name server.

More about the query:

• The Query ID is often a randomised, 16-bit identifier and return port.
• So if we spammed it, then you may have a decent chance at guessing it.

Taking it 1 step further:

• What if the someone requests 123random.google.com? Since it’s not in the cache, it does DNS to find the authoritative name server.
• What if you set up a name server that knows 123random.google.com? This leads them to a compromised server.

Defences against it:

• Port Randomisation AND Request Randomisation: The identifier can be spammed, but what if we randomise the source port? Then the chances of guessing that also drops.
• Limit Cache Lifetime (TTL - Time To Live): Minimises impact of poisoned cache by expiring records quickly.
• Rate Limiting: Limits the number of DNS responses processed per second from the same source.
• DNSSec