51–60 of 334 posts
can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .
These sorts of things is why D doesn't allow any system calls when running code at compile time, and such code also needs to be pure. Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.
I'm honestly not sure the benefits of executing code during compilation/install outweigh the bad. Most attacks we have seen leverage this as the attack vector.
Earlier quoted context omitted.
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 :)
Earlier quoted context omitted.
I'm honestly not sure the benefits of executing code during compilation/install outweigh the bad. Most attacks we have seen leverage this as the attack vector.
The problem comes when you need to do something bespoke and custom, like building a C dependency so you can link it into your Python (or whatever language) library. Sometimes your options are "run a makefile" or "reimplement an entire library from scratch". I'm not saying that this isn't a problem; it is. I think the better solution is transparent sandboxing for dev environments.
I don't disagree at all. We're building an open source sandbox for devs right now for this exact reason. Linked it in another comment.
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.
Quoted post unavailable.
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.
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?
You can see the rules we tried here[1].
[1]: https://github.com/pypi/warehouse/blob/main/warehouse/malwar...
Earlier quoted context omitted.
Python is just far more popular. RubyGem: https://www.bleepingcomputer.com/news/security/malicious-rub... Perl CPAN https://news.perlfoundation.org/post/malicious-code-found-in...
I think this has more to due with the contexts/industries we typically see Python used in over pure popularity. If popularity was the only factor I'd expect to seeing a lot more news about these problems in Java/PHP ecosystems which are absolutely massive.
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.
The article doesn't explain what exactly the "W4SP Stealer" does. Would someone be able to explain?
It downloads a script that, at least right now, will turn around and grab cookies and passwords from browsers and send the data off to an discord webhook.
Hah. Is this true? I find it funny since IRC has/had this reputation for being a means of communication with malware and it's often blocked on this grounds.
Nice to know that malware is going on with the times and is using Discord for that now.