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

71–80 of 104 posts

Re: PyPI: Python packets steal AWS keys from users

#71

Post by Pv9KKy3 »

Beltiras wrote: post #59
Pv9KKy3 wrote: post #5

Earlier quoted context omitted.

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.

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.

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.

Re: PyPI: Python packets steal AWS keys from users

#72

Post by ebfe1 »

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#

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 :)

Re: PyPI: Python packets steal AWS keys from users

#73

Post by [deleted] »

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?

[deleted]

Re: PyPI: Python packets steal AWS keys from users

#74

Post by [deleted] »

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.

[deleted]

Re: PyPI: Python packets steal AWS keys from users

#75

Post by pabs3 »

lovelearning wrote: post #28

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

bubblewrap, which is used by flatpak's containerisation, is a great tool for modifying the view of the filesystem seen by particular processes. You can even containerise processes installed in your rootfs.

Re: PyPI: Python packets steal AWS keys from users

#76

Post by oblio »

unnah wrote: post #61
oblio wrote: post #56

Earlier quoted context omitted.

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

I understand their reasoning but it's still kind of sad that there's no replacement planned.

It would be cool if there was a universal access control platform, but I guess the best we're getting is Docker, because such a platform would commoditize OSes, which OS creators for sure don't want :-(

Re: PyPI: Python packets steal AWS keys from users

#77

Post by oefrha »

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

Re: PyPI: Python packets steal AWS keys from users

#78

Post by 1337shadow »

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.

Re: PyPI: Python packets steal AWS keys from users

#79

Post by hcrean »

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…

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.

Re: PyPI: Python packets steal AWS keys from users

#80

Post by monkeybutton »

oblio wrote: post #76
unnah wrote: post #61

Earlier quoted context omitted.

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

I understand their reasoning but it's still kind of sad that there's no replacement planned. It would be cool if there was a universal access control platform, but I guess the best we're getting is Docker, because such a platform would commoditize OSes, which OS creators for sure don't want :-(

From an organizational standpoint its better because it lets a sysadmin/security person sandbox anything and everything instead of having to become proficient with the tooling for every different language (which may not even exist).
Post reply on HN