Dailydave mailing list archives
Re: DNS Poisoning via Port Exhaustion
From: Roee Hay <ROEEH () il ibm com>
Date: Wed, 19 Oct 2011 23:56:47 +0200
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
Current thread:
- DNS Poisoning via Port Exhaustion Roee Hay (Oct 18)
- Re: DNS Poisoning via Port Exhaustion David Dagon (Oct 19)
- Re: DNS Poisoning via Port Exhaustion Roee Hay (Oct 19)
- Re: DNS Poisoning via Port Exhaustion David Dagon (Oct 19)