PyPI: Python packets steal AWS keys from users • Hacker News Board

Re: PyPI: Python packets steal AWS keys from users

#81

Post by ciupicri » Mon, Jun 27, 2022, 12:42 PM UTC

oblio wrote: post #56

rjh29 wrote: post #50

Earlier quoted context omitted.

I guess you'd have to run it in a malware sandbox like Cuckoo.

Turns out, stuff like Java's SecurityManager: https://docs.oracle.com/javase/7/docs/api/java/lang/Security... were there for a reason. Note, it's been around since JDK 1.0, so 1996, 28 years ago (!), though it's not widely used. But it allows sandboxing of libraries you use. I was using it to make a faulty library that was calling System.exit(0) - yes, a library that was shutting down the entire process, closing the…

Python had some sandboxing attempts long time ago, like 20 years if not more, but without much success. Zope - one of the first web frameworks - needed one, but if I remember correctly it broke around Python 2.5, so you had to use Zope with an old version of Python.

https://wiki.python.org/moin/SandboxedPython has some details

Re: PyPI: Python packets steal AWS keys from users

#82

Post by di » Mon, Jun 27, 2022, 1:01 PM UTC

legutierr wrote: post #65

hcrean wrote: post #7

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

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

Using hash checking mode: https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

Re: PyPI: Python packets steal AWS keys from users

#83

Post by capableweb » Mon, Jun 27, 2022, 1:26 PM UTC

kortilla wrote: post #55

capableweb wrote: post #54

Earlier quoted context omitted.

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.

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.

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.

Re: PyPI: Python packets steal AWS keys from users

#84

Post by tremon » Mon, Jun 27, 2022, 2:05 PM UTC

jhugo wrote: post #25

devonkim wrote: post #13

Earlier quoted context omitted.

Source code has issues with obfuscation methodologies that can defeat a lot of techniques. It’s why companies are trying to build more analysis down into the kernel such as via EBPF. For example, concatenating a series of strings and characters that wind up reading from .AWS/credentials in the end is surprisingly tough to catch based upon simple pattern recognition alone, especially if it’s done in a subtle way such…

Right, code analysis to try to detect places where it reads from ~/.aws/credentials is never going to be reliable. The correct approach is not to run untrusted code in an environment where it can read your AWS credentials.

And if that's infeasible, to not run untrusted code in an environment where it has unfettered outbound access to the Internet.

Re: PyPI: Python packets steal AWS keys from users

#85

Post by tlonny » Mon, Jun 27, 2022, 2:35 PM UTC

Might something like this work as a robust solution:

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

Re: PyPI: Python packets steal AWS keys from users

#86

Post by ashishbijlani » Mon, Jun 27, 2022, 2:40 PM UTC

oefrha wrote: post #77

ashishbijlani wrote: post #9

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

Hey, I tried to check whether your project can detect obfuscation, but it doesn't appear to be installable. In requirements.txt: - esprima==4.0.0 requires Python 3.6 (EOL) or lower because the package is really old and uses the async keyword (promoted in py37) as an attribute name, which is a SyntaxError on py37+. - GitPython==3.1.27 requires Python 3.7 or later (requires-python:>=3.7).

Thanks for trying it out and sharing your feedback! I will fix this issue and also create a Dockerfile for easy testing.

Re: PyPI: Python packets steal AWS keys from users

#87

Post by ashishbijlani » Mon, Jun 27, 2022, 2:42 PM UTC

Akronymus wrote: post #66

ashishbijlani wrote: post #9

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

Does it work on obfuscated calls? For example, a base 64 encrypted string that gets decrypted and then passed to a shell. Altough, I guess in that case, the shell call itself is suspicious. What if the shell call itself is obfuscated?

> a base 64 encrypted string that gets decrypted and then passed to a shell.

This is a very common malicious behavior. Packj detects obfuscation [1] as well as spawning of shell commands (exec system call) [2]. I've updated threats.csv to flag code obfuscation.

1. https://github.com/ossillate-inc/packj/blob/main/main.py#L48... 2. https://github.com/ossillate-inc/packj/blob/main/main.py#L48...

Re: PyPI: Python packets steal AWS keys from users

#88

Post by ashishbijlani » Mon, Jun 27, 2022, 2:53 PM UTC

jhugo wrote: post #27

ashishbijlani wrote: post #9

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

Does this work at the system call level, where it would detect e.g. any attempt to open ~/.aws/credentials, or does it rely on heuristic analysis of the code itself, which will always be able to be "coded around" by the malware authors? The correct approach would seem to be to not run untrusted code in an environment where it can read your AWS credentials.

Packj currently uses static code analysis to derive permissions (e.g., file/network accesses). Therefore, it can detect open() calls if used by the malware directly (e.g., not obfuscated in a base64 encoded string). But, Packj can also point out such base64 decode calls. Fortunately, malware has to use these APIs (read, open, decode, eval, etc.) for their functionality -- there's no getting around. Having said that, a sophisticated malware can hide itself better, so dynamic analysis as you suggested must be performed for completeness. We are incorporating strace-based dynamic analysis (containerized) to collect system calls.

Re: PyPI: Python packets steal AWS keys from users

#89

Post by ashishbijlani » Mon, Jun 27, 2022, 2:56 PM UTC

codedokode wrote: post #47

lrem wrote: post #43

Earlier quoted context omitted.

https://github.com/ossillate-inc/packj#how-it-works I imagine you'd want some kind of fuzzer with security-oriented tracing on top. I've never heard of such a tool, but I'd bet it exists somewhere.

As I understand, they use static analysis. So the malicious code can be hidden by obfuscation. For example, instead of writing open('/etc/password') One can write method = calculateMethodName() name = calculateEtcPassword() geattr(__builtins__, method)(name)

Yes, we are incorporating strace-based dynamic analysis (containerized) to collect system calls. However, Packj can currently flag use of getattr() API as it is equivalent to "runtime code generation" [1]; a developer can go and take a deeper look then.

1. https://github.com/ossillate-inc/packj/blob/main/main.py#L47...

Re: PyPI: Python packets steal AWS keys from users

#90

Post by ashishbijlani » Mon, Jun 27, 2022, 3:03 PM UTC

jb_s wrote: post #20

ashishbijlani wrote: post #9

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

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

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 2. https://github.com/rsc-dev/pypi_malware 3. https://github.com/osssanitizer/maloss/blob/master/malware/R...