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

171–180 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#171

Post by trepatudo »

brianwawok wrote: post #26
prower wrote: post #22

Earlier quoted context omitted.

Some online banks (don't know how widespread this is) allow you to create "virtual card" that expire either after 1 purchase or at a specific date (and with a set maximum of budget). I use them for every single purchase I make online, it's inconvenient but at least i've never entered my real card info anywhere.

That sounds like a lot of work. At least in the US you are not responsible for fraud. (I think the law may have like a $50 liability thing, but Visa/MC waive). So it's better to just not do this, and every 3-4 years when my CC is stolen, call them up - dispute the charges, get a new number. Takes For what it's worth, the 2 times my number got stolen in the last 6 years, one was from a rogue agent at a hotel in Chicag…

In Portugal, you basically open the app, scan fingerprint to give permission and get a new card.

You can even scan the card via webcam or copy the details to clipboard.

The virtual card also limits itself either to single transaction or single store so it can't be used even if compromised on store level.

It's pretty simple process (<30sec) and it's really useful.

Re: Malicious PyPI packages stealing credit cards and injecting code

#172

Post by blibble »

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…

namedtuple used exec()

(I've also used exec() for some nasty bundling of multiple python files into one before)

Re: Malicious PyPI packages stealing credit cards and injecting code

#173

Post by blibble »

balls187 wrote: post #129
MikeKusold wrote: post #106

Earlier quoted context omitted.

On Mac, you could store the master key in the Keychain. I've been off of Windows for almost a decade so I'm not sure if they have a similar feature. > Keychain items can be shared only between apps from the same developer. https://support.apple.com/guide/security/keychain-data-prote...

Windows doesn't have a system level key store. Instead the Windows API's have a symmetric encryption API (DPAPI) that allows developers to supply plain text, and receive cipher text. It would then be up to developers to persist the cipher text. DPAPI master key is protected by the OS, behind User Credentials.

isn't it per user though, instead of per developer (like apple)?

a dodgy pypi package that can call CryptUnprotectData too

Re: Malicious PyPI packages stealing credit cards and injecting code

#174

Post by dhosek »

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…

I've been thinking about this a lot as I consider the scripting language for finl.¹ I had considered an embedded python, but ended up deciding it was too much of a security risk, since, without writing my own python interpreter (something I don't want to do), sandboxing seems to be impossible. Deno is a real possibility or else forking Boa which is a pure Rust implementation of JS.

1. One thing I absolutely do not want to do is replicate the unholy mess that's the TeX macro system. There will be simple macro definitions possible, but I don't plan on making them Turing complete or having the complex expansion rules of TeX.

Re: Malicious PyPI packages stealing credit cards and injecting code

#175

Post by at_a_remove »

I have some pretty complex feelings about this.

Many people end up at a given programming language because they are fleeing something else, rather than being necessarily drawn to it, and I know that in some senses, Python was my reaction to having to deal with what I didn't like about Perl. One of the larger factors was dealing with CPAN. I was always having to hunt down modules, which would do maybe seventy percent of what I needed, or a another module, that would cover a different seventy percent. And then comes the question of, "Can I get this to run on Windows?"

Meanwhile, Python made hay with its enormous standard library and certainly xkcd made many references to it. Now people tell me that the standard library is where code goes to die and I get sad all over again ...

Re: Malicious PyPI packages stealing credit cards and injecting code

#176

Post by dhosek »

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…

What I like about the Mac implementation of storing credit cards is that it requires using touch ID to autofill the credit card info. There's no autofill without explicit user interaction.

Re: Malicious PyPI packages stealing credit cards and injecting code

#177

Post by yardstick »

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.

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#178

Post by gunapologist99 »

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/

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#179

Post by yardstick »

polynomial wrote: post #130
yjftsjthsd-h wrote: post #101

Earlier quoted context omitted.

Sorry, I don't quite see how this would protect against supply chain attacks. If an upstream dependency is back-doored, they just have to silently add their code in an otherwise reasonable sounding release, and now you will happily download that version, add it to your internal mirrors, and pin its version forever. Unless you actually read the diff on every update, which I think is impractical (although you're welcom…

My read was GP is implying they do read the diff every time, and only change the pinned version after a manual review- "only after we are happy." This does seem impractical at even a modest scale.

We periodically review all dependencies change logs, security advisories etc and update based on risk review. We also keep an eye out for critical vulnerabilities that need immediate patching. There are tools to help with this, plus communities like HN are relevant for breaking news.

Re: Malicious PyPI packages stealing credit cards and injecting code

#180

Post by gunapologist99 »

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

All your Pythons are belonging to us
Post reply on HN