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

51–60 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#51

Post by cube00 »

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.

Re: Malicious PyPI packages stealing credit cards and injecting code

#52

Post by oefrha »

helsinki wrote: post #32
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…

FYI - You can overwrite an existing package’s release/version via pip (at least when using Artifactory’s PyPi). Not safe to assume pinning the version ‘freezes’ anything.

No, you cannot overwrite a file on PyPI once uploaded, even if you delete the release first. This policy has been in place for many years.

Re: Malicious PyPI packages stealing credit cards and injecting code

#53

Post by jrockway »

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.

I disagree with that analysis. That basically means running some binary yourself, with the alternative being buying a SaaS product that is hosted by the developer. You may think that "self-hosting" means having your own physical server, but I have never heard anyone else use the expression like that.

Re: Malicious PyPI packages stealing credit cards and injecting code

#54

Post by smallerfish »

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.

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 process is running as the same user.)

Re: Malicious PyPI packages stealing credit cards and injecting code

#55

Post by paulryanrogers »

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.

Meanings can evolve over time. I tend to think of self hosted as installing from code and managing myself, whether on local hardware or remote.

Re: Malicious PyPI packages stealing credit cards and injecting code

#56

Post by rtpg »

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

I mean you can have reproducible builds while being on the upgrade train. `package-lock.json` eixsts for a reason. And the tiny pains of upgrading packages over time mean that then you don't have to deal with gargantuan leaps when that one package has the thing you want and it requires updating 10 other packages because of dependencies.

Node is a special horror because of absolute garbage like babel splitting itself into 100s of plugins and slowly killing the earth through useless HTTP requests instead of just packaging a single thing (also Jon Schlinkert wanting to up his package download counts by making a billion useless micropackages). But hey, you're choosing to use those packages.

I think if you're using them, good to stay up to date. But you can always roll your own thing or just stay pinned. Just that stuff is still evolving in the JS world (since people still aren't super satisfied with the tooling). But more mature stuff is probably fine to stick to forever.

Re: Malicious PyPI packages stealing credit cards and injecting code

#57

Post by globular-toast »

helsinki wrote: post #32
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…

FYI - You can overwrite an existing package’s release/version via pip (at least when using Artifactory’s PyPi). Not safe to assume pinning the version ‘freezes’ anything.

Pip also supports packages hashes so you can be sure you're getting the exact same package that you got last time.

Re: Malicious PyPI packages stealing credit cards and injecting code

#59

Post by nvrspyx »

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?

I think the first typo is actually correct. They're saying that they stopped advocating for it because everyone treated them like they were crazy for doing so.

Re: Malicious PyPI packages stealing credit cards and injecting code

#60

Post by nIHOPp6MQw0f5ut »

prower wrote: post #22
jetrink wrote: post #14

Earlier quoted context omitted.

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.

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.

Privacy (dot) com offers that as a service and you can use their extension to generate a card without leaving the page.
Post reply on HN