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

221–230 of 230 posts

Re: Malicious PyPI packages stealing credit cards and injecting code

#221

Post by qwertox »

corty wrote: post #219
qwertox wrote: post #197

Earlier quoted context omitted.

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.

It's not like an already running process will be affected by this.

This would only occur when the package gets updated or reinstalled, which shouldn't happen without supervision if the program is running in a sensitive context.

Else a Denial of Service is a good last resort measure in order to prevent running a malicious service. Ideally this gets detected at install/build time.

Re: Malicious PyPI packages stealing credit cards and injecting code

#222

Post by geofft »

zomgwat wrote: post #217
geofft wrote: post #205

Earlier quoted context omitted.

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.

Again, how does any of that tell you whether a high-priority issue exists in the old version of the code that you're running, as opposed to in the latest release?

Re: Malicious PyPI packages stealing credit cards and injecting code

#223

Post by oauea »

kawsper wrote: post #220
oauea wrote: post #28

Earlier quoted context omitted.

https://hn.algolia.com/?q=cloudflare+down https://hn.algolia.com/?q=akamari+down https://hn.algolia.com/?q=github+down

I don't see how any of those are build machines that are offline.

Build machines generally want to be 'online' so they can connect to the internet. They want to connect to the internet so they can access services hosted on the internet. Many of those services use Cloudflare, Akamari or Github. If any of those are down, those services are down. Now it's great that your build machine is online, but the packages it's trying to fetch won't be available because their CDN is offline.

Now if only you had a local caching proxy.

Re: Malicious PyPI packages stealing credit cards and injecting code

#224

Post by zomgwat »

geofft wrote: post #222
zomgwat wrote: post #217

Earlier quoted context omitted.

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.

Again, how does any of that tell you whether a high-priority issue exists in the old version of the code that you're running , as opposed to in the latest release?

I understand your point. I'd expect the old version to have been reviewed when it was introduced into the system just as the new version should be. Of course, that doesn't guarantee something won't slip in.

Running private package infrastructure with audited dependencies isn't a panacea to stopping supply chain attacks. I do believe it's an effective defense-in-depth tactic for the reasons others have discussed.

An additional supporting tactic that should be done is to tightly control egress traffic. Like ingress traffic, all egress traffic should be denied by default. From there, traffic should be whitelisted. That makes it more difficult to exfiltrate data or communicate with command and control infrastructure. Tight control on egress traffic also makes it easier to alert on unexpected connection attempts. That all said, locking down egress traffic can be a pain. It also isn't a panacea. Where there’s a will there’s a way.

Re: Malicious PyPI packages stealing credit cards and injecting code

#225

Post by vagrantJin »

blamestross wrote: post #186
RulerOf wrote: post #182

Earlier quoted context omitted.

Skimming through that link, it seems that `yank` is for pulling _broken_ packages, whereas the suggestion above is to explicitly mark them as malicious.

Should we call the "mark them malicious" version "Yeet" or "Yoink"?

Good point. The keyword for uninstall and remove residual files should be Yeet indeed.

Downloading the latest, bleeding edge version should be Yoked

pip install yoked

Re: Malicious PyPI packages stealing credit cards and injecting code

#226

Post by balls187 »

blibble wrote: post #173
balls187 wrote: post #129

Earlier quoted context omitted.

Windows doesn't have a system level key store. Instead the Windows API's have a symmetric encryption API (DPAPI) that allows developers to supply plain text, and receive cipher text. It would then be up to developers to persist the cipher text. DPAPI master key is protected by the OS, behind User Credentials.

isn't it per user though, instead of per developer (like apple)? a dodgy pypi package that can call CryptUnprotectData too

Per login credential, yes.

Re: Malicious PyPI packages stealing credit cards and injecting code

#227

Post by blibble »

balls187 wrote: post #226
blibble wrote: post #173

Earlier quoted context omitted.

isn't it per user though, instead of per developer (like apple)? a dodgy pypi package that can call CryptUnprotectData too

Per login credential, yes.

so that's essentially useless against this sort of attack?

Re: Malicious PyPI packages stealing credit cards and injecting code

#229

Post by ASalazarMX »

mathattack wrote: post #81
wereHamster wrote: post #66

Earlier quoted context omitted.

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…

Both extremes are bad. If you never change anything, you are left behind on a lot of security updates and bug fixes. The longer you wait the harder it is to move. The “stay current” model comes with risks too. It’s just a matter of figuring out which manner has the better value to risk trade off, and how to mitigate the risks.

The sweet spot would be using a lock file for reproducible builds, and programmed dependency upgrades. Before the dependency upgrade you can check if the new version breaks something and plan for it.

I've used this in Python, where I try to keep dependencies to a minimum. I don't know if that would work in JavaScript, the dependency tree is huge there.

Re: Malicious PyPI packages stealing credit cards and injecting code

#230

Post by draegtun »

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…

  >> I am not aware of any languages or ecosystems that do this...
Rebol was designed with such a feature - http://www.rebol.com/docs/words/wsecure.html
Post reply on HN