[kwlug disc.] DNS security threat

Rashkae rashkae at tigershaunt.com
Fri Aug 1 11:00:47 EDT 2008


Insurance Squared Inc. wrote:
> Is that correct, about running an internal DNS?  Because that's exactly
> what I do (DNS on local server, behind my home router/firewall.  It
> serves to the public only my domains and serves the internal network
> with any domain).  Yet the testing tool shows my DNS as being unsafe. 
> It's not clear to me, because it's not even clear to me what the exploit
> is - unsure if they've even released this.
> 
> Is there patches available for the common DNS packages like bind?
> 
>


Here's how the attack works.  let's suppose, I want to poison a DNS
cache so any request for www.google.com will instead go to a malware phony.

First I send a request to the DNS server to resolve a bogus hostname,
like say, aaaa.google.com

The DNS server sends a request to google's NS to resolve the name

My attack then tries to spoof an answer.  If my answer guesses the
correct 16-bit transaction ID *and* reaches the DNS server before
google's answer, my spoofed response will be taken as correct.  This is
an old attack, but wasn't practical, because you only had one shot.

What's new with this 'attack' is, when I send my spoof, not only do I
have an A record for something useless like aaaa.google.com, but it
turns out, thanks to DNS design, I can include any *other* google.com
record, and it will ovewrite cache.  So I can overwrite the DNS server's
record for www.google.com, or as the new attack goes, overwrite google's
NS record and effectively hijack the entire domain.

Note that this attack can be repeated with any randomeGarbage.google.com
until the spoof finally succeeds.

As far as the patch goes, as fas as I can tell, it only makes the DNS
server randomize the IP port it uses to make the initial connection.
This way, not only does the attacker have to brute force the random
16-bit transaction ID, but now has to brute force a random port number,
effectively making the 'key' that needs to be brute-forced 32-bit (2
random 16 bit numbers)

That's why NAT screws it up, and the tool will report you aren't patched
if your DNS server is behind a NAT.  No matter how random the DNS server
makes it's request, the NAT will remap that to it's own convenient port.
 (maybe next generation NAT will randomize all ports used by any
outgoing connections.)  In any case, if the evildoers outside your
network can't send that aaaa.google.com request to your DNS server, they
can't launch the attack.  Rather than 32-bits of randomness, you are
protected by an extra layer of computers.  An attacker would have to
compromise or zombie one of your computers inside the NAT to then attack
the DNS server, which would then possibly redirect computers to phony
sites.  Does seem like a lot of extra work when they *already* have the
computer inside the network compromised, however.




More information about the KWLUG-Disc mailing list