Recent malware installed in PyPI underscores the need for code verification at the code repository level to defend the software supply chain.
Known as PyPI or “Cheese Shop”, the Python Package Index has been the target of misuse on several occasions. Most recently it fell victim to typosquatting, an intrusion method that replaces a known component with a compromised one with similar spelling. (In this case, libpeshnx versus libpeshka.)
Close, But No Cigar
Typosquatting means that introducing risk can be as simple as two transposed letters in a file name. Poor project hygiene allows this kind of intrusion to go undetected. While the risk was reported earlier, these misspelled and malicious components were still available for download on the component’s website.
“This [risk] is notable because it involves malicious code thought to have been previously fixed,” writes Curtis Franklin, Jr., at DarkReading.
Package repository managers, such as PyPI, RubyGems, and npm, sit between open source packages available for download and in-house development teams. Malicious actors circumvented the package repository manager by inserting code into the (previously approved) component.
This vector is a classic case for why understanding open source code dependencies is critical. It’s not enough to know top level package names and associate those with known vulnerabilities. The Cheese Shop hacks prove that what those top level packages contain, and their access to other components down the software supply chain, are where the complications lie in keeping code safe. Users were unaware of the compromised parts. This gave bad actors the potential for lateral access or rights to other components.
Who Moved My Cheese?
As deployed the Cheese Shop intrusion “involv[ed] a call to a command-and-control server followed by a wait to be activated,” writes Franklin. Could this hack have been stopped or headed off at the pass? Perhaps. This would mean understanding the components as deployed at a much more granular level and having data precise enough to implicate the new, malicious code.
In other words, a name-based-match-one-size-fits-all approach would not have worked. Identification is only part of the equation, however. Blocking the individual implicated components before they could be downloaded to a local repository is the only way to ensure they weren’t (or still aren’t) being leveraged for something more nefarious downstream.
For example, Sonatype’s Nexus Firewall stops open source risk at the front door by enabling a continuous audit of components prior to entering your supply chain. Nexus Repository Manager, a universal repository manager for binaries and build artifacts, allows the ability to cache these public components or packages locally. This provides developers easy access to components and peace of mind when building applications, knowing they are only sourcing secure open source components. Security professionals need to be aware of how developer centric tools can impact downstream vulnerabilities. These are critical pieces of the entire software supply chain.
How to Protect Your Software Supply Chain
The PyPI package libpeshnx is inherently malicious so we recommend removing it completely. Since it may have intended to impersonate a legitimate package, reconfirm that dependencies are spelled correctly before attempting to download the legitimate package. Any hosts that downloaded this package should be considered compromised and remediated as appropriate.
Sonatype Nexus customers were notified of the Cheese Shop compromise within hours of the discovery. Their development teams automatically received instructions on how to remediate the risk and specifically which dependent components were implicated.
If you are not a Sonatype customer, we recommend that you take the remediation guidance seriously. Take rigorous care to understand what’s declared in your code base, and also how that code base operates as deployed. Understand your dependencies and how those dependencies impact your software supply chain downstream.
Adversaries Increasingly Infecting Open Source Components
The PyPI compromise at the component level is no longer unique. Our 2019 State of the Software Supply Chain Report, highlights a shifting battlefront that we've been monitoring for the past two years. At the time of the report, we had monitored a series of 16 events that triangulate a serious escalation of software supply chain attacks. Adversaries are taking advantage of a new attack vector where they are directly injecting vulnerabilities into open source project releases and container images
Since the report was published, less than a month ago, we've seen 2 more such attacks, showing an incredible escalation.
Read the full report and learn more about how malware, and supply chain attacks, like this recent attack on PyPI, is a risk vector.
