Home / server / Questions / 40798
Accepted
Bill Gray
Asked: 2009-07-15 15:40:53 +0800 CST

kaminsky bug - bailiwicks

  • 772

I have been reading about the kaminsky DNS bug, trying to better understand how it works. I think I have the gist of it, but Dan mentions bailiwicks, being used to target DNS servers behind firewalls.

Can someone explain what a bailiwick is, and give an example of how it is used to target servers behind firewalls to exploit the kaminsky bug?

domain-name-system security

2 Answers

  1. As mentioned by Mark Johnson, the bailiwick of a DNS server is the set of domains it is authoritative for. At a time, recursive name servers accepted out-of-bailiwick data from authorititative name servers. So, the name server authoritative for foo.example could add additional data in his answer stating the IP address of www.bar.example and he was believed. This was the basis of the Kashpureff attack. For a long time, name servers no longer believe out-of-bailiwick data, as instructed by RFC 2181, section 5.4.1.

    The Kaminsky attack does not use out-of-bailiwick data and therefore worked with recent name servers as well. The Linux Journal article mentioned by Luke Quinane explains it very well (but the rest of the Luke Quinane's post, specially about firewalls, is questionable.)

    Regarding firewalls, this is mostly an unrelated issue. If a name server wants to receive answers to its queries, it needs to be reachable so, whether it has a firewall or nor in front of it does not matter: the Kaminsky attack needs only one channel, the DNS one.

    Since the Kaminsky attack is on the name server that client machines will use, whether these machines are protected or not by the firewall does not matter. (A good example of why a firewall is not a magic device and does not protect everything.)

    • 6
  2. Best Answer

    Bailiwick

    The Linux Journal article that Ehtyar posted has a pretty good explaination of what a bailiwick is and how it relates to DNS. Basically, extra records are added to a DNS response to help find delegate DNS servers. To quote the example from the article:

    $ dig @ns1.example.com www.example.com
;; ANSWER SECTION:
www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
example.com.        86400    IN    NS   ns1.example.com.
example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800   IN    A    192.168.2.20
ns2.example.com.    604800   IN    A    192.168.3.30


    Attack

    Details on the attack are in Dan's slides (see slides 24/25). To attack a server behind a firewall:

    • A lookup for a subdomain of a domain the attacker controls (e.g. '1.badguy.com') is triggered.
    • The attacking server responds with a CNAME record for the domain its trying to poison (e.g. 'debian.org'). This causes a DNS query from the target to 'debian.org'.
    • As soon as the attacking server sends the CNAME referal it starts streaming in spoofed DNS responses that include an additional response (e.g. 'security.debian.org' pointing to the IP address of 'badguy.com').
    • If the transaction Id in the response is correctly guessed, the server behind the firewall now thinks 'security.debian.org' resolves to the bad guy's address.

    There are plenty of ways to get the server behind the firewall to lookup an IP address, internal client requests, resolving IP addresses in server logs, etc. As bortzmeyer mentions the firewall is largely irrelevant in this attack.

    • 3