5 ms·

I'm interested to know how eScan, a security company, never noticed that they were using http to distribute executables to customer devices for so long.

deleted 2y ago
[deleted]
mistrial9 2y ago
plenty of critical services use HTTP -- maybe exactly because they are critical.. think the scenarios through and that may make more sense..
- capitainenemo 2y ago
  Common enough to use it.. linux distros frequently distribute updates over http (and ftp). But those are always signed. Something eScan did not do.
  - febeling 2y ago
    Can’t you switch out the signatures inflight, too?
    - beagle3 2y ago
      If it’s based on asymmetric encryption, (e.g. RSA, DH etc) and the private key did not leak, then no.
    - DaSHacka 2y ago
      AFAIK, the worst you could do is serve the victim stale (valid) packages, and prevent them from seeing that there are new updates available. I maintain a (somewhat) popular mirror server at a university, and we actually ran into this issue with one of our mirrors. The Tier 1 we were using as an upstream for a distro closed up shop suddenly, leaving our mirror with stale packages for some time before users told us they never got any updates.
      - capitainenemo 2y ago
        I don't think that would work with most distros, since you're fetching an (also signed) update list and you'd get notified that the update failed due to a stale list, or that the expected updated package was missing on the mirror.
    - jijijijij 2y ago
      You could, but then the signature check would fail. Usually the public keys of developers or packagers are shipped with a linux distribution. However, you shouldn't blindly trust in this in "linux" either. The implementation varies between package managers. Eg. DNF in Fedora has signature checks not enabled for local package installations, by default. There is no warning, nothing. If you want to infect new Fedora users, you MITM RPMFusion repo (codecs etc) installation, because that's a package almost everyone installs locally and the official install instructions don't show how to import the relevant keys beforehand. Arch was also very late to the validation party.
      - capitainenemo 2y ago
        How is Arch vulnerable? While I don't have an Arch system handy, I do have a steam deck that I play around with (in an overlay), and I've certainly run into a lot of signature issues due to Valve making a hackish "pin" of the evergreen Arch with signatures in the Valve tree's snapshot being often out of date. Those signatures are also checked for local installs unless you explicitly disable them.
        jijijijij 2y ago
        Pacman has signature checks by default, for over a decade now, I think, but they have been ridiculously late with universal usage of this feature, relatively speaking. They were still barebacking their machines, when everybody trivially knew the internet was serious business and expected signature checks, therefor.
    - febeling 2y ago
      I realize now it was a stupid question, but the excellent refresher and ensueing discussion of edge cases was well worth the downvote someone felt compelled to leave, haha
- jamespo 2y ago
  I'd hope these other critical services at least sign their packages
  - cryptonector 2y ago
    Yes. But IIRC there have been attacks on Debian package fetching anyways.
- seiferteric 2y ago
  Somewhat ironically OCSP.
  - cryptonector 2y ago
    This has to do with circularity. If you are building a TLS library that needs to fetch OCSP Responses dynamically, you might not have an easy time using HTTPS to do it. Well, obviously you'd have to disable the use of OCSP for validating the OCSP Responder's TLS server certificate, but still you have a re-entrance requirement, and anyways the OCSP Responses are signed. (Or, well, you could use OCSP to validate an OCSP Responder's TLS certificate if you had code to detect a circular dependency, then stop and consider it validated. This would allow the use of OCSP for validating OCSP Responder TLS server certs where ultimately you could use HTTP for a non-privacy-sensitive certificate or where you could elide OCSP Responder TLS server cert validation but still use HTTPS to fetch OCSP Responses so as to provide confidentiality about the server names you're visiting.) The main reason to want to use HTTPS for fetching OCSP Responses has to do with privacy rather than security relative to active attacks. It's probably time to revisit this.
