Re: DNS Poisoning via Port Exhaustion

[David Dagon <dagon () sudo sh>]

On Tue, Oct 18, 2011 at 11:14:56PM +0200, Roee Hay wrote:
> Hey,
>
> Today we are releasing a very interesting whitepaper which describes a DNS
> poisoning attack against stub resolvers.
>
> It discloses two vulnerabilities:

This is an interesting paper; I'd like to offer some comments.

The paper states, in S. 4.1, that the average time for success is:

$  E(T) = \frac{t}{p} = \frac{t*2^{16}}{\lfloor\frac{b*l}{s}\rfloor}  $

You might clearly note that this assumes a fixed source port (perhaps
a realistic assumption for your scenario), with only the QID
randomized.  You might also contrast your estimate to that provided in
RFC 5452, which additionally considers duplicate outstanding queries
and TTL; see Section 7 of http://tools.ietf.org/rfc/rfc5452.txt

Although a simple ratio is handy, yours does not consider a diversity
of authority IPs (which an attacker of course knows, but must also
guess when forging a response).  I think this is important.  Most
zones have a minimum of 2 NS (enforced by common registrar practice),
but 5 is very common for popular (read: target) zones.  RFC 1912's
recommended max of 7 is perhaps a sane upper bound.  This
significantly decreases the chance of success (albeit by a linear
scale).  I suggest the estimates are at least half off, and more for
popular zones.  Your paper states that tens of minutes (or so) is your
limit for a realistic attack, making the change in estimated success
significant.

For the payload size, s, you use 120 bytes.  While this is a
reasonable estimate for IP packets on wire with a DNS payload, should
one not also include common MTU values in your chart, e.g., 512, 1280,
etc., for remote, and 1492 bytes, etc., for local attackers?  This
seems more realistic for a bandwidth-limited attack.

For the latency, l, you show values of 1ms, 10ms, 50ms and 100ms.  I'm
not sure 1ms or even 10ms are realistic values for real-world
zones---even internals zones.  These values do help illustrate the
linear decrease in attack success found when higher speed DNS paths
are used, and perhaps that's the point.  But with real world RTTs
often between 100 and 150ms, you might expand the chart a bit.

Attackers always get a vote in latency, however, and perhaps you might
consider scenarios where l is artificially extended, e.g., by DoS'ing
authorities.  You can use an upper bound from the DNSQueryTimeouts key
in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, (defaulted
to 1sec, 2sec for the first two queries on preferred servers).
Similarly, for most default linux distros, a 3 seconds window is
reasonable for back of the envelope estimates.  

I realize you are perhaps illustrating how 'l' affects E(T) for a
range of values.  But the use of 1ms (even 10ms) just seems
unrealistic (unless you were considering an mDNS-based attack on a
local zone, not discussed in your paper).

It would be interesting if your testing included whether injection of
icmp(3,{3,13, etc.}) packets (forged by an attacker as coming from the
legitimate zone's NS) would prevent the caching of legitimate records.
An attacker could always win this packet race, since their average
latency is likely half that of the DNS path.  As far as I'm aware,
stub reaction to icmp signals on DNS queries is not well documented.
This would also permit retries; your paper seems to suggest low TTLs
provides an opportunity. (In any event, as Kaminsky took pains to
demonstrate, queries for nonce child labels in target zones allow one
to retry poisoning attempts.)

If you plan on expanding this work, you might look at application
caching (perhaps focused on the browser), since many browsers add
yet-another layer of cache that does not always respect the TTL.  I
suspect this lowers the attack success during the initial phase of an
attack, though one would expect poisonous RRs to have significantly
longer TTLs (thereby making even local caches vulnerable after cache
expiration).  Beyond rebinding, the forgery resistance of these caches
is not well known.

Overall, this is an interesting look at stub/local resolution, for the
otherwise well-studied problem of DNS poisoning via port exhaustion.
Thanks for sharing.

-- 
David Dagon
dagon () sudo sh
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave