5 ms·

And yet again, twice in a row this time. Note how the referenced Virustotal result has 40+ detections [1]. I'm still wondering why info like this isn't used by

And yet again, twice in a row this time. Note how the referenced Virustotal result has 40+ detections [1]. I'm still wondering why info like this isn't used by Pypi and NPM. Chocolatey has Virustotal integration for all releases. And it's not like Virustotal is the only option, there is Cape [2] for dynamic execution, Metadefender, and Intezer Analyze just to name a few. Really confusing for such a vital supply chain component to be this easily abused. One of the highlights is when someone recently used NPM to spread ransomware via a fake Roblox API package.[3] [1] https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295b1dcc70f7678434ef21d8b6aad5ec00beb8a72cf/detection https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295... [2] https://github.com/kevoreilly/CAPEv2 https://github.com/kevoreilly/CAPEv2 [3] https://www.reddit.com/r/programming/comments/qgz0em/fake_npm_roblox_api_package_installs_ransomware/ https://www.reddit.com/r/programming/comments/qgz0em/fake_np...

iancarroll 5y ago
It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.
- schleck8 5y ago
  I think Chocolatey has manual screens when there are more than 5 detections, but not entirely sure
- schemescape 5y ago
  Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.
  - thrashh 5y ago
    But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exploit is to not deploy the attack payload right away. Nothing you will think of will evade defeat.
    - schemescape 5y ago
      I agree that it is an unending arms race, but if NPM doesn't even plug obvious holes (like running install scripts by default), then they've lost my trust. Edit: if anyone knows of a way to disable NPM from running install scripts automatically (without having to remember to specify --ignore-scripts on each invocation), while still allowing me to use "npm run" to manually run scripts (e.g. test scripts for my own packages), I'd love to hear about it.
      - Ginden 5y ago
        npm ci --ignore-scripts
        schemescape 5y ago
        Ah, sorry, I meant a way to automatically do that (both so I don't have to type as much and so that I can't accidentally forget to add that argument). Edited my comment to reflect this.
        jffry 5y ago
        You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list
        schemescape 5y ago
        That breaks “npm run” (violating the second part of my request).
- peteatphylum 5y ago
  We're building a solution to solve exactly this at phylum. I'm not trying to be a sales shill, but if anyone is interested in discussing ideas on how to best defend open-source libraries from these types of attacks, please get in touch, I'd love to hear from you! We're consuming everything we can about a package to figure this out. We've built a static analysis system to reason about code (it's not perfect, but we're getting better and better). We process all the data we can get, then build analytics, heuristics and ML models to extract evidence. The evidence is then pieced together to identify software supply chain risk. In this case there is a lot of signal to show both bad and suspicious things are happening. 1. Obfuscation: this creates a comparatively deep AST of the code, and isn't difficult to identify. 2. Command execution: curl, wget, LOLBINs like certutil are pretty easy to identify. This isn't a slam dunk every time you see it, but it adds evidence to a potentially malicious claim. 3. URLs: These are uncommon in libraries and add evidence. 4. Pre/Post install scripts: These are fairly commonly used for other things as well, but invoking node on a source file that is likely obfuscated is a good sign something suspicious is happening. We're trying to build everything fast enough to make the target far less attractive for attackers before it gets a lot worse.
- perth 5y ago
  Chocolatey requires scans on _most_ uploads to the service. Under a certain threshold it only gives you a warning that says "this package had x detections". Here's FAR manager which for some reason has some hits on virustotal https://community.chocolatey.org/packages/Far https://community.chocolatey.org/packages/Far
megumax 5y ago
I think that volunteers (some of them maybe paid) should check the validity of code, at least for projects over 10-100k downloads. In case of crates.io (Rust), there is cargo-crev[1]. Also, npm should popularize 2FA. [1]https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/
- m4rtink 5y ago
  Say, like package maintainers do for major Linux distributions ?
