PyPI came under attack from bots at the weekend. Bad actors were trying to submit malicious packages with names similar to established dependencies.
It’s yet another scary illustration of the fragility inherent in our software supply chains. In this week’s Secure Software Blogwatch, we look deeper.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: For Doom fans.
[ Related repo news: RATs found hiding in the npm attic ]
Python team needs a rest
What’s the craic? Careful with that Ax Sharma — “PyPI temporarily pauses new users, projects amid high volume of malware”:
“PyPI is no stranger to being abused”
PyPI, the official third-party registry of open source Python packages has temporarily suspended new users from signing up, and new projects from being uploaded to the platform [after] a large influx of malicious users and packages: … "While we re-group over the weekend, new user and new project registration is temporarily suspended," … states an incident notice.
Like other open source registries, PyPI is no stranger to being abused by adversaries looking to distribute malware. [This] move by PyPI admins is unlikely to impact existing maintainers of Python packages available on the registry from publishing newer versions of their artifacts.
When will it end? Ross Kelly has more on what he calls a “PyPI attack”:
“Attack was automated”
Targeting of the … PyPI repository is likely to continue, given its popularity and potential to cause massive disruption. PyPI has been targeted numerous times in the past year and has been described as a “highly lucrative target” for cyber criminals.
The outage lasted for nearly 29 hours and appears to have been exacerbated by the fact that some admins were on leave for the weekend. … While exact details on the incident or the threat actors involved are yet to be disclosed, there are indications that the attack was automated.
Time to panic? Nate Nelson naysays — “Incident Was Overblown”:
“New tools to track dependencies”
Ee Durbin, director of infrastructure for the Python Software Foundation, [says] the actual circumstances of the shutdown were much less dramatic than they were made out to be: "This weekend was just a matter of human capacity. … Effectively, there was just one PyPI admin available to handle reports out of the usual three, and [we] needed a weekend."
At least some portion of the hubbub around [the] shutdown can be explained by growing fears around the state of open source security. … Malicious packages run so rampant today that some hackers hardly feel the need to hide them anymore.
Organizations that utilize open source software — read: all organizations — have a far more difficult time defending against even such low-level attackers, prompting calls for better package inspection, the development of new tools to track dependencies, and software bills of materials (SBOMs). … Supply chain security in years to come will turn on our ability to keep public repos clean and protect ourselves when they're not.
ELI5? Thomas Claburn explains like we’re five — “Project temporarily freezes new user accounts”:
Essentially, you really don't want malicious users to get their malware and fake libraries into popular registries: … That would lead to unsuspecting developers poisoning their apps and users with bad dependencies.
Someone has to filter out the nasty code from the good stuff. [But] maintainer burnout is a long-standing problem in the open source community, one generally dealt with by recognizing that more resources – in terms of people and often funding – need to be directed at affected projects.
Still too wordy? efitz cuts to the chase:
People suck and that is why we cannot have nice things.
How did we get here? Get off Antique Geekmeister’s lawn:
Having a broad variety of open source tools, some of which are the reference tool, is useful. [But] there are problems: Ridiculous chains of unreliable and unpredictably incompatible dependencies are one of the risks we've seen with all of these packaging systems.
Still, pretty lousy “service” from PyPi, amirite? ChoHag begs to differ:
It's called the weekend for a reason. Let the people who are paying for that 24 hour tech support complain. Give them their money back maybe.
Don’t feel smug if you don’t use Python. As imran-iq explains:
It's only a matter of time until it happens to other systems too. Take Rust for example, where folks can … cargo install <global name package>. Top that off with fact that during compile (as an attacker) you have full access to your victims computer.
Python just happens to have more popularity — for now.
You pesky kids with your new-fangled languages. Wrong again, says sg_oneill:
Despite what some of the hipsters might think, Python is an old language by tech standards (older than Java, all the .NET languages, JS, and so on. C++ is slightly older by a few years. I've been using Python since the late ’90s) but it wasn’t really discovered by the public until the last 4–5 years.
Unfortunately it’s brought over with it a lot of the bad actors and idiots that beset PHP and JS. That’s unfortunate because one of Python’s defining advantages was that it had an old and very carefully developed ecosystem of stuff that worked, was conservatively designed and relatively easy to use, and I do worry not all the new converts get that. We traditionally don’t re-invent wheels, we make older wheels rounder.
Dependency resolution … is largely a solved problem, its a tree. Its also hard for humans, because you have to ensure you are managing all the dependencies of the libraries you use,. and all of their dependencies, and so on. … You have an exponential trap of vunerability here.
Meanwhile, VoiceOfTruth reminds us why we even know about this:
I tip my hat to the dedicated people in the open source world who maintain this stuff. They are often nameless (until the **** hits the fan).
*Viewer discretion advised.
Hat tip: Invisible Wizard
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or firstname.lastname@example.org. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Get up to speed on key trends and understand the landscape with The State of Software Supply Chain Security 2024. Plus: Learn about ReversingLabs Spectra Assure for software supply chain security.
- Update your understanding: Buyer's Guide for Software Supply Chain Security
- Join the Webinar: Why you need to upgrade your AppSec for the new era
- Get the report and take action: The State of Supply Chain Security 2024
- See the Webinar: State of Software Supply Chain Security 2024
- See Gartner's guidance on managing software supply chain risk