Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dangers of Google’s .zip TLD

medium.com

Post reply on HN
Print view View original

1–10 of 14 posts

Re: The Dangers of Google’s .zip TLD

#2

Post by mooman219 »

> 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/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.

Re: The Dangers of Google’s .zip TLD

#4

Post by catiopatio »

mooman219 wrote: post #2

> 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/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…

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.

Re: The Dangers of Google’s .zip TLD

#5

Post by adhesive_wombat »

> 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.

Re: The Dangers of Google’s .zip TLD

#6

Post by tracker1 »

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.

Re: The Dangers of Google’s .zip TLD

#7

Post by wizofaus »

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 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!)

Re: The Dangers of Google’s .zip TLD

#8

Post by adhesive_wombat »

catiopatio wrote: post #4
mooman219 wrote: post #2

> 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/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…

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.

Maybe we should have the .exe TLD to make every URL using it look immediately suspicious.

Sorta like https://verylegit.link but built into the whole TLD.

Re: The Dangers of Google’s .zip TLD

#9

Post by cuttysnark »

mooman219 wrote: post #2

> 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/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…

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.
Post reply on HN