Attackers hijacked the .gh, .sl and .as country-code top-level domain registries, altered authoritative DNS records and used the access to obtain unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations. Google and Chrome blocked the identified certificates, coordinated their revocation with the issuing Certificate Authorities, and said the incident did not involve a compromise of Google’s systems.
Key Points
- Attackers compromised third-party operators of the Ghana, Sierra Leone and American Samoa domain registries.
- Control of registry DNS records allowed the attackers to pass domain control validation checks and obtain unauthorized HTTPS certificates.
- Google blocked the certificates in Chrome and worked with Certificate Authorities to revoke them.
- Certificate Transparency logs revealed additional affected organizations, including leading global brands and widely used online services.
- Domain owners should monitor Certificate Transparency logs and use restrictive CAA records as part of their defenses.
How the registry hijacks enabled certificate issuance
Google said the incidents affected the .gh namespace for Ghana, .sl for Sierra Leone and .as for American Samoa. The attackers compromised third-party operators of those registries and modified authoritative DNS records, putting domains under each namespace at risk.
Google described the incidents in its October 6 disclosure and said it became aware of the activity the previous week. The attackers have not been publicly identified in the disclosed information.
Google said:
“Last week, we became aware of a series of domain hijacks in the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) country-code top-level namespaces (i.e., ccTLDs). These incidents did not involve a compromise of Google’s systems; rather, attackers compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk.”
With control of authoritative DNS, the attackers could satisfy the domain control validation checks used by Certificate Authorities. Those checks establish control of a DNS record, rather than proving that the party requesting a certificate is the rightful owner of the domain, so control of the DNS infrastructure was enough to obtain certificates.
The unauthorized certificates covered several Google domains as well as domains belonging to other organizations. Analysis of Certificate Transparency logs found certificates associated with several leading global brands and widely used online services, and Google contacted affected organizations where possible.
Chrome blocked the certificates
Chrome used CRLSets to immediately block the identified unauthorized certificates for Google properties. Google also worked with the issuing Certificate Authorities to revoke the certificates, a step intended to protect users of other browsers and software clients that honor certificate revocation.
Google said there was “no reason to believe” that the Certificate Authorities that issued the impacted certificates did anything wrong. The certificates were issued after normal domain control validation checks were satisfied because the attackers controlled the relevant DNS records.
“Chrome users do not need to take any action to be protected.”
Google cautioned that Chrome’s protections should not be treated as the only defense and do not reliably protect users of non-Chrome browsers. The company used Certificate Transparency logs to identify additional suspicious certificates tied to the registry hijacks and applied Chrome blocking measures to those certificates as well.
Recommended steps for domain owners
Google advised owners of domains in the .gh, .sl and .as namespaces to review Certificate Transparency logs for unexpected certificate issuance. It also recommended monitoring those logs across entire domain portfolios, including parked domains and regional ccTLD properties.
Domain owners should publish restrictive Certification Authority Authorization DNS records that specify permitted Certificate Authorities and approved ACME accounts. CAA records cannot prevent certificate issuance while an attacker controls authoritative DNS, but they can help prevent reissuance using cached validation after legitimate DNS control has been restored.
The disclosed reporting did not cite any CVE identifiers. The incident involved the hijacking and modification of authoritative DNS records and the use of those records to pass domain control validation checks for certificate issuance.
Sources
About the Author
