The article doesn't explain what exactly the "W4SP Stealer" does. Would someone be able to explain?
The source is actually hosted on GitHub, and there is a good readme explaining all that :)
Dozens of malicious PyPI packages discovered targeting developers
131–140 of 334 posts
Re: Dozens of malicious PyPI packages discovered targeting developers
#132Re: Dozens of malicious PyPI packages discovered targeting developers
#133So malicious packages for JS, now python, but still no W4SP stealers for libc :(
Feeling a bit left out, guys! How will my code get compromised randomly?
Re: Dozens of malicious PyPI packages discovered targeting developers
#134can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .
I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address.
I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to trust your colleagues or specific people rather than the package authors. This seems like a much more viable solution to scale trust.
[1]: https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet
Re: Dozens of malicious PyPI packages discovered targeting developers
#135Earlier quoted context omitted.
Full disclosure, I am a co-founder at Phylum. We are actively working on a solution that will fully sandbox package installations for npm, yarn, poetry and others. It's rolled up as part of our core CLI [1], but is totally open source [2]: [1] https://github.com/phylum-dev/cli [2] https://github.com/phylum-dev/birdcage
Sounds awesome. Though I’m not sure of the solution really is / should be increased sandboxing. The alternative may be a rethinking of the increasingly smaller packages. Maybe it’s better to have few large packages maintained by reputable organisations or personalities?
The problem is large, sprawling and complex. In an ideal case, we'd have high quality packages maintained by reputable people/organizations. But today this just isn't true. Open source takes contributions from a large number of unknown authors/contributors with motivations that may or might night align with your own.
We really need a defense in depth approach here. Sandbox where it makes sense, perform analysis of code being published, consider author reputation, etc.
Re: Dozens of malicious PyPI packages discovered targeting developers
#136Earlier quoted context omitted.
This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be…
It might be too cumbersome for most, and I might be more paranoid than average, but each project for me means a fresh VM, a new Keepass database and dedicated accounts. Then again I work mostly in ops, and I've seen first hand how badly things can go wrong so isolation and limiting blast radius takes precedence over daily convenience for me.
That does sound incredibly cumbersome. I suppose that means you are an ace at provisioning machines.
How do you move data in/out of the guests? I always found that part of interacting with VMs to be annoyingly painful.
Re: Dozens of malicious PyPI packages discovered targeting developers
#137I wonder why we can’t have pip packages be published by username or organization, like
pip install google/tensorflow
Re: Dozens of malicious PyPI packages discovered targeting developers
#138It makes me very sad that something as wonderful as code, the closest we have to actual magic is tainted by this. You know how to code and you chose to spend your time doing this? What a shame
Re: Dozens of malicious PyPI packages discovered targeting developers
#139can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .
I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address. I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to t…
We've found a lot of open-source packages that are authored by (well, released by authors identified by) disposable email addresses. We were shocked to find companies doing this, too.
Package Dependency land is a crazy place
Re: Dozens of malicious PyPI packages discovered targeting developers
#140In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.
Plug: I've been building Packj [1] to address exactly this problem. It offers “audit” as well as “sandboxing” of PyPI/NPM/Rubygems packages and flags hidden malware or "risky” code behavior such as spawning of shell, use of SSH keys, and mismatch of GitHub code vs packaged code (provenance). 1. https://github.com/ossillate-inc/packj
There is also this, although I haven't tested it yet. The approach is interesting though. https://github.com/avilum/secimport