Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

Malware in PyPI Code Shows Supply Chain Risks

A code backdoor in a package on the Python Package Index demonstrates the importance of verifying code brought in from code repositories.

The pace of modern software development requires code reuse, and effective code reuse requires code repositories. These collections of code fragments, functions, libraries, and modules allow developers to write applications without having to reinvent every small (or large) detail in their code. That makes repositories very valuable to developers – and very rich targets for malicious actors.

Researchers at ReversingLabs have discovered the most recent attack against a repository: a module that carries a backdoor found in popular Python repository Python Package Index (also known as PyPI or Cheese Shop). This isn't the first time PyPI has been attacked, but this one is notable because it involves malicious code thought to have been previously fixed.

"Essentially, a backdoor that has been reported before but hasn't been cleaned completely from the repository was still available and live on the Web page," says Robert Perica, principal engineer at ReversingLabs. And while the package involved is not ubiquitous, it is being used. "What's troubling about this package is that even though it's not a popular package, it averages 82 installs per month," Perica says.

The malware resides in a module named "libpeshnx," which is similar to an earlier module named "libpeshna" and was contributed by the same author. According to ReversingLabs' blog post on the discovery, the actual backdoor mechanism is very simple, involving a call to a command-and-control server followed by a wait to be activated.

A Supply Chain Attack
Recent years have seen an increase in the number of attacks launched against companies' supply chains. Most of these involve physical supply chains, but Perica says security professionals need to understand these code repositories – from PyPI to RubyGems, NuGet, and npm – are critical pieces of their software supply chain. That understanding should lead to strong security procedures around code drawn from the repositories.

"Many of these software repositories don't have such a thorough review process during user submissions," Perica says. "Essentially, any user can more or less submit anything."

He contrasts this with open source projects hosted on GitHub, where there is typically a review and approval process for new code added to the official release. Still, PyPI is trusted within the Python developer community. "PyPI is like the official package repository for the Python Software Foundation," Perica notes.

He points out that PyPI hosts more than 188,000 projects, with almost 1.4 million releases and roughly 350,000 users. PyPI is almost certain to be the repository used by beginning developers, Perica adds, whether they're working on individual projects or software for an employer.

Worst-Case Scenario
Writing secure code is complicated by the fact that modules tend to contain other modules. The "dependencies," or network of functions and modules brought together for a single library, can be many layers deep. Perica says the best solution for companies looking to minimize the risk from code repositories is to have a security team look at each library to be used and verify the contents.

It takes a lot of effort, he says, but that effort can still be dramatically less than that required to recover from a major software vulnerability that has been exploited.

Related Content:

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

 

 

 

 

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4147
PUBLISHED: 2019-09-16
IBM Sterling File Gateway 2.2.0.0 through 6.0.1.0 is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 158413.
CVE-2019-5481
PUBLISHED: 2019-09-16
Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3.
CVE-2019-5482
PUBLISHED: 2019-09-16
Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.
CVE-2019-15741
PUBLISHED: 2019-09-16
An issue was discovered in GitLab Omnibus 7.4 through 12.2.1. An unsafe interaction with logrotate could result in a privilege escalation
CVE-2019-16370
PUBLISHED: 2019-09-16
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.