woodruffw 5y ago
> Note how the referenced Virustotal result has 40+ detections. I'm still wondering why info like this isn't used by Pypi and NPM. I was contracted to help build a malware analysis pipeline for PyPI[1][2]. We don't currently have a VirusTotal detector/analyzer (IIRC, we couldn't get a high-enough volume API token on short order), but I think any work towards that would be greatly appreciated by both the PyPA members and the Python packaging community! [1]: https://pyfound.blogspot.com/2018/12/upcoming-pypi-improvements-for-2019.html https://pyfound.blogspot.com/2018/12/upcoming-pypi-improveme... [2]: https://github.com/pypa/warehouse/tree/main/warehouse/malware/checks https://github.com/pypa/warehouse/tree/main/warehouse/malwar...

iancarroll 5y ago

It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.

schleck8 5y ago
I think Chocolatey has manual screens when there are more than 5 detections, but not entirely sure
schemescape 5y ago
Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.
- thrashh 5y ago
  But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exploit is to not deploy the attack payload right away. Nothing you will think of will evade defeat.
  - schemescape 5y ago
    I agree that it is an unending arms race, but if NPM doesn't even plug obvious holes (like running install scripts by default), then they've lost my trust. Edit: if anyone knows of a way to disable NPM from running install scripts automatically (without having to remember to specify --ignore-scripts on each invocation), while still allowing me to use "npm run" to manually run scripts (e.g. test scripts for my own packages), I'd love to hear about it.
    - Ginden 5y ago
      npm ci --ignore-scripts
      - schemescape 5y ago
        Ah, sorry, I meant a way to automatically do that (both so I don't have to type as much and so that I can't accidentally forget to add that argument). Edited my comment to reflect this.
        jffry 5y ago
        You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list
        schemescape 5y ago
        That breaks “npm run” (violating the second part of my request).
peteatphylum 5y ago
We're building a solution to solve exactly this at phylum. I'm not trying to be a sales shill, but if anyone is interested in discussing ideas on how to best defend open-source libraries from these types of attacks, please get in touch, I'd love to hear from you! We're consuming everything we can about a package to figure this out. We've built a static analysis system to reason about code (it's not perfect, but we're getting better and better). We process all the data we can get, then build analytics, heuristics and ML models to extract evidence. The evidence is then pieced together to identify software supply chain risk. In this case there is a lot of signal to show both bad and suspicious things are happening. 1. Obfuscation: this creates a comparatively deep AST of the code, and isn't difficult to identify. 2. Command execution: curl, wget, LOLBINs like certutil are pretty easy to identify. This isn't a slam dunk every time you see it, but it adds evidence to a potentially malicious claim. 3. URLs: These are uncommon in libraries and add evidence. 4. Pre/Post install scripts: These are fairly commonly used for other things as well, but invoking node on a source file that is likely obfuscated is a good sign something suspicious is happening. We're trying to build everything fast enough to make the target far less attractive for attackers before it gets a lot worse.
perth 5y ago
Chocolatey requires scans on _most_ uploads to the service. Under a certain threshold it only gives you a warning that says "this package had x detections". Here's FAR manager which for some reason has some hits on virustotal https://community.chocolatey.org/packages/Far https://community.chocolatey.org/packages/Far

megumax 5y ago

I think that volunteers (some of them maybe paid) should check the validity of code, at least for projects over 10-100k downloads. In case of crates.io (Rust), there is cargo-crev[1]. Also, npm should popularize 2FA. [1]https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/

m4rtink 5y ago
Say, like package maintainers do for major Linux distributions ?

woodruffw 5y ago

> Note how the referenced Virustotal result has 40+ detections. I'm still wondering why info like this isn't used by Pypi and NPM. I was contracted to help build a malware analysis pipeline for PyPI[1][2]. We don't currently have a VirusTotal detector/analyzer (IIRC, we couldn't get a high-enough volume API token on short order), but I think any work towards that would be greatly appreciated by both the PyPA members and the Python packaging community! [1]: https://pyfound.blogspot.com/2018/12/upcoming-pypi-improvements-for-2019.html https://pyfound.blogspot.com/2018/12/upcoming-pypi-improveme... [2]: https://github.com/pypa/warehouse/tree/main/warehouse/malware/checks https://github.com/pypa/warehouse/tree/main/warehouse/malwar...