I submitted this link: https://thehackernews.com/2021/07/several-malicious-typosqua...
https://news.ycombinator.com/item?id=28022035
3 days ago and it was killed, I wonder why?...
Malicious PyPI packages stealing credit cards and injecting code
211–220 of 230 posts
Re: Malicious PyPI packages stealing credit cards and injecting code
#212Earlier 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…
> Another thing is to PULL backups, not push them out. That's an absolute must. A push backup may not be a backup at all when you need it, or it may be compromised. It also requires the system you push into to be accessible for inbound connections, which in itself may be problematic.
Really once the secure channel between two processes running on each host is setup, there is no difference between the two methods.
A pull backup can be tricked just as easily by presenting a false filesystem or backdooring the 'pull process' running on the compromised machine.
You want append only backups with secure timestamps and do forensics to find the last good snapshot. It is easier to set that up with pull backups, but not so hard with the right tools for push backups.
Re: Malicious PyPI packages stealing credit cards and injecting code
#213how to check if any of these packages are installed on a system? It seems like python (mac version, various homebrew versions) writes packages all over the place, from user-local dirs, to /usr/local etc.
Re: Malicious PyPI packages stealing credit cards and injecting code
#214Earlier quoted context omitted.
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…
Also, you really ought to not allow egress from your servers except to your load balancer.
Just attempting should create alarms.
Re: Malicious PyPI packages stealing credit cards and injecting code
#215Earlier quoted context omitted.
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…
Also, you really ought to not allow egress from your servers except to your load balancer. Just attempting should create alarms.
Correct. That's probably actually why it took so long to detect the malicious packages: when the got installed on machines running internal services, nothing much unexpected happened. Come to think of it, I actually don't remember how the packages were detected and identified to begin with.
Re: Malicious PyPI packages stealing credit cards and injecting code
#216Earlier 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…
> Another thing is to PULL backups, not push them out. That's an absolute must. A push backup may not be a backup at all when you need it, or it may be compromised. It also requires the system you push into to be accessible for inbound connections, which in itself may be problematic.
Another option is to use a cloud storage service that supports fine grained access control (e.g. write-only vs read-only) and retention polices.
Re: Malicious PyPI packages stealing credit cards and injecting code
#217Earlier quoted context omitted.
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.
Security mailing lists. GitHub has security alerts. Good old fashioned RSS. For example, rubygems.org supports RSS for releases. GitHub Release pages also support RSS. An easy way to create a shared RSS feeds is to create a #news channel in Slack that has all the feeds.
It can be a pain but that pain might be motivation to not pull in dependencies with little thought.
Re: Malicious PyPI packages stealing credit cards and injecting code
#218Earlier quoted context omitted.
Even better would be allow their install, but to have them start up with an immediate panic() sort of function (i.e., print("This package has been found to be malicious; please see pypi/evilpackagename for details"); sys.exit(99)) to force aborts of any app using those packages.
python packages run arbitrary code at install/build time, so this isn't viable.
.whl packages don't run arbitrary code, they're just zips.
Re: Malicious PyPI packages stealing credit cards and injecting code
#219Earlier quoted context omitted.
Just that it isn't as simple as adding the lines to when the code gets executed. I think I misunderstood you, instead of prepending the code you are suggesting the entire compromised package get replaced with `throw "You got Hacked"` at import time.
Correct, when the program starts to run and imports the modules, as nothing will make admins more aware that something is really wrong here. Maybe raise an exception which, if not handled, executes sys.exit() with a predefined code. And some mechanism to detect this at install/build time as well, so that automated built systems can cleanly abort a build and issue a specific message which can then be forwarded via ema…
Denial of Service by panicing is also harmful for some processes.