iptables, NAT, DNS & Dan Kaminsky

iptables, NAT, DNS & Dan Kaminsky

[Richard Hartmann]

Hi all,

as you are very likely all aware, Dan Kaminsky uncovered a major exploit
in RFC-compliant DNS caching servers the successful execution of which
relies on port prediction/guessing.

After quite some research, I have come up with the following facts which
I want to cross-check with you guys so I can be _sure_.


1) The --random target for SNAT exists since 2.6.22 to allow 'fixing' of
broken DNS servers in your NATted LAN along the lines of

iptables -t nat -I POSTROUTING 1 -p udp -s 1.2.3.4 --dport 53 -j SNAT \
--to 1.2.3.4 --random

Is that correct?


2) Unless there is a collision, the original UDP source ports for
requests are kept the same. I.e. boxes within the NATted LAN which use
random UDP ports are secure and neither the 2.4.x nor the 2.6.x series
of kernels will make those ports predictable while NATting the packets.
Is that correct?


3) Ever since a commit that went into 2.6.24 [1], UDP ports that are
NATted are randomized by the NATting forewarder, anyway. This means that
any DNS lookup made from within a NATted LAN secured with iptables to a
DNS server outside of said NAT is secure by default.
Is that correct?


Thanks for any and all input. I am sure many people would like
clarification on those points.

Richard


[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30

Re: iptables, NAT, DNS & Dan Kaminsky

[Thomas Jacob]

On Wed, 2008-07-30 at 16:53 +0200, Richard Hartmann wrote:
> Hi all,
> 
> as you are very likely all aware, Dan Kaminsky uncovered a major exploit
> in RFC-compliant DNS caching servers the successful execution of which
> relies on port prediction/guessing.
> 
> After quite some research, I have come up with the following facts which
> I want to cross-check with you guys so I can be _sure_.
> 
> 
> 1) The --random target for SNAT exists since 2.6.22 to allow 'fixing' of
> broken DNS servers in your NATted LAN along the lines of
> 
> iptables -t nat -I POSTROUTING 1 -p udp -s 1.2.3.4 --dport 53 -j SNAT \
> --to 1.2.3.4 --random
> 
> Is that correct?

