Hackers hijacked three country domains to get fake Google certificates

Last week, Google became aware of a series of domain hijacks in three country-code top-level domains, or ccTLDs. Those are the endings like .uk or .de that belong to a country or territory.

The three here:

• .gh: Ghana
• .sl: Sierra Leone
• .as: American Samoa

Attackers compromised the third-party organizations that run these registries. That put any domain ending in .gh, .sl or .as at risk, Google says. The attackers then modified authoritative DNS records for selected domains and used that control to get HTTPS certificates covering several Google domains and domains belonging to other organizations.

Google hasn't said which of its domains were involved. It also hasn't named the other companies, Ars Technica notes.

Every time you see the padlock next to a web address, your browser has checked a TLS certificate. It's a digital credential that ties a domain name, like google.com, to a cryptographic key.

The public half of that key is out in the open. The private half stays with the site's operator. When the two match, your browser knows it's talking to the real site and not an impostor, Ars Technica explains.

Here's the analogy: a certificate is like an ID card for a website. The fake ones in this story weren't forged in a basement. They were real ID cards, issued by the real office, to someone who had temporarily taken over the address on the application.

Why it matters: with an unauthorized certificate, an attacker can cryptographically impersonate a site. If they can also steer your traffic to their server, your browser has no obvious reason to complain.

Certificate authorities, or CAs, are the companies that issue these certificates. Before they do, they check that whoever is asking actually controls the domain. That check is called domain control validation.

The usual way to prove control is through DNS, the internet's address book. You put a specific record on your domain, or answer a request sent to it, and the CA takes that as proof.

By controlling the registries, the attackers could change those DNS records and nameserver delegations for the domains they picked. That let them pass the industry's validation checks, Ars Technica reports. From the CA's point of view, the requests looked legitimate.

The catch: that is why Google says it has "no reason to believe" the CAs did anything wrong. They followed the rules. The rules simply trust DNS, and DNS was the part that got taken over.

Google says it followed its usual incident response process:

• Blocked the certificates in Chrome: it used CRLSets, Chrome's own fast list of certificates the browser refuses to trust.
• Got them revoked: it worked with the issuing CAs to revoke the certificates for Google properties, which protects people using clients other than Chrome.
• Searched for more victims: Certificate Transparency log data revealed additional organizations, "including several leading global brands and widely used online services," believed to have been hit by the same attacks.
• Blocked those too: Google proactively blocked those certificates in Chrome and reached out to the affected organizations where possible.

By the numbers: Google hasn't said how many certificates were issued. Ars Technica says it's not clear how many there were, or whether all of the non-Google ones have been blocked.

Why a browser list and not just revocation? Ars Technica notes that the official process for revoking certificates is slow and cumbersome, so browser makers built quicker ways to block specific certificates themselves.

In real life If you use Chrome, you don't have to do anything. Google says Chrome users are already protected. If you use another browser, keep it updated, since Google's own blocks live inside Chrome.

Because it can't be sure it found everything. Google was unusually direct about the limits of its own fix:

"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."

The company also says browser-side intervention "should not be relied on" to protect a site's users. In plain words: Chrome caught what it could see, and site owners have to watch their own doors.

Google says domain owners are in the best position to know which certificates and CAs they actually authorized. So its advice goes to them, not to you.

Google recommends two steps.

1. Watch Certificate Transparency logs. Every certificate Chrome trusts by default must be recorded in public CT logs. Monitoring them gives you a near real-time alert whenever someone gets a certificate for your domain.

• Cover everything: Google says monitoring should include your entire domain portfolio, including parked or regional country-code domains you rarely think about.
• If you're on the affected endings: anyone running a domain in .gh, .sl or .as should review recent CT log entries for unexpected certificates.

2. Publish restrictive CAA records. Certification Authority Authorization records are DNS entries that say which CAs are allowed to issue certificates for your domain. Google recommends tying them to specific ACME accounts, the automated accounts many sites use to renew certificates.

CAA can't stop an attacker who controls your DNS at that moment. But it matters afterward. CAs are allowed to cache and reuse a completed validation check for later certificates, so a strict CAA policy, restored once you get DNS back, stops the attacker from using that leftover validation to mint new ones, Google says. It can also block some routing-based and HTTP attacks entirely.

What's next: Google says it will keep pushing longer-term fixes through the Chrome Root Program and its new Chrome Quantum-resistant Root Program, including shorter certificate lifetimes and less reuse of old validation checks.

Yes, though usually the weak spot was somewhere else. In 2011, attackers hacked DigiNotar, a certificate authority based in the Netherlands, and minted counterfeit certificates for Google.com and more than 200 other high-traffic domains, Ars Technica recalls.

Those certificates were used against at least 300,000 people with ties to Iran as they browsed the impersonated sites. Ars Technica says there have been many similar incidents since, most often through failures at CAs but sometimes at domain holders.

This time is different in one way. Nobody broke into a CA or into Google. The attack went one level up, to the registries that decide where a whole country's domains point. If you want more background on how attacks on big platforms play out, our story on the ASOS and Snowflake hack is a good companion read, and you can follow all of our Google coverage.

• Chrome users: nothing to do. Google says Chrome already blocks every unauthorized certificate it found.
• Other browsers: install updates when they arrive. Google worked with the CAs to revoke the Google certificates, but its Chrome blocks don't cover you.
• Site owners: set up Certificate Transparency alerts for every domain you own, including forgotten regional ones, and publish a strict CAA record.
• On a .gh, .sl or .as domain: check recent CT log entries now for certificates you didn't request.