WHOIS clients across the internet, including those used by email servers and Certificate Authorities (CAs), are relying on outdated records for WHOIS servers, potentially allowing attackers to hijack old WHOIS server domains and impersonate domain owners, security researchers have found. This opens the door to a variety of attacks including obtaining rogue TLS certificates for domains they don’t own.
Investigating for remote code execution (RCE) vulnerabilities in WHOIS clients, researchers from watchTowr bought the domain name previously used by the WHOIS server for the entire .mobi top-level domain (TLD), only to discover that tens of thousands of systems still query the old WHOIS server address now under their control.
“In the wrong hands, owning the domain could enable attackers to ‘respond’ to queries and inject malicious payloads to exploit vulnerabilities in WHOIS clients,” the researchers told CSO. “For the concern of the government mail servers reaching out to watchTowr’s WHOIS servers — traffic analysis can be performed to passively observe and infer email communication.”
The biggest discovery, however, was that some CAs — the organizations trusted to issue Transport Layer Security (TLS) certificates to domain owners as part of the Web’s Public Key Infrastructure — were still relying on the old .mobi WHOIS server to obtain contact email addresses for .mobi domains as part of their domain control validation (DCV) processes.
“We released this blog post to initially share our process around making the unexploitable exploitable and highlight the state of legacy infrastructure and increasing problems associated with abandoned domains — but inadvertently, we have shone a spotlight on the continuing trivial loopholes in one of the Internet’s most vital encryption processes and structures — TLS/SSL Certificate Authorities,” the researchers wrote in their blog post. “Our research has demonstrated that trust placed in this process by governments and authorities worldwide should be considered misplaced at this stage, in our opinion.”
The ancient WHOIS protocol
The WHOIS protocol dates back to the early 1980s when it was standardized, but the first WHOIS service was actually set up on ARPANET, the precursor of the internet. The protocol, which is used to query information about domain names and IP addresses, works over TCP port 43, returning text records about when domains were registered, through what registrar, when they expire, who owns them and their contact information, among other data.
Organizations that manage TLDs — .com, .org, .net, etc. — are the stewards of such information and operate their own WHOIS servers. These servers are listed in the internet’s root zone database maintained by the Internet Assigned Numbers Authority (IANA), a standards organization that’s part of the Internet Corporation for Assigned Names and Numbers (ICANN).
IANA provides its own WHOIS server at whois.iana.org that can be queried to obtain the addresses of WHOIS servers for individual TLDs — there are currently over 1,500 TLDs covering more than 350 million registered domain names worldwide. An application querying WHOIS information would first query whois.iana.org, obtain the current WHOIS server for a particular TLD and then query that server for a particular domain name.
To limit the number of requests, especially when processing a large number of IP addresses or hostnames, WHOIS clients instead tend to use hard-coded lists of WHOIS servers or rely on services that similarly use outdated lists.
For example, a quick Google search reveals several forums where developers have asked how to get a list of all the WHOIS servers and responders have suggested various such lists. There is also an 8-year-old list on GitHub and another one maintained by the creator of several Windows WHOIS utilities that is similarly outdated. One user suggested using the service provided by whois-servers.net, which he points out some WHOIS clients use by default. That service also uses outdated WHOIS servers.
To make it easier for developers to query domain or IP registration information programmatically, the IETF has created the Registration Data Access Protocol (RDAP), which returns results in JSON. ICANN has mandated all generic TLDs to provide standardized RDAP services by February 2024, but this doesn’t apply to country-level TLDs, so the WHOIS protocol will not disappear anytime soon.
What happens when WHOIS servers change addresses?
While investigating response parsing vulnerabilities in WHOIS clients, watchTowr researchers needed control over a WHOIS server to serve malformed responses. In the real world, such an attack can only be performed from a man-in-the-middle position — to intercept the request in transit and impersonate a server — or by taking control of a WHOIS server the client queries.
Taking over a domain registry’s WHOIS server seemed like a difficult prerequisite but on a whim, “in a hotel room while escaping the Vegas heat surrounding Black Hat,” the researchers had the idea of checking how many WHOIS servers changed their addresses in recent years, potentially abandoning their old ones.
It wasn’t long before they struck gold: A few years ago, the WHOIS server for .mobi — a TLD originally intended for mobile-friendly versions of websites — switched from whois.dotmobiregistry.net to whois.nic.mobi.
Moreover, the registry let the previous domain expire, and dotmobiregistry.net could be registered for $20, which the researchers promptly did. Wondering what systems might still query the old address and therefore be targeted for their WHOIS RCE investigation, the researchers set up a WHOIS server at whois.dotmobiregistry.net and started monitoring.
“The results have been fairly stunning since — we have identified 135,000+ unique systems speaking to us, and as of 4th September 2024 we had 2.5 million queries,” the researchers wrote in their report. “A brief analysis of the results showed queries from (but certainly not limited to): Various mail servers for .GOV and .MIL entities using this WHOIS server to presumably query for domains they are receiving email from; various cyber security tools and companies still using this WHOIS server as authoritative (VirusTotal, URLSCAN, Group-IB as examples).”
Domain registrars such as GoDaddy and Name.com, various online WHOIS and SEO tools, and a large number of universities were also querying the old server address. Governments whose systems queried the now rogue WHOIS server included the US, Ukraine, Israel, India, Pakistan, Bangladesh, Indonesia, Bhutan, the Philippines, and Ethiopia.
The researchers have since worked with the UK’s National Cyber Security Centre and the Shadowserver Foundation to hand over dotmobiregistry.net and configure it to proxy correct WHOIS responses from whois.nic.mobi.
Benjamin Harris, CEO and founder of watchTowr, confirmed to CSO that they did indeed find memory corruption and command injection vulnerabilities in WHOIS clients. But the ability to subvert the CA domain control validation process was by far the most devastating impact uncovered.
Breaking the TLS/SSL chain of trust
TLS, the successor to SSL, is the foundation of secure communications on the internet. It is used in conjunction with protocols such as HTTP, SMTP, IMAP, or POP3 to create secure, encrypted versions of those protocols: HTTPS, SMTPS, STARTTLS, etc.
TLS relies on digital certificates issued by trusted Certificate Authorities to verify the identity of servers that browsers, email servers, and email clients connect to. This critical process, meant to protect communications from man-in-the-middle snooping or redirection attacks, hinges on attackers not being able to obtain certificates for domains they don’t control.
To ensure this, CAs follow specific procedures to verify domain ownership or control before issuing a TLS certificate to someone who requests one for a particular domain.
Three verification methods are currently considered acceptable by the CA/Browser Forum, an organization that defines guidelines for issuing and managing TLS certificates:
- Placing a secret token in the root of the web server where the domain points to;
- Placing a secret token in a CNAME DNS record for the domain;
- Receiving a secret token at the domain’s presumed administrative contact email address.
Where is this email address taken from? WHOIS records.
With the ability to fake WHOIS records for any .mobi domain, watchTowr researchers wondered whether any CAs still query dotmobiregistry.net for WHOIS information and thus could be tricked into using a rogue email address for domain control validation.
To test this, the researchers chose to alter WHOIS information for microsoft.mobi, owned by Microsoft, on their fake WHOIS server. They then generated a certificate signing request (CSR) for microsoft.mobi, requesting the certificate through a CA using the email-based option for DCV.
When queried, the CA should list domains@microsoft.com as the email contact for microsoft.mobi. But if the CA queried the researchers’ fake WHOIS server rather than the real one for .mobi, the email address listed would be whois@watchtowr.com, which they controlled.
After testing a couple of CAs, the researchers stopped at GlobalSign, which printed an error saying it couldn’t find any email address in the WHOIS record for microsoft.mobi. But the researchers knew the domain had a proper address listed in its real WHOIS records. So what was going on? Was GlobalSign trying to reach the correct WHOIS server and failing for some reason, or was it trying to reach the researchers’ server but wasn’t able to process its response?
Turns out it was the latter. The formatting of watchTowr’s response wasn’t correct. They made the quick fix and tried again. This time GlobalSign offered whois@watchtowr.com as an option for receiving the token.
“We want to be explicitly clear that we stopped at this point and did not issue any rogue TLS/SSL certificates to ourselves,” the researchers said. “This would undoubtedly create an incident, and require significant amounts of work by many parties to revoke and roll back this action.”
WatchTowr’s Harris told CSO that due to the sensitivity of this attack, the researchers stopped any additional CA testing with their new WHOIS response format. Still, there are over 100 CAs around the world so it’s possible that others might be querying the outdated WHOIS server address for .mobi as well.
“At this time, GlobalSign is actively investigating and working on remediation of this matter,” a GlobalSign spokesperson told CSO via email. “As a company committed to compliance, we will be reporting this issue on Bugzilla per industry requirements. The company will take any additional required steps as necessary. Please note that, at this point, this seems to be a wider issue affecting more CAs.”
Bugzilla is Mozilla’s bug tracking system. As a browser and email client vendor, Mozilla maintains a CA program. GlobalSign also pointed to an ongoing discussion about this issue in Mozilla’s DEV Security Policy mailing list.
Fortunately, it seems like this attack can’t be easily replicated with other WHOIS servers, at least for now. Harris said watchTowr did not identify any other TLD aside from .mobi that had changed its WHOIS server address and left the old one to expire.
“However, the challenge here is that because there is no central body, how often this occurs, and whether this will occur again, is unfortunately down to the actions of the public and private operators who manage the .TLDs that we as a planet use,” he said.
Potential mitigations
With RDAP now the preferred method for gathering domain information, ICANN has set January 28, 2025, as the WHOIS Sunset Date, after which generic TLD (gTLD) registries will no longer be required to run WHOIS servers, instead providing just RDAP services. If many gTLDs shut down their WHOIS servers, many developers, including CAs, will be forced to switch to RDAP instead.
To mitigate the TLS-related impact, domain owners can set Certification Authority Authorization (CAA) records in the DNS for their domain names. This record can be used to specify exactly which CAs are allowed to issue certificates for a particular domain name. All CAs are required to check and validate CAA records before issuing a certificate, according to the CA/B Forum baseline requirement.
DNS CAA records can also be used to provide a contact email that can be used for domain validation and can also be used to restrict the accepted domain validation methods via a “validationmethods” parameter.
Furthermore, CAs are required to publish the certificates they issue in a public Certificate Transparency (CT) log. Domain owners can monitor these logs to automatically discover if any unauthorized certificates have been issued for their domains.