Latest Attack on PyPI Users Shows Crooks Are Only Getting Better 21
More than 400 malicious packages were recently uploaded to PyPI (Python Package Index), the official code repository for the Python programming language, in the latest indication that the targeting of software developers using this form of attack isn't a passing fad. From a report: All 451 packages found recently by security firm Phylum contained almost identical malicious payloads and were uploaded in bursts that came in quick succession. Once installed, the packages create a malicious JavaScript extension that loads each time a browser is opened on the infected device, a trick that gives the malware persistence over reboots. The JavaScript monitors the infected developer's clipboard for any cryptocurrency addresses that may be copied to it. When an address is found, the malware replaces it with an address belonging to the attacker. The objective: intercept payments the developer intended to make to a different party.
Have a local repository (Score:5, Insightful)
Even for my student projects, I tried to maintain a local repository of development packages.
This not only helps avoid attacks, but also helps with version stability. If you do an npm/nuget/pypy update, often your build will break, due to new version of one of the tens of libraries not being compatible with your code.
This should become a standard practice. Don't play with random code, at least not inside a sandbox.
Why go to all the trouble? (Score:1)
If all they wanted was a set of magic bits, they should certainly be able to create a Python script to give them all the ones and zeros they could want.
Stop serving centralized repos (Score:2)
Golang got this right, use URIs that point to source code directly.
If a language wants to know more about what their community needs, implement a package proxy, which golang also did [golang.org].
Re: (Score:2)
That is wayyy worse because then attackers have a ton of URLs they can all try to hack.
Re: (Score:3)
That doesn't help against website hijacking attacks, as what happened with Shaeraza years ago. It also doesn't help against untrustworthy people still submitting seemingly acceptable URLs, before changing the content to be malicious.
Actually, it's an issue with the centralized repository being uncurated. As soon as there's moderation to spot anything suspicious, it gets stopped.
Re: (Score:1)
It also doesn't help against untrustworthy people still submitting seemingly acceptable URLs, before changing the content to be malicious.
This literally makes no sense. Where would they be submitting them to? If repos aren't centralized, this would require them to hack some cvs, insert some code for download, and modify the source code to point at this newly uploaded package. Seriously, your concern isn't making any sense.
I would argue that you didn't click the links I included. Golang uses a module proxy that transparently hashes packages, preventing the exact type of concern you are presenting.
Re: (Score:2)
The link you provided has some text at the bottom: "I have discovered a malicious module version in the mirror. Where do I report it?
Following the security policy, send an email to security@golang.org with the word "vulnerability" in the message somewhere."
A security statement like that indicates that malicious entries can still get into the proxy, and it did in the past [portswigger.net] simply by being a typo, or pretending to be an improved QoL version of an existing package. Whateve
Re: (Score:1)
I think these are straw arguments. The example given is type squatting on a typo. This is a human problem and exists whether you use distributed or centralized repos. Same with a malicious actor that inserts evil code in a transitive dependency later. Same with altruist owners that sell their code to a malicious actor that inserts evil code. Nothing here is solved or even made the slightest bit better by having centralized repos.
PyPi users (Score:2, Informative)
This is a disaster (Score:2)
Re: This is a disaster (Score:5, Informative)
This is not an unsolved problem. E.g. big banks are not worried about this because of the controls they have in place.
You will end up with a custom python repository containing only approved packages. To upgrade a package will trigger a security review of all of the associated code and the cost of this will be billed to the product owner. Every library will be built from source or otherwise have third-party binaries validated and warrantied by the maintainer. It is a gated community where malware has a difficult time getting in. It is also costly and too expensive for most companies. That may change as the price of risk goes up
Re: This is a disaster (Score:3)
Re: (Score:2)
Many ... (Score:4, Insightful)
Many eyes but also many monkeys and quite a lot of miscreants.
This is the next big problem OSS faces. There are way to many npm, gem, pip, nuget.... whatever package sources and way to many published packages for all the bad stuff to be detected and caught out.
Sure you can create proxies, curated repositories, use things things like sync to help mitigate some of these supply chain challenges but ultimately you are trusting others whom you have no real reason to trust or you are manually vetting a lot code. In the later case it destroys a lot of value, because lets face it when it comes to smaller utility things you can generally write and test them yourself as quickly as you could adequately review someones else's work in the context of not just looking for errors but them being deliberately malicious and willfully obfuscating what is 'wrong'.
That said in most contexts there are only so many ways to go about hiding something intentionally evil in code that does not result in code that is going to make anyone looking at it go 'why would you do it this way, don't think I am using this in my project even if it does work." ML could probably be deployed here to stop the 'hey the tucked code in here to download and run bitcoin miner' pretty effectively. On the other hand if a threat actor intentionally introduced something like CVE-2022-21449: Psychic Signatures in Java, I am not so sure that is going to be easy to spot for humans or machines without high effort.
Re: (Score:2)
The only real solution is being less open and less "inclusive". Developers need to have reputation and need to be known in some way by gatekeepers that also look at all stuff. Yes, that is not a good solution, but the alternatives are worse.
Re: (Score:2)
This seems like a good use case for simple AI like ChatGPT. It could be trained to recognize obfuscated code and highlight sections that seem to be obfuscated.
That would probably lead to a cat and mouse game, with malware developers eventually just writing very long code that was tedious for a human to read, but tools could also be created to detect that as well--maybe by guessing, since complete static analysis of runtime behavior is impossible. I'd certainly feel better about using packages from Github i