8 ms·

The Dangers of Google’s .zip TLD

35 points by paulsb 3y ago

mooman219 3y ago
> Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe? Yes? When you hover the first link the browser says "v1271.zip", and when you hover the second link it says "https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip https://github.com/kubernetes/kubernetes/archive/refs/tags/v..." You don't even need a .zip domain to do this, just assign a misleading link i.e. [google.com](badsite.com). If the argument is going to be no one looks at the on hover link preview, then why bother even paying for a .zip domain in the first place? Going further, you can also just buy a similar domain to confuse people, which might even work better than buying the .zip since then you _might_ even catch careful people that glance at the on hover preview.
- catiopatio 3y ago
  If I copy and paste the malicious URL into the terminal, or the browser’s location field, there’s no indication that it’s anything but what it appears to be. Of course, there’s nothing unique about `.zip` other than that it’s a common file extension. Any TLD that makes for a convincing file extension could be used this way.
  - adhesive_wombat 3y ago
    Maybe we should have the .exe TLD to make every URL using it look immediately suspicious. Sorta like https://verylegit.link https://verylegit.link but built into the whole TLD.
- cuttysnark 3y ago
  Hovering the link to preview its location in the status bar reveals the trick because the browser doesn't see any real slashes. The anchor's href (when inspected) actually does have the full bogus URL, but when hovered we're shown the browser-evaluated URL—which is a TIL.
freedude 3y ago
Blue Coat Systems warned about the .zip domain quite some time ago. https://www.cio.com/article/220242/the-webs-10-most-shady-neighborhoods.html https://www.cio.com/article/220242/the-webs-10-most-shady-ne...
adhesive_wombat 3y ago
> In an email client, we could make it even more convincing, and change the size of the @ operator to a size 1 font Doesn't change the underlying issue, but plain text email would have stopped that part of it! Of course, that's banned at work because then the signature wouldn't have the approved font and picture in it, and therefore it's not Corporate (TM) enough.
tracker1 3y ago
While I get it... there are plenty of risks just with high characters in domain names. I would simply suggest the "hover" view for links don't show the translated punycode character encoding for domains. I think it would be far more of an issue if .lan or .local were ever able to make it past icann for a registrar. What's funny to me, is the number of web forms that haven't been updated to allow anything other than .com/net/org for signup.
wizofaus 3y ago
The fact that browsers will silently strip out everything before @, including "fake" slashes is surely the real problem here. That .zip is now a valid TLD doesn't strike me as making the situation vastly worse - something like https://github.com/kurbernetes/@latest.dev/package.zip https://github.com/kurbernetes/@latest.dev/package.zip seems just as likely to fool a recipient not being 100% vigilant. (To be fair, that used real slashes - all the substitute slash characters do actually look noticeably different to a regular slash - perhaps surprisingly there's no "non-breaking slash". Actually the big solidus ⧸ is pretty close but HN seems to block me using it in a URL!)
- lgats 3y ago
  github.com∕not-suspicious@package.zip add https:// https:// and your browser will take you right to https://package.zip https://package.zip
  - wizofaus 3y ago
    Sure, and the fact that .zip is both a common file extension for downloading AND now a TLD is not a good thing (I don't know who though having .zip as a TLD was a good idea), but I still don't think it's the main risk here. Maybe it'll finally prompt Google (and other browser distributors) to stop automatically stripping stuff from URLs, and to check/warn on Unicode homographs (hell, it doesn't even warn on www․google.com - and that's NOT a regular period/full stop after the first www - I doubt anyone would be able to register www․google.com as a domain but who knows).
suprjami 3y ago
You can block all .zip with the following uBlock Origin filter: ||zip^ Tell everyone you know.
callalex 3y ago
What is the argument in favor of these TLDs existing other than corruption/extortion?
kanetw 3y ago
I blackholed .zip and .mov in my DNS servers.

35 points by paulsb 3y ago

> Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe? Yes? When you hover the first link the browser says "v1271.zip", and when you hover the second link it says "https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip https://github.com/kubernetes/kubernetes/archive/refs/tags/v..." You don't even need a .zip domain to do this, just assign a misleading link i.e. [google.com](badsite.com). If the argument is going to be no one looks at the on hover link preview, then why bother even paying for a .zip domain in the first place? Going further, you can also just buy a similar domain to confuse people, which might even work better than buying the .zip since then you _might_ even catch careful people that glance at the on hover preview.

catiopatio 3y ago
If I copy and paste the malicious URL into the terminal, or the browser’s location field, there’s no indication that it’s anything but what it appears to be. Of course, there’s nothing unique about `.zip` other than that it’s a common file extension. Any TLD that makes for a convincing file extension could be used this way.
- adhesive_wombat 3y ago
  Maybe we should have the .exe TLD to make every URL using it look immediately suspicious. Sorta like https://verylegit.link https://verylegit.link but built into the whole TLD.
cuttysnark 3y ago
Hovering the link to preview its location in the status bar reveals the trick because the browser doesn't see any real slashes. The anchor's href (when inspected) actually does have the full bogus URL, but when hovered we're shown the browser-evaluated URL—which is a TIL.

freedude 3y ago

Blue Coat Systems warned about the .zip domain quite some time ago. https://www.cio.com/article/220242/the-webs-10-most-shady-neighborhoods.html https://www.cio.com/article/220242/the-webs-10-most-shady-ne...

adhesive_wombat 3y ago

> In an email client, we could make it even more convincing, and change the size of the @ operator to a size 1 font Doesn't change the underlying issue, but plain text email would have stopped that part of it! Of course, that's banned at work because then the signature wouldn't have the approved font and picture in it, and therefore it's not Corporate (TM) enough.

tracker1 3y ago

While I get it... there are plenty of risks just with high characters in domain names. I would simply suggest the "hover" view for links don't show the translated punycode character encoding for domains. I think it would be far more of an issue if .lan or .local were ever able to make it past icann for a registrar. What's funny to me, is the number of web forms that haven't been updated to allow anything other than .com/net/org for signup.

wizofaus 3y ago

The fact that browsers will silently strip out everything before @, including "fake" slashes is surely the real problem here. That .zip is now a valid TLD doesn't strike me as making the situation vastly worse - something like https://github.com/kurbernetes/@latest.dev/package.zip https://github.com/kurbernetes/@latest.dev/package.zip seems just as likely to fool a recipient not being 100% vigilant. (To be fair, that used real slashes - all the substitute slash characters do actually look noticeably different to a regular slash - perhaps surprisingly there's no "non-breaking slash". Actually the big solidus ⧸ is pretty close but HN seems to block me using it in a URL!)

lgats 3y ago
github.com∕not-suspicious@package.zip add https:// https:// and your browser will take you right to https://package.zip https://package.zip
- wizofaus 3y ago
  Sure, and the fact that .zip is both a common file extension for downloading AND now a TLD is not a good thing (I don't know who though having .zip as a TLD was a good idea), but I still don't think it's the main risk here. Maybe it'll finally prompt Google (and other browser distributors) to stop automatically stripping stuff from URLs, and to check/warn on Unicode homographs (hell, it doesn't even warn on www․google.com - and that's NOT a regular period/full stop after the first www - I doubt anyone would be able to register www․google.com as a domain but who knows).

suprjami 3y ago

You can block all .zip with the following uBlock Origin filter: ||zip^ Tell everyone you know.

callalex 3y ago

What is the argument in favor of these TLDs existing other than corruption/extortion?

kanetw 3y ago

I blackholed .zip and .mov in my DNS servers.