A recent move by Google to populate the Internet with eight new top-level domains is prompting concerns that two of the additions could be a boon to online scammers who trick people into clicking on malicious links.
Frequently abbreviated as TLD, a top-level domain is the rightmost segment of a domain name. In the early days of the Internet, they helped classify the purpose, geographic region, or operator of a given domain. The .com TLD, for instance, corresponded to sites run by commercial entities, .org was used for nonprofit organizations, .net for Internet or network entities, .edu for schools and universities, and so on. There are also country codes, such as .uk for the United Kingdom, .ng for Nigeria, and .fj for Fiji. One of the earliest Internet communities, The WELL, was reachable at www.well.sf.ca.us.
Since then, the organizations governing Internet domains have rolled out thousands of new TLDs. Two weeks ago, Google added eight new TLDs to the Internet, bringing the total number of TLDs to 1,480, according to the Internet Assigned Numbers Authority, the governing body that oversees the DNS Root, IP addressing, and other Internet protocol resources.
Two of Google’s new TLDs—.zip and .mov—have sparked scorn in some security circles. While Google marketers say the aim is to designate “tying things together or moving really fast” and “moving pictures and whatever moves you,” respectively, these suffixes are already widely used to designate something altogether different. Specifically, .zip is an extension used in archive files that use a compression format known as zip. The format .mov, meanwhile, appears at the end of video files, usually when they were created in Apple’s QuickTime format.
Many security practitioners are warning that these two TLDs will cause confusion when they’re displayed in emails, on social media, and elsewhere. The reason is that many sites and software automatically convert strings like “arstechnica.com” or “mastodon.social” into a URL that, when clicked, leads a user to the corresponding domain. The worry is that emails and social media posts that refer to a file such as setup.zip or vacation.mov will automatically turn them into clickable links—and that scammers will seize on the ambiguity.
“Threat actors can easily register domain names that are likely to be used by other people to casually refer to file names,” Randy Pargman, director of threat detection at security firm Proofpoint, wrote in an email. “They can then use those conversations that the threat actor didn’t even have to initiate (or participate in) to lure people into clicking and downloading malicious content.”
Undoing years of anti-phishing and anti-deception awareness
A scammer with control of the domain photos.zip, for instance, could exploit the decades-long habit of people archiving a set of images inside a zip file and then sharing them in an email or on social media. Rather than rendering photos.zip as plaintext, which would have happened before Google’s move, many sites and apps are now converting them to a clickable domain. A user who thinks they are accessing a photo archive from someone they know could instead be taken to a website created by scammers.
Scammers “could easily set it up to deliver a zip file download whenever anyone visits the page and include any content they wish in the zip file, such as malware,” said Pargman.
Several newly created sites demonstrate what this sleight of hand might look like. Among them are setup.zip and steaminstaller.zip, which use domain names that commonly refer to naming conventions for installer files. Especially poignant is clientdocs.zip, a site that automatically downloads a bash script that reads:
#! /bin/bash echo IAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINE
It’s not hard to envision threat actors using this technique in ways that aren’t nearly as comical.
“The advantage for the threat actor is that they didn’t even have to send the messages to entice potential victims to click on the link—they just had to register the domain, set up the website to serve malicious content, and passively wait for people to accidentally create links to their content,” Pargman wrote. “The links seem much more trustworthy because they come in the context of messages or posts from a trusted sender.”
What’s this @ doing in my domain name?
Another illustration of the potential for abuse came in a recent post by security researcher Bobby Rauch. In it, he showed how an attacker could use the .zip TLD to create a malicious URL that could fool just about anyone and that looks almost identical to the legitimate one it’s mimicking. The two URLs are:
https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip
and
https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip
The first one leads to https://v1271, which, if used by a real attacker who took the time to register the domain, could deliver a malicious .exe file. Although the second URL looks almost identical, it downloads a legitimate Kubernetes zip file from the official GitHub repository for that open source software.
Rauch’s trick leverages a .zip domain by combining it with the @ operator and the Unicode character ∕ (U+2215) to create a URL that leads to the theoretical malicious site.
Here’s how: Unbeknownst to many, everything between “https://” and the @ operator in a domain name is treated as user information, while everything following the @ operator is treated as a hostname. One of the reasons this distinction escapes most people is that many browsers—Chrome, Safari, and Edge among them—don’t act on the characters in the user info section of the domain name and instead direct the user to the hostname portion.
This convention makes for counterintuitive results. The URL https://google.com@bing.com, for example, actually leads to bing.com. As if things weren’t confusing enough, placing a forward slash before the @ operator in the same URL—i.e., https://google.com/search@bing.com—will lead to google.com (the 404 error occurs because the path “/search@bing.com” doesn’t exist on google.com). These URLs lead to different domains because browsers parse everything after the slash as the path.
It gets even more complicated. A Chromium bug known since 2016 allows two Unicode characters that look almost identical to the forward slash—U+2044 (⁄) and U+2215 (∕)—to be present in a URL without altering the way the browser interprets it. Consequently, whereas https://google.com/search@bing.com (with a normal forward slash) leads to the 404 page on google.com—as we saw above—replacing the normal forward slash with one of the lookalike Unicode characters leads to the Bing homepage.
The malicious Kubernetes page that leads to the theoretically malicious .zip URL is identical to the real Kubernetes page on GitHub with one nearly unnoticeable distinction: The forward slashes following the “https://” have been replaced with Unicode characters. Rauch’s post goes on to show how manipulating the @ operator in the URL—specifically changing its size to a size 1 font—can make malicious URLs look more convincing still.
“I don’t believe .zip or .mov [top-level] domains necessarily open up any new or novel attack vectors, but they certainly can make a threat actor’s job easier,” Rauch wrote in an online interview. “The .mov TLD can be leveraged in the same way as the .zip TLD.”
He continued:
In a business context, let’s say a .mov video file is disseminated detailing how employees can use a new piece of accounting software. You receive an email from someone in your company containing the following link to watch the video tutorial on Dropbox. Do you click it?
He then provided two URLs:
https://www.dropbox[.]com∕s∕6lv9fph03m2boen∕@tutorial.mov
and
https://www.dropbox[.]com/s/6lv9fph03m2boen/@tutorial.mov
Although they look almost identical, the first can potentially deliver malware, while the second leads to a legitimate Dropbox account hosting a video.
Where to go from here?
Google representatives defended the company’s use of .zip and .mov TLDs in a statement that said the company would monitor the usage of the new TLDs for any new threats they may pose. The company provided a couple of reasons why its new TLDs are safe. One is that any abuse will be kept in check by browser mitigations such as Google Safe Browsing, which warns users when they attempt to navigate to a malicious website or to download malicious files.
The statement also noted that the potential confusion occurred when US conglomerate 3M acquired the domain name command.com, the name of an important program on MS-DOS and early versions of Windows. The Google statement glossed over the fact, however, that command.com is a single domain name, while the .zip and .mov TLDs have the potential to be affixed to hundreds of thousands or even millions of domain names.
Google is technically correct that similar concerns over TLDs aren’t new. More than a decade ago, the Internet Corporation for Assigned Names and Numbers, the body that oversees domain names, approved a measure allowing anyone to submit applications for virtually any TLD. The move stoked concerns that threat actors might severely disrupt the safety and stability of the Internet by, for instance, obtaining TLDs such as “.domain,” “.mailserver,” “.lan,” and “.local,” all of which would collide with widely used server names inside local networks.
Those fears never materialized—not because they weren’t valid, but because none of those names have ever been used in TLDs available. In 2016, ICANN affirmatively rejected TLD applications seeking .corp, .home, and .mail. What’s more, the Internet Assigned Numbers Authority has also barred the TLDs .example, .invalid, .local, .localhost, .onion, and .test.
While Google’s statement aimed to show that concerns about confusing TLDs aren’t new, it didn’t acknowledge that the restriction of TLDs on such grounds is an established precedent that its use of .zip and .mov seems to go against.
As of Thursday, there were 2,753 domains ending in .zip, according to Johannes Ullrich, the dean of research at the SANS Institute. Of those, Ullrich identified only two suspect ones, meaning they were potentially malicious. One domain, fermwartung[.]zip (“Fernwartung” is the German word for Remote Maintenance), directed to what looked like a legitimate company website but downloaded a file that, according to VirusTotal, was flagged as malware by security firm Dr.Web.
The rest were either parked—meaning they have been reserved but sites haven’t yet been set up—or generated errors or had unknown behaviors. Forty-eight of the domains direct to the Rick Astley song “Never Gonna Give You Up,” a prank known as “rickrolling” that researchers often use to demonstrate the ability to compromise an end user.
Now that Google’s new TLDs are available, engineers who oversee the domain-naming conventions are debating what to do next. One such engineer recently requested that .zip and .mov be removed from the public suffix list (PSL), a community-maintained machine-readable list of all known DNS public suffixes and the rules pertaining to them. The aim of the PSL is to assist in ensuring browsers and other applications process domain names in a way that promotes the security and stability of the Internet.
“These TLDs are unsafe to be on the PSL due to their deceptive nature,” the engineer wrote. “PoCs [proofs of concept] are emerging and organizations are blocking these TLDs.”
Several engineers who responded opposed the proposal, mainly on the grounds that removing TLDs approved by ICANN would create instability and work against the purpose of the PSL. Eventually, the original poster relented.
“My criticisms lie with Google, which has provided no substantial technical benefits of these new TLDs, so we can only conclude that the incentive is money; and the community has demonstrated several new PoC risks and threats that we must now deal with,” the engineer wrote, adding:“Honorable mention goes to Google for undoing years of anti-phishing and anti-deception work overnight, and for making computers more confusing and risky to use. 🏅”
