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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
> 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.
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.
43 comments
[ 5.2 ms ] story [ 110 ms ] threadWhile 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.
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.
It is an old trick, and browsers tend to throw a fit before opening URLs with user names.
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...
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.
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.
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.
Pretty much any chat application
Pretty much any website that allows comments, like HN
> Same goes for HN etc
No. Show me if you think you can.
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.
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
Citation?
https://en.wikipedia.org/wiki/COM_file
I get a: "404: Not Found" from the site "codeload.github.com"
> 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.