10 ms·

PyPI: Python packets steal AWS keys from users

168 points by modinfo 4y ago

deleted 4y ago
[deleted]
anonymousnotme 4y ago
Glad they were able to automatically detect/catch this. There seems to be so much bloat when dependencies get pulled in. Wonder if something like pledge and unveil around library code could be helpful; perhaps library code needs to be separated out into a separate process that would not have reason to access AWS keys. Also, looking at the screenshot, could a simple programming searching for URLs in the library code help in this case? Looks like they removed the modules, so one can't examine them any more.
- Pv9KKy3 4y ago
  Yeah, I'd love to have a decorator at the top of a file - @env to provide access to env variables or @secrets for some kind of secrets access, nothing else gets this. Python is tough though, a very dynamic language so probably kind of hard to lock it down.
  - Beltiras 4y ago
    You would normally be able to solve things like this via file permissions in the OS but currently we are running everything as root inside a container.
    - Pv9KKy3 4y ago
      Not really, because the dependencies to your python code often have access to all global variables and/or run at same permission level as all your code etc.
- grepfru_it 4y ago
  Is it really automated? The infographic glosses over the how with a “security research team” in the flowchart. Maybe the automation catches suspicious code/activity (like the urls or accessing sensitive files) and the research team just verifies
selcuka 4y ago
I believe this is something that automated code parsing (a la Github Copilot) could really shine. Those tools are able to explain what a block of code does, so it should be possible to catch many types of malware hidden in source code.
- qbasic_forever 4y ago
  If a human can't figure it out than an AI trained on human behavior (or more specifically, trained on comments left next to code) can't figure it out either. It's not like malware authors annotate their code with nice "here's where I exfiltrate all the user's secret data" comments.
  - jart 4y ago
    That's not going to stop people from trying though. If people keep abusing the package managers like this, then publishing open source code is at risk of ending up like distributing binaries on Windows, where you need to fight dozens of virus scanners arbitrarily blocking your code for no apparent reason. Imagine opening a tab in VSCode only to see a popup warning saying it might be harmful, even though you just wrote it yourself.
    - imwillofficial 4y ago
      This kinda happens already. I get prompted to trust stuff I wrote
    - dapids 4y ago
      That's exactly was vscode does for me.
      - jart 4y ago
        Are you talking about this? https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust That's different from how virus scanners work and not exactly what I'm talking about. Even Emacs does that.
hcrean 4y ago
I wonder if the target of loglib-modules and hkg-sol-utils is a specific company running its own internal PyPi server, or something like a scientific collaboration (which can be thousands of people and billions of dollars, especially in the drugs discovery domain). PIP is designed to treat all indexes as mirrors, rather than to specify the source of a package: So a higher package version of an internal package name would be chosen whether it is on public or private PyPi. Equally a certain percentage of the time it would choose public over private with the same package version.
- legutierr 4y ago
  Wow. So what you are saying is that someone with knowledge of a company’s internal private package dependencies would be able to hijack their build process by publishing a higher-numbered version of the same package to the public PyPi? And even if the build system explicitly references the package version number, part of the time the package would be taken from the public PyPi instead of the company’s own package server? How do you mitigate this, other than just totally blocking access to the public PyPi? Shouldn’t everyone be blocking access to PyPi, then, and only be relying on their own private package server?
  - hcrean 4y ago
    So the correct solution is really to pre-approve dependencies and store them in a local PyPi. Defence, Medical and some other high-sec industries do this as a matter of course. The problem with this approach is the amount of security toil required to vet packages is large, generally too large for most companies to buy into. So one solution I see in the wild a lot is to prefix your company packages with a company identifier, then to set proxy rules to prevent fetching these from public PyPi (often these are set directly on the private PyPi and all traffic is directed through it). Having been an agency pentester, I can tell you that given access to one company package (Open Sourced?), you can correctly guess the package structure, naming conventions and internal build infra of the company 90+% of the time.
  - di 4y ago
    Using hash checking mode: https://pip.pypa.io/en/stable/topics/secure-installs/#hash-checking-mode https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...