One of the main points of the Kaminsky exploits allegedly is
(but who knows for sure, it hasn't been published yet) that
the bind people weren't using a cryptographically secure
random number generator for the transaction ids (which aren't
affected by SNAT I gather) and the fixed but random query
source port. Sure they also didn't change the query source
port for each query, but the question is if this is really
the most important part of the equation. 

I rather suspect that the random32 generator in the Linux
kernel is not cryptographically secure, and you will not
be changing the transaction ids.

The question therefore is if you will really gain a lot
of security with respect to the exploit in question. Hmm..

We'll know next week :)

Re: iptables, NAT, DNS & Dan Kaminsky

[Richard Hartmann]

On Wed, Jul 30, 2008 at 18:39, Thomas Jacob <jacob@internet24.de> wrote:

> One of the main points of the Kaminsky exploits allegedly is
> (but who knows for sure, it hasn't been published yet)

The exploit _has_ been published and Dan confirmed it. The
current Metasploit implementation is not as fast as Dan's
version, but it works. Several people reported expoits in
the wild that are actively abusing said security hole.


> The question therefore is if you will really gain a lot
> of security with respect to the exploit in question. Hmm..

Yes. You increase the entropy from 2^16 to 2^32 - 1025.
This is not great security and DNSSEC is the only viable
long-term solution, but right now, I am concerned to fully
understand the impact of the exploit with regards to my
three questions.


> We'll know next week :)

We know right now. You have a chance of approximately
1/3000 to successfully exploit an old DNS caching server.
But you have to sit off the TTL each time so the attack
vector is impractical for most uses. Now, you can mount
a hundred attacks per second. That means you can
chew through the 3000 tries you need on average in less
than a minute.
With the higher entropy, I don't know the chances for a
successful exploit, but they are so low as to provide
some protection.


I am especially concerned about question 2:
Do all versions of iptables available in kernels 2.4 and 2.6
use the original source port for their NAT traffic, by default?
If not, what are the earliest versions that did this?


Thanks,
Richard

Re: iptables, NAT, DNS & Dan Kaminsky

[Thomas Jacob]

> The exploit _has_ been published and Dan confirmed it. The
> current Metasploit implementation is not as fast as Dan's
> version, but it works. Several people reported expoits in
> the wild that are actively abusing said security hole.

Hmm, am obviously not up to date ;-)

> 
> > The question therefore is if you will really gain a lot
> > of security with respect to the exploit in question. Hmm..
> 
> Yes. You increase the entropy from 2^16 to 2^32 - 1025.
> This is not great security and DNSSEC is the only viable
> long-term solution, but right now, I am concerned to fully
> understand the impact of the exploit with regards to my
> three questions.

But are you really? My point is that the sequence of numbers both of
the old bind random number generator and also, probably,
the one used in the Linux kernel, can easily be predicted, if
you can get hold of a small number of samples. Maybe that's
irrelevant to the attack, but why did the bind people include
OpenBSD's ARC4 PRNG then, accepting the big performance penalty this
apparently causes... but I should really check out the details of the
exploit...

Re: iptables, NAT, DNS & Dan Kaminsky

[Michael Rash]

On Jul 30, 2008, Richard Hartmann wrote:

> Hi all,
> 
> as you are very likely all aware, Dan Kaminsky uncovered a major exploit
> in RFC-compliant DNS caching servers the successful execution of which
> relies on port prediction/guessing.
> 
> After quite some research, I have come up with the following facts which
> I want to cross-check with you guys so I can be _sure_.
> 
> 
> 1) The --random target for SNAT exists since 2.6.22 to allow 'fixing' of
> broken DNS servers in your NATted LAN along the lines of
> 
> iptables -t nat -I POSTROUTING 1 -p udp -s 1.2.3.4 --dport 53 -j SNAT \
> --to 1.2.3.4 --random
> 
> Is that correct?

Yes (but see below) - you may be interested in this post:

http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html

> 2) Unless there is a collision, the original UDP source ports for
> requests are kept the same. I.e. boxes within the NATted LAN which use
> random UDP ports are secure and neither the 2.4.x nor the 2.6.x series
> of kernels will make those ports predictable while NATting the packets.
> Is that correct?
> 
> 
> 3) Ever since a commit that went into 2.6.24 [1], UDP ports that are
> NATted are randomized by the NATting forewarder, anyway. This means that
> any DNS lookup made from within a NATted LAN secured with iptables to a
> DNS server outside of said NAT is secure by default.
> Is that correct?

That commit applies to the UDP stack itself and is independent of any
iptables NAT functionality.  That is, the source port assigned to a
local UDP socket is randomized, but only if a bind() does not otherwise
request a specific source port.  You can also use the SNAT --random
option in an iptables rule to force a random source port even for those
applications that request a specific source port (the blog post above
has an example of this).

There is also another important factor for the attack which is that any
nameserver that is behind a NAT device that removes any randomness that
the server builds into the UDP source port (regardless of whether this
is accomplished by a patched nameserver or something like the SNAT
--random option is used) will once again make the server vulnerable (at
least from the source port predictability problem).  At this point
randomized transaction ID's become really important - and insufficient.

BTW, I emailed Dan about the first version of his DNS checker tool (see
http://www.doxpara.com) not accounting for cases where the targeted
nameserver is behind something like the SNAT --random feature.  The
source port appears to be predictable because of iptables state
tracking, but only if one testing server is used - Dan has since updated
the DNS checker to use five different testing servers, so the change in
the tuple means the different source ports are assigned and the checker
detects this.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

> 
> 
> Thanks for any and all input. I am sure many people would like
> clarification on those points.
> 
> Richard
> 
> 
> [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html