Live data from Hacker News

Deceptive example for malicious usage of .zip domain

fosstodon.org

1–10 of 44 posts

Re: Deceptive example for malicious usage of .zip domain

#3
Here's the original source by the author: https://scribe.rip/@bobbyrsec/the-dangers-of-googles-zip-tld...

While I think that we really don't need a .zip domain, this trick falls apart when not shown as an image. Hovering over either URL should tip you off. Firefox shows the actual link in the bottom left.

Re: Deceptive example for malicious usage of .zip domain

#5
Cool trick - they're using HTTP auth URLs[1] so that the @ sign is doing a lot of the heavy lifting (plus some clever unicode slashes). It's an old school phishing trick, with the additional layer of looking like a genuine zip file.

Not sure if this trick would be too effective in real life, Firefox and likely others will give you warnings when logging into a site like this, as this form of HTTP auth is way deprecated. However, this is the strongest example against .zip I've seen yet though, from someone who didn't buy into the initial panic.

Side note - I'm using .zip for something legitimate! https://HN.zip is a little weekend project for an offline-caching read-only Hacker News (I lose reception in the Subway a lot so it makes it easier to navigate). It's not done yet though - still pretty rough around the edges. Maybe in a week or two I'll do a Show HN and see if anyone cares.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...

Re: Deceptive example for malicious usage of .zip domain

#9

How is this different from paypal.com@notpaypal.com?

What you have in your comment is an email address, where anti-phishing training has hopefully helped users to identify non-authentic or at least suspicious domains. We (should) know to look at the part after the "@" in an email.

This trick is a URL, not an email address. It looks like a valid URL, because we are accustomed to checking the hostname for authenticity. But the URL in the post is crafted to look like the hostname is X, when in reality it is Y. With URLs, we usually look for the part between the https://, and the first forward / after that. This malicious URL uses unicode characters that look like forward slashes, but aren't, so it appears to be on a different hostname than it is. I don't think anyone is trained to look for the "@" in a URL, and certainly to non-technical folks it's not all that different than a "#" or a "!", i.e., inconspicuous.

Post reply on HN