My reason for replying to this thead is to say that “we have other solutions in place for this, why one more?”
On 8/13/18, 16:43, "DNSOP on behalf of Brian Dickson" <dnsop-boun...@ietf.org<mailto:dnsop-boun...@ietf.org> on behalf of brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>> wro >While it is easy to misunderstand what Duane is referencing, or perhaps there >was some minimization on his part as well, there is a weakness caused by the >unsigned nature of delegations, whereby not protecting (e.g. via zonemd) a >publication point against a host of vulnerabilities, by protecting the data >itself, creates a very attractive target that lets an adversary scale their >attack very effectively. I think the fears are greatly exaggerated. We have much experience with bad glue, usually as a result of fat-fingering and poor decommissioning practices. So there’s some real-world information to work on. When glue is fat-fingered, traffic is either reduced or not received at the authoritative server. As fat fingering is the culprit, the zone administrator (usually well connected to the authoritative servers) will know to make an edit somewhere. I’ve handled one very interesting case of malicious cache poisoning that proved to be due to poor decommissioning. A zone administrator noted that their mailhost address was “poisoned” repeatedly at an open recursive service. This service permitted remote purging of entries, so even I could go to the service, purge the record, execute a query, see the correct value appear and then replaced by the poisoned value. The result of this “went to litigation” so I never got a documented final report. (I’m omitting some details so as not to expose the case, despite this being about 6 years ago.) But what I did uncover, via calls to the victim and other traces was this. A sysadmin was fired from the store (from the phone call). He then (because the cell number traced him in WhoIs to the next employer) went to a competitor and set up their DNS (WhoIs records). He apparently knew that the victim had transitioned their DNS services from hoster A to hoster B but neglected to purge all of the glue records at the registrar (otherwise, the needle in the haystack would be seen). This left the glue record still in the database of the TLD and he was able to have an NS record refer to the owner, thus getting the TLD to respond with the should-be-cruft glue. Due to the failure of the recursive server algorithm (it was home grown) to follow at least the trustworthiness rules in “Clarifications to the DNS”, and without DNSSEC in place, the recursive service believed the stale glue over the authoritative answer for the glue. After a query for the victim was seen, all that needed to happen was a query for the attacker’s new zone to swap out the glue value, the latter query could have been delivered via a cron entry. The danger in this case was that mail traffic was misdirected from the victim to the attacker as a denial of service (impact on business operations). The victim’s MX record’s RDATA domain name was the same as the malicious NS record mentioned before. In that case, DNSSEC would have helped, a solution we already have but not in place. Additionally, and this was a conversation I never got to have, the open recursive service’s implementation choice permitted the attack to happen, (I do know it wasn’t a bug, I did get to speak to the lead engineer but never had the chance to educate them) once again, a solution is already there (better software!). So, I can attest to glue being a weakness. That’s not in question. >Here's the gist of the problem, inherent in unsigned glue: >IF (big if, with the how/when/where etc kept as a separate discussion) an >attacker manages to modify glue (for example, poisoning a resolver's cache for >glue info), the attacker has the opportunity to selectively return unmodified >glue, or to replace further glue data (and continue to be a DNS-MITM) and thus >both view queries, and if/when the queries cross to insecure delegations, >modify non-glue data. For example, if there is a TLD "foo", and the attacker >manages to poison the A record for one (or more) names of NS for "foo", the >attacker can act as a forwarder for most *.foo names, but then selectively >modify the A records for the NS for "bar.foo", and then for "blech.bar.foo", >until there is an insecure delegation, at which point the attacker can spoof >any RR type for any name below that zone cut. The attacker also has control >over TTLs of any/all spoofed records, modulo recursive resolver's TTL >ceiling/floor. The attacker can gain further information about the ongoing >success of attacks by TTL-based meta-monitoring (high TTL on delegation glue, >low TTL on sub-delegation glue, observe sub-delegation re-queries at the >spoofed delegation point.) Once the tree falls to “insecure” land, all bets are off. (And this is hard to determine, as trust anchors define the root of secure subtrees, not necessarily what’s in authoritative servers.) >Even in the case of an all-DNSSEC sub-tree, some attackers may see value in >observing ALL the queries (and answers);being a DNS-MITM (via modified glue) >achieves this, even for an off-path attacker who normally would not have any >visibility to the UDP/53 packets. If one is overly concerned about someone seeing traffic flows, there are a number of steps to take. Sending a potentially telling query along an unsecured reference is not one of them. For one, getting the authoritative version of the glue can be done (this is done in parallel, not before, when traffic inspection fear is less than the desire to get a page loaded). And then there’s all the privacy widgets being invented. >The above scenario works even on networks you trust, and even with resolvers >you know and trust, as long as there is the ability to attack the glue. A >single successful attack on a single resolver's glue has the potential to >result in a persistent long-lived DNS exploit, the scope of which is largely >limited by the attackers resources and/or intent and/or desire to evade >detection. Application of such an exploit is an exercise in Kaminsky, i.e. the >danger is obvious. Glue is just a hint. Over time it has been confused as something more significant, such as when the old COM/NET/ORG servers would put it into the answer section of referrals (a practiced ended before DNSSEC was operationalized). The solution to this has been better software. >IMHO, this is the antithesis of "uninteresting". > >The theoretical existence of this sort of attack, should be motivation enough >to advocate for greater DNSSEC deployment efforts. It should motivate any and >all methods of preventing undetected (and undetectable) modification of glue >records when copies of zone data are retrieved. A centralized distribution >point without data integrity protection of some kind, becomes a very scalable >place for an attacker to do bulk attacks against large numbers of resolvers. A >centralized distribution point WITH data integrity protection that scales, >provide protection against both centralized AND decentralized (direct cache >poisoning) attacks, thus justifying the effort on doing this exact thing. > >P.S. Documenting aspects of the more-than-theoretical poisoning attacks are >long overdue; when time permits, I will work on this, possibly with interested >parties. Any/all are welcome to work on this with me, FYI. A somewhat flippant reply – treating theoretical attacks contributes to software bloat without benefit (cue a camel joke). I mean this seriously – I’d like to see a risk assessment of what’s involved to judge whether as solution is needed or not. With the way the DNS is defined and operated today, if it was possible to seal up all the holes and cracks, it would have been done by now. I’d concentrate on demonstrated problems without solutions. Outside of the lone cache poisoning case I’ve dealt with, I am eager to see any published descriptions of real (more-than-theoretical) attacks.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
