Re: DNS Poisoning via Port Exhaustion

[Roee Hay <ROEEH () il ibm com>]

Hello David,

Thank you for the great and thorough feedback!

- Our formula does indeed assume that a fixed port is used for queries. 

- Regarding multiple outstanding requests, this can be a good topic for 
future research, as multiple unanswered queries of the same host might be 
consolidated by the stub resolver. 

- Since we attack stub resolvers, we do not need provide forged responses 
with a zone authoritative nameserver, but rather with the recursive 
nameserver which is preconfigured. We assume that this is known for the 
attacker, and for the sake of simplicity also assume that only one 
nameserver is configured (so yes, the number of nameservers is omitted 
from the formula).

- As for the payload size, can you please elaborate on your intentions for 
providing multiple MTUs on the chart?

- The idea for providing low 'l' values is that the whitepaper describes 
two different attacks of internal zones (see 3.3.2 and 3.3.3).

- Re icmp:  very interesting, a good topic for future work, this only 
relates to the Java attack (as for the local attack, we have shown that a 
non-administrative user can flush the DNS cache).

- Re browsers caches: The impact analysis of the Java vulnerability 
naturally assumes that the cache is a browser one, Since browsers neglect 
the TTL value (DNS pinning).  we've only dealt with NX domains (and 
127/8). Despite that, I totally agree that it's very interesting to 
research the internals of the DNS cache of various browsers.

Thanks again,
Roee Hay





From:   David Dagon <dagon () sudo sh>
To:     Roee Hay/Haifa/IBM@IBMIL
Cc:     dailydave <dailydave () lists immunityinc com>
Date:   19/10/2011 11:39 AM
Subject:        Re: [Dailydave] DNS Poisoning via Port Exhaustion



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