Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two malicious Python libraries caught stealing SSH and GPG keys

zdnet.com

Post reply on HN
Print view View original

71–80 of 323 posts

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#71

Post by gruez »

microtonal wrote: post #15
greggman2 wrote: post #13

I 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…

I never understood the point of hardware tokens. If the machine it's plugged into it's compromised, the attacker can still use it to sign whatever they want. If the attacker has persistence on your machine, it's as good as stealing the key file. You're basically counting that you can discover the infection before the attacker can use it, or the attacker is unsophisticated so all they do is copy your .asc files (although you could also protect against this by putting your key files in a weird location). Depending on how proficient the attacker is and how vigilant you are, it could be a while before it's discovered. When you do discover it, you still have to revoke/rotate your keys since you have no idea what it could have been used for. So you end up not saving any effort at all.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#72

Post by JakeMimoni »

rmbryan wrote: post #9

What's the best information source for me to follow to keep up to date on these kinds of library vulnerabilities? I would make a feed of the homepages for all the libraries I know I use, but that won't help me with the libraries I use without knowing.

we made a tool that automates that process - https://trustd.dev

it will analyse open-source packages as you install them and tell you of any vulnerabilities before they are even on your system...

meaning it will detect problems in the libraries you aren't thinking about.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#74

Post by jstanley »

keyP wrote: post #68

One thing I've always thought would be a good idea is a tool (either local or part of the pip/other packet manager download process) that greps and prints out all URLs and IP addresses within the code, including common encodings. Additionally, any lines that uses any transfer protocols (like HTTP requests) should be highlighted too as IP/urls can be encoded. Any HTTP request, for example, to suspiciously encoded URLs…

> it raises the difficulty barrier to implement outgoing network calls.

Not very much. You just obfuscate your code until this tool doesn't notice anything untoward, and then upload it.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#75

Post by johnday »

swiley wrote: post #62

Don’t install packages with large numbers of dependancies (for me, this is more than 2.) Don’t install packages you haven’t at least been to the website for and preferably couldn’t build yourself. Libraries and package managers help us work together, they’re not excuses for not thinking.

Placing the burden of responsibility for security on the end user is not the way to go about this - at least, not if you want people to actually use your product / language.

Package managers do not only exist as a convenience. They should also provide guarantees about their packages, or at the very least some level of moderation.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#77

Post by keyP »

jstanley wrote: post #74
keyP wrote: post #68

One thing I've always thought would be a good idea is a tool (either local or part of the pip/other packet manager download process) that greps and prints out all URLs and IP addresses within the code, including common encodings. Additionally, any lines that uses any transfer protocols (like HTTP requests) should be highlighted too as IP/urls can be encoded. Any HTTP request, for example, to suspiciously encoded URLs…

> it raises the difficulty barrier to implement outgoing network calls. Not very much. You just obfuscate your code until this tool doesn't notice anything untoward, and then upload it.

Highly obfuscated code would raise suspicions, especially in similar cases found in NPM packages.

E.g. in Python, obfuscators I've come across tend to replace characters with non-Latin unicode chars, which should raise flags when found in a predominatenly latin based source code.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#78

Post by Xylakant »

gruez wrote: post #71
microtonal wrote: post #15

Earlier quoted context omitted.

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…

I never understood the point of hardware tokens. If the machine it's plugged into it's compromised, the attacker can still use it to sign whatever they want. If the attacker has persistence on your machine, it's as good as stealing the key file. You're basically counting that you can discover the infection before the attacker can use it, or the attacker is unsophisticated so all they do is copy your .asc files (altho…

Yubikeys for example can require a touch on the token to activate it. A dedicated attacker could still trick you into activating the token by waiting for you to do something where you'd need to activate it, but it significantly raises the bar.

They also entirely prevent various compromises:

* Theft or loss of the laptop does not mean loss of token.

* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial.

* Attacks where the attacker can read files do not turn into a compromise of key material.

* Even a compromise that allows code execution would require a sophisticated attacker to pivot: You'd need to figure out how to make good use of the acces gained either in a fully automated fashion or be online when the victim has its token plugged in. You cannot collect the key and later figure out what to do. This pretty much rules out attacks such as the one we're discussing here.

So while they do not protect against a full persistent compromise, there are quite a few cases that they do protect against.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#79

Post by zbentley »

pouta wrote: post #65
objectified wrote: post #63

This will keep happening, and not only will SSH And GPG keys be the target, but any interesting data will be stolen. And the problem is much larger than these typosquatting attacks. Abandoned Github projects taken over my malicious users, rogue Maven/npm/PyPI/what have you repositories, hacked accounts on any website that is used for distributing programs, feature branches in open source projecs that are automaticall…

How would this work for a public facing API? Or an API that serves a SPA? I'm interested in this approach

objectified has it already, but to reiterate: you can block outbound traffic initiated on a host without blocking outbound traffic that is a response to externally initiated traffic. This is, for example, what haproxy, iptables, and AWS security group outbound rules do.

I'm deliberately avoiding the term "connection" above because new UDP-first protocols require slightly different handling to determine who initiated what, but most routing/firewall software can deny-initiated-outbound for those protocols as well.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#80

Post by jagged-chisel »

qxnqd wrote: post #76
mikorym wrote: post #4

> The first is "python3-dateutil," which imitated the popular "dateutil" library. The second is "jeIlyfish" (the first L is an I), which mimicked the "jellyfish" library.

I don't get it. Who would type "pip install jeilyfish" by mistake?

I can only see this working where someone would copy and paste the package name.

EDIT: another vector I saw mentioned in another comment: you pull in what appears to be a 'valid' dependency, and jeIlyfish is listed as a dependency of that package; looks legit so you proceed.

Post reply on HN