.ZIP domains as a vulnerability
by Lyuben Petrov
What is the problem with Google’s recently announced .zip and .mov top-level domains? What (obvious) risks do they hide, how can they be exploited by malicious actors? Who is most vulnerable? Find the answers to all of these questions and more in this blog.
What happened?
Fairly recently, Google announced the introduction of eight new top-level domains (TLDs) that raised quite a few eyebrows around the cybersecurity community. Particularly, the .zip and .mov TLDs were at the center of an intense dicussion about the risks of abuse by malicious actors. Somewhat obviously, the concerns of cybersecurity experts arose due to the similarities between these TLDs and the popular file extensions .zip and .mov.
File extensions were already a source of risks
File extensions have long been a favourite of cybercriminals. They are useful in both phishing campaigns and hiding longer attack chains. In both cases the file extensions serves to misdirect and confuse the victim with the ultimate goal of delivering malware. One example would be a phishing email containing a .zip file that contains malware or it contains instructions for the victim machine to download malware. Another example would be the creation and use of files with two file extensions - photos.zip.exe. These alone are enough to confuse some less seasoned internet users. But to make matters even worse - Windows hides the second file extension by default.
Making matters worse
The newly introduced Google TLDs have the potential to make attacks like these much harder to spot. Here I will be focusing on an example featured in this incredible article by the security researcher Bobby Rauch. Take a look at the following two links and try to identify the malicious one:
https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip
https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1.27.1.zip
Hopefully, you identified the second one as being malicious. But if you didn’t, don’t worry. It turns out this is hard even for relatively tech savvy people. Now let’s take minute to discuss how this attack works and why it’s dangerous.
Clearly, the domain in the URL is github.com. However, we can also see that the URL contains the character ‘@’. The link takes advantage of a little known legacy feature of URLs called UserInfo. This parameter allows login credentials to be sent directly with the URL. You see it highlighted below.
https://user:pass@website.com:443/path/to/file
Luckily, this isn’t used much anymore since people realised that including plaintext credentials within the URL is probably a bad idea from a security standpoint.
However, the feature still lingers in modern browsers. The ‘@’ can be used in links to make it such that everything up to the symbol itslef is treated as user information. Thus, https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1.27.1.zip would actually take the victim to the website https://v1.27.1.zip where the next step in the attack would be completed by downloading a piece of malware, for example.
Now, this technique requires one more element for it work. Some of you may have correctly pointed out that anything that comes after the ‘/’ would be treated as a path to a file on the server (/path/to/file in the example above). Therefore any ‘@’ characters that come after the slash would be treated as the name of a directory or file, for instance.
The malicious link works around this by using a fake slash. Yes, literally. Do you notice a difference between the following: ‘/’ and ‘∕’? The second is a Unicode character that looks suspiciously similar to the regular slash. Some fonts may make it stand out more and thus make it more noticeable. But in general the fake slash could be easily used to make some really convincing phishing links.
There also isn’t much hope that confusing Unicode slash characters will be fixed by browsers anytime soon as evident in this issue on bugs.chromium.org.
The upside
Some security researchers suggest that this is not actually as bad as it seems. For one, when such malicious links are pasted inside the Google search bar, the real links are shown below thus notifying the user that something fishy is going on.
The same effect can be achieved by hovering over URLs (sent over email, for instance) which reveals the expanded/real URL path.
Others have noted that the new TLDs do not actually increase the risk of confusion that much more since issues related to overlapping names, homoglyphs (characters that look alike such as the letter “O” and the number “0”) and related concerns already exist. Furhtermore, the CC-TLD (Country Code Top-Level Domain) for Poland (.pl) is the same as the file extension for Perl. Similarly, the CC-TLD for Saint Helena (.sh) is the file extension for shell scripts and the CC-TLD of the Republic of Serbia (.rs) remains the Rust file extension.
How to detect and protect?
To be on the safer side, Bobby Rauch advises the following (with one addition of yours truly):
- Look for domains containing U+2044 (⁄) and U+2215 (∕)
- Look for domains containing @ operators followed by .zip files
- Always be careful about downloading files from URLs sent by unknown recipients, and hover over URLs before clicking to see the expanded URL path
- If you are unsure about a domain and it is important that you know whether it can be trusted, you can always consult this GutHub repository which provides up-to-date data on newly registered .zip domains.