Hacker News Reader

Comment by planede | Hacker News Reader

These redirects are cute, but how can we be sure that the domain is owned by the same people as 7-zip.org? I can imagine an attack scenario where someone with malicious intent registers seven.zip, initially sets it up to redirect 7-zip.org. People start using this new URL and then after a while seven.zip starts to host a mirror of 7-zip.org with a malicious installer.

Not trying to accuse anybody, just wondering.

View on HN

The real answer is that trust isn't needed, because you just shouldn't use it.

You know that 7-zip.org is the official site. You see that's where you end up after the redirect. Just bookmark and use that. No reason to add more steps.

The real answer is: trust is not a problem that can ever be fully mitigated by smart technology and that's why we depend on things like the wonderful package maintainers of debian and other projects to do due diligence for the rest of us!

Even typing in a domain you know can be fraught. There are still plenty of popular domains with common typos registered by shady people. Most of them I encounter tend to be spam sites rather than maliciously impersonating the site they are trying to steal traffic from but that's not a far leap. See https://news.ycombinator.co

until a Node coder withdraws a tiny-but-widely-referenced package.

That might be the real answer, but not very satisfactory, as it suggests that this domain just shouldn't exist.

At least 7-zip.org could have a list of domains that they own and control if they wish people to use these alternate domains.

> if they wish people to use these alternate domains

I would have assumed the main reason to register alternate domains like this would not be so people can use them, but rather to prevent others registering them and abusing them.