lupusreal 2y ago
Seems like criminal negligence to me.
- hermannj314 2y ago
  If an Uber Eats driver poisons your food en route from McDonalds, then McDonalds is criminally negligent? I mean, I understand HTTPS is industry best practice but the criminals in this story are the actual criminals.
  - NegativeLatency 2y ago
    All analogies are flawed but this feels a bit more like the tamper proof labels on products, the antivirus company threw some chicken in a produce bag, and called it good. At this point a lot of antivirus software is just useless or actively harmful.
    - yborg 2y ago
      Avast actually had a trojan horse product whose main purpose was collecting browsing history for sale to data brokers ... that you paid a subscription fee for. https://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-ban-avast-selling-browsing-data-advertising-purposes-require-it-pay-165-million-over https://www.ftc.gov/news-events/news/press-releases/2024/02/...
  - lupusreal 2y ago
    > I understand HTTPS is industry best practice Right. Unlike your McDonalds example, there is already an industry standard solution to this problem. The software ""engineers"" who neglected to implement it should be found criminally negligent for the harm they caused to their users. I know this is an unpopular suggestion on HN because code monkeys want all the glory of the "engineer" job title without any of the responsibility.
    - robocat 2y ago
      > The software ""engineers"" should be found criminally negligent Software goes across borders. Perhaps you also think negligent software "engineers" should be extradited or rendered across jurisdictions? Apart from the fact that Engineer does not have to imply either certified or licenced (the words you should be using if you know anything).
