One of the most common attacks on the software supply chain is malicious code in open-source packages. A cyber threat actor inserts malicious code into publicly accessible code libraries, which unsuspecting developers then use to perform specific functions in their third-party code. This week, we talked to Ax Sharma, a Security Researcher at Sonatype, a software supply chain management company that helps businesses create secure, high-quality applications. Recently, Sonatype’s experts have discovered multiple malicious Python packages containing ransomware scripts, named after a well-known library. Here’s what happened, as well as Sonatype’s recommendations on how developers can identify, assess, and mitigate risks.

Could you tell us more about the PyPI malware? What was found, and what did it affect?

Sonatype found a total of three malicious packages in PyPI titled “requesys,” “requesrs,” and “requesr” – all typosquats of the legitimate, widely known library called 'requests.' These were uploaded by the author b8ff and contained ransomware scripts.

This means any developer who intends to install or include the 'requests' library in their package but inadvertently mistypes its spelling, could end up with one of these malicious packages and further, have their files encrypted. While incidences of malware infiltrating open-source repositories are hardly surprising, it’s not often we come across packages that drop ransomware.

Interestingly enough, if the program did run successfully, a popup message would appear on the user’s screen, further instructing them to contact the package author b8ff via Discord. No payment was required from end users to get their encrypted files back.

This incident could have easily escalated into a research experiment gone astray.

This malware attack is especially interesting, as the attacker didn't request a ransom, and did it “for fun.” Was it truly harmless?

b8ff told Sonatype researchers who made contact that the ransomware script is "completely open source" and part of a "project that I developed for fun." As they are a school-going "learning developer," this was meant to be a fun research project on ransomware exploits.

If Sonatype had not intervened, this incident could have easily escalated into a research experiment gone astray. Whatever their motivations, it’s clear the author hadn’t thought through the potential harm to fellow developers. Following our contact, the author renamed his malicious package to prevent devs from accidentally falling for the typosquat.

The ransomware script depended on a common typo. Is this a common method hackers use? Are there any other methods used to trick developers into downloading malware?

Yes, this is an extremely common tactic we often see hackers use because it relies on careless keyboard strokes – which happen quite regularly.

Another common attack we’ve seen recently is dependency confusion, which involves publishing malware using the same package name as private, internally created packages, but with a higher version number. Systems typically grab the “latest” version of a component, and because there is no proper namespacing requirement, the false plant is grabbed. While other software supply chain attacks, like typosquatting, require social engineering — a developer misspelling a word — this attack requires no interaction on the developer’s part.

Other methods commonly used by hackers that may be more familiar to non-coding audiences include sending malicious attachments or links by email or planting malicious software on victims’ devices via infected websites.

The two biggest takeaways from this incident that developers should be mindful of are: be cautious about what you type and what you incorporate into your software builds. Open source is both critical fuel for digital innovation and a ripe target for software supply chain attacks.

Be cautious about what you type and what you incorporate into your software builds.

Malicious code in open-source packages is one of the most common attacks on the software supply chain. This incident was just a “fun” experiment, but the next one might not be so harmless. How can software developers detect ransomware threats? What are some red flags that something is wrong with a package?

There are a number of things that can be done. First, ensure the integrity of your software releases, both from the point of view of the code you write and the code you borrow, through a balanced set of testing and verification. The easiest way to begin this process is to generate and maintain a Software Bill Of Materials (SBOM) to understand what actually is, and what should be, contained in a release.

Another aspect is ensuring the containers you run your software in are clean, protected, and hardened; And, that you are using tooling that alerts you when suspicious activity occurs.

The most important thing to do is have a balanced approach to managing all aspects of your supply chain. Modern software comprises a complex supply chain of internal code, open-source dependencies, APIs, and containers. Organizations must have an understanding of what their individual supply chain consists of. This is the only way to even begin to understand where the risks may lie.

What would you suggest students interested in infosec and hacking do instead of creating malware packages? How can they safely learn more and experiment without it going astray?

There are plenty of ways students can get cybersecurity experience without going down the route of experimenting with malware. You can complete a basic project for yourself or someone you know or offer up your technical knowledge in a volunteer setting. There was an amazing project called the URLHause back in 2019 that relied on volunteers within cybersecurity to seek out websites that distribute malware. More than 100,000 websites were identified and taken down.

Ethical hacking may be another avenue for developers.

Familiarity with malware is important, but above-board research projects using malicious code should include clear disclaimers for developers, which was not the case with b8ff’s components.

What has the Python Software Foundation done so far to identify and address security flaws? Could anything be done to make Python more secure, in your opinion?

We work closely with the hardworking volunteer maintainers of PyPI, swiftly reporting our findings on malware we find in their repository. PyPI admins then take these malicious packages down. In this case, after notifying PyPI on July 28, we also made contact with the author, b8ff, who renamed the packages themselves, to prevent further attacks.

The question of security should not just be posed to maintainers, like the PyPI team. It’s also down to developers to keep a critical eye on what they’re putting in their builds, and to make sure they’re using the latest, malware-free components.

Do you think open-source software is becoming less secure?

Open-source software is becoming a more popular attack surface which is why we’ve seen an increase in vulnerabilities there. In our State of the Software Supply Chain Report last year, we saw a 73% YoY growth in developer downloads of open-source components and that the majority of security research is focused on finding and fixing vulnerabilities in projects that are commonly utilized.

That said, recent major attacks (such as Log4j) have also prompted industry and government action to tackle these issues head on and start implementing plans of action. Sonatype’s work with the Open-Source Software Security Mobilization Plan is an example of this as we work to fix OSS software at the source and help open-source maintainers better manage their projects.

Thank you so much for taking the time to answer our questions!

If you would like to learn more about the incident, visit Sonatype’s blog. Following this interview, several other cases emerged, and you can read about one of them in our Over 200 Cryptomining Packages Discovered in PyPI and npm Registries blog.