Google reports DNS kidnapping: TLS certificates for google.com.gh, google.sl and google.as

Google reported on October 6 that attackers managed to issue unauthorized HTTPS certificates for Google and YouTube names after compromising authoritative DNS records of three top-level domains with country code: .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). According to the public records of Certificate Transparency (CT), between 22 and 27 September, at least twelve certificates were added for variants of these names (e.g., google.com.gh, google.sl and google.as); Let's Encrypt issued 11 and ZeroSSL issued one. Google clarifies that its own internal systems were not violated; the path of attack was the manipulation of DNS in those ccTLD.

In technical terms, what happened is a classic type of DNS area kidnapping: the attackers changed the authoritative records that indicate which servers respond for a domain. The certification authorities (Cans) verify the control over a domain name before issuing a certificate and a regular form of verification is to require the applicant to place a specific DNS register or serve a token on a domain URL. By taking control of the DNS area, the attackers were able to respond to these tests and thus obtain valid certificates issued by legitimate Cans. With a valid certificate in hand, an attacker capable of intercepting traffic (for example, in a public Wi-Fi network or through a malicious routing) can present the certificate and establish apparently legitimate encrypted connections, which would allow for reading or handling confidential data.

Verified facts: Google blocked the unauthorized certificates in Chrome using CRLSet - the browser's rapid emergency certificate locking mechanism - and worked with the CAs to revoke the certificates, according to its statement. CT records show entries and cancellations; searches in public services such as ctlogs.dev and monitoring tools such as Cert Spotter confirmed the presence and subsequent revocation of the registered prints. Google also said it detected indications that other organizations - widely used brands and services - were affected by the same pattern, although they did not identify them publicly.

Which is still uncertain and not confirmed by Google includes whether any of these certificates were actually used in active attacks against users to read data, the identity of the attackers, the exact method by which the DNS records of each ccTLD were committed and whether the registrations or records of those ccTLD have been completely remitted. Google also noted that, due to the complexity of DNS abductions, it cannot guarantee that its analysis has detected all affected domains.

The incident exposes several vulnerabilities in the TLS / DNS ecosystem confidence chain. First, the issue of certificates based on domain validation tests depends on the integrity of the DNS system: if the control signal can be falsified by a zone hijacking, the CA can legitimately issue a certificate to an attacker. Second, CAs can re-use prior control checks to accelerate subsequent emissions; the rules of the Baseline Requirements (CA / Browser Forum) set time limits for such re-use to be reduced in the coming years, and some suppliers such as Let's Encrypt have already announced changes in their reuse time. These details explain why a temporary domain control can result in valid certificates for days.

The real consequences vary by role: for end users, the main risk is a man-in-medium attack that presents one of those certificates and deciphers apparently encrypted traffic. For domain operators and service providers, the consequence is loss of control and possible service supplanting; in addition, the need to quickly audit CT logs, revoke certificates and check the integrity of DNS areas. For CAs, the event requires the review of validation procedures and the acceleration of policies that reduce the reuse window of domain checks.

Google and the Cans took concrete and visible measures: blocking in Chrome through CRLSet and requests for revocation to the Cans emitores. However, Google warned that Chrome protections are not enough for all browsers and that domain owners should not rely only on the browser to protect their users.

Practical and specific recommendations (who should do what): domain owners under any of these ccTLD or with regional subdomains should immediately audit certificates transparency records for all variants of their names - including parked and regional domains - using CT monitoring services and review any unsolicited certificates. Publish a CAA(Certification Authority Authorization) strict that limits which CAs can issue certificates for their domain and, when the CA allows, ascribe it to your account in that CA to reduce risks. It immediately reports any unauthorized issue to the issuing CA through a Certificate Problem Report; the CAs are required to investigate and respond in short time according to the rules of the sector.

In addition, and although Google already suggested it indirectly, DNS administrators and registry officials must check credentials and access to their registrator accounts and to authoritative name servers: active multifactor authentication in the registrator accounts, apply transfer locks, review changes in name servers and record SOA / serial change alerts. Implement or verify DNSSEC in its areas where possible; DNSSEC is not a panacea and is not always available for all ccTLD, but it adds a layer that makes it difficult to handle the delegation information on the road. Finally, reduce the confidence window in domain validations where your CA allows (e.g. use CAs that do not re-use long-term checks).

For end-users, the immediate recommendation is to keep browsers and systems up-to-date: Chrome has already blocked the affected certificates, but other browsers may take longer to receive retorations and updates. Avoid unreliable public Wi-Fi networks and, if you handle sensitive information, consider using reliable private networks or VPNs as investigations continue.

Finally, this incident underlines the importance of constant monitoring: Certificate Transparency is a public tool that allows to detect unusual emissions, but it only works if the owners use it. Documentation and resources on CT and public surveillance are available on the official Certificate Transparency page and in monitoring services such as Cert Spotter; those who manage domains must incorporate them into their security processes. More technical information on CT and resources to start with can be found at certificate-transparency.org and Cert Spotter's documentation.