Malicious PyPI packages stealing credit cards and injecting code • Hacker News Board

Re: Malicious PyPI packages stealing credit cards and injecting code

#201

Post by jjnoakes » Tue, Aug 03, 2021, 10:17 PM UTC

beefjerkins wrote: post #200

tracker1 wrote: post #183

Earlier quoted context omitted.

This... worked in an org, where it literally took nearly 3 months to get package updates and additions approved... and that was for licensing review, not even proper security audits. It may be safer to just accept that you live in the wild west and have systems boundaries in place to limit exposure/impact. I've been pushing for closed-box logging targets, for example, where all logging goes to at least two systems (l…

I'm trying to wrap my head around the concept of 'pulling' backups, rather than pushing them. In my mind, once you make a backup, you should then transfer it to a separate system for archival. Where am I going wrong?

To pull backups, the backup system connects to the production system and grabs the data, storing it locally on the backup system. To push backups would be for the production system to connect to the backup system and send the data.

The main benefit of pull-based backups is that the production machine doesn't need credentials to write to the backup server; this means if production is compromised, it can't corrupt your backups.

Re: Malicious PyPI packages stealing credit cards and injecting code

#202

Post by progmetaldev » Tue, Aug 03, 2021, 10:27 PM UTC

gruez wrote: post #146

progmetaldev wrote: post #126

Earlier quoted context omitted.

I know in Chrome on Windows, I am asked for my Windows login password if I want to view any saved passwords. Really hope that's not just a "UI" feature, and those passwords really are encrypted.

>Really hope that's not just a "UI" feature, and those passwords really are encrypted. It's definitely a ui feature. If you want to extract the password all you have to do is visit the login page, open the developer console, and type $("input[type=password]").value

I meant more at rest. I think even if you use an extension like LastPass with a policy that the user can't see the password, it's still going to show up in developer tools under the POST.

Re: Malicious PyPI packages stealing credit cards and injecting code

#203

Post by kristianp » Tue, Aug 03, 2021, 10:32 PM UTC

jetrink wrote: post #14

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.

I definitely want to avoid having my credit card details stolen. The inconvenience of calling the bank to report fraudulent transactions and then waiting a few weeks for a replacement card to arrive is something to avoid if you value your time.

I save most passwords in the browser, including discord, but not important things like banks and emails. Password manager for that. I think it's foolish of Chrome to offer to save CC details.

Re: Malicious PyPI packages stealing credit cards and injecting code

#204

Post by cilefen » Tue, Aug 03, 2021, 10:42 PM UTC

wiremine wrote: post #85

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

Feels like this is a business opportunity for someone. Use case: 1. Upload a pre-reviewed package.json file. 2. The service monitors changes, and recommends updates. Recommendations might include security, bug, features, etc. It would check downstream dependencies, too. For production systems, the team might only care about security features. 3. Developer team can review recommendations, and download the new package.…

We use Renovate for this.

Re: Malicious PyPI packages stealing credit cards and injecting code

#205

Post by geofft » Tue, Aug 03, 2021, 10:46 PM UTC

yardstick wrote: post #177

jameshart wrote: post #137

Earlier quoted context omitted.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

Not true. We assess each update in case of high priority issues that need a quick update. Also we are cautious of using dependencies that don’t provide long term support/back fixes - where possible I pick stable, responsibly-managed dependencies. Postgres is a great example, security fixes are applied across multiple major versions, not just the latest.

How do you get informed about whether a high-priority issue exists?

In particular, who is auditing the old version of the code that you happen to be running to make sure it doesn't have vulnerabilities that are now gone after a non-security-motivated change like a refactoring or a feature removal? Probably not the upstream maintainers, who generally only maintain HEAD.

Re: Malicious PyPI packages stealing credit cards and injecting code

#206

Post by geofft » Tue, Aug 03, 2021, 10:55 PM UTC

cesarb wrote: post #187

HALtheWise wrote: post #119

It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…

What you want sounds like the way Java sandboxing worked (commonly seen with Java applets). The privileged classes which do the lower-level operations (outgoing network requests, filesystem access, and so on) ask the Java security code to check whether the calling code has permission to do these operations, and that Java security code throws an exception when they're not allowed.

Yes, and also, this is an extraordinarily complex design to implement and get right. Java more or less failed in contexts where it was expected to actually enforce those boundaries reliably - untrusted applets on the web. It's working great in cases where the entire Java runtime and all libraries are at the same trust level and sandboxing/access control measures, if any, are applied outside the whole process - web servers, unsandboxed desktop applications like Bazel or Minecraft, Android applications, etc. Security vulnerabilities in Java-for-running-untrusted-applets happened all the time; security vulnerabilities that require you to update the JRE on your backend web servers are much rarer.

If you make a security boundary, people are going to rely on it / trust it, and if people rely on it, attackers are going to attack it for real. Making attacks harder isn't enough; some attacker will just figure it out, because there's an incentive for them to do so. It is often safer in practice not to set up the boundary at all so that people don't rely on it.

Re: Malicious PyPI packages stealing credit cards and injecting code

#207

Post by teddyh » Tue, Aug 03, 2021, 11:37 PM UTC

