[HN Gopher] Deceptive example for malicious usage of .zip domain
       ___________________________________________________________________
        
       Deceptive example for malicious usage of .zip domain
        
       Author : lhoff
       Score  : 68 points
       Date   : 2023-06-22 16:05 UTC (6 hours ago)
        
 (HTM) web link (fosstodon.org)
 (TXT) w3m dump (fosstodon.org)
        
       | lostmsu wrote:
       | I am not sure what this does that cant be made with a href tag
       | with text and a tooltip.
        
         | sebzim4500 wrote:
         | There are lots of contexts where you can't use an href tag.
         | Twitter maybe?
        
           | lostmsu wrote:
           | This may be a twitter problem, but it is not a web problem.
        
             | faangsticle wrote:
             | 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
        
               | rainonmoon wrote:
               | ...the same email where you can modify links to appear as
               | whatever you'd like anyway? Same goes for HN etc. This is
               | overblown.
        
           | CydeWeys wrote:
           | 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.
        
       | blooalien wrote:
       | 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.
        
       | tedunangst wrote:
       | How is this different from paypal.com@notpaypal.com?
        
         | 0x0000000 wrote:
         | 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.
        
           | tedunangst wrote:
           | I chose to not add https so it wouldn't link.
        
           | SAI_Peregrinus wrote:
           | Doesn't every browser "grey out" everything other than the
           | hostname & TLD these days?
        
           | pests wrote:
           | 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
        
       | NoMoreNicksLeft wrote:
       | Can't wait for the .exe domain.
        
         | Zambyte wrote:
         | Next thing you know there'll be a .com tld!
         | 
         | https://en.wikipedia.org/wiki/COM_file
        
       | watashiato wrote:
       | 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.
        
         | donmcronald wrote:
         | > 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.
        
           | mid-kid wrote:
           | at that point you can just use a regular hyperlink without
           | showing the url on the page at all.
        
       | throw7 wrote:
       | https://github.com/kubernetes/kubernetes/archive/refs/tags/@...
       | 
       | I get a: "404: Not Found" from the site "codeload.github.com"
        
         | yurymik wrote:
         | Now replace all inner slashes with U+2215 (copy-paste from here
         | https://www.compart.com/en/unicode/U+2215)
        
           | CydeWeys wrote:
           | 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.
        
       | [deleted]
        
       | its-summertime wrote:
       | > The new ".zip" domain is being used almost solely for malware.
       | 
       | Citation?
        
       | GuB-42 wrote:
       | 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.
        
         | 0x0000000 wrote:
         | 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.
        
       | yathern wrote:
       | 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...
        
         | Akashic101 wrote:
         | 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
        
         | fragmede wrote:
         | Side note: someone's using http://yourmom.zip for hilariously
         | nerdy purpose
        
         | GloomyBoots wrote:
         | 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?
        
           | Arnt wrote:
           | 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.
        
             | fragmede wrote:
             | click and hold brings up a user-initiated popup that shows
             | the full url, though it may not sufficiently deobfuscate
             | it.
        
         | lhoff wrote:
         | 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.
        
       | cxr wrote:
       | 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.
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-06-22 23:02 UTC)