ashishbijlani 4y ago
I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down; a few are listed here https://packj.dev/malware https://packj.dev/malware 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
- jb_s 4y ago
  Is it easy to find a list of packages that have been pulled from python/npm in the past? Would be interesting to train some models against it
  - karxxm 4y ago
    What would the input to such a model be? The malicious code snippets? Or do you want to classify packages according to other meta data?
    - jb_s 4y ago
      Yeah. I was wondering how easy it would be to classify using a language model/models. ALthough I don't know how it'd work with binary blobs, multiple languages, etc. I think certain things would be picked up pretty easily e.g. obfuscated code would be a pretty loud feature, but subtle stuff might be undetected and generally I can't see the model being super accurate.
  - ashishbijlani 4y ago
    Sure. Please email me (in profile) for the list. You can also look at the following resources for malware samples: 1. https://github.com/IQTLabs/software-supply-chain-compromises https://github.com/IQTLabs/software-supply-chain-compromises 2. https://github.com/rsc-dev/pypi_malware https://github.com/rsc-dev/pypi_malware 3. https://github.com/osssanitizer/maloss/blob/master/malware/README.md https://github.com/osssanitizer/maloss/blob/master/malware/R...
ed25519FUUU 4y ago
Remember that AWS credentials are easy to lock down. At the very least you could add an ACL to only let them be used on your AWS instances. Then you can set up alerts if someone attempts to use them outside.
- cromd 4y ago
  But wouldn’t any host running the malicious package be vulnerable to having creds stolen from that host? Maybe I don’t know which “ACL” tech you’re referencing. You can limit where credentials are used from, and not just something like where an S3 bucket is read from? (For example)
  - ed25519FUUU 4y ago
    You can set a permission that says “these credentials can only be used on an aws instance owned by this account” Even if the creds are stolen they’d need access to an instance in your account to use them. Also you can be alerted if someone attempts to use them anywhere else.
    - jhugo 4y ago
      There are very few situations where it even makes sense to have static credentials on an AWS instance any more. "Ambient" short-lived credentials from the instance profile and assumed roles are much safer.
      - bloopernova 4y ago
        Exactly. My assumed roles last an hour and are protected by MFA.
    - noahmasur 4y ago
      In the article they claim the package is literally stealing the IAM role credentials from the EC2’s metadata URL. So it’s presumed that the code is already running on your EC2. Of course, just because it takes the credentials doesn’t mean it does anything else with them, but it could have done anything.
rcar 4y ago
Title should be "packages" rather than "packets".
- semitones 4y ago
  I got really excited thinking this was something super interesting that I didn't know about i.e. "Python packets?? What?? Stealing AWS keys?? How??" Disappointed that it's actually just malicious packages
lovelearning 4y ago
In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Perhaps some kind of friendlier CLI or GUI frontend may help. I'm assuming SELinux can achieve this but I don't have first-hand experience with it and from what I've read online, it seems to be less user-friendly than even AppArmor. Any other approach you know about? Do secure distros like Qubes OS or Tails implement this systematically?
- paskozdilar 4y ago
  Containerization is what you want. There are many containerization tools for Linux, Docker being the most popular, and systemd-nspawn being the most Linuxy, but a bit unknown.
  - lovelearning 4y ago
    I didn't know about systemd-nspawn — thanks for the suggestion. I already use Dockerized aliases for some CLI apps (e.g.: ffmpeg) but I didn't find the approach as convenient as I'd like. I've found docker mounts difficult to secure. I'd like to mount $HOME but exclude even read-only access to "$HOME/.ssh/", "$HOME/passwordsafe.pwsafe3" and a dozen other sensitive file patterns. Some kind of predefined "access profiles" to create FS access rules and assign processes to them ("assign all python processes to python profile") is probably what I'd like. Containerization is probably the best approach but I'd prefer if it's more opaque and less effort than Docker. For example, if I create a pyenv environment and run its 'python' command, I want that python process to not have full access to the filesystem without having to create container images, command aliases, or volume mounts.
    - paskozdilar 4y ago
      In that case, you should look into NixOS/Nix package manager (or, if you're a GNU fan, GuixSD/Guix package manager). I've heard a lot of good things about them related to your problems, including extremely good support for virtual environments of any kind.
29athrowaway 4y ago
You can try clearing environment variables before running a command: env -i <command> And only set the ones you absolutely need.
- hnlmorg 4y ago
  That doesn’t help you when you’re application legitimately needs an environmental variable set but unknown to the developer, that application pulls a malicious module.
jbverschoor 4y ago
Network access (outgoing) should be firewalled a lot more these days.. There’s almost no need to open an outgoing connection
- fmajid 4y ago
  It’s tricky, though. Data could be exfiltrated by a DNS lookup or OCSP request.
  - capableweb 4y ago
    I'm not familiar with OCSP, but DNS happens via UDP, and since parent said "network access", I'm assuming they mean all network protocols, not just TCP.
    - kortilla 4y ago
      Any access to resolve global dns lets you exfiltrate even if you’re locked to a local resolver. Just blocking connections to the internet directly is not enough.
      - capableweb 4y ago
        Sure, but again, parent said "Network access" which I assume includes internet (global), local network or any other type of sockets/connections, not just "internet" ones.
        fmajid 4y ago
        Not all OSes’ resolver libraries use the network. Solaris/Illumos uses door IPC.
- WhyNotHugo 4y ago
  Right. Have a DNS servers which only forwards request to trusted domains, and a transparent proxy which only allows traffic to those same domains. This is not a new idea at all, but it's still a very good one.
raverbashing 4y ago
Now, the question is, who is pygrata and who is using their packages?
jSherz 4y ago
What's HN's go-to solution for egress control? It seems to be a murky mix of expensive vendor products and hand-rolled Squid. With supply chain attacks much more common, I'm starting to think that egress control is essential for all.
ebfe1 4y ago
This is also why I like to put honey credentials everywhere, including in my .aws/credentials... You will never know when it might save you XD If you cant be bother with setting up cloudtrail+metric alert, canarytokens peeps can generate one for you ;) https://canarytokens.org/generate# https://canarytokens.org/generate# Like any other tools though, i recommend to have a script to trigger it every now and then to make sure it works (and alert you about it so you dont go into panic mode)... for personal stuff, I usually have a specific day in the month i expect to see some canary tokens fire :)
1337shadow 4y ago
We need the GPG feature in pip to be finished. We can currently upload signed packages, but pip won't check if you thrust the keys. Pip should include a keyring system and prevent people from installing packages without a signature that has a certain thrust level without explicit whitelist or interactivity.
- yrro 4y ago
  Unbelievable that a major packaging ecosystem still has no mechanism for end-to-end signature verification!
  - 1337shadow 4y ago
    Apparently they are working on it in PEP-480
