My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

BIND 9 DoS attacks in the wild

Published: 2009-07-29. Last Updated: 2009-07-29 19:53:16 UTC
by Bojan Zdrnja (Version: 1)
7 comment(s)

Earlier today Marc posted a short diary about a vulnerability in the Internet Systems Consortium's BIND 9 (all versions). As you almost certainly know, BIND is the most popular DNS service application running on majority of DNS servers today – and DNS is one service that we *really* need.

As the DoS attacks have been seen in the wild, and simple scripts that can be used to reproduce the attack are also easily available, this is not really surprising.

I wanted to draw your attention to this vulnerability (if you are running a BIND DNS server) – although the vulnerability exists in the dynamic update feature of BIND, even installations that have dynamic updates disabled are affected! This makes this vulnerability especially dangerous.

Only servers hosting master zones are vulnerable though, so even if the master DNS servers are down, all slaves should still continue to work (I'm not sure what happens if those slaves are masters for some other zones and they are subsequently taken down).

No workarounds exist – you might be able to create some firewall rules that will drop these packets though. In any case, it is recommended to upgrade your BIND DNS servers urgently from https://www.isc.org/node/474

--
Bojan

Keywords: bind dns dos
7 comment(s)
My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

Comments

Not to blow our horn too much, but all the ThreatSTOP name servers that are accessible from the Internet are secondary/caching ONLY, so if you're using us for your recursive NS (you have to be an actual subscriber to do that), we'll continue to operate.

ThreatSTOP

Jul 29th 2009
1 decade ago

Please keep in mind that the exploit works with _any_ master zone. On recursive Nameservers you often load localhost., 127.in-addr.arpa and 192.168.in-addr.arpa for example to lessen the RFC1918 load on the root nameservers, you can trigger the exploit with these zones too.
Also they are BCP and part of Team Cymru's secure bind template. ;-)

ZaphodB

Jul 30th 2009
1 decade ago

Because of what the TS query servers are designed to do, they don't load any masters. Recusrive service is provided because, for the simplest way to use TS, it is necessary that we do so, so we did it in the most secure, stable and fast-loading way we possibly could. It has turned out to be a pretty useful feature, even if it is simply an unintended consequence of making implementation of the core functionality simpler for users.
BTW: the public Threatstop.com zones, and the servers that serve them, are not protected in this way. W're in the same boat as everyone else eon that one.
So, if you're using the Dshield lists in public DNS (basic*.threatstop.com), I'd recommend signing up for the basic ThreatSTOP service. It's free to try, and since the original team is now back in control (as of yesterday), we're going to keep Basic/DShield free (as in beer, you'll have to send logs) forever.

ThreatSTOP

Jul 30th 2009
1 decade ago

if you don't need updates, you can try u32 for udp/tcp variant.
iptables -I INPUT -p udp --dport 53 \! -f -m u32 --u32 "0>>22&0x3C@8>>11&0x05=5" -j DROP
iptables -I INPUT -p tcp --dport 53 \! -f -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@2>>11&0x05=5" -j DROP
this is working for me, but small fragments still can slip by probably


tk

Jul 30th 2009
1 decade ago

The iptables rule for TCP above doesn't seem to work for me (UDP works great). Can you test this ? I've tried with no luck to modify it. Thanks.

vom

Aug 1st 2009
1 decade ago

tcp is not the default behavior, so you have to ... do something.
anyway it's working (in lab), it's the same, just in 0x
#iptables -I INPUT -p tcp --dport 53 \! -f -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x2>>0xb&0x5=0x5" -j DROP
# iptables -nvL
Chain INPUT (policy ACCEPT 462 packets, 36250 bytes)
pkts bytes target prot opt in out source destination
6 636 DROP tcp !f * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 u32 0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x2>>0xb&0x5=0x5

tk

Aug 2nd 2009
1 decade ago

Hmm, yes I'm using the perl script posted in the Debian bug report to test. It still gets through on tcp (setting Net::DNS 'usevc' to use tcp). Are you crafting a packet differently to test your rule ? My packets skip right past this every time and hit on my allow tcp/53 :( Thanks anyway.

vom

Aug 3rd 2009
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives