The attackers launched a series of attacks on the .gh, .sl, and .as country code top-level domains (ccTLDs) and then modified authoritative DNS records for selected domains within those namespaces. By controlling those DNS records, the attackers were able to pass automated domain control validation checks and obtain unauthorized certificates for “several Google domains” and “several leading global brands and widely used online services.” Google said it updated Chrome to block all certificates it identified as unauthorized, and worked with the issuing certification authorities to ensure the unauthorized certificates for Google properties were revoked.
[...]
Google didn’t identify the affected domains it owns or name any of the other organizations whose domains were affected. While noting that Chrome users do not need to take any action to be protected, Google cautioned domain owners not to rely solely on browser-side interventions to protect their users. The company is advising domain owners to monitor certificate transparency logs for unexpected certificate issuance across their domains and to publish restrictive Certification Authority Authorization DNS records to prevent attackers from reusing cached validation data after DNS control is restored.
“While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users,” Google said. “Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.”
[...]
Google noted that the incident didn’t involve the compromise of the infrastructure of any of the affected domain owners and that certificate authorities followed all requirements. With control of the three ccTLDs, the attackers were able to change the IP addresses of a selected list of websites. With the ability to send and receive traffic on those sites, the attackers were able to modify authoritative DNS records and nameserver delegations for selected domains, allowing them to pass industry validation checks requiring an applicant to prove control of the domain.
Compromising on a TLD level is interesting and worrying at the same time. It means gaining access to those servers but also understanding enough of those systems to be able to return false...
Compromising on a TLD level is interesting and worrying at the same time. It means gaining access to those servers but also understanding enough of those systems to be able to return false information there. I’m curious how returning false information was even possible; I wouldn’t expect any of these DNS queries to even end up at a TLD. Anybody more knowledgeable have a more in-depth explanation?
That's how DNS works at a low level. There are root servers, which contain records which point to TLD servers, which in turn hold records which point to authoritative nameservers for a given...
I wouldn’t expect any of these DNS queries to even end up at a TLD.
That's how DNS works at a low level.
There are root servers, which contain records which point to TLD servers, which in turn hold records which point to authoritative nameservers for a given domain, which in turn hold the actual DNS records (AA, AAAA, cname, mx, and so on).
The kind of nameservers we usually interact with - like Google's 8.8.8.8 - cache results, do some stuff with regards to geolocation, etc, but when they don't know the answer to a query, or a cached record expires, they act as or forward to recursive resolvers which walk the hierarchy I just described. This is why dns propagation is a thing that takes time, it takes a while for cache invalidation and new records to propagate.
So what's going on here, as I understand it, is they hacked the TLD servers for the affected country codes to returned modified records for select domains pointing to authorative name servers they controlled, and in turn allowed them to change the DNS records to anything they wanted. The blast radius for this kind of thing is huge, as it breaks the foundation of trust which the internet is built on. Attackers can get automated SSL certs, send/receive email pretending to be from the compromised domain, redirect traffic, install themselves as an intercepting proxy (which is the very thing SSL is supposed to protect against)! Etc.
I think the only thing worse than this would be compromising a certificate authority.
but also understanding enough of those systems to be able to return false information there.
It's actually not that arcane. Iirc, the spec is documented, and even if it weren't, you can query the root, TLD, and authoritative nameservers yourself and figure out the response format. Unbound is popular selfhosted recursive resolver.
From the article:
[...]
[...]
I have no idea how bad this is, but I gotta tell you, that's not gonna be good for business.
Given that the tlds involved were
.gh,.sl, and.as(Ghana, Sierra Leonne, and American Samoa), I doubt that they were super high impact.Compromising on a TLD level is interesting and worrying at the same time. It means gaining access to those servers but also understanding enough of those systems to be able to return false information there. I’m curious how returning false information was even possible; I wouldn’t expect any of these DNS queries to even end up at a TLD. Anybody more knowledgeable have a more in-depth explanation?
That's how DNS works at a low level.
There are root servers, which contain records which point to TLD servers, which in turn hold records which point to authoritative nameservers for a given domain, which in turn hold the actual DNS records (AA, AAAA, cname, mx, and so on).
The kind of nameservers we usually interact with - like Google's 8.8.8.8 - cache results, do some stuff with regards to geolocation, etc, but when they don't know the answer to a query, or a cached record expires, they act as or forward to recursive resolvers which walk the hierarchy I just described. This is why dns propagation is a thing that takes time, it takes a while for cache invalidation and new records to propagate.
So what's going on here, as I understand it, is they hacked the TLD servers for the affected country codes to returned modified records for select domains pointing to authorative name servers they controlled, and in turn allowed them to change the DNS records to anything they wanted. The blast radius for this kind of thing is huge, as it breaks the foundation of trust which the internet is built on. Attackers can get automated SSL certs, send/receive email pretending to be from the compromised domain, redirect traffic, install themselves as an intercepting proxy (which is the very thing SSL is supposed to protect against)! Etc.
I think the only thing worse than this would be compromising a certificate authority.
It's actually not that arcane. Iirc, the spec is documented, and even if it weren't, you can query the root, TLD, and authoritative nameservers yourself and figure out the response format. Unbound is popular selfhosted recursive resolver.