Hacker News Reader

> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name?

Turn of all of your developer knowledge for a minute.

You click on a link "very-trustworthy-ceo-information.zip" in a mail, since you want to download this very important information from your CEO. Sure, your browser pops up, but it does that all the time so who cares, and then there is a file "very-trustworthy-ceo-information.zip" in your downloads folder. Native Outlook might usually open it in a different way usually, but who cares? OWA - you won't notice a difference in the UI at all. But anyway, important CEO information. Open the zip, open the PDF, oops your workstation is compromised.

If we turn our technical knowledge back on, it's rather simple. A user was phished to open a link to "https://very-trustworthy-ceo-information.zip". This returned with a file download, obviously called "very-trustworthy-ceo-information.zip", containing whatever I want to contain based off of IPs and whatever I can stuff into the link in a hidden fashion the average user won't note.

A lot of people would not be able to distinguish between https://foo.zip answering with a binary content type and naming the file foo.zip through content disposition headers and foo.zip coming from a trusted source.

And honestly, I would personally have to double-check what's going on there if it happened to me.

My point was that the person fooled by https://foo.zip/ would have been also fooled by https://foo.com/bar.zip, so the existence .zip wouldn’t change much.

But now I’ve understood that the auto-linkification of a simple non-link mention like update.zip can be indeed dangerous.

Imagine a URL like http://www.chase.com.auth.statement.zip

Average users would never suspect a thing.

I genuinely do not see how that is different than http://www.chase.com.auth.statement.com

I'm here with mobile Firefox and HN is abreviating the display of those links so they are ACTUALLY identical on my screen.

As a developer, the difference might be minimal, you see the http:// part.

For the average computer user, I'm guessing they don't "see" the http:// part. It looks like a link to an attachment in the email, so safer than a random URL.

But a random attachment would be much less safe than a random url!

> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody; downloading a .zip might, which you can attach to any link name? But in any case I wasn’t able to find any .zip URL with a purpose, but lots of Reddit posts of angry sysadmins who bemoaned the influx of terrible TLDs with mostly phishing use and vowed to block them all. So they probably have a point in downright blocking the whole TLD.

