Deceptive example for malicious usage of .zip domain | Hacker News Reader

Deceptive example for malicious usage of .zip domain

fosstodon.org

88 pointslhoff41 comments

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

Side note: someone's using http://yourmom.zip for hilariously nerdy purpose

This is the type of website I would want to show up in marginalia

Okay I was hoping someone else was going to chime in but even with the influx of Reddit users, the rest of HN isn't that juvenile so I'll do it.

https://selfesteem.zip

410 - https://yourdad.zip

411 - https://yourpenis.zip

413 - https://mypenis.zip

413 - https://yourmom.zip Formally https://yourmother.zip https://yourmum.zip for the British and also http://yomama.zip

417 - https://yourlife.zip

418 - https://yourcoffee.zip

https://yourdick.zip

https://yourwife.zip

https://yoursister.zip/

https://chatgpt3.zip/

mirrored from: https://www.reddit.com/r/ProgrammerHumor/comments/13pzxea/ht... because who knows if that'll be around in a couple of months.

iMessage thinks this URL is a zip file.

I haven’t seen this combination of Unicode forward slashes and http auth before. I would have fallen for it. Does anyone maintain a kind of “phishing URL menagerie” of interesting cases like this?

Sort of. The browser vendors work hard to keep deceptive links and sites from fooling users.

In this case, the browsers I use don't fall for it. Hovering over the link shows the real domain. The browser I use on my work iphone also does something sensible, but I can't remember what. Obviously I can't hover on that device.

click and hold brings up a user-initiated popup that shows the full url, though it may not sufficiently deobfuscate it.

An offline reader does sound pretty nice. I have to travel for work quite a lot in the Berlin Metro and often loose connection there, so a way to cache stories before would be great

I think the dangerous is not phishing for credentials but malware. The example is a Github Link to a release. You click on the link expecting to download the legitimate kubernetes relase zip file. But instead you end up with a patched version with an e.g. included monero miner.

A less tech-savy or distracted user would also fall for a .exe file that downloads and just click on it since he just expects a zip file from github.

Is the code for hn.zip available? I'd love to archive this into a pdf so that it's easy to read on a remarkable.

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.

> Hovering over either URL should tip you off. Firefox shows the actual link in the bottom left.

Most people don't even know what a URL is, let alone how to discover this kind of deception by looking at the hover info.

at that point you can just use a regular hyperlink without showing the url on the page at all.

This so-called attack is also not as effective in most contexts as the simple <a href="https://evilsite.com">https://goodsite.com</a> trick. Raw URLs in web pages don't get auto-linkified anyway, so something is turning it into a link (e.g. through use of HTML), and at that point you can have the link text and the URL be whatever you want, completely independently of each other.

How exactly does this trick work? Thing is, a URL can't have any non-ASCII characters in it. So this would only happen if the webpage or some app takes the URL and undoes the percent-encoding to try to make it more readable.

I just tried the fake URL by pasting it into Safari's address bar, and it “helpfully” percent-encoded the special slashes and tried to go to v1271.zip.

> The new ".zip" domain is being used almost solely for malware.

Citation?

As an "old school" web developer, the `@` sign in the URL was an instant dead giveaway to me, but I'm willing to bet almost nobody outside of those sorts of "old school" tech circles is gonna even notice that.

I am not sure what this does that cant be made with a href tag with text and a tooltip.

There are lots of contexts where you can't use an href tag. Twitter maybe?

This supposed attack doesn't work on Twitter either (or Gmail, or anywhere else I can think of). The full URL doesn't get linkified because of the very contrived use of Unicode slashes in the username portion of the URL.

This may be a twitter problem, but it is not a web problem.

Email (people have been told to look at the little popup that shows where a hyperlink goes for like a decade now)

Pretty much any chat application

Pretty much any website that allows comments, like HN

...the same email where you can modify links to appear as whatever you'd like anyway? Same goes for HN etc. This is overblown.

Like I said "people have been told to look at the little popup that shows where a hyperlink goes for like a decade now"

> Same goes for HN etc

No. Show me if you think you can.

From Google's domain delegation application (<https://gtldresult.icann.org/applicationstatus/applicationde...>):

> 28. Abuse Prevention and Mitigation [...] all registered domain names will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”). The Abuse Policy will provide CRR with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. We plan to post the Abuse Policy on a publicly facing website at nic.zip⁄abuse

The policy document in question cannot, in fact, be found at that* address (because they're using a wildcard URL-rewriting redirect for nic.zip that ends up pointing to a bogus URL on registry.google).

* Actually, anyone familiar with IANA applications will be aware that the applications posted publicly end up, coincidentally enough, mangling all references to URLs because slashes get transformed into U+2044 FRACTION SLASH, so if you actually tried to dereference that, you'll end up on a path dealing in punycode TLDs—specifically "xn--zipabuse-g03d" in this case, which has not (yet) been delegated to anyone.

The trick here is the "@" in the URL, which makes everything before it a user name.

It is an old trick, and browsers tend to throw a fit before opening URLs with user names.

It's a combination of the "@", and the forward-slash-looking-but-not-actually-forward-slash characters in the username and password that complete the trick, as normal forward slashes are not permitted there.

https://github.com/kubernetes/kubernetes/archive/refs/tags/@...

I get a: "404: Not Found" from the site "codeload.github.com"

Now replace all inner slashes with U+2215 (copy-paste from here https://www.compart.com/en/unicode/U+2215)

HN literally doesn't allow you to post those characters, so it doesn't work here. Doesn't actually work anywhere I've tried it.

Can't wait for the .exe domain.

Next thing you know there'll be a .com tld!

https://en.wikipedia.org/wiki/COM_file

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.

My only qualm is that similar slash-shenanigans can already happen and cause the same issue with subdomains.

How many regular users are going to know the real tdl of the below link? Two subdomains one containing many fake slashes.

paypal.com/long/path/to/my/account/.my-evil-invoices.com/transactions.csv

Doesn't every browser "grey out" everything other than the hostname & TLD these days?

They do, but you're probably not doing to come across that when clicking on a URL ending with .zip that downloads a zip file, as shown in the example.

You're not likely to see the URL when clicking on it, because the vast majority of sites use links with text other than the URL. Chrome (the most popular browser) truncates the URL that shows up when you hover over it, if you even notice that bar pop up. So they can just make the URL really long to hide the domain, like many scammers already did.

I chose to not add https so it wouldn't link.

Reply on news.ycombinator.com