Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dozens of malicious PyPI packages discovered targeting developers

blog.phylum.io

Post reply on HN
Print view View original

41–50 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#41

Post by sigg3 »

banana_giraffe wrote: post #23
sigg3 wrote: post #7

It's using base64 encoded strings to deliver the initial stage. Can this be avoided/flagged more easily if by adding a scan of statements featuring base64 or import?

That'd catch a ton of valid packages. Right now on my random collection of packages in site-packages I have ~60 packages that have 'import base64' in them.

Yeah, it would probably create more manual work if you have too many false positives. I have maybe six base64 strings in the code I'm working on, so it might be worthwhile looking into provided my legitimate imports don't have any.

Re: Dozens of malicious PyPI packages discovered targeting developers

#42

Post by kroolik »

stemlord wrote: post #10
jacob019 wrote: post #2

PyPi should warn when the package and developer are new.

Yeah a time/activity based trust system like thepiratebay uses could be helpful. Also devs should get into the habit of providing sha256 hashes on offical channels (i.e., github readme) so users can validate (if its possible to validate a pkg before executing malicious code in the python ecosystem, I'm not sure how that'd work).

Doesn't pip's hash checking mode solve this issue? Freeze your requirements with hashes. Pypi already provides hashes for sdists and wheels. See https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

If we are talking typos or other human errors, guess we could only warn people that there are other package with similar name available. Can't predict what people have in mind when they make a typo.

Re: Dozens of malicious PyPI packages discovered targeting developers

#43

Post by koolba »

coffeeblack wrote: post #3

I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.

> Only one typo in an import statement up the dependency chain and you’d be compromised.

Doesn’t even have to be a typo if the actual project is compromised. Like one of the 100s of NPM modules without 2FA for publishing.

Re: Dozens of malicious PyPI packages discovered targeting developers

#44

Post by RockRobotRock »

louislang wrote: post #34
RockRobotRock wrote: post #31

The guy who runs the C2 openly has the source code for the stealer on his GitHub. Why doesn't GitHub do anything about this shit? I've personally been hacked by a supply chain attack via a GitHub wiki link. I contacted GitHub support and didn't hear back from them for 3 months. They are completely useless.

They are trying. The level of effort to release these things is so low, the effort required to catch it and remove it at scale is much harder, unfortunately.

Are they? I know I'm biased because this affected me and I'm still mad about it, but I just don't buy it.

I contacted them, showing the plainly obvious malicious account that was distributing malware. Two months later, they send me a generic message saying that they've "taken appropriate action", but the account and their payload was STILL THERE, they hadn't done anything. The attacker was rapidly changing their username, and honestly I'm not sure their support staff has a way of even dealing with that. I tried to explain the situation as best I could, but they were not helpful in the slightest.

Re: Dozens of malicious PyPI packages discovered targeting developers

#45

Post by csunbird »

louislang wrote: post #29
sigg3 wrote: post #7

It's using base64 encoded strings to deliver the initial stage. Can this be avoided/flagged more easily if by adding a scan of statements featuring base64 or import?

Yes, this works really well. But as soon as you deploy it, the actors change tactics. We've had to build a defense in depth approach to discovering malicious packages as they are introduced into the system.

it is probably very easy to bypass, by creating a sub package that can do the decoding via proxy functions, which is not evil at all, and depending on that package on the evil one. It won’t trigger the alarm, as it is indirectly depending on the base64 :)

Re: Dozens of malicious PyPI packages discovered targeting developers

#46

Post by frankjr »

suchar wrote: post #39
frankjr wrote: post #30

Earlier quoted context omitted.

Sometimes but I wonder to what degree it actually matters. Tasks, debuggers, extensions etc. run in the context of the VM, not the host. The Remote SSH extension turns VS Code into a "thin" client which presents pretty much just the UI. https://code.visualstudio.com/docs/remote/ssh

Readme says: https://marketplace.visualstudio.com/items?itemName=ms-vscod... > A compromised remote could use the VS Code Remote connection to execute code on your local machine. So I would say that it might be a bit harder for an attacker to gain access to your local machine, but you should not rely on it, because it's more like security by obscurity.

Well damn. I was under the impression that the communication channel uses/accepts only well defined VSCode specific messages related to the UI...

Re: Dozens of malicious PyPI packages discovered targeting developers

#47

Post by lovelearning »

In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network.

I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.

Re: Dozens of malicious PyPI packages discovered targeting developers

#50

Post by hulitu »

lovelearning wrote: post #47

In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.

No post body was provided.
Post reply on HN