8 ms·

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 m

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.

hyperhopper 3y ago
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.
- calvinmorrison 3y ago
  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!
  - tstrimple 3y ago
    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 https://news.ycombinator.co
  - euroderf 3y ago
    until a Node coder withdraws a tiny-but-widely-referenced package.
- planede 3y ago
  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.
  - gibspaulding 3y ago
    > 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.
    - planede 3y ago
      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.
    - JohnFen 3y ago
      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.
- bmacho 3y ago
  > 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?
  - HelloNurse 3y ago
    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.
    - freedomben 3y ago
      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?
  - AstralStorm 3y ago
    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.
- esquivalience 3y ago
  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.
- pjmlp 3y ago
  Except the way most people end up with malware is searching for software and downloading the first result they can find.
- s3p 3y ago
  The real answer is that .zip should never have been allowed as a TLD.
- _8j50 3y ago
  Selective/targeted redirection is possible based on geography,client.etc....
chrismorgan 3y ago
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.
- bawolff 3y ago
  That doesn't mean much though. Its hardly uncommon to just use the rigistrar's servers for a redirect for smaller project.
- nixpulvis 3y ago
  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
thomastjeffery 3y ago
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.
- aqfamnzc 3y ago
  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?
  - thomastjeffery 3y ago
    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.
    - WorldMaker 3y ago
      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/manifests/7/7zip/7zip 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.)
8organicbits 3y ago
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 https://en.m.wikipedia.org/wiki/MarkMonitor
gnabgib 3y ago
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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 [1]: https://developers.google.com/search/docs/crawling-indexing/301-redirects https://developers.google.com/search/docs/crawling-indexing/...
paulddraper 3y ago
Of course you don't know. For example, http://byurejects.com/ http://byurejects.com/ redirects to https://admissions.utah.edu/apply/ 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.)

hyperhopper 3y ago

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.

calvinmorrison 3y ago
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!
- tstrimple 3y ago
  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 https://news.ycombinator.co
- euroderf 3y ago
  until a Node coder withdraws a tiny-but-widely-referenced package.
planede 3y ago
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.
- gibspaulding 3y ago
  > 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.
  - planede 3y ago
    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.
  - JohnFen 3y ago
    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.
bmacho 3y ago
> 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?
- HelloNurse 3y ago
  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.
  - freedomben 3y ago
    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?
- AstralStorm 3y ago
  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.
esquivalience 3y ago
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.
pjmlp 3y ago
Except the way most people end up with malware is searching for software and downloading the first result they can find.
s3p 3y ago
The real answer is that .zip should never have been allowed as a TLD.
_8j50 3y ago
Selective/targeted redirection is possible based on geography,client.etc....

chrismorgan 3y ago

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.

bawolff 3y ago
That doesn't mean much though. Its hardly uncommon to just use the rigistrar's servers for a redirect for smaller project.
nixpulvis 3y ago
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

thomastjeffery 3y ago

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.

aqfamnzc 3y ago
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?
- thomastjeffery 3y ago
  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.
  - WorldMaker 3y ago
    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/manifests/7/7zip/7zip 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.)

8organicbits 3y ago

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 https://en.m.wikipedia.org/wiki/MarkMonitor

gnabgib 3y ago

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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 [1]: https://developers.google.com/search/docs/crawling-indexing/301-redirects https://developers.google.com/search/docs/crawling-indexing/...

paulddraper 3y ago

Of course you don't know. For example, http://byurejects.com/ http://byurejects.com/ redirects to https://admissions.utah.edu/apply/ 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.)