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

121–130 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#121

Post by DSingularity »

ozzythecat wrote: post #107
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…

It’s not 100% bullet proof, but it’s safer than pulling any random repos directly from the internet. It’s also good that your business doesn’t have to rely on a third party every time you need to pull down your dependencies and build your software.

Protects you against a dependency being hijacked and retroactively embedding malware in prior versions . Check summing would protect against that without the trouble of manually hosting the dependency.

Re: Malicious PyPI packages stealing credit cards and injecting code

#122

Post by LambdaTrain »

On Windows 10 if I want to view plaintext of stored password in chrome, the password of the currently logged in Windows user will be required. So is password stored and encrypted? Just wondering if the same is done to cc information and if such practice is effective against malware stealing

Re: Malicious PyPI packages stealing credit cards and injecting code

#123

Post by parhamn »

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 was wondering earlier how useful deno's all-or-nothing policies would actually be in the real world. It seems like rules like this (no dep network requests, intranet only, only these ips) are much more useful than "never talk to the web".

For python this probably wont ever be possible given the way the import system works and the patching packages can do.

Re: Malicious PyPI packages stealing credit cards and injecting code

#124

Post by wereHamster »

specialist wrote: post #78
wereHamster wrote: post #66

Earlier quoted context omitted.

Everyone I know uses some form of lock file, and most of the modern programming languages support it. As for upgrading only when absolutely necessary, let's be honest, nothing is absolutely necessary. If the software is old, or slow, or buggy, well dear users you'll just have to deal with it. In my experience however, it's easier to keep dependencies relatively up to date all the time, and do the occasional change th…

How do you deal with regressions? For example, we once upgraded the redis client. One brief revision of the parser submodule had an apparent resource leak. (I can't imagine how...) Causing all of our services to ABEND after a few hours. Because everything is updated aggressively, and there's so many dependencies, we couldn't easily back out changes. -- FWIW, Gilt's "Test Into Production" strategy is the first and onl…

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)

Re: Malicious PyPI packages stealing credit cards and injecting code

#125

Post by tremon »

pornel wrote: post #112
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…

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#126

Post by progmetaldev »

smallerfish wrote: post #54
RL_Quine wrote: post #48

Earlier quoted context omitted.

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.

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…

I know in Chrome on Windows, I am asked for my Windows login password if I want to view any saved passwords. Really hope that's not just a "UI" feature, and those passwords really are encrypted.

Re: Malicious PyPI packages stealing credit cards and injecting code

#127

Post by ncann »

HALtheWise wrote: post #115
ncann wrote: post #104

Earlier quoted context omitted.

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.

Mobile OS security works by clamping down hard on what the local user can do, by severely restricting your freedom on what you can do with your device, to the point where you can't even access most of the device's file system. It works under the assumption and reality that 99% of users out there don't have root access on their phone. At the other side of the spectrum we have PC where we have full freedom to do what we want with just a "sudo" or "run as admin" away but that comes with a price.

Re: Malicious PyPI packages stealing credit cards and injecting code

#128

Post by hggythhdtr »

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…

> That sounds like a lot of work.

My bank has a browser plugin that can create virtual cards with just a few clicks.

> dispute the charges, get a new number. Takes This isn't the case for me, it would take me quite a bit of time over a period of several weeks to update all of the places i use my card if I were using the same number everywhere and it was compromised. I handle a lot of billing. I've had cards compromised at least three times in the past and it's very unpleasant. (for me)

Re: Malicious PyPI packages stealing credit cards and injecting code

#129

Post by balls187 »

MikeKusold wrote: post #106
RL_Quine wrote: post #48

Earlier quoted context omitted.

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.

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#130

Post by polynomial »

yjftsjthsd-h wrote: post #101
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…

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.

Post reply on HN