Python Package Index was found to contain AWS Credentials and Malware

PyPI, which is intended to be a repository of Python libraries that developers can incorporate into their projects to save time, has been discovered hosting packages containing active Amazon Web Services (AWS) keys and data-stealing malware.

Unfortunately, malicious packages are nothing new for PyPI or other packaging systems such as npm, RubyGems, and crates.io. Supply chain attacks – via compromising software libraries or typosquatting – have been an issue for years, albeit one that has recently received more attention due to incidents such as the compromise of SolarWinds.

Despite increased vigilance, these incidents continue to occur at an alarming rate. The maintainers of the machine learning framework PyTorch issued a warning just before the New Year that PyTorch-nightly if installed on Linux via pip, included a compromised dependency called torch triton that was available via PyPI.

Less than a week later, the security firm Phylum reported that in December it had discovered a remote access trojan named pyro-login in a PyPI package. ReversingLabs, another security firm, also discovered a malicious PyPI package that month: Malware masqueraded as an SDK from the security company SentinelOne. And in November, it was discovered that dozens of newly published PyPI packages contained W4SP malware.

In March of 2021, 3,653 malicious code blocks were removed from PyPI as a result of a massive malware cull. However, the weeds have returned, not to mention the security issues identified through automated analysis in nearly half of the PyPI libraries a few months later.

Other than subverted libraries and mediocre code, what has the PyPI ever given us? Recently, it has been offering access keys to the AWS computing resources and data utilized by Amazon, Intel, various US universities, the Australian government, US energy company Fusion Atomics, and Top Glove, the largest glove manufacturer in Malaysia, among others.

Brits find keys again

 a software developer from the United Kingdom, published a blog post on Friday detailing how he discovered 57 active API access keys for AWS services from the aforementioned organizations.

developed a Rust tool to automatically scan all new PyPI packages for the presence of AWS API keys. And, well, it works.

that his scanner searches for AWS keys in new releases from PyPI, HexPM, and RubyGems using GitHub Actions. If any are discovered, a report with the pertinent details is generated and added to the aws-cred-scanner repository.

“This report contains the discovered keys, as well as a public link to the keys and other metadata about the release.” Because these keys have been uploaded to a public GitHub repository, Github’s Secret Scanning service notifies AWS that the keys have been compromised.

As a result, AWS opens a support ticket to notify the offending developer and implements a quarantine policy to prevent the key from being misused.

A less scrupulous individual could create a similar scanning script for exploitation and abuse. And it would be surprising if this is not already occurring.

the exact permissions granted to the key itself. “The InfoSys-leaked key had ‘full admin access,’ which means it can do anything, and other keys I discovered in PyPI were ‘root keys,’ which are also permitted to do anything. An attacker in possession of these keys would have complete access to the associated AWS account.”

He stated that other keys may have more restricted but still excessive permissions. For instance, he stated that it is common for a key intended to grant access to a single AWS S3 storage bucket to instead grant access to all S3 buckets associated with an account.

You’re in an impossible situation.

GitHub’s automated key scanning, which includes npm package keys, is an example of an effective defensive measure. However, he stated that the company’s strategy has limitations.

“GitHub cares a great deal about supply chain security, but they’ve dug themselves a hole: the method they use to scan for secrets involves a great deal of collaboration with vendors, who may divulge confidential information about how keys are constructed to GitHub,” he explained.

“This implies that the regular expressions that GitHub employs to scan for secrets cannot be publicly disclosed and are sensitive,” which precludes third parties like PyPI from using this wonderful infrastructure without sending every line of code uploaded on PyPI to GitHub.

this is unfortunate because, although PyPI could do more to improve supply chain security, it is a difficult task to perform effectively.

“GitHub has an entire team working on this, whereas PyPI lacks the necessary resources,” he explained. “I believe there are improvements that could be made to the Python ecosystem to prevent keys (and code) from being inadvertently bundled and published to PyPI, which could be a more efficient use of resources.”

A Python Foundation representative did not respond immediately to a request for comment. security is difficult to get right at the best of times.” “AWS is also to blame: IAM is notoriously difficult to debug and get right, which leads to keys being granted excessively broad permissions.”

“Policies may stipulate that “nothing on S3 should be public,” and when something is required to be public, it may be simpler to make the IAM credentials public than to attempt to negotiate an exception with the security policies. This is something I have previously heard of occurring.”

Read More: Critical IoT for Real-Time Data Revolution

Stay Connected!

Are You Looking For Python?