SSH keys stolen by stream of malicious PyPI and NPM packages

I am looking forward to PyPI's "answer" to this class of malicious packages with automated third-party reporting (and hopefully long-term, quarantining or even deletion). Hopefully this project will swing the narrative closer to the /actual/ security threat that these packages represent to their respective package ecosystems. The PyPI Safety and Security Engineer Mike Fiedler is working on this project :)

I... disagree.

I feel that the differentiation between "lifting keys" and "maliciously using them" is not a useful one to make. Both actions are very bad. If you want to wait until we have evidence that the compromised keys were used to pull e.g. proprietary code or configuration from Github; why not also wait until that compromised data is sold? Or until a company is formed leveraging it? Ultimately, it's a slippery slope of "nothing will satisfy you", and there's clearly a genesis event here that is reprehensible and should be known about, even if it is, as you say, just opportunistic script kiddies.

Speaking of which; I loath that characterization of threat actors. This is not the 90s anymore, and it's time to grow up and recognize that the opponents in this space can be extremely sophisticated and well-funded. This is, genuinely, something that many people in the industry refuse to accept; because it implies that we absolutely need to hold ourselves and our work to a higher standard, treat what we produce with severe gravity, and ultimately this means the pace of innovation will slow down and we'll need to ask the mirror serious questions like "wait, so you just, npm installed critical code that was handling sensitive user data? without even auditing it?"

NPM (and, by extension, Github) are extremely blame-worthy here. Reports like this one absolutely happen so Sonatype can sell their product; no doubt on that coming from me whatsoever. But, they also put pressure on key infrastructure providers.

> FTA, the “rapid evolution” in question is that the malicious packages switched from using base64 for obfuscation to…double base64.

Ok, yeah; describing that as "rapid evolution" is overselling it. But let's play in that playground; it's not a rapid evolution, it's an unsophisticated additional layer of easily-reversible obfuscation, which npm did not catch. Why? Why is sonatype catching this, and not npm?

A few years ago, my company found hundreds of internal projects using the malicious "python3-dateutil" library. One instance was ultimately used to get full ATO of an AWS account and launch hundreds of EC2 instances to mine crypto. So, the threat is real, even if it is overstated by "companies capitalizing on supply chain security fears".

Better yet, we need a new model of running computer programs. I think the good old running a python file through an interpreter that has at least read-only access to ~/ is not cutting it anymore. This is why Apple's additional access (explicitly granting read access to certain user folders to certain applications) is a good step to the right direction.

Can you say more about how this works?

It's funny how many don't know this. Almost as if the TPM wasn't designed to protect users.

Pardon my ignorance but is TPM specific to PCs or available on Macs as well?

This great find!

That is really cool. Apple should add support to their ssh implementation to do something similar.

>Because secrets in the Secure Enclave are not exportable, they are not able to be backed up, and you will not be able to transfer them to a new machine. If you get a new Mac, just create a new set of secrets specific to that Mac.

I consider that to be a deal-breaker. Hardware fails/lost/stolen, and I need to know that I have an offline backup somewhere if disaster strikes.

Note that this comes with a set of pretty important caveats, notably no way to backup keys. Which means you absolutely need to have some way to regain access to whatever you secured with this - either via a backup key, by having another person that can grant access or similar.

Regardless of how good that project might be: No, we don't.

Might be appropriate to store keys in Secure Enclave for some but a dedicated TPM (Yubikey/Nitrokey/Trezor/Ledger/etc) is often preferred. Some might want or need backups.

And even then, having multiple implementations widely used is preferred over having everyone relying on the same small group of volunteers or corporate working on any single one.

Superior to using ssh agent of software like bitwarden or keeper etc?

Would this be more secure than using GnuPG (https://incenp.org/notes/2015/gnupg-for-ssh-authentication.h...)?

Spend $650 and chill?

https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/

Trusting third-party code on machines run as administrator is problematic no matter when the article was published.

Does ssh-keygen use a good/modern algorithm by default? My unfounded suspicion is that owing to its age and backwards compatibility, the password could be brute-forced on a modern GPU.

Would love to hear differently.

Edit: To put it differently, would it be irresponsible to commit my private key to a public repo if it were locked behind a 32-character passphrase?

And don't blindly trust packages you download from the internet.

Good, but that doesn't protect other files in your filesystem. Stealing ssh keys is the symptom; trusting someone else's code is the disease.