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

11–20 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#11

Post by tyingq »

codefined wrote: post #8
tyingq wrote: post #7

Earlier quoted context omitted.

Doesn't installing a python package from PyPI (optionally) run some of the code in the package? Like "setup.py" ? I'd take advantage of that if I were injecting malicious code in a module.

Downloading a Python package (as done by scrapers, mirrors and security analysts) does not run setup.py. Only if the module is installed is this run. It's analagous to downloading vs. running an executable.

Ah, sure. Just making the distinction that you don't have to actually use a module within your code. That installing the module, even if you never use it in your own code, runs some of the code in that module.

Re: Malicious PyPI packages stealing credit cards and injecting code

#12

Post by DannyBee »

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…

In the US, CC has, by law, almost no liability for fraud - it's capped at 50 bucks, and is 0 bucks if you report it before it gets used. They are also easily replaced, so i think many wouldn't go as far as you are.

Debit cards are weirder in their liability (and are extracting money from your bank account, which is harder to get back).

If you report them lost/stolen before someone uses them, it's 0 bucks Within 2 days of learning about it, it's 50 bucks. More than 2 days, but less than 60, 500 bucks. More than 60 days - unlimited liability.

So i'd be a lot more careful with debit cards, at least in the US.

(You are never liable on either for unauthorized transactions when your card is not lost/stolen as long as you report them within 60 days)

Re: Malicious PyPI packages stealing credit cards and injecting code

#13

Post by yardstick »

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 has been a bit of a challenge, especially with js & node and quite literally thousands of dependencies for a single library we want to use. In such cases we try avoid the library or look for a static/prepackaged version, but even then I don’t feel particularly comfortable.

I should really start specifying checksums too.

Re: Malicious PyPI packages stealing credit cards and injecting code

#14

Post by jetrink »

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#15

Post by [deleted] »

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…

[deleted]

Re: Malicious PyPI packages stealing credit cards and injecting code

#16

Post by ericpauley »

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…

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

Re: Malicious PyPI packages stealing credit cards and injecting code

#17

Post by fortran77 »

ericpauley wrote: post #16
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…

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

It's nice to have a build machine that can complete a build when it's disconnected from the Internet

Re: Malicious PyPI packages stealing credit cards and injecting code

#18

Post by kawsper »

fortran77 wrote: post #17
ericpauley wrote: post #16

Earlier quoted context omitted.

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

It's nice to have a build machine that can complete a build when it's disconnected from the Internet

How often does that happen?

Re: Malicious PyPI packages stealing credit cards and injecting code

#19

Post by yardstick »

ericpauley wrote: post #16
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…

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

Seems reasonable enough depending on your use case.

In our situation we store our own (private, commercial) artifacts as well as third party ones, so we already need to have a server, and we know our server is configured, maintained & monitored in a secure fashion whereas I have no guarantees with public servers.

Plus our build servers don’t have access out to the internet either, for security. Supply chain attacks like SolarWinds and Kaseya are too common these days.

Edit: Also, our local servers are faster at serving requests, allowing for faster builds, and ensures no issues with broken builds if a public repo went offline or was under attack.

Post reply on HN