The problem is auto-linkification. It is extremely common in forum posts or emails to refer to attached filenames. Most forum softwares or email clients are helpful it automatically turning obvious URLs (doesn't start with a protocol:// but ends in a .tld) into clickable links. Anybody's reference to a zip filename is now a clickable link, only waiting to be registered for phishing attempts.

That makes sense. Funnily enough I had kind of an inverse problem building the https://3dgs.zip/ landing page, or linking to the project from elsewhere - I’d point a link to the compression survey with the link text “survey.3dgs.zip”.

And had to have people point out to me that they don’t want to click on that, because they don’t want to download a big file.

That's not a new problem tho. .TS and .CS are TLDs and Heck even .COM is also a file extension, should we block that too? What changed suddendly?

The type of user who has email conversations about .COM files is the same type of user who will realize that the link was automatically created by someone's email client and have a laugh about it.

I don't know if you can say the same about zip files, an average user they might encounter someone mentioning a zip filename a handful of times in a year and they might click on the link expecting to get that zip file.

The thing is '.com' is relatively unknown. When was the last time you had a genuine .com file you needed to use?

And you're someone who's tech-savvy.

Most people are going to see ".com" and think "Website" not "Program". So if suddenly a .com file is downloaded there's at least a chance they might stop and wonder what's going on.

I run into this issue all the time - We get Bug bounty reports constantly because $SecurityResearcher put "example.com" into the "Company Name" field, and we sent them an email saying "Thanks for signing up. We hope you find $OurProduct useful at $CompanyName. "

When the email turns up in their Gmail inbox, Gmail "helpfully" turns the plain text "example.com" into a link to https://example.com - so $SecurityResearcher reports it to us as a vulnerability in our platform because "we" are linking to example.com - except we never did, and we have no way to tell Gmail, or Outlook, or any other platform to stop doing that.

Services we pay for, directly, also do this - Notion and Slack are two I can think of immediately. I have to fight them to stop turning my mention of some file into a link to a random domain. (e: Maybe Slack has stopped doing this, perhaps - in testing it didn't do automatic linkifying for messages to myself)

This was bad enough with .cs, .ts, .js., .json and so forth - but having a .zip link appear in the middle of documentation on how to do something with a zip file is a recipe for disaster.

I've had a document saying "please download package.zip from the build artifacts site" - which was then auto linked to https://package.zip - and anyone not paying attention might expect that it was a link to the build artifacts site.

The COM file exploit worked because it is relatively unknown. I remember a worm going around when I was in grad school where you'd get an e-mail with a link to https://giftcard.customerservice.savemoneyonanew.tv/amazon.c.... Users who had been through the phishing training would see the HTTPS at the beginning and the amazon.com at the end and know that this was a legitimate Amazon email. The e-mail instructed them to click the link and "open the PDF file". Users would click the link, down load the COM file, and the open the file, installing malware all over the machine and forwarding the worm to all their contacts.

Good point. I wonder what happens if i rename a malicious file into google.com and push it into ever AD user's desktop at a large corporation. Might not even make a difference that MS hides extensions by default.

I don't get it, why is it a "vulnerability" if you send people emails that contain a link to example.com? What exploit is possible?

Unsanitized web form mailers are a common source of spam mails, in particular if that form allows specifying an arbitrary email address to send the mail to. Essentially what the website owner meant to do was sending an innocent email (maybe for leaving feedback, or for a signup link), and the email text then gets mangled by the spammer in a way that you are seeing a link to product they want you to buy. It is not a vulnerability in the sense that it leads to malicious code being executed, but it allows spammers to send their spam links through "reputable" email sources, increasing the likelihood that it will make it through spam filters.

Because some unsuspecting user may think we are linking them to some random site, even if we are not.

If that domain is "important-banking-info.zip" then people are less likely to be suspicious if their browser happens to download a file of the same name.

You're missing the point: he did not send an email with a link, he sent an email in plain text, no hyperlink, containing the ASCII characters "example.com", and the recipient's email client silently changed it into a hyperlink. And of course that doesn't just happen with "example.com"; it happens with any piece of plain text that the email client decides might be a URL, which includes many file names since many common file extensions are also TLDs. That is the security issue.

COM files have been used maliciously due to confusion with urls [0]. I think I've heard of antivirus software preventing COM files from being run because of this.

[0] https://en.wikipedia.org/wiki/COM_file#Malicious_usage_of_th...

Can .COM files even run on modern 64-bit Windows systems? Surely they can't - hasn't the 16-bit subsystem been removed?

Windows will run a regular MZ exe even if its name ends in .com.

MZ exe, what do you mean?

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

MZ is the magic number at the start of the file.

Although gp probably meant a PE executable [0] which (typically) start with a stub MZ executable telling DOS users to run it under Windows. Because of this they still have a MZ magic number.

[0] https://en.wikipedia.org/wiki/Portable_Executable

OK, thanks I thought I screwed up.

I have recently been working on a command line tool and the windows version is called mz.exe. On Linux it is just 'mz', just a coincidence. I was concerned this name collision might cause problems, but that is fine.

It's not a new problem, but think about how many average computer users expect to be sent a ZIP file, vs how many of them expect to receive a TS, CS or COM file in their inbox.

COM files are a good point I hadn't considered.

> The problem is auto-linkification.

Who's auto-linkifying .zip domains?

I've seen it happening on GitHub, among others. Anyone that automatically imports an up-to-date list of all existing TLDs will fall into the same "trap".

I grabbed two .zip domain names that I knew were used frequently as filenames and set them up to return a zip with an html inside. The html tries to load a specific resource from the server to let it know the html was opened.

There are dozens of unique opens per week.

I'm very curious how an executable would do, but I'm not trying to cause any problems.

Ah that makes a lot more sense as an attack vector. Thanks for explaining! Indeed, checking a list of common .zip file names, most of them are registered domains. Uhhh.

http://iloveu.exe would be a neat website tho

Looks more like everyone is try to exit the EU ;)

> ILOVEYOU, sometimes referred to as the Love Bug or Loveletter, was a computer worm that infected over ten million Windows personal computers on and after 5 May 2000. It started spreading as an email message with the subject line "ILOVEYOU" and the attachment "LOVE-LETTER-FOR-YOU.TXT.vbs".

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

:D

> I’m no security person, so the reasoning felt a bit weird to me, as I guess the .zip TLD can’t hurt anybody

I really apologize that our docs don't cover what to do in your situation. We move really fast with software to bring you the best experience possible and sometimes miss these things.

I'm the founder, John Smith, and I'll provide direct support here for you.

Just go in your browser and open the .zip archive to extract the file you need. You can use chrome, Internet Explorer, Firefox, or any other browser.

In your browser, open the zip file that you downloaded earlier from our website. Open it this way: https://3DGScode.zip/cross-platform-imaging

That's it! Opening the archive in that manner performed a reconfiguration on your exact system, so everything should now work on your end. Sorry about that snafu on our end.

I block .top and several other of the newer TLDs in SMTP. We get tons of spam from these TLDs, and we don't otherwise interact with those TLDs in our business.

With a little trickery with URL's you could construct something like:

https://github.com/example/project/releases/@example-project...

Due to everything in a URL before the @ being interpreted as a username for basic authentication, this would result in the user navigating to https://example-project-v1.zip instead of to github.

Edit: Fortunately it seems like browsers have caught on to this trick

Is how you find out that your company's IT department is just a bunch of bozos in a trenchcoat.

Sucks, but it's the norm for any company who's payroll isn't >50% programmers.

Some firewalls just block newly-registered domains. Are you totally sure it wasn’t that category?

Yep, I checked other, established .zip domains. Finding one was quite a hard task, which gave me pause. I found a link shortener site on some Google promotional page for .zip (.zip is a Google-TLD). Accessing any .zip url was denied on the tested machines.

So this matches what IT told me and what the sister comments state here: some tool blocks the whole .zip TLD on the DNS level.

Tip: “nic.TLD” should always exist and will often be the first domain registered. It is operated by the domain’s registry. For example, see https://nic.zip.

Counterexample:

https://nic.gy

https://registry.gy

Those are ccTLDs, which don't have any rules to abide by.

Email servers also put a high spam score on new domains, from what I've witnessed.

So these type of filters work on massive lists that IT or Sec admin configure. Its not that they specifially blocked .zip but software like Umbrella, Zorus DNS etc have a filter for "phising domains" and that TLD is probably part of it. Blocks at the DNS level, its actually useful.

Demo for ZorusTech DNS blocker: https://www.youtube.com/watch?v=MeubLoEHW9E