Live data from Hacker News

Malicious PyPI packages stealing credit cards and injecting code

jfrog.com

191–200 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#191
post #155

Can trusted PyPI packages or other language packages be taken over? Can their author once benevolent become malicious and inject code and push a minor version after they wake up one day?

there once was an adblocker called nano which was open source and quite popular. the developer sold the ownership and the new owners injected malware which was then shipped to all chrome users with the extension.

so i don't see why the same shouldn't work for pypi packages and i also don't understand why noone saw this coming. with how many companies have adopted python there surely will be a security vendor willing to provide free package screening for the repo

Re: Malicious PyPI packages stealing credit cards and injecting code

#192
why don't they start a partnership with a security company like they have with a server monitor and google? many security vendors use python somewhere (1), so I'm sure there would be someone willing to cooperate. scan all packages uploaded and all updates, when there is a detection put a warning on the page and in console put a warning like "this package might contain maliscious code. continue regardless?" so that typosquatting and code hijacking is mitigated

1 https://github.com/KasperskyLab?q=&type=&language=python&sor...

https://github.com/CrowdStrike?q=&type=&language=python&sort...

https://github.com/intezer?q=&type=&language=python&sort=

Re: Malicious PyPI packages stealing credit cards and injecting code

#193
post #95

Earlier quoted context omitted.

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 get notifications every other week about my NodeJS packages having security vulnerabilities, and so I upgrade. I'm not sure why NodeJS devs are so bad at security compared to say C++ devs. It's not like I'm getting asked to upgrade libstdc++ and eigen all the time ...

I’m not going to get into barriers for entry and what kind of developer chooses which language, but C/C++ has always eschewed having unnecessary dependencies (originally because dependency management is hard, but that’s no longer the real reason - it’s just become baked into the culture). Even if you copy and paste hundreds of lines of code (or individual source files) the way you think about and treat them is very different from when they are external to your code base. You own (your copy of) them now, and at the very least, you familiarize yourself with their internals (and you wouldn’t copy and paste something that had its own dependencies). Actual (dynamically linked) dependencies don’t export objects with super brittle interfaces so much as they do expose very stable, carefully designed, and as minimal as possible boundaries for interfacing with their internals. Anything crossing API boundaries is considered leaving/entering the trusted domain, and lifespans of pointers and references in a non-garbage collected language guide/force you to eschew incorporating external libraries into your code globally and isolate the interaction (and therefore, the attack surface area) between your code and external code.

Then there’s the type system. Despite having some of the weakest type systems of strongly types languages, C (to some extent) and C++ (especially modern C++) are still light years ahead of what even Typescript buys you because they don’t offer the same escape hatches or “fingers crossed this TS interface matches the JS object that we are binding it to, but two lines from here, no one will remember that this isn’t actually a native TS class and that this non-nullable field might actually be null because the compile-time type checking system can’t verify this even at runtime without manual user validation because the MS TS team refuses to transpile type validation because they insist on zero overhead even though JS is not a low level or systems language.”

More than anything else however, developers of statically typed languages tend to fundamentally disagree with the idea of “move fast and break often” and will put off changes for years if they’re not at least 90% sure it’s the correct solution (and even when they end up wrong, it’s still far better than someone that says “who cares if it’s the or even just an actually correct solution, it’s still a solution and we can always revisit this later”).

Re: Malicious PyPI packages stealing credit cards and injecting code

#194
post #125
post #112

Earlier quoted context omitted.

Own hosting, pinning, and checksum checks are defenses against network-based attacks and compromise of the package repository. They do nothing against trojans like these. You will be running your own pinned checksummed version of the malicious code. If you want to stop malware published by the legitimate package author, you need to review the code you're pulling in and/or tightly sandbox it (and effective sandboxing…

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.

And you should run an antivirus in the repository machine. It will be really slow, but will eventually catch these malicious libs.

Re: Malicious PyPI packages stealing credit cards and injecting code

#195

Earlier quoted context omitted.

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?

Just that it isn't as simple as adding the lines to when the code gets executed. I think I misunderstood you, instead of prepending the code you are suggesting the entire compromised package get replaced with `throw "You got Hacked"` at import time.

Re: Malicious PyPI packages stealing credit cards and injecting code

#196

Earlier quoted context omitted.

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

`npm yeet malcious-package`

Re: Malicious PyPI packages stealing credit cards and injecting code

#197

Earlier quoted context omitted.

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

Just that it isn't as simple as adding the lines to when the code gets executed. I think I misunderstood you, instead of prepending the code you are suggesting the entire compromised package get replaced with `throw "You got Hacked"` at import time.

Correct, when the program starts to run and imports the modules, as nothing will make admins more aware that something is really wrong here. Maybe raise an exception which, if not handled, executes sys.exit() with a predefined code.

And some mechanism to detect this at install/build time as well, so that automated built systems can cleanly abort a build and issue a specific message which can then be forwarded via email or SMS through some custom code.

The entire package gets replaced by a standardized, friendly one. No harmful code gets downloaded.

Re: Malicious PyPI packages stealing credit cards and injecting code

#198

Earlier quoted context omitted.

When I see a regression, I look at what was recently updated (in the past hours, days), and it's usually one of those packages. Because frequent updates tend to be independent, it's usually not difficult to revert that change (eg. if I update react and lodash at the same time, chances are really good that I can revert one of those changes independently without any issues)

This is the way. Also, you should try to update as few things as possible at once, and let your changes "soak" into production for a while before going in all "upgrade ALL the things!" Why? Well, sometimes things that fail take a while to actually start showing you symptoms. Sometimes, the failure itself takes a while to propagate, simply due to the number of servers you have. And, one of these days, cosmic rays, or…

Totally agree. That's why I'm asking if compulsively updating modules is a JavaScript, nodejs, whatever pathos.

This team pushed multiple changes to prod per day. And the load balancer with autoscaling is bouncing instances on its own. And, and, and...

So resource leaks were being masked. It was only noticed during a lull in work.

And then because so many releases had passed, delta debugging was a lot tougher. And then because nodejs & npm has a culture of one module per line of source (joking!), figuring out which module to blame took even more time.

I think continuous deploys are kinda cool. But not without a safety net of some sort.

Re: Malicious PyPI packages stealing credit cards and injecting code

#199

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 tend to assume OSS contributors/maintainers are working generally to make things better, features I'm not using/don't need aside, they're fixing bugs (that I might not know I'm hitting/about to hit), patching security holes, etc. - so that's one for the 'pro-upgrading' column.

Against that, sure, there might be something bad in the new release (maliciousness aside even, there might be a new bug!). But.. there might be in the old one I've pinned to as well? Assuming I'm not vetting everything (because how many places are, honestly) I have no reason to distrust the new version any more than my current one.

Reproducible builds are an orthogonal issue? You can still keep your dependencies' versions updated with fully reproducible builds. Ours aren't, but we do pin to specific versions (requirements.txt & yarn.lock), and keep the former up to date with pyup (creates and tests a branch with the latest version) and up to date within semver minor versions just with yarn update (committed automatically since in theory it should be safe, had to revert only occasionally).

Re: Malicious PyPI packages stealing credit cards and injecting code

#200

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…

I'm trying to wrap my head around the concept of 'pulling' backups, rather than pushing them. In my mind, once you make a backup, you should then transfer it to a separate system for archival.

Where am I going wrong?

Post reply on HN