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

31–40 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#31

Post by dane-pgp »

tyingq wrote: post #7
geofft wrote: post #3

Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. They say that the packages were downloaded 30,000 times, but automated processes like mirrors can easily inflate this. (As can people doing the exact sort of research they were doing - they themselves downloaded the files from PyPI!) Quoting PyPI maintainer D…

Doesn't installing a python package from PyPI (optionally) run some of the code in the package? Like "setup.py" ? I'd take advantage of that if I were injecting malicious code in a module.

For what it's worth, npm supports an option "ignore-scripts" for both "npm install" and "npm ci" (the latter of which ensures the installed packages match the integrity hashes from the package-lock.json file).

https://docs.npmjs.com/cli/v7/commands/npm-install/#ignore-s...

https://docs.npmjs.com/cli/v7/commands/npm-ci/#ignore-script...

Re: Malicious PyPI packages stealing credit cards and injecting code

#32

Post by helsinki »

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…

FYI - You can overwrite an existing package’s release/version via pip (at least when using Artifactory’s PyPi). Not safe to assume pinning the version ‘freezes’ anything.

Re: Malicious PyPI packages stealing credit cards and injecting code

#33

Post by the_only_law »

williamdclt wrote: post #30
legrande wrote: post #9

> The second payload of the noblesse family is an “Autocomplete” information stealer. All modern browsers support saving passwords and credit card information for the user: > Browser support for saving passwords and credit card information > This is very convenient, but the downside is that this information can be leaked by malicious software that got access to the local machine. I never store CC deets anywhere, not…

I've been thinking I should probably just memorising my card number. Would take a bit of effort but can't be much harder than memorising a phone number, and possibly faster than entering my master password to unlock my password manager

I’ve done it a number of times without even trying. Problem is if you have to replace it a lot.

Re: Malicious PyPI packages stealing credit cards and injecting code

#35

Post by Majestic121 »

codefined wrote: post #8
tyingq wrote: post #7

Earlier quoted context omitted.

Doesn't installing a python package from PyPI (optionally) run some of the code in the package? Like "setup.py" ? I'd take advantage of that if I were injecting malicious code in a module.

Downloading a Python package (as done by scrapers, mirrors and security analysts) does not run setup.py. Only if the module is installed is this run. It's analagous to downloading vs. running an executable.

Doing a pip install actually runs the setup.py of the package for source dist, which means running an executable.

It's not the case for wheels though, so you can protect yourself by restricting to binary : --only-binary.

Also doing a pip download is not sensible to this issue, but most people do pip install

Re: Malicious PyPI packages stealing credit cards and injecting code

#36

Post by grincho »

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…

Yes, this is why I implemented hash-checking in pip (https://pip.pypa.io/en/stable/topics/repeatable-installs/#ha...). Running your own server is certainly another way to solve the problem (and lets you work offline), but keeping the pinning info in version control gives you a built-in audit trail, code reviews, and one fewer server to maintain.

Re: Malicious PyPI packages stealing credit cards and injecting code

#38

Post by specialist »

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. (I can't even comment on Python projects; I was just happy when I could get them to run.)

What's going on? FOMO?

Lock ~~Look~~ down dependencies. Only upgrade when absolutely necessary. Keep things simple to facilitate catching regression bugs and such.

Oh well. I moved on. I don't miss it one bit.

Re: Malicious PyPI packages stealing credit cards and injecting code

#39

Post by jrockway »

ericpauley wrote: post #16
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…

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

Security and availability don't have to be mutually exclusive. I remember in the early day of Go modules our Docker builds (that did "go mod download") would be rate-limited by Github, so a local cache was necessary to get builds to succeed 100% of the time. (Yes, you can plumb through some authentication material to avoid this, but Github is slow even when they're not rate limiting you!) Honestly, that thing was faster than the official Go Module Proxy so I kept it around longer than necessary and the results were good.

Even if you cache modules on your own infrastructure, you should still validate the checksums to prevent insiders from tampering with the cached modules.

I'll also mention that any speed increases really depend on your CI provider. I self-hosted Jenkins on a Rather Large AWS machine, and had the proxy nearby, so it was fast. But if you use a CI provider, they tend to be severely network-limited at the node level and so even if you have a cache nearby, you are still going to download at dialup speeds. (I use CircleCI now and at one point cached our node_modules. It was as slow as just getting them from NPM. And like, really slow... often 2 minutes to download, whereas on my consumer Internet connection it's on the order of 10 seconds. Shared resources... always a disaster.)

Re: Malicious PyPI packages stealing credit cards and injecting code

#40

Post by toyg »

terom wrote: post #37

http://webcache.googleusercontent.com/search?q=cache%3Ahttps... Google cache still has the malicious package visible FWIW > This Module Optimises your PC For Python

> This Module Optimises your PC For Python

Well, it does... just not for your Python...

Post reply on HN