Maybe, then it serves that purpose (if it's indeed their domain). But why redirect then or even point them to an HTTP server?

Anyway, I would never choose to fight this battle, feels rather futile. It doesn't help that they have a dash in the name, so they have to hunt down names with 7-zip and 7zip as well.

That's the only reason that I have done it with my domains. I don't use a redirect, though, I just have the DNS records resolve all the alternate domains to the same IP address.

> You know that 7-zip.org is the official site.

How would I know that, tho? What if 7-zip.com is the official, and 7-zip.com is a similar site with a malware?

The squatters just need to start saying that "seven.zip" is the new home page and 7-zip.org is deprecated instead of redirecting.

It only takes some SEO to make it look plausible for many users who trust Google and see "seven.zip" as the first search result.

then you address it by reporting/complaining. It's already perfectly possible to do that, the only change here is a name. I'm sure there's also phishing detection (that will certainly improve with ML) that can help too.

either way, what's the solution to prevention? disallow the entire TLD and every possible TLD that could lead to phishing? there are already plenty of issues with .com being used for phishing. have a regulatory body do ID verification of every registrant and if it sounds like a domain that could possibly be misused then ... what?

Said malware would also have to be code signed with the 7-zip authors' code signing certificate. However, if you're downloading it for the first time, you wouldn't know what that correct value is.

Just wanted to point out that trust is already embedded in your scenario: where you say "you know", that really means that you trust, based on experience. The experience that gives rise to that knowledge is the same sort of thing that gives rise to the attack vector being suggested here.

Except the way most people end up with malware is searching for software and downloading the first result they can find.

The real answer is that .zip should never have been allowed as a TLD.

Selective/targeted redirection is possible based on geography,client.etc....

whois isn’t much use any more, but registrar doesn’t match:

  $ whois 7-zip.org
  …
  Registrar: GoDaddy.com, LLC
  …

  $ whois seven.zip
  …
  Registrar: Google LLC.
  …

Name servers don’t match:

  $ dig +short 7-zip.org NS
  ns01.domaincontrol.com.
  ns02.domaincontrol.com.

  $ dig +short seven.zip NS
  ns-cloud-c1.googledomains.com.
  ns-cloud-c2.googledomains.com.
  ns-cloud-c3.googledomains.com.
  ns-cloud-c4.googledomains.com.

(Aside: I believe these queries are strictly the wrong thing, asking seven.zip what its nameservers are, but you actually need to ask the zip. nameservers what seven.zip’s nameservers are. The two will normally match, but don’t actually have to, and in my crazy hacker dreams (you know, the ones where five dollar wrenches don’t exist) I can imagine the difference being used sneakily. But I’m not sure if there’s any good way of asking for the actual nameservers with dig, which is basically “`dig +short zip. NS`, then `dig +short @one-of-those-zip-nameserver-addresses seven.zip. NS`”, and yes, you’d need to follow more steps if you were dealing with a deeper domain name. Whois records are actually more convenient in general!)

And servers don’t match:

  $ dig +short 7-zip.org
  49.12.202.237
  $ dig +short -x 49.12.202.237
  static.237.202.12.49.clients.your-server.de.

  $ dig +short seven.zip
  216.239.36.21
  216.239.34.21
  216.239.32.21
  216.239.38.21
  $ dig +short -x 216.239.36.21
  any-in-2415.1e100.net.

These checks give no reason to suspect it’s legitimate.

That doesn't mean much though. Its hardly uncommon to just use the rigistrar's servers for a redirect for smaller project.

Step 1. Buy domain X' similar to X

Step 2. Redirect to X

Step 3. Gain popularity quickly and appear as a legitimate alias of X

Step 4. Take control of X

Step 5. ...

Step 6. Profit

The real way is to gpg-sign all of your distributed binaries, and tell your users to be careful where they get the corresponding public key.

This is both much-needed and incredibly inconvenient in the world of windows binary distribution.

I've always wondered what the point of this is. Why not just skip the signature and tell users to be careful where they get the binary? If I can't trust that the binary made it to me untampered, why should I believe the pubkey is any more legitimate?

Because the website itself or the primary domain server could potentially be hacked. More likely, your DNS service (or a maliciously edited /etc/hosts) could give you a dishonest resolution, sending you to the fraudulent address.

A public key does not exist in a vacuum. Ideally, it is part of a larger "web of trust", having been signed by others in that web. Unfortunately, websites like 7-zip.org do: they are socially isolated, which is where this situation of mistrust originated. Package managers (like Debian's apt or Archlinux' pacman) are at the advantage here, because the social coordination of a software repository sets the perfect circumstances for a web of trust; and the package manager itself automatically checks gpg signatures after downloading each package.

I think that's part of the problem, if you don't have that package manager to bootstrap your signature key ring, DNS is your next best bootstrap. It is, of course, a terrible bootstrap for trust, but it is one so many users on Windows have been relying on for such a long time.

For power users on any modern Windows 10/Windows 11 there is at least WinGet now. Its manifests repo is becoming a very interesting (open) source of truth for common Windows applications. Admittedly, it in most cases doesn't seem to be checking specific code signatures in most cases either, but at least includes SHA checksums.

For instance, 7zip's manifests: https://github.com/microsoft/winget-pkgs/tree/master/manifes...

It's too bad there's still not a great option for "average user that doesn't know/trust how to use a CLI", given how sadly polluted the Microsoft Store can be for many common, especially Open Source, applications. For direct instance, because winget kindly includes Microsoft Store results when searching, there is a "7zip 22" in the Microsoft Store that costs some amount of money (winget details say "PaidUnknownPrice" for the pricing information; I'm on a corporate machine right now with the actual Store access locked so can't search in the actual Store right now) and the Publisher is listed as RepackagerExpress.com. (That website currently doesn't go anywhere, giving it a spot check.)

Having seen this, I may boot up my personal machine and try to report this specific Store listing for violating the Store's Open Source policies, though I'm unsure if such whackamole is all that useful. (Seems like it might be a useful winget feature request for it to provide Store Report URLs.)

Microsoft Store is precisely what I expected it to be: what likely started as an effort by some in the company to reproduce the utility of a package manager, but in the end sabotaged by the perverse incentives of capitalism.

The Cathedral cannot emulate a Bazaar.

I think the point was the binaries would be distributed around different mirrors that might not be under the control of the author - so long as you got the key from the author the actual binary (which is a much larger filesize than the key) could have less secured mirrors.

This is where the TOFU model comes in, you implicitly trust the key on first use.

Finding a legitimate download one time is better than having to find it every time.

Bootstrapping keys is a difficult thing for sure, but TOFU is still better than nothing at all and seems to work pretty well in practice.

Of course you don't know.

For example, http://byurejects.com/ redirects to https://admissions.utah.edu/apply/

IDK exactly who owns "byurejects.com" but I'm guessing it's not "utah.edu."

(Background: Brigham Young University and University of Utah are rivals.)

It's a fair point, although that concept of trust happens with every domain.. including those that use another TLD for their content delivery network (example.com with images served from example.net), or SaaS app (example.blog with login.example.app).

In this particular case though, it's a 301/Permanent redirect[0], meaning it should be remembered forever. This includes the domain not being listed by search engines[1] (the target URL is used) and once you've visited it on your system it will remember the redirect indefinitely.

The point being, you don't need to trust who set it up, it's very hard to undo. If someone wanted to do this nefariously or reserve the right to use the domain in a different way in the future, they would want to use a temporary redirect.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 [1]: https://developers.google.com/search/docs/crawling-indexing/...

Check out MarkMonitor. There's a bunch of companies that worry about someone registering lookalike domains, or trademarked terms on alternate TLDs. This feels like a variant of that larger problem.

Without a statement on the official 7-zip site, I'd assume it's unofficial and untrustworthy.

https://en.m.wikipedia.org/wiki/MarkMonitor

Reply on news.ycombinator.com