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

61–70 of 323 posts

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

#61

Post by whack »

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…

When I first realized that any and all code that I execute, has read/write permissions to most of my filesystem, it blew my mind. The OS grants every process its own unique virtual-memory-space, specifically to prevent malicious/accidental interference with other processes. It seems like the file-system really should operate on a similar principle as well. Every application should run in a sandboxed environment by default, with exceptions being granted by the user for specific applications that actually do need access to the entire file system.

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

#62

Post by swiley »

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.

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

#63

Post by objectified »

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 automatically built on CI servers in side corporate networks, the possibilities to grab data and send it to somewhere on the internet are endless.

One security measure that somehow grew out of fashion over the last years, is at least on application servers, to disallow any outgoing network traffic, especially to the internet (at least any cloud environment I see nowadays allows it by default). This would largely prevent these sorts of attacks from being able to actually send anything out, but also prevent XXE attacks from happening, prevent reverse connections to an attacker host from being set up, make SSRF attacks harder to verify, and so on.

I strongly recommend whitelisting only the network traffic that your application actually needs.

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

#65

Post by pouta »

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

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

#66

Post by als0 »

aledthemathguy wrote: post #55
XorNot wrote: post #24

Earlier quoted context omitted.

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.

This is currently only implemented in FreeBSD? No other distro uses this?

SELinux is part of Linux. FreeBSD has its own mandatory access control framework.

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

#67

Post by andybak »

JakeMimoni wrote: post #59

We just recently launched a free tool that helps python developers prevent exactly these type of issues. Feel free to check it out: https://trustd.dev we work preventatively, so as you download packages, the tool will analyse it and tell you of any issues found. We’re looking to collaborate with devs to work out what features should be next.

First question is what the hell does this mean:

> As you install open-source packages, trustd will scan them and provide you with instant feedback on any problems.

What kind of scanning? Algorithmic? Based on human review? If we're outsourcing trust to you, I'd want to know a lot more.

And "we use Slack instead of a dashboard" doesn't sound terribly appealing. I'd want a dashboard and a range of notification options (for me email > Slack. Others may differ)

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

#68

Post by keyP »

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 could raise flags.

The official library itself could have a "urls" file which has a list of urls that are expected and so anything that doesn't match can be questioned.

Whilst this won't solve the issue 100%, it raises the difficulty barrier to implement outgoing network calls.

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

#69

Post by objectified »

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

I'm not sure I understand your question correctly, but I'm talking specifically about outbound network traffic. Your API's application servers (where such evil libraries could be deployed) should not be able to have any network connectivity towards the internet. So on that server, you should not be able to do even `curl www.google.com` for example.

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

#70

Post by Xylakant »

microtonal wrote: post #32
Xylakant wrote: post #26

Earlier quoted context omitted.

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...

yubikeys can store GPG keys and emulate SSH keys via gpg-agent. Indeed. Same for gnuk keys. I currently use a gnuk key (Nitrokey Start) with Ed25519 and have GPG set up as the SSH agent for SSH. Though I hope to switch to a YubiKey soon, so that I don't need a separate key for U2F/Fido2.

I'm really looking forward to the U2F support - it's built into openssh and allows multiple ssh-keys tied to a single yubikey. The gnupg stack has become more stable, but it's always been the problematic part of the setup.

The other advantage is that you can use the cheap U2F/Fido yubikeys without GPG/applet support.

Post reply on HN