PyPI Goes Quiet After Huge Malware Attack: 500+ Typosquat Fakes Found – Source: securityboulevard.com

More software supply-chain security shenanigans: PyPI came under attack earlier, with more than 500 fake packages with similar names to popular ones. Scrotes unknown have been trying to steal cryptocurrency credentials and other secrets.

Yes, it’s happened yet again. In today’s SB Blogwatch, we ask if it’s time for a code-reuse rethink.

Your humble blogwatcher curated these bloggy bits for your enter­tainment. Not to mention: Midjourney hijinks.

“Malicious code”

The Python Package Index (PyPI) … is an index for Python projects that helps developers find and install Python packages. With thousands of packages available, the repository is an attractive target for threat actors, who often upload typosquatted or fake packages to compromise software developers and potential supply-chain attacks.

…

Such activity has forced PyPI administrators earlier today to announce that all new user registrations have been suspended to allow mitigating [hundreds of] packages with names that mimic legitimate projects. The packages include malicious code … that executes upon installation, attempting to retrieve an additional payload from a remote server. To evade detection, the malicious code is encrypted … and the remote resource’s URL is dynamically constructed when needed. The final payload is an info-stealer with persistence capabilities.

“Poisoned package”

PyPI said it had restored services … after blocking new project creation and new user registration for about 10 hours. … Like many malware campaigns involving software repositories, the … incident involved attempts to trick users into downloading code packages that seem legitimate but are secretly malicious.

…

The malware appears to be persistent: … When a developer begins to work with a poisoned package, the malware quietly executes and can survive a system reboot. The attackers targeted developers working with popular elements like Pillow, which helps software handle images, and Colorama, used for text coloring.

“Not an isolated case”

Between March 27 and March 28, 2024, multiple malicious Python packages were uploaded on the Python Package Index (PyPI). These packages most likely created using automation. … The malicious code is located within each package’s setup.py file. … This incident is not an isolated case, and similar attacks targeting package repositories and software supply chains are likely to continue.

…

IOCs:

hxxps://funcaptcha[.]ru/paste2

hxxps://funcaptcha[.]ru/delivery

hxxps://funcaptcha[.]ru/atomic/app.asar

ABE19B0964DAF24CD82C6DB59212FD7A61C4C8335DD4A32B8E55C7C05C17220D

0C1DDD33E630F4AC684880F0E673DFA84919272494C11DA0F1EC05FB4F919CE8

So far, we’ve seen over 500 typosquat variations published, targeting  … requests, py-cord, colorama, capmonstercloudclient, pillow, bip-utils, TensorFlow, BeautifulSoup, PyGame, simplejson, matplotlib, pytorch … customtkinter … selenium, playwright, asyncio [and] requirements. … PyPI has done a great job of promptly removing these packages.

…

A few hours before the automated attack started we can see the attacker experimenting with a package called schubismomv3. 11 packages and about 2.5 hours later, we can see the attacker testing a variety of malware deployment techniques. … About 1.5 hours after the last publication of schubismomv3, we see the publication of insanepackagev1414. … Finally, at around 15:06 UTC … we see the start of the typosquatting attack. … Then, strangely, the next day at 07:56, the attacker published … johnhammondfanpackage124 and … johnhammondontop183 five hours later. After the bizarre interlude, the attack picked up again.

…

[The] payload … appears to be a pretty standard stealer, attempting to grab cookies, passwords, wallets, etc. At the very end it attempts to grab another payload: … A .NET binary: … zgRAT.

I think people should stop using PyPI altogether. It’s full of abandoned garbage and malware because there’s really no filter on who can upload what.

…

If Linux distro packaging worked the same way, Linux would be a hellscape of malware and weird random broken apps. I’d rather use old software than constantly worry about fat fingering a package name and ending up with a crypto miner on a thousand machines.

But—who’s going to do the curation? This becomes even more dire when people can use the AI plague to generate garbage floods at-scale. No humans can ever keep up with that. And then as soon as the guard is down, purpose-made malicious packages can be inserted. It’s the package repo version of the MFA-fatigue attacks.

Isn’t it the same principle at play here that virtually every programming language’s package managers are vulnerable to? npm, cargo, etc have all had similar situations and threat actors seem to have become very supply chain focused. … Feels like the entire package manager concept needs to be redesigned/reevaluated for modern development.

Python, eh? I get that it’s a nice language for teaching. [But] it seems unsuited to programming.

…

Lots of people who need to write code but aren’t really programmers day-to-day seem to rely on it to access useful library code. … In fact I would go as far as to say that their “coding” amounts to gathering together third party libraries … and providing boilerplate glue. This seems dangerous: … If you are working with code then you ought to be able to understand it.

Am I the only one who is scared by the entire ecosystem of “drag random **** and dependencies off the internet from who the hell knows”? I’ve had a couple of minor incidents with NodeJS dependencies over the last few years on this front which sort of opened my eyes to running untrusted code.

And the payload URL goes to a .ru domain—what a surprise!

Recent Articles By Author