Software Downloaded 30,000 Times From PyPI Ransacked Developers' Machines (arstechnica.com) 26
Open source packages downloaded an estimated 30,000 times from the PyPI open source repository contained malicious code that surreptitiously stole credit card data and login credentials and injected malicious code on infected machines, researchers said on Thursday. Ars Technica reports: In a post, researchers Andrey Polkovnichenko, Omer Kaspi, and Shachar Menashe of devops software vendor JFrog said they recently found eight packages in PyPI that carried out a range of malicious activity. Based on searches on https://pepy.tech, a site that provides download stats for Python packages, the researchers estimate the malicious packages were downloaded about 30,000 times. [...] Different packages from Thursday's haul carried out different kinds of nefarious activities. Six of them had three payloads, one for harvesting authentication cookies for Discord accounts, a second for extracting any passwords or payment card data stored by browsers, and the third for gathering information about the infected PC, such as IP addresses, computer name, and user name. The remaining two packages had malware that tries to connect to an attacker-designated IP address on TCP port 9009, and to then execute whatever Python code is available from the socket. It's not now known what the IP address was or if there was malware hosted on it.
Like most novice Python malware, the packages used only a simple obfuscation such as from Base64 encoders. Karas told me that the first six packages had the ability to infect the developer computer but couldn't taint the code developers wrote with malware. "For both the pytagora and pytagora2 packages, which allows code execution on the machine they were installed, this would be possible." he said in a direct message. "After infecting the development machine, they would allow code execution and then a payload could be downloaded by the attacker that would modify the software projects under development. However, we don't have evidence that this was actually done."
Like most novice Python malware, the packages used only a simple obfuscation such as from Base64 encoders. Karas told me that the first six packages had the ability to infect the developer computer but couldn't taint the code developers wrote with malware. "For both the pytagora and pytagora2 packages, which allows code execution on the machine they were installed, this would be possible." he said in a direct message. "After infecting the development machine, they would allow code execution and then a payload could be downloaded by the attacker that would modify the software projects under development. However, we don't have evidence that this was actually done."
Who would be stupid enough... (Score:5, Funny)
... to blindly run python scripts they don't know or understand, especially with elevated privileges?
(other than when they install Linux)
Re:Who would be stupid enough... (Score:4, Interesting)
Re: Who would be stupid enough... (Score:3)
It's NOT about going through the code, but about everyone being "allowed to go through the code"
Jyst like transparency in democratic Govt functioning, or say a Police force, does not mean some of us can go and actually stop them from doing bad stuff.
But with a right to information type laws, the govt now has to be very careful as anyone "could " discover their wrong doing today or tomorrow or after 10 years and could lead to prosecution and jail time.
Better analogy: None of us have gone through the million
Re: (Score:2)
How about running 35 million lines of compiled code that you don't know or understand, and then willingly inputting your credit card numbers and other personal information into it?
Chromium is 35 million lines of code. Have you gone over that pile of code yet?
Read permission is not the same as write permission.
Does Chromium allow anyone to make changes without review?
Re: (Score:2)
Use open-source, better than proprietary. *starts reading through every bit of code* Well that's one way to conquer the world. One line at a time.
Re: Who would be stupid enough... (Score:3)
There's a mismatch here (Score:5, Interesting)
The New Way of Coding is to download dozens, maybe hundreds of little bits of code from random places.
But the languages, operating systems, runtime environments, everything, are from the Old Way of Coding, where every line of code has access to everything, and there's no way of knowing what something might do.
Something's gotta give.
If people want to keep coding this way, things need to be rebuilt from the ground up. With tight, granular control. With fine-grained isolation. With proof-carrying code. Docker and flatpak and VMs are not good enough. And no, you will not be able to keep coding anything you would recognize as being Python.
It should be unusual for a piece of code to have access to files and the network; that should be reserved for a very fiew pieces of code that have good reasons and come from known sources and are looked at carefully. And "files" shouldn't mean "every file on the system" or even "every file some single user has", and "the network" shouldn't mean "just anything anywhere on the Internet". And it should be weird for code that can read much of anything at all to be able to write things that much other code can read.
Re: (Score:2)
Re: (Score:2)
However- both of the 2 I'm familiar with (SELinux and AppArmor) give full permissions to things run explicitly from a terminal context.
Re: (Score:2)
Those provide some granularity on the things that get accessed, but not on the code that does the accessing.
I'm not really sure that I see the distinction.
They provide granularity on the things that get access by the binary that accesses them (or the contexts, rather)
If you want to build your binary out of a hundred tiny libraries, then each one of those libraries has to be separately controlled.
Ah, I think I see.
You want contexts per dynamically loadable chunk of code. That's interesting... But I'm not sure I believe it's necessary.
It's not enough to give every line of code in the whole binary the exact same access.
Ya, I don't think I agree with you there. From a purely hypothetical point of view, sure, you're right. But that sounds like the... most complicated solution to a problem that has a myriad of simpler solutions.
Re: (Score:2)
We're long overdue for a data center OS that does all that. 10+ years ago I used to have my fingers crossed VMware would announce a new OS, because screw virtualizing Linux I just want to run software and not deal with all that baggage. Then docker and k8s happened and it seems we're stuck with those bolted on duct taped garbage solutions. Going back to crying in my beer now, thanks.
Re: There's a mismatch here (Score:2)
There's a role for the OS here as well. Windoes by default gives any application access to everything the user can access. Why does Android provide me with more granular control of app permissions (showing the permissions at install time but also, crucially, explicitly requesting a specific permission when first used) than a Desktop OS like Windows?
Is _anyone_ surprised? (Score:4, Interesting)
Other open source installation tools have precisely this issue, including ant, maven, CPAN, and ansible galaxy. It's compounded by tools that reach out directly to obscure github or sourceforge repos which may not be securely managed. It's why Linux distributions exist to provide some sanity checking and chance to lock down specific versions of the software.
As if anyone needed another reason (Score:3)
to avoid using Python... :P
Re: (Score:2)
Because he is suggesting there are other reasons to avoid using Python. This is not hard to understand.
Insert anti Open Source cyberBS (Score:1)
Dependencies (Score:3)
I used to pull in Java and C# dependencies into my SVN tree manually every time, and disabled every effort by tools to auto update the libraries. However even for smaller projects those "external" dirs quickly grew in size, and was difficult to audit.
Today, I don't have the same energy, and dependency trees grew even larger. To make things worse, auto downloaders like pip are now standard with many Linux distributions, and many libraries assume you would use them, without asking. I could of course set up a managed mirror for every tool, and try to check each and every package I download, but let's be frank, almost nobody will do that. Or at least without having a separate dedicated team tasked with only 3rd party packages.
And, again many Linux distributions gave up on following each and every Python, Ruby, Node, R, .Net. Java package out there, but just give you tools to do local installs from remote repositories.
So, unfortunately, the battle is already lost.
Fuck motherfuckers (Score:2)
Anaconda (Score:2)
This is one of the motivations why curated software repositories exist.
Anaconda for Python
Microsoft R Open
I recall Node.js has some quality controlled repos too.
Frankly, much of the fun of open source is discovering neat things other people have written. So the risk is always there. Perhaps the future is development machines that aren't our personal machines. We are already getting there. RStudio cloud is a decent replacement for local development experience. RStudio Server, Eclipse Theia and VS Code server