Three Packages Targeting Linux with Crypto Miners Found in Python's 'PyPi' Repository (thehackernews.com) 17
An anonymous reader shared this report from The Hacker News:
Three new malicious packages have been discovered in the Python Package Index (PyPI) open-source repository with capabilities to deploy a cryptocurrency miner on affected Linux devices.
The three harmful packages, named modularseven, driftme, and catme, attracted a total of 431 downloads over the past month before they were taken down...
The malicious code resides in the __init__.py file, which decodes and retrieves the first stage from a remote server, a shell script ("unmi.sh") that fetches a configuration file for the mining activity as well as the CoinMiner file hosted on GitLab. The ELF binary file is then executed in the background using the nohup command, thus ensuring that the process continues to run even after exiting the session. "Echoing the approach of the earlier 'culturestreak' package, these packages conceal their payload, effectively reducing the detectability of their malicious code by hosting it on a remote URL," said Fortinet FortiGuard Labs researcher Gabby Xiong. "The payload is then incrementally released in various stages to execute its malicious activities."
The three harmful packages, named modularseven, driftme, and catme, attracted a total of 431 downloads over the past month before they were taken down...
The malicious code resides in the __init__.py file, which decodes and retrieves the first stage from a remote server, a shell script ("unmi.sh") that fetches a configuration file for the mining activity as well as the CoinMiner file hosted on GitLab. The ELF binary file is then executed in the background using the nohup command, thus ensuring that the process continues to run even after exiting the session. "Echoing the approach of the earlier 'culturestreak' package, these packages conceal their payload, effectively reducing the detectability of their malicious code by hosting it on a remote URL," said Fortinet FortiGuard Labs researcher Gabby Xiong. "The payload is then incrementally released in various stages to execute its malicious activities."
Many eyes (Score:1)
Fails again.
Re:Many eyes (Score:2)
One reason why I never use these (Score:4, Interesting)
This is one reason why I never use CPAN, PyPI, Go-anything. Many application authors want to deploy their applications using these tools, or to deploy the application without the supporting libraries and insist you go to these tools to get them. This happens sometimes even when applications are put into distribution packages, that the authors want to deploy updates or bug fixes using these language-specific repositories instead of releasing update packages.
The issue is, that the maintainer of these repositories aren't (and shouldn't be asked to be) security experts. But as reliance on them increases, so does their attractiveness as a vector to exploit both technical and behavioral vulnerabilities. Get something sketchy in there, and then expend your effort to move it from the outskirts of dependencies in to more and more mainstream use.
From the beginnings I have never liked these systems much as they have never played well with system packages, This is just another reason why to avoid them and insist that application developers deploy their fare in traditional ways.
Re:One reason why I never use these (Score:2)
Can one even use Python offline?
Re:One reason why I never use these (Score:2)
Can one even use Python offline?
More than javascript
Re:One reason why I never use these (Score:2)
Yes, but it does depend on what you want to do. If you want net access in your code, you need to be online. Otherwise not. That's part of what Python means by "batteries included". Clearly, though, there are libraries that are NOT included. This is no guarantee that they can't be trusted, but ... well, fewer people have vetted them.
Re:One reason why I never use these (Score:0)
Yes. Debian and Red Hat build a stack of packages containing individual python modules, compiled and GPG tagged and possible to mirror for internal use from their deployment mirrors. This provides far more provenance for a software collection than simply running "pip install" with little effort to verify the individual modules. The problem is exacerbated when one module requires more modules which each bring their own stack of dependencies.
I dare you: run "pip install ansible airflow" to see just how bad the stack gets.
Re:One reason why I never use these (Score:3)
Most software developers are not security experts either. Even if they bundle the library, they are unlikely to have checked it for malware first.
Re:One reason why I never use these (Score:4, Insightful)
No, but in that case, a) the developer has at least used all the libs they are referencing, and b) the end user is not vulnerable to the whims of dependency changes made by third parties. When it's just something on PyPI or CPAN, the chain of dependencies can shift and change in ways the original author doesn't even know about long after release. And once the bad-actor module is in PyPI or CPAN, you can bet its authors and supporters are going to be working behind the scenes to be getting it linked in to the chain.
Re:One reason why I never use these (Score:3)
No, but in that case, a) the developer has at least used all the libs they are referencing, and b) the end user is not vulnerable to the whims of dependency changes made by third parties. When it's just something on PyPI or CPAN, the chain of dependencies can shift and change in ways the original author doesn't even know about long after release. And once the bad-actor module is in PyPI or CPAN, you can bet its authors and supporters are going to be working behind the scenes to be getting it linked in to the chain.
With Python a requirements.txt file that has pinned versions at least has the outdated libraries that were built with the exact version that the developer used.
This is trading one set of problems for another set of problems.
A bigger problem that impacts more people is that pinned dependencies mean that the code statistically, is almost certainly going to depend on a library with a known vulnerability that has been patched, and if you don't have a method for rebuilding the app with current dependencies you'll wind up trying to find out where you have copies of the vulnerable library and how you are going to update it and retest the application and which other dependencies you are going to have to update and how you are going to have to modify the code to work with the newer non-vulnerable libraries.
The most basic of test suites in an environment with basic anomaly detection would prevent this code from making out of the QA process (which if you have millions of people running your crypto miner during their QA job that is flagged, could still be profitable if short runs of the miner are useful)
Most simple solutions fail when dealing with the reality of modern software development. I've been responsible for dozens of software projects that had over a thousand dependencies. There are solutions, but none of them are magical.
Re:One reason why I never use these (Score:4, Interesting)
"Many application authors want to deploy their applications using these tools, or to deploy the application without the supporting libraries and insist you go to these tools to get them."
Yup, they're too lazy to make a fucking binary executable.
The sad state of our software world. Download this in order to download this, then redownload it all over again because what you just downloaded was out of date, oh and this dependency over here is out of date too so let's just update that and....
Hang everyone who thought that was a good idea.
Was bound to happen (Score:4, Interesting)
PyPi is one of most of whatever goes.
I'm surprised it isn't completely full of malware.
Just the amount of times I've been suggested try pip install this or that and I've installed some completely different thing is countless.
Re:Was bound to happen (Score:3)
This is much more profitable than trying to just ship malware.
Re:Was bound to happen (Score:1)
PyPi! (Score:2)
So, why did people get it? (Score:2)
Anyone looking at this would immediately be suspicious based on the description. Downloading and executing a coin miner program? Hum. I'm not sure that's what it's supposed to do...kind of thing at least. Or maybe people just downloaded it and didn't run it. Oh who am I kidding I know some did.
re: (Score:-1)