tlonny 4y ago
Might something like this work as a robust solution: https://0bin.net/paste/TTOdW9+B#olQ+FmoCmluokC8UdWllx8GXQtos48RCUMX+7HmRFzL https://0bin.net/paste/TTOdW9+B#olQ+FmoCmluokC8UdWllx8GXQtos... TL;DR At program initialization, clear the `environ` object, and stash the environment variables in some random location in memory. You can then restore the `environ` object when needed via a contextmanager - meaning that code must explicitly be granted permission to access env vs. being able to snoop regardless. Curious to hear your thoughts! EDIT: I wonder if this approach could be extended to allow the use of certain "restricted" libraries (I'm thinking stuff to do with network calls/file system) only within specific scopes - as this would defend against publishing the env vars to a public endpoint...

168 points by modinfo 4y ago

deleted 4y ago

[deleted]

Glad they were able to automatically detect/catch this. There seems to be so much bloat when dependencies get pulled in. Wonder if something like pledge and unveil around library code could be helpful; perhaps library code needs to be separated out into a separate process that would not have reason to access AWS keys. Also, looking at the screenshot, could a simple programming searching for URLs in the library code help in this case? Looks like they removed the modules, so one can't examine them any more.

Pv9KKy3 4y ago
Yeah, I'd love to have a decorator at the top of a file - @env to provide access to env variables or @secrets for some kind of secrets access, nothing else gets this. Python is tough though, a very dynamic language so probably kind of hard to lock it down.
- Beltiras 4y ago
  You would normally be able to solve things like this via file permissions in the OS but currently we are running everything as root inside a container.
  - Pv9KKy3 4y ago
    Not really, because the dependencies to your python code often have access to all global variables and/or run at same permission level as all your code etc.
grepfru_it 4y ago
Is it really automated? The infographic glosses over the how with a “security research team” in the flowchart. Maybe the automation catches suspicious code/activity (like the urls or accessing sensitive files) and the research team just verifies

selcuka 4y ago

I believe this is something that automated code parsing (a la Github Copilot) could really shine. Those tools are able to explain what a block of code does, so it should be possible to catch many types of malware hidden in source code.

qbasic_forever 4y ago
If a human can't figure it out than an AI trained on human behavior (or more specifically, trained on comments left next to code) can't figure it out either. It's not like malware authors annotate their code with nice "here's where I exfiltrate all the user's secret data" comments.
- jart 4y ago
  That's not going to stop people from trying though. If people keep abusing the package managers like this, then publishing open source code is at risk of ending up like distributing binaries on Windows, where you need to fight dozens of virus scanners arbitrarily blocking your code for no apparent reason. Imagine opening a tab in VSCode only to see a popup warning saying it might be harmful, even though you just wrote it yourself.
  - imwillofficial 4y ago
    This kinda happens already. I get prompted to trust stuff I wrote
  - dapids 4y ago
    That's exactly was vscode does for me.
    - jart 4y ago
      Are you talking about this? https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust That's different from how virus scanners work and not exactly what I'm talking about. Even Emacs does that.

