Comment In early May, Google Domains added support for eight new top-level domains, two of which – .zip, and .mov – raised the hackles of the security community.
The reason, of course is, that .zip and .mov are both file extensions. So there’s concern that a miscreant could employ these TLDs to confuse people by visiting a malicious website rather than opening a file, among other threat scenarios.
A security researcher who goes by the name “bobbyr” offered an example of the problem with Google’s movein a blog post on Tuesday. They pointed out that by abusing a known Chrome behavior – one Google has decided not to fix – it’s possible to construct a URL with a Unicode character that displays as a slash – U+2215 (∕) – but isn’t treated as a slash when the browser fetches the URL.
And by adding the @ operator in the URL – used to delimit the user information (RFC 3986) part of the URL scheme and ignored in most modern browsers because embedded authentication is somewhat unsafe – this link …
… gets treated as …
… because everything before the @ delimiter is treated as user information.
The resulting v1271.zip domain could be registered and used to host, say, a Flask application that responds to any request with a malicious .exe file.
That URL parsing behavior is evident if the above URL is pasted into the Chrome omnibox. Chrome will show the shortened actual address (everything to the right of the @ sign) atop the URL as a search query.
“bobbyr” argues this technique can be even more effective in an email client, such as the web version of Gmail, where the @ sign can be set to a non-visible font size to make the URL look even more convincing.
Other email clients, however, differ. Apple Mail, for example, just hyperlinks the github.com portion of the URL as a link, and stops at the U+2215 (∕), which inadvertently prevents the formation of an unsafe link to the v1271.zip domain.
While there’s some risk of confusion, it’s not really appreciably more than the status quo, which tolerates rather a lot of issues related to overlapping names, homoglyphs, and related concerns. As others have noted, .com was once a common Windows file extension and the CC-TLD for Poland (.pl) remains the file extension for Perl. The CC-TLD for Saint Helena (.sh) is also the file extension for shell scripts and the Republic of Serbia shares its CC-TLD (.rs) with the Rust file extension.
‘Not bad, actually’
Eric Lawrence, principal software engineer for Microsoft and veteran browser wrangler, recently described the arrival of .zip and .mov as “not bad, actually.”
In his own blog post, Lawrence allows that there’s possibly some risk from automatic hyperlinking mechanisms in applications – say, email clients that turn “VacationPhotos.zip” into linked text pointing to the corresponding .zip domain. However, he contends that’s not a particularly exciting or likely attack vector, and suggests it might be a good idea to exempt those particular domains from app hyperlinking routines.
Lawrence also expressed skepticism that URLs, which are already confusing, will be made much more so by .zip and .mov. “URLs are already incredibly subtle, and relying on users to mentally parse them correctly is a losing proposition in multiple dimensions,” he argued.
Finally, he sees the new TLDs as having a potential upside in that newer domains can be rolled out with more stringent security defaults for registrars. He notes that .zip and .mov are among the 40 TLDs included on the HTTPS Strict Transport Security (HSTS) preload list, which tells browsers to automatically use secure TLS by default.
Google voiced similar sentiment in an email to The Register, allowing that abuse is possible but insisting that the risk is familiar and manageable.
“The risk of confusion between domain names and file names is not a new one,” a spokesperson said. For example, 3M’s Command products use the domain name command.com, which is also an important program on MS-DOS and early versions of Windows.”
“Applications have mitigations for this (such as Google Safe Browsing), and these mitigations will hold true for TLDs such as .zip. At the same time, new namespaces provide expanded opportunities for naming such as community.zip and url.zip.
“Google takes phishing and malware seriously and Google Registry has existing mechanisms to suspend or remove malicious domains across all of our TLDs, including .zip. We will continue to monitor the usage of .zip and other TLDs and if new threats emerge we will take appropriate action to protect users.” ®
READ MORE HERE