Skip to content

Researchers exploit WHOIS flaw to issue TLS/SSL certificates

  • by
  • 4 min read

A routine cybersecurity experiment has exposed a critical vulnerability in the WHOIS system. It revealed that outdated domain configurations in the .mobi top-level domain (TLD) could allow attackers to undermine the integrity of internet security. Researchers discovered that by purchasing an expired WHOIS server domain, they could manipulate queries from government entities, cybersecurity tools, and Certificate Authorities (CAs), potentially enabling the issuance of TLS/SSL certificates for major domains.

The cybersecurity team, looking for real-world exploitation opportunities, focused on the outdated WHOIS protocol, a 50-year-old system used to query domain name information. Their attention was drawn to the expired domain, dotmobiregistry.net, which previously served as the WHOIS server for .mobi domains.

When this domain was left unrenewed in December 2023, the researchers purchased it for a nominal fee, recognising the potential implications.

This move transformed what was initially an academic exercise into an unintentional real-world exploit. The team deployed a WHOIS server under the dotmobiregistry.net domain, and I’m curious to see if any systems still reference the obsolete server.

To their surprise, the experiment attracted 135,000+ unique systems and over 2.5 million queries within a few days.

Source: Watchtowr

The gravity of the situation became apparent when the researchers realised that numerous systems, including those belonging to government and military entities, continued to query their rogue WHOIS server.

Even more concerning were the Certificate Authorities (CAs) issuing TLS/SSL certificates for .mobi domains, such as ‘google.mobi’ and ‘microsoft.mobi.’

Through their Proof of Concept (PoC), the researchers demonstrated that CAs like GlobalSign used their server’s responses to verify domain ownership. This flaw allowed them to trick the CA into recognising a fraudulent email address — whois@watchtowr.com — as the authoritative contact for domains like ‘micrsoft.mobi.’

This effectively undermines the CA process, opening the door to potential man-in-the-middle attacks or certificate fraud.

WHOIS entry for google.mobi. | Source: Watchtowr

CAs are critical to securing online communications. They issue certificates that verify the authenticity of websites and ensure encrypted data transmission. By compromising this system, attackers could interpret or manipulate sensitive information.

Furthermore, when we look at this vulnerability historically, we find that the nation-state actors usually targeted CA processes, with past attacks attributed to Iran and China.

Researchers say that this incident underscores a longstanding problem with WHOIS infrastructure. Each TLD, such as .mobi, has its own WHOIS server; many servers are hardcoded into WHOIS clients. While these server addresses change infrequently, when they do, as in the case of dotmobiregistry.net, outdated systems continue to reference old addresses, creating security blind spots.

By exploiting this weakness, the researchers showed that malicious actors no longer need sophisticated man-in-the-middle attacks to compromise WHOIS clients. Instead, they can wait for queries to reach a rogue server and respond with manipulated data.

The findings from this research raise serious questions about the security of Internet infrastructure and the processes that support it. While the researchers did not disclose whether affected entities, such as CAs or government bodies, have been notified, the vulnerability has far-reaching implications for organisations relying on outdated WHOIS configurations.

“If we could do this, anyone can,” the researchers concluded.

In the News: Servers hijacked to boost malicious sites in search rankings

Kumar Hemant

Kumar Hemant

Deputy Editor at Candid.Technology. Hemant writes at the intersection of tech and culture and has a keen interest in science, social issues and international relations. You can contact him here: kumarhemant@pm.me

>