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

71–80 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#71

Post by jijji »

helsinki wrote: post #42
jrockway wrote: post #39

Earlier quoted context omitted.

Security and availability don't have to be mutually exclusive. I remember in the early day of Go modules our Docker builds (that did "go mod download") would be rate-limited by Github, so a local cache was necessary to get builds to succeed 100% of the time. (Yes, you can plumb through some authentication material to avoid this, but Github is slow even when they're not rate limiting you!) Honestly, that thing was fas…

Tangential non-sequitor: > self-hosted on AWS People forgot what self-hosting actually means.

The OP wrote "self-hosted Jenkins", which has a different meaning

Re: Malicious PyPI packages stealing credit cards and injecting code

#72

Post by jimmaswell »

dailyanchovy wrote: post #61
cube00 wrote: post #51

Earlier quoted context omitted.

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…

I've had some success finding the pages or processes I need on a site with virtual assistants, but the design of the website had failed in the first place if I had to resort to that.

Re: Malicious PyPI packages stealing credit cards and injecting code

#73

Post by psanford »

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…

There are plenty of ways you can obfuscate calls to `eval`. `unpickle` is a classic example.

Re: Malicious PyPI packages stealing credit cards and injecting code

#74

Post by You-Are-Right »

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

This is not a solution.

Re: Malicious PyPI packages stealing credit cards and injecting code

#75

Post by NullPrefix »

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.

Well don't be rude, say hi, you never know if it's a person on the other end. In that case it's ok to open up about the current events in your dogs' life.

Re: Malicious PyPI packages stealing credit cards and injecting code

#76

Post by rchaud »

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.

It's a billion-dollar anti-pattern that's been sanitized as "conversational commerce". Several large orgs have Intercom, Drift or other popups infesting their site....by choice!

Re: Malicious PyPI packages stealing credit cards and injecting code

#77

Post by njharman »

tikkabhuna wrote: post #41
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.

We use an artifact server and our build servers are completely airgapped. We know exactly what dependencies are used across the organisation. We can take centralised action against malicious dependencies. I wouldn't bother having one if you're small (<25) people. If you start having a centralised Infosec group, then it starts to become necessary.

Airgaped? Really? Everytime a build happens someone physically moves a Thu drive or some other media too from the build server?

Airgap means not networked, even internally. Not just "blocked" from internet.

Re: Malicious PyPI packages stealing credit cards and injecting code

#78

Post by specialist »

wereHamster wrote: post #66
specialist wrote: post #38

Earlier quoted context omitted.

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 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 only sane regime I've heard for "Agile". Potentially reasonable successor to the era when teams did actual QA & Test.

Sorry, I don't have a handy cite. I advocated for Test Into Prod. Alas, we didn't get very far before our ant farm got another good shake.

Re: Malicious PyPI packages stealing credit cards and injecting code

#79

Post by njharman »

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…

I use CC for everything. Shop tons online, multiple sites . Store my CC on browser and share that across desktop, laptop, ipad and phones.

In last 10 years I've had one incident were CC company did not automatically deny fraud. Two purchases both refunded to me.

Re: Malicious PyPI packages stealing credit cards and injecting code

#80

Post by specialist »

oblio wrote: post #49
specialist wrote: post #38

Earlier quoted context omitted.

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

Java/Spring/Maven should have locked down dependencies by default. They have to go out of their way to not do that. Not that some people don't, anyway. Typos: > I stopped advocating for locking everything down. started? > Look down dependencies. lock?

Edited. Thanks for proofreading my rant. :)
Post reply on HN