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

111–120 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#111

Post by bastardoperator »

jetrink wrote: post #14
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…

Credit cards are insecure by design and worrying about having them stolen from your browser or vault is not worth it in my opinion. You're far more likely to have it compromised from the retailer side no matter how careful you are. Also, it's easy to set up a notification on your phone for every time a card is used, so you can report fraud before any harm is done.

Exactly this. I just assume my credit card will be stolen or leaked. Nearly every credit card has zero liability protection too so there is no use in worrying, this is why I use credit cards.

Re: Malicious PyPI packages stealing credit cards and injecting code

#112

Post by pornel »

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…

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 is usually impossible for dependencies running in your own process).

Re: Malicious PyPI packages stealing credit cards and injecting code

#113

Post by banana_giraffe »

CivBase wrote: post #68

I wonder how many Python packages have a justifiable reason for using `eval()` to begin with. I've been writing Python professionally for almost a decade and I've never run into a use case where it has been necessary. It's occasionally useful for debugging, but that's all I've ever legitimately considered it for. It's neat that JFrog can detect evaluation of encoded strings, but I think I'd prefer to just set a stati…

You can always call eval without ever mentioning eval in code:

    __builtins__.__dict__[''.join(chr(x^y^(i+33)) for i,(x,y) in enumerate(zip(*[iter(ord(z) for z in '2vb63qz2')]*2)))]("print('hello, world')")
Maybe there are ways to detect all of the paths, but it feels like a tricky quest down lots of rabbit holes to me.

There are also some fairly big packages that use eval(), like flask, matplotlib, numba, pandas, and plenty of others. Perhaps they could be modified to not use eval, but it might be more common than you expect.

Re: Malicious PyPI packages stealing credit cards and injecting code

#115

Post by HALtheWise »

ncann wrote: post #104
smallerfish wrote: post #54

Earlier quoted context omitted.

Right, but I wouldn't have expected that processes outside of chrome could get at its internally managed db (or encrypted properties), especially if it's using an authenticated (chrome) user profile. Windows doesn't have any application firewalls by default? I thought that was the whole thing that came in with Vista that people were upset about. (Of course, thinking it through, Linux isn't any better, assuming the pr…

If you have untrusted code running on your computer, especially with admin privilege, then it's already game over no matter what you do. Any kind of stored secret can be extracted, and any kind of typed in secret can be keylogged.

This was definitely true a decade ago, but secure elements in processors have opened up all sorts of options. Unfortunately, taking advantage of those is one place where mobile operating systems are far ahead of desktops.

Re: Malicious PyPI packages stealing credit cards and injecting code

#116

Post by TheFreim »

bastardoperator wrote: post #111
jetrink wrote: post #14

Earlier quoted context omitted.

Credit cards are insecure by design and worrying about having them stolen from your browser or vault is not worth it in my opinion. You're far more likely to have it compromised from the retailer side no matter how careful you are. Also, it's easy to set up a notification on your phone for every time a card is used, so you can report fraud before any harm is done.

Exactly this. I just assume my credit card will be stolen or leaked. Nearly every credit card has zero liability protection too so there is no use in worrying, this is why I use credit cards.

Liability and protection provided by credit cards is one of the reasons some people suggest using them and never using a debit card. Easier to get money back if it gets stolen from a credit card (assuming some YouTube video I saw was accurate).

Re: Malicious PyPI packages stealing credit cards and injecting code

#117

Post by TheFreim »

toyg wrote: post #40
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...

Our python

Re: Malicious PyPI packages stealing credit cards and injecting code

#118

Post by tikkabhuna »

njharman wrote: post #77
tikkabhuna wrote: post #41

Earlier quoted context omitted.

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.

Airgaped? Really? Everytime a build happens someone physically moves a Thu drive or some other media too from the build server? Airgap means not networked, even internally. Not just "blocked" from internet.

Wikipedia[1] offers a slightly relaxed definition, although I agree, I (and my colleagues) abuse the term.

The artifact repository server connects to the internet via a proxy. Build servers have no access to the internet.

[1] https://en.wikipedia.org/wiki/Air_gap_(networking)

Re: Malicious PyPI packages stealing credit cards and injecting code

#119

Post by HALtheWise »

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 everything it calls or eval()'s. Of course, it would still be possible to make malware that exfiltrates data through other channels, but it would be a lot harder.

I am not aware of any languages or ecosystems that do this, so maybe there's some reason this won't work that I'm not thinking of.

Re: Malicious PyPI packages stealing credit cards and injecting code

#120

Post by mikepurvis »

goodpoint wrote: post #93
Nursie wrote: post #87

Earlier quoted context omitted.

This is how it always used to be, back in the before[1] times. Libraries would be selected carefully and dependencies would be kept locally so that you could always reproduce a build. The world is different now, and just being able to select a package and integrate it like that is a massive effectiveness multiplier, but I think the industry at large lost something in the transition. ([1] before internet package manag…

> I think the industry at large lost something in the transition. Lost a lot of trust and security with the advent of language-specific installers that pull libraries and their dependencies from random URLs without any 3rd party vetting.

I agree, though I think there are a couple pieces to the puzzle. Like, quite apart from the enormous convenience of new releases being available right away, and even being able to drop in a git URL and run your dependency off a branch while you wait for your upstream PR to merge, pip provides isolation between workspaces that apt has never been able to do natively because it's too generic— the closest thing is lightweight unshares, but those were years after virtualenv, require more ceremony to get going with, and may be isolated from the outside system in ways that impede productivity (there's also never really been a consistent tooling story for it, with having to cobble together debootstrap + whatever the chroot flavor of the week is).

But the biggest issue is when npm, cargo, etc showed how to include a dependency multiple times at different versions. Operating system package managers (other than Nix & friends) have no concept for how this could or would work. Pip has no story for it, and the various pip-to-apt bridges like py2deb and stdeb if anything just exacerbate the problem, by mixing your project's dependencies with those on your system.

Anyway, yes. Things were lost, 100%. But I don't think the system you want (isolation, version freedom, but with safe/vetted packages) is going to be something that's possible to evolve out of any of the current systems. It's got to be something that goes back to first principles.

Post reply on HN