andmarios 2y ago
Some customers actually ask for it. The correct behavior is to have https as the default and have the user explicitly switch to http.
- nucleardog 2y ago
  Or just validate the binary you download then none of this even matters—for this or any other sort of potential vulnerability, your updater will never end up running untrusted software with escalated privileges. HTTPS is providing confidentiality, and authentication. The confidentiality doesn’t really matter here. You’re distributing a software installer. There’s a good chance you’ll give a copy to anyone that visits your website and wants to use your software. And you’re not hiding what you’re downloading in any meaningful way. The authentication is important. That prevents someone from, say, sending the user a completely different binary and having your software run it. The authentication could just as easily be solved by signing the files you distribute and validating the signature of the downloaded update before running it. (Hell, if you’re signing your installers (likely) it could be as simple as deferring to Windows’ WinVerifyTrust method and a check that the certificate used is actually your own.) Debian still distributes packages primarily over HTTP (https://www.debian.org/mirror/list https://www.debian.org/mirror/list) without issue.
radicaldreamer 2y ago
http or https doesn't matter (in fact, you shouldn't rely on it because the end user could be MITM'd already with a root certificate maliciously installed on their device). You should sign binaries and verify and consider the network/distribution method compromised by default.
- dixie_land 2y ago
  If the user is MITM'd, what's preventing the attacker also replace the signature to verify against?
  - kuhsaft 2y ago
    The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload. EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.
  - pixl97 2y ago
    You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.
    - littlestymaar 2y ago
      And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
      - pixl97 2y ago
        I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest. The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.

deleted 2y ago

[deleted]

mistrial9 2y ago

plenty of critical services use HTTP -- maybe exactly because they are critical.. think the scenarios through and that may make more sense..

capitainenemo 2y ago
Common enough to use it.. linux distros frequently distribute updates over http (and ftp). But those are always signed. Something eScan did not do.
- febeling 2y ago
  Can’t you switch out the signatures inflight, too?
  - beagle3 2y ago
    If it’s based on asymmetric encryption, (e.g. RSA, DH etc) and the private key did not leak, then no.
  - DaSHacka 2y ago
    AFAIK, the worst you could do is serve the victim stale (valid) packages, and prevent them from seeing that there are new updates available. I maintain a (somewhat) popular mirror server at a university, and we actually ran into this issue with one of our mirrors. The Tier 1 we were using as an upstream for a distro closed up shop suddenly, leaving our mirror with stale packages for some time before users told us they never got any updates.
    - capitainenemo 2y ago
      I don't think that would work with most distros, since you're fetching an (also signed) update list and you'd get notified that the update failed due to a stale list, or that the expected updated package was missing on the mirror.
  - jijijijij 2y ago
    You could, but then the signature check would fail. Usually the public keys of developers or packagers are shipped with a linux distribution. However, you shouldn't blindly trust in this in "linux" either. The implementation varies between package managers. Eg. DNF in Fedora has signature checks not enabled for local package installations, by default. There is no warning, nothing. If you want to infect new Fedora users, you MITM RPMFusion repo (codecs etc) installation, because that's a package almost everyone installs locally and the official install instructions don't show how to import the relevant keys beforehand. Arch was also very late to the validation party.
    - capitainenemo 2y ago
      How is Arch vulnerable? While I don't have an Arch system handy, I do have a steam deck that I play around with (in an overlay), and I've certainly run into a lot of signature issues due to Valve making a hackish "pin" of the evergreen Arch with signatures in the Valve tree's snapshot being often out of date. Those signatures are also checked for local installs unless you explicitly disable them.
      - jijijijij 2y ago
        Pacman has signature checks by default, for over a decade now, I think, but they have been ridiculously late with universal usage of this feature, relatively speaking. They were still barebacking their machines, when everybody trivially knew the internet was serious business and expected signature checks, therefor.
  - febeling 2y ago
    I realize now it was a stupid question, but the excellent refresher and ensueing discussion of edge cases was well worth the downvote someone felt compelled to leave, haha
jamespo 2y ago
I'd hope these other critical services at least sign their packages
- cryptonector 2y ago
  Yes. But IIRC there have been attacks on Debian package fetching anyways.
seiferteric 2y ago
Somewhat ironically OCSP.
- cryptonector 2y ago
  This has to do with circularity. If you are building a TLS library that needs to fetch OCSP Responses dynamically, you might not have an easy time using HTTPS to do it. Well, obviously you'd have to disable the use of OCSP for validating the OCSP Responder's TLS server certificate, but still you have a re-entrance requirement, and anyways the OCSP Responses are signed. (Or, well, you could use OCSP to validate an OCSP Responder's TLS certificate if you had code to detect a circular dependency, then stop and consider it validated. This would allow the use of OCSP for validating OCSP Responder TLS server certs where ultimately you could use HTTP for a non-privacy-sensitive certificate or where you could elide OCSP Responder TLS server cert validation but still use HTTPS to fetch OCSP Responses so as to provide confidentiality about the server names you're visiting.) The main reason to want to use HTTPS for fetching OCSP Responses has to do with privacy rather than security relative to active attacks. It's probably time to revisit this.

lupusreal 2y ago

Seems like criminal negligence to me.

hermannj314 2y ago
If an Uber Eats driver poisons your food en route from McDonalds, then McDonalds is criminally negligent? I mean, I understand HTTPS is industry best practice but the criminals in this story are the actual criminals.
- NegativeLatency 2y ago
  All analogies are flawed but this feels a bit more like the tamper proof labels on products, the antivirus company threw some chicken in a produce bag, and called it good. At this point a lot of antivirus software is just useless or actively harmful.
  - yborg 2y ago
    Avast actually had a trojan horse product whose main purpose was collecting browsing history for sale to data brokers ... that you paid a subscription fee for. https://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-ban-avast-selling-browsing-data-advertising-purposes-require-it-pay-165-million-over https://www.ftc.gov/news-events/news/press-releases/2024/02/...
- lupusreal 2y ago
  > I understand HTTPS is industry best practice Right. Unlike your McDonalds example, there is already an industry standard solution to this problem. The software ""engineers"" who neglected to implement it should be found criminally negligent for the harm they caused to their users. I know this is an unpopular suggestion on HN because code monkeys want all the glory of the "engineer" job title without any of the responsibility.
  - robocat 2y ago
    > The software ""engineers"" should be found criminally negligent Software goes across borders. Perhaps you also think negligent software "engineers" should be extradited or rendered across jurisdictions? Apart from the fact that Engineer does not have to imply either certified or licenced (the words you should be using if you know anything).

andmarios 2y ago

Some customers actually ask for it. The correct behavior is to have https as the default and have the user explicitly switch to http.

nucleardog 2y ago
Or just validate the binary you download then none of this even matters—for this or any other sort of potential vulnerability, your updater will never end up running untrusted software with escalated privileges. HTTPS is providing confidentiality, and authentication. The confidentiality doesn’t really matter here. You’re distributing a software installer. There’s a good chance you’ll give a copy to anyone that visits your website and wants to use your software. And you’re not hiding what you’re downloading in any meaningful way. The authentication is important. That prevents someone from, say, sending the user a completely different binary and having your software run it. The authentication could just as easily be solved by signing the files you distribute and validating the signature of the downloaded update before running it. (Hell, if you’re signing your installers (likely) it could be as simple as deferring to Windows’ WinVerifyTrust method and a check that the certificate used is actually your own.) Debian still distributes packages primarily over HTTP (https://www.debian.org/mirror/list https://www.debian.org/mirror/list) without issue.

radicaldreamer 2y ago

http or https doesn't matter (in fact, you shouldn't rely on it because the end user could be MITM'd already with a root certificate maliciously installed on their device). You should sign binaries and verify and consider the network/distribution method compromised by default.

dixie_land 2y ago
If the user is MITM'd, what's preventing the attacker also replace the signature to verify against?
- kuhsaft 2y ago
  The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload. EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.
- pixl97 2y ago
  You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.
  - littlestymaar 2y ago
    And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
    - pixl97 2y ago
      I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest. The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.