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

PyPI: Python packets steal AWS keys from users

blog.sonatype.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: PyPI: Python packets steal AWS keys from users

#61

Post by unnah »

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…

The Java Security Manager was not very effective in practice. It was already deprecated in Java 17 and will be removed in the future: https://openjdk.org/jeps/411

Re: PyPI: Python packets steal AWS keys from users

#62

Post by ykonstant »

eszaq wrote: post #44
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…

How about flagging anything that looks like obfuscated code?

Apologies if this was not a joke, but just imagining the implications of this made me laugh harder than any comedy I've watched the past few weeks. My... umm... "scientific code" would be flagged in miliseconds :D

Re: PyPI: Python packets steal AWS keys from users

#63

Post by Beltiras »

323 wrote: post #8
selcuka wrote: post #4

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.

This is the kind of stuff that antiviruses did for ages, from signature, code simulation to heuristics. They have a lot of expertise in this, it feels like they could branch out in finding malware in source code, instead of in binaries.

Binaries can be seen as "source code" for the CPU.

Re: PyPI: Python packets steal AWS keys from users

#64

Post by Scea91 »

rjh29 wrote: post #52
selcuka wrote: post #4

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.

Isn't this impossible as per the halting problem? It would be better to run the code in a sandbox and log all the syscalls it makes, similar to how Cuckoo's malware sandbox works.

Halting problem is only relevant if we are discussing a perfect 100% solution with no false-positives and false-negatives.

In real-life it is not of much relevance. I haven't seen a practical case in my life where I would conclude that it is undecidable to say what a function does (happy to see some practical examples if someone has some). For a theoretical program that "uploads credentials iff a sub-program halts" you would probably block it and live with a possible false-positive.

Re: PyPI: Python packets steal AWS keys from users

#65

Post by legutierr »

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

Re: PyPI: Python packets steal AWS keys from users

#66

Post by Akronymus »

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?

Re: PyPI: Python packets steal AWS keys from users

#67

Post by smcleod »

intense_feel wrote: post #48
smcleod wrote: post #33

Earlier quoted context omitted.

Looks interesting, thanks. I'd like to see something like this but with a transparent proxy interface that you can point your package managers to so that you always in inspected and approved packages.

That's exactly what I am working on right now! I made an open source project called ambience (currently in public alpha https://ambience.sourcecode.ai ). The point of that project is that you can create or use an existing repository proxies and attach to it what I called "audit policies" those are basically a list of packages/versions you want to block or allow. The default ones include for example malicious, vulnera…

That's a cool project - I really like that it's open source and self hostable. A key thing for me would be npm package support - the nodejs ecosystem is such a dumpster fire.

Re: PyPI: Python packets steal AWS keys from users

#68

Post by bloopernova »

jhugo wrote: post #26
ed25519FUUU wrote: post #21

Earlier quoted context omitted.

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.

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.

Exactly. My assumed roles last an hour and are protected by MFA.

Re: PyPI: Python packets steal AWS keys from users

#69

Post by planede »

progval wrote: post #49
planede wrote: post #45

Earlier quoted context omitted.

firejail is not limited to GUI apps, is it?

It's not, but there is a 2-3s startup and shutdown delay, which I find too annoying for CLIs

I guess you can limit entire shell sessions with firejail, to amortize the startup time. But I suppose the limits would need to be looser in that case to be useful.

Re: PyPI: Python packets steal AWS keys from users

#70

Post by noahmasur »

ed25519FUUU wrote: post #21
cromd wrote: post #16

Earlier quoted context omitted.

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)

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.

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.

Post reply on HN