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

Malicious PyPI packages stealing credit cards and injecting code

jfrog.com

Post reply on HN
Print view View original

181–190 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#181

Post by cesarb »

watermelon0 wrote: post #149
oblio wrote: post #49

Earlier quoted context omitted.

Java/Spring/Maven should have locked down dependencies by default. They have to go out of their way to not do that. Not that some people don't, anyway. Typos: > I stopped advocating for locking everything down. started? > Look down dependencies. lock?

AFAIK Maven and Gradle don't have any built-in way of locking down dependencies (direct or transient), unless I missed something.

In my experience, Maven always uses the exact version specified in your pom.xml (and the pom.xml of your dependencies, transitively), it never uses a newer version automatically. That is, the built-in way in Maven is locked down dependencies.

Re: Malicious PyPI packages stealing credit cards and injecting code

#182

Post by RulerOf »

tylfin wrote: post #160
qwertox wrote: post #150

I don't think that it's good to just delete the packages. Same goes for Android Apps in the Google Play Store or for Chrome Extensions. These compromised packages should have their page set to a read-only mode with downloads/installs disabled, with a big warning that they were compromised. This is specially troublesome with Chrome Extensions and Android Apps, where it is not possible to get to know if I actually had…

There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research. https://www.python.org/dev/peps/pep-0592/

Skimming through that link, it seems that `yank` is for pulling _broken_ packages, whereas the suggestion above is to explicitly mark them as malicious.

Re: Malicious PyPI packages stealing credit cards and injecting code

#183

Post by tracker1 »

jameshart wrote: post #137
tremon wrote: post #125

Earlier quoted context omitted.

Well, it does induce a timed delay between upstream release of a compromised package and when it enters the own codebase. As long as the exploit is found and published before someone manually uploads it to the local store, you're safe. But yes, a better option would be to run your own acceptance tests on each new upstream release, and that includes profiling disk/network/cpu usage across different releases.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

This... worked in an org, where it literally took nearly 3 months to get package updates and additions approved... and that was for licensing review, not even proper security audits.

It may be safer to just accept that you live in the wild west and have systems boundaries in place to limit exposure/impact.

I've been pushing for closed-box logging targets, for example, where all logging goes to at least two systems (local and remote) so that the logging target is generally only available to submit log lines entries to. Not perfect, but where my head has been at.

Another thing is to PULL backups, not push them out.

Re: Malicious PyPI packages stealing credit cards and injecting code

#184

Post by rexelhoff »

yardstick wrote: post #177
jameshart wrote: post #137

Earlier quoted context omitted.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

Not true. We assess each update in case of high priority issues that need a quick update. Also we are cautious of using dependencies that don’t provide long term support/back fixes - where possible I pick stable, responsibly-managed dependencies. Postgres is a great example, security fixes are applied across multiple major versions, not just the latest.

Sounds exactly like what we do for medical device software.

Version pinning, self-managed forks and code reviews of the dependency on upgrade.

Re: Malicious PyPI packages stealing credit cards and injecting code

#185

Post by paulddraper »

specialist wrote: post #38
yardstick wrote: post #13

This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…

I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…

For quite a while now, the JS ecosystem has used lock files -- npm, yarn, pnpm. You have to got out of your way not to pin JS dependencies.

Re: Malicious PyPI packages stealing credit cards and injecting code

#186

Post by blamestross »

RulerOf wrote: post #182
tylfin wrote: post #160

Earlier quoted context omitted.

There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research. https://www.python.org/dev/peps/pep-0592/

Skimming through that link, it seems that `yank` is for pulling _broken_ packages, whereas the suggestion above is to explicitly mark them as malicious.

Should we call the "mark them malicious" version "Yeet" or "Yoink"?

Re: Malicious PyPI packages stealing credit cards and injecting code

#187

Post by cesarb »

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

What you want sounds like the way Java sandboxing worked (commonly seen with Java applets). The privileged classes which do the lower-level operations (outgoing network requests, filesystem access, and so on) ask the Java security code to check whether the calling code has permission to do these operations, and that Java security code throws an exception when they're not allowed.

Re: Malicious PyPI packages stealing credit cards and injecting code

#188

Post by blamestross »

gunapologist99 wrote: post #178
tylfin wrote: post #160

Earlier quoted context omitted.

There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research. https://www.python.org/dev/peps/pep-0592/

Even better would be allow their install, but to have them start up with an immediate panic() sort of function (i.e., print("This package has been found to be malicious; please see pypi/evilpackagename for details"); sys.exit(99)) to force aborts of any app using those packages.

python packages run arbitrary code at install/build time, so this isn't viable.

Re: Malicious PyPI packages stealing credit cards and injecting code

#189

Post by jacquesm »

tracker1 wrote: post #183
jameshart wrote: post #137

Earlier quoted context omitted.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

This... worked in an org, where it literally took nearly 3 months to get package updates and additions approved... and that was for licensing review, not even proper security audits. It may be safer to just accept that you live in the wild west and have systems boundaries in place to limit exposure/impact. I've been pushing for closed-box logging targets, for example, where all logging goes to at least two systems (l…

> Another thing is to PULL backups, not push them out.

That's an absolute must. A push backup may not be a backup at all when you need it, or it may be compromised. It also requires the system you push into to be accessible for inbound connections, which in itself may be problematic.

Re: Malicious PyPI packages stealing credit cards and injecting code

#190

Post by qwertox »

blamestross wrote: post #188
gunapologist99 wrote: post #178

Earlier quoted context omitted.

Even better would be allow their install, but to have them start up with an immediate panic() sort of function (i.e., print("This package has been found to be malicious; please see pypi/evilpackagename for details"); sys.exit(99)) to force aborts of any app using those packages.

python packages run arbitrary code at install/build time, so this isn't viable.

It's no longer arbitrary if the PyPI crew is the one who controls the code, or did I understand you wrong?
Post reply on HN