5 ms·
This attack vector is not something DNSSEC was ever intended to defend against, so why would it be mentioned? Once the registrar account associated with a domai
by magila 8y ago
This attack vector is not something DNSSEC was ever intended to defend against, so why would it be mentioned? Once the registrar account associated with a domain is pwned the attacker can do pretty much anything they want with it, including obtain fraudulent certificates.
- tptacek 8y agoAs Colm MacCárthaigh noted on Twitter, not only does DNSSEC not defend against the most likely and damaging DNS attacks (hijacking between clients and servers, and hijacking at the registrar), it actually makes things worse: an attacker who has achieved the vantage point these attackers have can use DNSSEC to semipermanently poison records by using it to sign high-TTL records. It's not my claim that DNSSEC is what enabled this attack in the first place. But there's no way I'm going to leave the irony of USG agencies laboriously configuring their security-theater DNSSEC protocol while not being able to defend their registrar accounts or get basic MFA deployed.
- Abekkus 8y agoHijacked high-ttl records for signed zones aren't more dangerous than hijacked, high-ttl records for unsigned zones. Why do you claim that they are? They are both invalidated through the same mechanisms. It would be nice if there were reasonable limits on TTLs, but I'm not getting invited to those meetings.
- jessaustin 8y agoEffort spent on DNSSEC might have been better spent on e.g. CT.
- tptacek 8y agoCT: extensively remarked on in this advisory.
- jessaustin 8y agoYeah I read it; I was highlighting this for parent.
- tptacek 8y agoSorry, was emphasizing, not correcting.
- deleted 8y ago[deleted]
- anoncontractor 8y agoAs someone who has recently dealt with a major government agency, the requirement of DNSSEC means that agencies can’t use Route53 as it doesn’t support DNSSEC. This makes it much less likely that an agency will use something like Terraform for managing DNS, which would help in making sure all records are validated and easily auditable. Instead, many DNS records are managed by hand or with bespoke systems. The best case is that it’s managed by maybe Akamai, but records are still updated via support tickets and implemented by hand (as akamai’s Terraform support is pretty bad). So it’s relevent to mention DNSSEC because it’s spoken of within the government as a method of securing DNS, but in reality it makes things worse. It doesn’t protect against attacks like these and the end result is you are forced to use a crappy system that makes you even more vulnerable to these sorts of attacks. It’s the worst of all worlds. (Also, I was on the call they held for CIOs and tech leaders of all agencies, and it was astonishing how many of the questions in their chat made it obvious that many of the entrenched players didn’t even understand how this attack worked.)
- minaguib 8y agoTangential, but since you mentioned Akamai. I wrote a framework at work that maintains authoritative DNS configuration truth (static, and advanced GSLB variations) as text files going through git and regular PRs, auditing, etc. The truth is then flushed out via APIs to multiple DNS providers (active-active), Akamai being one of them. Nobody's APIs are perfect, but I don't recall it being too difficult to push the state to their system.
- anoncontractor 8y agoFor sure, you can totally make something like this happen, but again that means writing and securing a bespoke system. If you’re a team managing your AWS infrastructure with Terraform, it sucks to have to write a totally different system (and all the secrets management that goes along with it). Additionally, for a government agency you could have dozens of contractor teams, and you need a method of securing access for all of them. It’d be much easier to just use Route53 and delegated subdomains, as all teams are largely deployed and managing infra (with MFA) there. But it’s not allowed, because DNSSEC.