jjnoakes wrote: post #201

beefjerkins wrote: post #200

Earlier quoted context omitted.

I'm trying to wrap my head around the concept of 'pulling' backups, rather than pushing them. In my mind, once you make a backup, you should then transfer it to a separate system for archival. Where am I going wrong?

To pull backups, the backup system connects to the production system and grabs the data, storing it locally on the backup system. To push backups would be for the production system to connect to the backup system and send the data. The main benefit of pull-based backups is that the production machine doesn't need credentials to write to the backup server; this means if production is compromised, it can't corrupt your…

If you can’t trust the production machine to initiate regular backups by itself, why do you trust the production machine to allow the backup server to access the production machine and make backups? In both cases you need an alert system to detect if a production system has not been backed up for too long.

Therefore, a push system is no different than a pull system, provided, of course, that the production system can only make new backups, not write indiscriminately to the backup server (e.g. delete old backups).

Re: Malicious PyPI packages stealing credit cards and injecting code

#208

Post by actually_a_dog » Tue, Aug 03, 2021, 11:38 PM UTC

tracker1 wrote: post #183

jameshart wrote: post #137

Earlier quoted context omitted.

Also introduces that same time delay for getting security patches released by package maintainers into your build pipeline.

This... worked in an org, where it literally took nearly 3 months to get package updates and additions approved... and that was for licensing review, not even proper security audits. It may be safer to just accept that you live in the wild west and have systems boundaries in place to limit exposure/impact. I've been pushing for closed-box logging targets, for example, where all logging goes to at least two systems (l…

Re: backups

Yes, yes, yes!

Not only that, but test your backups! And follow the 3-2-1 rule for any data of any importance: 3 copies in at least 2 different formats and 1 copy located off-site and in a different physical location from the other 2. Be sure to check the integrity of your backups, as well. It doesn't do much good to restore from a corrupted backup.

That all sounds like a lot of work, and an excess of paranoia, but you won't be thinking that when it comes time to restore from those backups. Let's see: pay millions of dollars in ransom anonymously in BTC to hackers who've held your data (and your company!) hostage, or, spend anywhere from a couple of hours to a few days restoring from backups.

It's your call, but, I know which one I would choose if I were the one who gets paged for things like that.

Re: Malicious PyPI packages stealing credit cards and injecting code

#209

Post by actually_a_dog » Tue, Aug 03, 2021, 11:46 PM UTC

specialist wrote: post #198

actually_a_dog wrote: post #170

Earlier quoted context omitted.

This is the way. Also, you should try to update as few things as possible at once, and let your changes "soak" into production for a while before going in all "upgrade ALL the things!" Why? Well, sometimes things that fail take a while to actually start showing you symptoms. Sometimes, the failure itself takes a while to propagate, simply due to the number of servers you have. And, one of these days, cosmic rays, or…

Totally agree. That's why I'm asking if compulsively updating modules is a JavaScript, nodejs, whatever pathos. This team pushed multiple changes to prod per day. And the load balancer with autoscaling is bouncing instances on its own. And, and, and... So resource leaks were being masked. It was only noticed during a lull in work. And then because so many releases had passed, delta debugging was a lot tougher. And th…

I'm gonna toss this grenade out here, just because I don't see a better place to do it lol...

One of the companies I worked at had an incident a couple years before I started, where there were multiple malicious Python libraries being used in the code. For 3 months.

Luckily, the libraries didn't do anything significant except to ping an IP address in China, actually did perform their advertised functionality, didn't exfiltrate any data other than the source IP address on the ping packets, and they were easy to replace once the situation was found out. But, for months, they had servers pinging or attempting to ping somewhere in China.

Oh, and those libraries made it into our internal repos we were using to pin versions with, too.

Beyond being a speecy spicy meatball of a story, the moral here is that you have to constantly be on your guard and verifying every single line of code that goes into your application somehow.

Re: Malicious PyPI packages stealing credit cards and injecting code

#210

Post by jjnoakes » Tue, Aug 03, 2021, 11:51 PM UTC

teddyh wrote: post #207

jjnoakes wrote: post #201

Earlier quoted context omitted.

To pull backups, the backup system connects to the production system and grabs the data, storing it locally on the backup system. To push backups would be for the production system to connect to the backup system and send the data. The main benefit of pull-based backups is that the production machine doesn't need credentials to write to the backup server; this means if production is compromised, it can't corrupt your…

If you can’t trust the production machine to initiate regular backups by itself, why do you trust the production machine to allow the backup server to access the production machine and make backups? In both cases you need an alert system to detect if a production system has not been backed up for too long. Therefore, a push system is no different than a pull system, provided, of course, that the production system can…

> If you can’t trust the production machine to initiate regular backups by itself, why do you trust the production machine to allow access by the backup server?

If production is compromised, you can't trust either.

> Therefore, a push system is no different than a pull system

Not entirely - a push system can DOS the backups much easier than a pull system (filling the disks, say), and a push system requires append-only backups in order to protect against backup corruption. A pull system just requires read-only access into production, which is much more simple to configure, audit, enforce, and maintain (IMO).