hcrean 4y ago

I wonder if the target of loglib-modules and hkg-sol-utils is a specific company running its own internal PyPi server, or something like a scientific collaboration (which can be thousands of people and billions of dollars, especially in the drugs discovery domain). PIP is designed to treat all indexes as mirrors, rather than to specify the source of a package: So a higher package version of an internal package name would be chosen whether it is on public or private PyPi. Equally a certain percentage of the time it would choose public over private with the same package version.

legutierr 4y ago
Wow. So what you are saying is that someone with knowledge of a company’s internal private package dependencies would be able to hijack their build process by publishing a higher-numbered version of the same package to the public PyPi? And even if the build system explicitly references the package version number, part of the time the package would be taken from the public PyPi instead of the company’s own package server? How do you mitigate this, other than just totally blocking access to the public PyPi? Shouldn’t everyone be blocking access to PyPi, then, and only be relying on their own private package server?
- hcrean 4y ago
  So the correct solution is really to pre-approve dependencies and store them in a local PyPi. Defence, Medical and some other high-sec industries do this as a matter of course. The problem with this approach is the amount of security toil required to vet packages is large, generally too large for most companies to buy into. So one solution I see in the wild a lot is to prefix your company packages with a company identifier, then to set proxy rules to prevent fetching these from public PyPi (often these are set directly on the private PyPi and all traffic is directed through it). Having been an agency pentester, I can tell you that given access to one company package (Open Sourced?), you can correctly guess the package structure, naming conventions and internal build infra of the company 90+% of the time.
- di 4y ago
  Using hash checking mode: https://pip.pypa.io/en/stable/topics/secure-installs/#hash-checking-mode https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

ashishbijlani 4y ago

I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down; a few are listed here https://packj.dev/malware https://packj.dev/malware 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj

jb_s 4y ago
Is it easy to find a list of packages that have been pulled from python/npm in the past? Would be interesting to train some models against it
- karxxm 4y ago
  What would the input to such a model be? The malicious code snippets? Or do you want to classify packages according to other meta data?
  - jb_s 4y ago
    Yeah. I was wondering how easy it would be to classify using a language model/models. ALthough I don't know how it'd work with binary blobs, multiple languages, etc. I think certain things would be picked up pretty easily e.g. obfuscated code would be a pretty loud feature, but subtle stuff might be undetected and generally I can't see the model being super accurate.
- ashishbijlani 4y ago
  Sure. Please email me (in profile) for the list. You can also look at the following resources for malware samples: 1. https://github.com/IQTLabs/software-supply-chain-compromises https://github.com/IQTLabs/software-supply-chain-compromises 2. https://github.com/rsc-dev/pypi_malware https://github.com/rsc-dev/pypi_malware 3. https://github.com/osssanitizer/maloss/blob/master/malware/README.md https://github.com/osssanitizer/maloss/blob/master/malware/R...

ed25519FUUU 4y ago

Remember that AWS credentials are easy to lock down. At the very least you could add an ACL to only let them be used on your AWS instances. Then you can set up alerts if someone attempts to use them outside.

cromd 4y ago
But wouldn’t any host running the malicious package be vulnerable to having creds stolen from that host? Maybe I don’t know which “ACL” tech you’re referencing. You can limit where credentials are used from, and not just something like where an S3 bucket is read from? (For example)
- ed25519FUUU 4y ago
  You can set a permission that says “these credentials can only be used on an aws instance owned by this account” Even if the creds are stolen they’d need access to an instance in your account to use them. Also you can be alerted if someone attempts to use them anywhere else.
  - jhugo 4y ago
    There are very few situations where it even makes sense to have static credentials on an AWS instance any more. "Ambient" short-lived credentials from the instance profile and assumed roles are much safer.
    - bloopernova 4y ago
      Exactly. My assumed roles last an hour and are protected by MFA.
  - noahmasur 4y ago
    In the article they claim the package is literally stealing the IAM role credentials from the EC2’s metadata URL. So it’s presumed that the code is already running on your EC2. Of course, just because it takes the credentials doesn’t mean it does anything else with them, but it could have done anything.

rcar 4y ago

Title should be "packages" rather than "packets".

semitones 4y ago
I got really excited thinking this was something super interesting that I didn't know about i.e. "Python packets?? What?? Stealing AWS keys?? How??" Disappointed that it's actually just malicious packages

lovelearning 4y ago

In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Perhaps some kind of friendlier CLI or GUI frontend may help. I'm assuming SELinux can achieve this but I don't have first-hand experience with it and from what I've read online, it seems to be less user-friendly than even AppArmor. Any other approach you know about? Do secure distros like Qubes OS or Tails implement this systematically?

