3 ms·

Abusing anti-DDoS mechanisms to perform DNS cache poisoning

27 points by p4bl0 13y ago

peterwwillis 13y ago
If i've got this right, here's how the attack works: 1. Make a resolver (your ISP) query a nameserver (ns.godaddy.com) until the nameserver's DDoS protection kicks in (dropping DNS queries). 2. The resolver's s queries are getting dropped now, so it re-tries them over and over. While the resolver waits for a response from the nameserver, you send the resolver Kaminsky packets to poison its cache. According to the slides, this works everywhere that Response Rate Limiting is enabled and set to "2" (the default). Apparently this has been known for some time. Here's a response from ISC on the whole thing: http://www.isc.org/blogs/cache-poisoning-gets-a-second-wind-from-rrl-probably-not/ http://www.isc.org/blogs/cache-poisoning-gets-a-second-wind-... An article by Paul Vixie at the bottom has the most insight about the whole thing.
- axaxs 13y ago
  Pretty close. Step 1 isn't quite right - you can't make your resolver send queries repetitively as it will just use its cache. The attack involves sending tons of queries to the auth server yourself(or, from a botnet) - but spoofing to appear that you are the resolver you are poisoning. The auth server starts dropping queries from this ip, allowing you to send it answers with greater chance of successful poisoning.
- RyanZAG 13y ago
  I believe you've got this incorrect: We have the following: ServerWeb ServerDNS Attacker Background: To poison DNS for ServerWeb, Attacker will need to send forged DNS packets to ServerWeb from ServerDNS. However, ServerWeb will only accept packets for the short interval between requesting the lookup and receiving the reply. In practice, that makes poisoning the DNS extremely unlikely. DDoS protection: A completely unrelated attack on ServerWeb by Attacker is to send a spoofed DNS request to ServerDNS from ServerWeb. This DNS request uses very few bytes. However, the answer to this request sends many more bytes. This means that Attacker only needs X bandwidth to create a DDoS of 100X bandwidth on ServerWeb. To avoid this, ServerDNS will simply ignore these types of requests that generate a lot of data. The problem: If Attacker is able to make ServerWeb request these types of large response DNS queries from ServerDNS, ServerDNS will simply not reply. This is very good for Attacker as he now has a good 10 seconds or more to forge the correct request and poison ServerWeb. The attack shows how the complexity involved in DNS and other web protocols can quickly go out of control when making seemingly simple 'fixes' to stop newly discovered attacks. Understanding the repercussions of even minor changes to any part of the infrastructure can have unintended side effects.
AsymetricCom 13y ago
The original vuln that invited in this kludge: http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html The solution to this kludge? > What has ANSSI done to improve the security of the DNS? > ANSSI led a 4 months alert campaign, warning DNS software vendors and critical DNS operators (such as the root operators and several TLD operators). aka, nothing, more kludge, push complexity off onto clients.

27 points by p4bl0 13y ago

If i've got this right, here's how the attack works: 1. Make a resolver (your ISP) query a nameserver (ns.godaddy.com) until the nameserver's DDoS protection kicks in (dropping DNS queries). 2. The resolver's s queries are getting dropped now, so it re-tries them over and over. While the resolver waits for a response from the nameserver, you send the resolver Kaminsky packets to poison its cache. According to the slides, this works everywhere that Response Rate Limiting is enabled and set to "2" (the default). Apparently this has been known for some time. Here's a response from ISC on the whole thing: http://www.isc.org/blogs/cache-poisoning-gets-a-second-wind-from-rrl-probably-not/ http://www.isc.org/blogs/cache-poisoning-gets-a-second-wind-... An article by Paul Vixie at the bottom has the most insight about the whole thing.

axaxs 13y ago
Pretty close. Step 1 isn't quite right - you can't make your resolver send queries repetitively as it will just use its cache. The attack involves sending tons of queries to the auth server yourself(or, from a botnet) - but spoofing to appear that you are the resolver you are poisoning. The auth server starts dropping queries from this ip, allowing you to send it answers with greater chance of successful poisoning.
RyanZAG 13y ago
I believe you've got this incorrect: We have the following: ServerWeb ServerDNS Attacker Background: To poison DNS for ServerWeb, Attacker will need to send forged DNS packets to ServerWeb from ServerDNS. However, ServerWeb will only accept packets for the short interval between requesting the lookup and receiving the reply. In practice, that makes poisoning the DNS extremely unlikely. DDoS protection: A completely unrelated attack on ServerWeb by Attacker is to send a spoofed DNS request to ServerDNS from ServerWeb. This DNS request uses very few bytes. However, the answer to this request sends many more bytes. This means that Attacker only needs X bandwidth to create a DDoS of 100X bandwidth on ServerWeb. To avoid this, ServerDNS will simply ignore these types of requests that generate a lot of data. The problem: If Attacker is able to make ServerWeb request these types of large response DNS queries from ServerDNS, ServerDNS will simply not reply. This is very good for Attacker as he now has a good 10 seconds or more to forge the correct request and poison ServerWeb. The attack shows how the complexity involved in DNS and other web protocols can quickly go out of control when making seemingly simple 'fixes' to stop newly discovered attacks. Understanding the repercussions of even minor changes to any part of the infrastructure can have unintended side effects.

AsymetricCom 13y ago

The original vuln that invited in this kludge: http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html The solution to this kludge? > What has ANSSI done to improve the security of the DNS? > ANSSI led a 4 months alert campaign, warning DNS software vendors and critical DNS operators (such as the root operators and several TLD operators). aka, nothing, more kludge, push complexity off onto clients.