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

61–70 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#61

Post by dailyanchovy »

cube00 wrote: post #51
dailyanchovy wrote: post #46

Nice writeup, but the title flashes to '(1) New Message' and back twice a second. That's kind of silly in my opinion, from whom do I expect the message? I assume from the chatbot at the bottom right corner. Even so, to talk to it I would need to grant it access to some personal information. It all ends up leaving a bitter aftertaste. Whatever the message was, why not place it in a block of text somewhere less distrac…

This junk is appearing on more and more web sites, at least this one is clearly a bot. Plenty of sales sites will pretend a human is sending you a message, try and talk back and all of a sudden you're in a queue waiting for a reply. Another anti pattern for web.

Yeah. The sad thing is, I've never used a single chatbot that was actually helpful. I naturally don't go looking for conversations with chatbots, but recently more and more companies decided to shut down their email address. So the only way to resolve an issue is by wither talking to a chatbot and then a person (hopefully), or by phoning them (and I'd rather not).

Some chatbots even refuse to let me talk to a person at all due to a bug (the dutch water utility service). Another asks you to write a message to the human representative and then discards it due to a bug (bol.com).

Re: Malicious PyPI packages stealing credit cards and injecting code

#62

Post by ageofwant »

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#63

Post by oefrha »

rlpb wrote: post #50
geofft wrote: post #3

Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. They say that the packages were downloaded 30,000 times, but automated processes like mirrors can easily inflate this. (As can people doing the exact sort of research they were doing - they themselves downloaded the files from PyPI!) Quoting PyPI maintainer D…

> Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. There's a bigger social problem here. In many communities it has become completely normalized for any dependency to be just added from these types of "anyone can upload" repositories without any kind of due diligence as to provenance or security. It's as if…

> It's now rare for projects to properly audit their dependencies

In the Python ecosystem, it is at least pretty easy to limit yourself to a handful of developers you trust (e.g. Django developers, Pallets developers, etc.).

In the npm ecosystem however, for instance I just ran `npx create-react-app` and got a node_modules with 1044 subdirectories, a 11407-line yarn.lock, and "207 vulnerabilities found" from `yarn audit`. Well what can you possibly do.

Re: Malicious PyPI packages stealing credit cards and injecting code

#64

Post by acdha »

dailyanchovy wrote: post #46

Nice writeup, but the title flashes to '(1) New Message' and back twice a second. That's kind of silly in my opinion, from whom do I expect the message? I assume from the chatbot at the bottom right corner. Even so, to talk to it I would need to grant it access to some personal information. It all ends up leaving a bitter aftertaste. Whatever the message was, why not place it in a block of text somewhere less distrac…

Add these to your hosts file and the page will load a lot faster, too:

   0.0.0.0 js.driftt.com
   0.0.0.0 send.webeyez.com sec.webeyez.com
   0.0.0.0 splitting.peacebanana.com flaming.peacebanana.com

Re: Malicious PyPI packages stealing credit cards and injecting code

#65

Post by cube00 »

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

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#66

Post by wereHamster »

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

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 that goes along with each upgrade, than waiting five years until it's absolutely necessary, at which point upgrading will be a nightmare.

I much rather spend each week 10 minutes reading through the short changelog of 5 dependencies to check that yes, that changes are simple enough that they can be merged without fear, and with the confidence that it's compatible with all the other up-to-date dependencies.

Re: Malicious PyPI packages stealing credit cards and injecting code

#67

Post by pjmlp »

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 have been doing internal repositories and vendoring since 2000, only for personal projects do I do otherwise as they are mostly throw away stuff.

Teaching good security practices and application lifecycle management seems to always be an uphill battle.

Re: Malicious PyPI packages stealing credit cards and injecting code

#68

Post by CivBase »

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 static analysis rule which prevents devs from using `eval()` in the first place.

Re: Malicious PyPI packages stealing credit cards and injecting code

#69

Post by toss1 »

rlpb wrote: post #50
geofft wrote: post #3

Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. They say that the packages were downloaded 30,000 times, but automated processes like mirrors can easily inflate this. (As can people doing the exact sort of research they were doing - they themselves downloaded the files from PyPI!) Quoting PyPI maintainer D…

> Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. There's a bigger social problem here. In many communities it has become completely normalized for any dependency to be just added from these types of "anyone can upload" repositories without any kind of due diligence as to provenance or security. It's as if…

>> if I suggest that a modern web app only use dependencies that ship in Debian (a project that does actually take this kind of thing seriously), many would laugh me out of the building

And you are more right, and they are more wrong than they know.

Not only are malicious inserts in code a problem in themselves, if you have failed to properly vet your dependencies and it causes real losses for one of your users/customers, YOU have created a liability for yourself. Sure, many customers may never figure it out, and it might take them a while to prove it in court, but if it even gets to the point where someone is damaged and notices, and decides to do something about it, you have defense costs.

The "whatever" attitude has no place in serious engineering of any kind, and anyone with a "move fast and break things" attitude (unless these tests are properly sandboxed) shows that they are not engaged in any serious engineering.

Post reply on HN