paskozdilar 4y ago
Containerization is what you want. There are many containerization tools for Linux, Docker being the most popular, and systemd-nspawn being the most Linuxy, but a bit unknown.
- lovelearning 4y ago
  I didn't know about systemd-nspawn — thanks for the suggestion. I already use Dockerized aliases for some CLI apps (e.g.: ffmpeg) but I didn't find the approach as convenient as I'd like. I've found docker mounts difficult to secure. I'd like to mount $HOME but exclude even read-only access to "$HOME/.ssh/", "$HOME/passwordsafe.pwsafe3" and a dozen other sensitive file patterns. Some kind of predefined "access profiles" to create FS access rules and assign processes to them ("assign all python processes to python profile") is probably what I'd like. Containerization is probably the best approach but I'd prefer if it's more opaque and less effort than Docker. For example, if I create a pyenv environment and run its 'python' command, I want that python process to not have full access to the filesystem without having to create container images, command aliases, or volume mounts.
  - paskozdilar 4y ago
    In that case, you should look into NixOS/Nix package manager (or, if you're a GNU fan, GuixSD/Guix package manager). I've heard a lot of good things about them related to your problems, including extremely good support for virtual environments of any kind.

29athrowaway 4y ago

You can try clearing environment variables before running a command: env -i <command> And only set the ones you absolutely need.

hnlmorg 4y ago
That doesn’t help you when you’re application legitimately needs an environmental variable set but unknown to the developer, that application pulls a malicious module.

jbverschoor 4y ago

Network access (outgoing) should be firewalled a lot more these days.. There’s almost no need to open an outgoing connection

fmajid 4y ago
It’s tricky, though. Data could be exfiltrated by a DNS lookup or OCSP request.
- capableweb 4y ago
  I'm not familiar with OCSP, but DNS happens via UDP, and since parent said "network access", I'm assuming they mean all network protocols, not just TCP.
  - kortilla 4y ago
    Any access to resolve global dns lets you exfiltrate even if you’re locked to a local resolver. Just blocking connections to the internet directly is not enough.
    - capableweb 4y ago
      Sure, but again, parent said "Network access" which I assume includes internet (global), local network or any other type of sockets/connections, not just "internet" ones.
      - fmajid 4y ago
        Not all OSes’ resolver libraries use the network. Solaris/Illumos uses door IPC.
WhyNotHugo 4y ago
Right. Have a DNS servers which only forwards request to trusted domains, and a transparent proxy which only allows traffic to those same domains. This is not a new idea at all, but it's still a very good one.

raverbashing 4y ago

Now, the question is, who is pygrata and who is using their packages?

jSherz 4y ago

What's HN's go-to solution for egress control? It seems to be a murky mix of expensive vendor products and hand-rolled Squid. With supply chain attacks much more common, I'm starting to think that egress control is essential for all.

ebfe1 4y ago

This is also why I like to put honey credentials everywhere, including in my .aws/credentials... You will never know when it might save you XD If you cant be bother with setting up cloudtrail+metric alert, canarytokens peeps can generate one for you ;) https://canarytokens.org/generate# https://canarytokens.org/generate# Like any other tools though, i recommend to have a script to trigger it every now and then to make sure it works (and alert you about it so you dont go into panic mode)... for personal stuff, I usually have a specific day in the month i expect to see some canary tokens fire :)

1337shadow 4y ago

We need the GPG feature in pip to be finished. We can currently upload signed packages, but pip won't check if you thrust the keys. Pip should include a keyring system and prevent people from installing packages without a signature that has a certain thrust level without explicit whitelist or interactivity.

yrro 4y ago
Unbelievable that a major packaging ecosystem still has no mechanism for end-to-end signature verification!
- 1337shadow 4y ago
  Apparently they are working on it in PEP-480

tlonny 4y ago

Might something like this work as a robust solution: https://0bin.net/paste/TTOdW9+B#olQ+FmoCmluokC8UdWllx8GXQtos48RCUMX+7HmRFzL https://0bin.net/paste/TTOdW9+B#olQ+FmoCmluokC8UdWllx8GXQtos... TL;DR At program initialization, clear the `environ` object, and stash the environment variables in some random location in memory. You can then restore the `environ` object when needed via a contextmanager - meaning that code must explicitly be granted permission to access env vs. being able to snoop regardless. Curious to hear your thoughts! EDIT: I wonder if this approach could be extended to allow the use of certain "restricted" libraries (I'm thinking stuff to do with network calls/file system) only within specific scopes - as this would defend against publishing the env vars to a public endpoint...