To search your own projects for the malicious libraries: pip3 freeze | grep -i jeIlyfish pip3 freeze | grep -i python3-dateutil
[deleted]
Two malicious Python libraries caught stealing SSH and GPG keys
21–30 of 323 posts
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#22I get the python3-dateutil because you might think it's an updated version of the standard library. But how does jellyfish with a different char for L work? Someone would need to copy and paste it. But if they go to pypi, it won't have many installs. Unless they started writing tutorials with: "okay now just pip install X"
I think the key here is that jeIlyfish had malicious code in it, and the fake python3-dateutil imported jeIlyfish. Even if you were examining the source for malicious code, you might not notice the difference between jellyfish and jeIlyfish, I guess.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#23I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#24I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#25Would sticking to the OS upstream package manager be a safer option compared to installing from pypi directly? How often does something like this happen with packages in the CentOS, epel, or Debian repositories?
I think it would be quite a bit safer and you are already trusting your distribution but those libraries tend be very old/stale versions, and limited selections.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#26I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
For this particular case: if you have GnuPG or SSH private keys, do not store them on-disk. Use a hardware token, such as a gnuk token, or a token with a secure element if you also want resistance against physical key exfiltration. A gnuk-based hardware token can be had in a nice format for under 30 Euro [1] or you could buy a STM32F103-based microcontroller for a few bucks and flash gnuk [2] if you like DIY. If you…
yubikeys can store GPG keys and emulate SSH keys via gpg-agent. More exciting: OpenSSL recently added full U2F/Fido support, but it might take a bit until that lands in all distros https://www.undeadly.org/cgi?action=article;sid=201911150648...
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#27Anyone here not encrypting their private keys? Also known_hosts file is a double edged sword. It's pretty sensitive in combination with a private key.
You shouldn't just encrypt the keys. If malicious code is running on a machine, they could as well eavesdrop on keystrokes. This is even made simpler by the fact that a large part of the demography uses X11, which is inherently insecure since all applications can read key strokes, mouse events, and do screen grabs.
Get a hardware token. If you have a hardware token with a pin, they could extract your PIN by reading keystrokes and use the token on your machine. But once you yank the token out of the USB port, that's the end of it. Even better is a hardware token that requires physical confirmation for operations.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#28These two have been caught. How many haven't yet been caught? Traditional Unix file permissions are pretty much a joke for the way developer computers get used (one user - does everything). Real process sandboxing is needed.
And it's not just the developer machine that's at risk. Even if you protect your own system, you will still be shipping malware to your users, who may be vulnerable. And you'll be lending your credibility to the malicious libraries you distribute.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#29Package management and curation are the Achilles heel of open source. Abandoned packages, typo and letter substitutions, maliciously crafted pull requests and so on are all going to go up in frequency until the environment is hardened enough that the bulk of these attempts fail. That's a long way to go, and the number of capable maintainers and curators is relatively small.
Some environments (Python, Node) are more susceptible to this sort of trickery than others.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#30From the article... The libraries were "jeIlyfish" (with an upper case I) and "python3-dateutil" (not "dateutil"). Both libraries were close spellings of the real libraries.
The lesson for developers is double check your imports! Spelling does count and there are lots of similarly named libraries (most are not malicious thankfully)