Security News Google says counterfeit TLS certificates of major services stolen by hackers

Brownie2019

Level 23
Verified
Well-known
Forum Veteran
Three country-code top-level domains were hijacked
  • Attackers hijacked three country-code domains to obtain fraudulent HTTPS certificates for major websites
  • Fake certificates could enable convincing traffic interception and phishing against affected domains
  • Google revoked the certificates, protected Chrome users, and warned impacted organizations
Cybercriminals recently managed to hijack three country-code top-level domains (ccTLDs) and used the access to generate HTTPS certificates covering several Google domains, as well as those belonging to other organizations. Google said the attack placed thousands of websites at risk, but stressed that the certificates have since been revoked.

According to Google, the domains that were hijacked are .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). During the attacks, the threat actors modified authoritative DNS records, obtaining HTTPS certificates covering not just Google, but other organizations, too.

In other words, any website operating on these domains was at risk, as well as all of the visitors. By manipulating authoritative DNS records, threat actors could redirect traffic away from legitimate websites and towards malicious ones under their control, all the while telling users they were visiting the legitimate one by showing the padlock icon. Visitors entering login credentials, payment information, or other data, would easily lose them to the attackers, and depending on the circumstances, they could also end up installing malware.
“Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong,” Google said.

Read more:
 
(link omitted)


Good find, Brownie2019. The incident is serious, although the headline’s wording is technically off: the certificates were not “stolen,” and Google itself was not compromised. Attackers gained control within the .gh, .sl and .as DNS namespaces, then used that control to obtain newly issued, publicly trusted certificates for affected domains.

The attack chain was essentially:

  1. Compromise the ccTLD infrastructure and alter authoritative DNS.
  2. Point a selected domain or certificate-validation record at attacker-controlled infrastructure.
  3. Request a certificate from a public Certificate Authority.
  4. Pass the CA’s domain-control check because DNS now says the attacker controls the domain.
  5. Redirect visitors and present the valid certificate without triggering the usual browser warning.

That explains why Google says the issuing CAs did not necessarily do anything wrong: their automated validation saw apparently valid control. These were genuine certificates issued without the legitimate domain owner’s authorization, rather than forged cryptographic objects.

The practical lesson is that the padlock only confirms an encrypted connection to whoever currently controls the domain—it was never a character reference for the site operator. In this situation, DNS redirection plus a trusted certificate could make interception or phishing extremely convincing.

Google says it blocked identified certificates in Chrome through CRLSets and worked with the issuing CAs to revoke them for other clients. It also used Certificate Transparency logs to find certificates affecting other organizations. However, Google’s original account explicitly says it cannot guarantee that every affected domain was identified. Chrome users need take no special action for the certificates Google blocked, but keeping browsers and other TLS clients updated remains important.

For domain operators, the useful measures are:

  • Monitor Certificate Transparency across the entire domain portfolio, including parked and regional domains.
  • Review recent CT entries if operating under .gh, .sl or .as.
  • Use restrictive CAA policies, preferably tied to authorized ACME accounts and validation methods.
  • Audit registry, registrar and authoritative DNS changes and protect those accounts with strong MFA.

One important evidence boundary: the compromise and unauthorized issuance are confirmed, and interception was a real capability. Neither the TechRadar report nor Google’s disclosure establishes that every exposed site was redirected or that credentials were actually stolen. “Thousands at risk” is not the same thing as thousands of confirmed victims.

Sources
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top