22 ms·
Dozens of malicious PyPI packages discovered targeting developers
- jacob019 4y agoPyPi should warn when the package and developer are new.
- prox 4y agoYeah, an onboarding process build on trust and time-delay would be nice.
- stemlord 4y agoYeah 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).
- yjftsjthsd-h 4y ago> 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). I would think the easy solution is to publish a public signing key per-person or per-project, and then sign individual files with that. So, GPG.
- louislang 4y ago> Yeah a time/activity based trust system like thepiratebay uses could be helpful. This is an excellent idea. Authors are something we are digging into heavily as part of an ongoing effort to improve trust in the open source ecosystem.
- kroolik 4y agoDoesn'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-checking-mode 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.
- louislang 4y agoIt definitely does help. We've seen malicious actors introduce "bad things" into legitimate packages [1]. So hashes help identify what you got, but doesn't necessarily prevent you from getting something you didn't intend. [1] https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22/malware-discovered-popular-npm-package-ua-parser-js https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22...
- MichaelCollins 4y agoEven Firefox and Chrome's extension "stores" don't get this right. In either, a once trusted extension can be sold to a malicious company who then pushes new updates which automatically get downloaded by Firefox and Chrome by default, with no warning. Quite possibly without Mozilla and Google having any way of knowing it happened at all. One way to address this is to move to a traditional "debian" style system, where packages are people affiliated with / known by Debian/Mozilla/Google, and specifically aren't the developers of the software themselves. The software is written by Developer X, but is then packaged and distributed by Packager Y, who ideally has no commercial affiliation with Developer X. If Developer X sells out to Malware Corp Z, end users can hope that Packager Y isn't part of that deal and prevents the malware from being packaged and distributed. This still isn't bullet-proof, but it's a lot better.
- pkrumins 4y agoTotally agree. There should be a 30 day pe
- coffeeblack 4y agoI 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.
- fsflover 4y agoThen you might be interested in Qubes OS: https://qubes-os.org https://qubes-os.org.
- orblivion 4y agoThat's why I chose it. A lot of peace of mind there.
- lupire 4y agoVirtual is part of a solution but not the key: the key is to separate your dev env from your real life/business environment -- including all your personal and professional business data and web accounts that expose your financials and private data. If you log into your email from the virtual machine, you are at risk.
- orblivion 4y agoI think that separation is the point of the VM. Do the dev work in the VM, don't give it sensitive info about yourself.
- hollerith 4y agoThat protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.
- suchar 4y agoAs long as your are creating web applications then browsers are pretty good at limiting blast radius of a single attacked website. Well, at least until attacker discovers that he can inject some fancy phishing into trusted site. With local development environment it is a bit different, because unless you are running build/test etc. in a container/vm/sandbox, then attacker has access to all of your files, especially web browser data.
- lupire 4y agoOpen/free software is great when a great person writes some code and lets you use it, because they are kind and there's nearly no marginal cost. But malicious actors can get value from polluting the sharing network, and that costs effort to defend against, which means someone(s) has to pay to secure the network, or be open to attack.
- LudwigNagasena 4y agoThat’s not an either or thing. Someone you pay to can also be a malicious actor.
- sigg3 4y agoIt'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?
- banana_giraffe 4y agoThat'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.
- sigg3 4y agoYeah, 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.
- louislang 4y agoYes, 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.
- csunbird 4y agoit 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 :)
- louislang 4y agoExactly, I don't think you can rely on a naïve import to determine maliciousness. We've basically had to build out heuristics that are capable of walking function calls for this exact reason. Otherwise things are just too noisy.
- 4y ago
- rrwo 4y agoIs there something about Python or PyPI that makes it more attractive for malicious developers to add malware? Is this also happening for repos for other languages (e.g. CPAN, RubyGems)?
- lupire 4y agoPython is just far more popular. RubyGem: https://www.bleepingcomputer.com/news/security/malicious-rubygems-packages-used-in-cryptocurrency-supply-chain-attack/amp/ https://www.bleepingcomputer.com/news/security/malicious-rub... Perl CPAN https://news.perlfoundation.org/post/malicious-code-found-in-cpan-package https://news.perlfoundation.org/post/malicious-code-found-in...
- d4mi3n 4y agoI 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.
- mcdonje 4y agoI mean, PHP is pretty much a domain specific language, and we're only about a year out from log4j.
- marcinzm 4y agoJava is special since it has mandatory version pinning of all dependencies, doesn't run code at install time and uses a full url for dependency names. That means dependencies don't auto-update, don't compromise CI/CD as easily and don't get misspelled as easily (ie: people copy paste the whole name+version versus writing it from memory). Many languages since then decided that causes too much overhead.
- lupire 4y agoW4SP is a python module that harvests passwords from your computer/network?
- louislang 4y agoThat's correct, it's exfiltrating data from the developer machine
- RockRobotRock 4y agoYep. You can read the source code for it here: https://github.com/loTus04/W4SP-Stealer https://github.com/loTus04/W4SP-Stealer
- sc__ 4y agoThe article doesn't explain what exactly the "W4SP Stealer" does. Would someone be able to explain?
- banana_giraffe 4y agoIt 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.
- avian 4y ago> 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.
- neurostimulant 4y agoDiscord is great as command and control server because the malware author doesn't need to expose their ip address or implement a complex web of proxy to secure their C&C server.
- remram 4y agoCouldn't you use someone else's IRC server, the same way you use Discord's server?
- neurostimulant 4y agoI suppose you could, but have you seen how popular new opensource projets being run these days? Young devs really loves discord to the point of hosting documentations there. I imagine young malware authors are no different.
- 4y ago
- RockRobotRock 4y agoThe 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.
- louislang 4y agoThey 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.
- RockRobotRock 4y agoAre 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.
- jorvi 4y agoI don't know what their standard for 'malicious' is, but they nuked Popcorn Time and Butter (the technological core without the actual piratey bits) from orbit until there was a huge amount of backlash.
- RockRobotRock 4y agoI'm not even asking them to deal with the problem "systemically" or "at scale". I just want them to respond when I am trying to stop an active criminal campaign whose goal is to steal money and cryptocurrency from people.
- zzzeek 4y agocan there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons.
- josephwegner 4y agoYes, this lines up with the "Critical Project" concept that has been floating around in the past year. It is... contentious to say the last. Previous HN discussion: https://news.ycombinator.com/item?id=32111738 https://news.ycombinator.com/item?id=32111738
- remram 4y agoThis gives a checkmark based on number of downloads, so there is absolutely no guarantee that the package doesn't do anything malicious or won't in the future.
- woodruffw 4y agoIt's not going to be a "blue checkmark" per se, but we're currently working on integrating Sigstore signatures into PyPI. The idea there will be that you'll be able to verify that a package's distributions are signed with an identity that you trust (for example, your public email address, GitHub repository name, or GitHub handle).
- dheera 4y agoI think the issue isn't so much malicious authors, it's compromised repositories and compromised repositories as dependencies. Blue check would gatekeep a lot of noble, new developers.
- zzzeek 4y agothese aren't compromised repositories on pypi, these are fully legitimate repos started by bad actors that intentionally use similar sounding names and readmes. a system by which all of the major packages and dependencies are coming in, which to be clear is the whole pile of stuff that people aren't usually looking at, on a set of trusted authors and where someone who is being careful can whitelist specific repos for newer projects they want to use would reduce the problem to almost nothing.
- WalterBright 4y agoThese 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.
- louislang 4y agoI'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.
- kibwen 4y agoThe 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.
- louislang 4y ago> 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.
- wiredfool 4y agoI'd love transparent sandboxing -- but the difference between me wanting to install the awscli and something that steal awscli's credentials is only a matter of intent, so a bit difficult. I've basically converted to doing all node development in docker containers with volume mounts for source, now it looks like python is going to need to be there as well, at least for stuff that pulls in any remote dependencies.
- WalterBright 4y ago
- lovelearning 4y agoIn 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.
- hulitu 4y ago
- lovelearning 4y agoIt's a problem with every open ecosystem where libraries can be downloaded and run. Rust, Golang, Node all have the same problem. That's why I think it's better to assume anything we download is malicious. Stuff like Bubblewrap and Qubes OS seem to be the better approach compared to relying on vulnerability hunters and scanning tools.
- quickthrower2 4y agoDo both and more. When using an unfamiliar package check it’s upload history. How far does it go back? How did I discover the package, do i trust that source? Etc. Unless your code is never going to touch important data or resources, like for example (but not limited to) being used commercially in any vein then you can’t keep it in a padded cell forever.
- unnah 4y agoThat's not going to help much if code from the malicious attacker is still going to end up integrated into the software product being built.
- insanitybit 4y agoI disagree. I need to write this up in more detail but it helps quite a lot. 1. An attacker who can access your development environment and your production environment is worse than one who can only access your production environment. You might say "but the end goal is prod", but it's not that simple because of (2). 2. We already have very good tooling for isolating services at runtime. Separating them onto different instances, firewall/security groups, limited API keys, docker/ containers, apparmor, selinux, etc. We have a lot of tooling for "a service in production is owned". What we lack is "a library in dev environment is owned". 3. Devs often have more privileges than your services. It's unfortunate but at a lot of companies, perhaps given some lateral movement around dev envs, you'll find SSH keys to production, browser session cookies that give you console access, source code, chat sessions, internal documents, git keys, gpg keys, etc. So I'm actually fine with a tool that sandboxes the build process but leaves open the hole of "but the attacker can patch the binary and execute code in production". That's a huge win.
- john61 4y agoThis is one reason I prefer Debian python packages.
- dheera 4y agoThere's also a disturbing new trend of publishing end-user software as pip packages instead of apt-get packages, just because the bar to join apt-get is too high.
- jjgreen 4y agoThis really is the sweet spot when production is a specific Debian version, set up your dev environment to match that and it's pretty bombproof. Run CI with pip installs against later Python versions to see the shouty deprecations you'll be able to sidestep.
- pxc 4y agoThis is definitely a benefit of using distro-provided packages. You get some vetting, and in addition, standard practice for many distros is to build everything that goes into the repos in sandboxes or VMs which have restricted or no network access. Additionally, some package managers incorporate that kind of sandboxing into their builds categorically, like Nix and Guix. (For Nix, this may only be on Linux— there are issues with sandboxing on macOS.) So if you build your project's dependencies via Nix or Guix, you're also protected. This only protects you from `setup.py`-type (build time) attacks, of course. If the distro packages get compromised in some other way so that malicious code ends up in your installed programs (this attack has elements of that, IIRC), you're still in trouble.
- MichaelCollins 4y agoI hope the age of a thousand dependencies automatically pulled and upgraded on a basis of trust is coming to a close. It was obvious from the start this would eventually become a problem. Trust-based systems like this only work for as long as scoundrels remain out of the loop.
- deleted 4y ago[deleted]
- alexb_ 4y agoA lot of people in this thread are asking for a reputation/"verified user" solution for this, but really I think just pulling a gazillion dependencies for applications is just all around bad. I actually think having a reputation system would be even worse, because people would see it and assume that reputation is a guarantee of safety. Trust without verification is where issues can become even worse.
- alxlaz 4y agoBased on my experience with shady plug-ins for e.g. Photoshop back in the late 90s/early 00s, all that a reputation/"verified user" solution is going to achieve is a very lucrative black market of high-reputation/verified user profiles and credentials.
- deleted 4y ago[deleted]
- SamuelAdams 4y agoSo is .NET finally going to make a comeback? Yes, you need some dependencies for projects, but in general Microsoft does a good job providing a lot of tooling and libraries.
- zmaurelius 4y agoI am really surprised that there haven't been even more malicious packages distributed in the past couple of years considering the rise of cryptocurrency. Seems like a determined and malicious actor could score big by targeting the more popular wallets.
- louislang 4y agoIt's totally happening. We've seen packages targeting a lot of the big exchanges. Most of the packages are targeting developers directly though; attempting to exfil the users wallets/keys.
- blktiger 4y agoSonatype found a whole bunch of those and blogged about it in August. https://blog.sonatype.com/more-than-200-cryptominers-flood-npm-and-pypi-registry https://blog.sonatype.com/more-than-200-cryptominers-flood-n... Disclaimer: I currently work for Sonatype, but in a different area of the company.
- zmaurelius 4y agoThanks for sharing this, I had no idea it was already this prevalent.
- AtNightWeCode 4y agoThis is a fundamental flaw in most langs. There should be a smarter way to track changes in what is specifically used in dependencies.
- roflyear 4y agoOnce a buddy and I reverse engineered some JS on a site that did the same thing - sent you down one rabbit hole, more obfuscated code, etc.. etc.. we eventually got to the end of it and discovered a comment: // help my name is ### // i am being held at #### (address in china) // please contact my family ### (this was in chinese, we had to translate it) Scary!
- lgessler 4y agoSo did it seem like some kind of weird scam, or what?
- dane-pgp 4y agoPresumably it's to trick whitehats into tipping off the hackers that their code was being analysed and had been successfully deobfuscated, so the hackers knew they needed to move to a different attack. It's actually quite devious, like a reverse honeypot that the bad guys use against the good guys, exploiting their empathy.
- roflyear 4y agoThat would be clever!
- roflyear 4y agoNo, maybe a joke? Or serious...
- mbeex 4y agoFrom a web page so crammed with JavaScript that it's pointless to even try to take a look at the article.
- zepearl 4y ago> Upon first glance, nothing seems out of the ordinary here. However, if you widen up your code editor window (or just turn on word wrapping) you’ll see the __import__ way off in right field. For those counting at home, it was offset by 318 spaces Haha, simple & effective...
- dmitrygr 4y agoSo malicious packages for JS, now python, but still no W4SP stealers for libc :( Feeling a bit left out, guys! How will my code get compromised randomly?
- jerpint 4y agoI wonder why we can’t have pip packages be published by username or organization, like pip install google/tensorflow It would significantly reduce the attack space
- louislang 4y agonpm does something similar with their scoped packages. It fixes the problem for the top level packages, but you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors. In this case, you have to guarantee that no one involved in the dependency chain ever typos anything.
- jerpint 4y agoThis is true, and wouldn’t remove the entire space of attack, but would still limit it to some extent.
- louislang 4y agoOh absolutely. Unless everyone wants to be cool and stop publishing malware, gotta take a defense in depth approach here.
- collinmanderson 4y ago"you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors" - generally these are the higher risk dependencies anyway and should probably be used with extra caution anyway.
- YetAnotherNick 4y agoIt gives false sense of security. What about google_official/tensorflow
- germandiago 4y agoIt would still be an improvement if companies make clear what their namespace is.
- sergiotapia 4y agoIt makes me very sad that something as wonderful as code, the closest we have to actual magic is tainted by this. You know how to code and you chose to spend your time doing this? What a shame
- NotYourLawyer 4y agoLots of “reputable” devs write code that’s every bit as shitty as this. Somehow it’s ok when all you’re doing is spying on your users and shoving ads into their eyeballs.
- tonnydourado 4y agoOne of the fake packages is called `felpesviadinho`, which looks like calling someone named "felpes" with a homophobic slur in Brazilian Portuguese.
- heleninboodler 4y agoThis type of stuff is one reason I like vendoring all my deps in golang. You have to be very explicit about updating dependencies, which can be a big hassle, but you're required to do a git commit of all the changes, which gives you a good time to actually browse through the diffs. If you update dependencies incrementally, it's not even that big a job. Of course, this doesn't guarantee I won't miss any malicious code, but they'd have to go to much greater lengths to hide it since I'm actually browsing through all the code. I'm not sure the amount of code you'd have to read in python would be feasible, though. Definitely not for most nodejs projects, for example. I think it's an interesting cultural phenomenon that different language communities have different levels of dependency fan-out in typical projects. There's no technical reason golang folks couldn't end up in this same situation, but for whatever reason they don't as much. And why is nodejs so much more dependency-happy than python? The languages themselves didn't cause that.
- plugin-baby 4y ago> And why is nodejs so much more dependency-happy than python? Could it be that nodejs has implemented package management more consistently and conveniently than other languages/platforms?
- Scarblac 4y agoThat's one thing, the other is the almost complete absence of a standard library.
- heleninboodler 4y agoYeah, I think this is a big one. One of the things that I have always liked about Golang is that the standard library is quite complete and the implementations of things are (usually) not bare-bones implementations that you need to immediately replace with something "prod-ready" when you build a real project. There are exceptions, of course, but I think it's very telling that most of my teammates go so long without introducing new dependencies that they usually have to ask me how to do it. (I never said the ux was fantastic :) This also goes to GP's "consistent and convenient" argument.
- cr4nberry 4y agoThat bit with the semicolon way off to the right side of screen is kind of sloppy. It's a dead giveaway of "I'm doing something I shouldn't be doing"
- gatesn 4y agoI’ve been building out a PyPi proxy to try and protect against these use-cases: https://artifiction.io https://artifiction.io Explicit allow-lists and policies such as requiring "greater than X downloads per week" go a pretty long way to filtering out malicious packages.
- erustemi 4y agoI think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "access": [] // no system resources allowed for this dependency, own or transitive }, ... } It would probably require the language to limit monkey-patching core primitives (such as Object.prototype in javascript), and it would be more cumbersome for the developer to define the permissions it gives to each dependency. These required permissions could be listed on the package site (eg npm or PyPI) and the developer would just copy paste the permissions when adding the dependency. But if you upgrade a dependency version and it now requires a permission that seems suspicious (eg "stringutils" needing "filesystem"), it would prompt the developer to stop and investigate, or if it seems justified add the permission to "access" list.
- louislang 4y agoThis is one of the projects we're working on (and open sourcing)! Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1]. The sandbox itself lives here [2] and can be integrated into other projects. 1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/PhylumExt.toml https://github.com/phylum-dev/cli/blob/main/extensions/npm/P... 2. https://github.com/phylum-dev/birdcage https://github.com/phylum-dev/birdcage
- deleted 4y ago[deleted]
- c0balt 4y agoAt the beginning the permissions aspect of deno[0] was actually on of the major selling points for me. The approach used there was to begin at zero and offer granular permission control, e.g. `--allow-read=data.csv`, for filesystem, network etc. I would love to have this for, e.g., python or npm packages. [0]: https://deno.land/manual@v1.27.0/getting_started/permissions https://deno.land/manual@v1.27.0/getting_started/permissions
- 7373737373 4y agoProgramming languages have to become able to sandbox imported dependencies, to limit their side effects up to sandboxing them completely, ideally in a fine grained way that allows developers to gradually reduce the attack surface of even their own code https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... https://github.com/void4/notes/issues/41 https://github.com/void4/notes/issues/41
- qwertox 4y agoCouldn't forcing publishers to sign a hash of the module not be a solution? The certificate could contain information about the owner and the consumer could check if he wants to deal with the owner or not. Developers could add a desired whitelist to pip (or use a curated one) to continue using automation.
- louislang 4y agoHashing solves one side of the coin. Namely, whether or not you got the thing you expected (or perhaps, got the thing you expected from the individual you expected it to come from). On the other side, we have to contend with the fact that malware can be slipped into otherwise legitimate packages. This has happened numerous times over the years. In this case, the hash would serve as a way to say "yup, you definitely got malware". Useful for incident response, but I think we can do better and try and prevent these attacks from being viable in the first place.
- Uptrenda 4y agoIt's okay people: I have the solution. We just need to make Python as hard to use and ugly as all other languages and then the skids won't be able to use it. Thank me later.
- bigbillheck 4y agoA lot of people in the comments here aren't happy with people using tons of dependencies, but what else do you expect from ecosystems that (a) make it easy to download and publish packages and (b) don't have much of (b') a standard library or (b'') set of blessed solutions? This isn't a case of 'oh, python (javascript, etc) programmers are dumb and lazy'. If C++ had a packaging system and it wasn't so horrible to add third party dependencies we'd be seeing the same thing there.
- deleted 4y ago[deleted]
- djbusby 4y agoWould it be possible to make a more trusted package mirror? Somehow validating packages before inclusion? IIRC mirrors for NPM, Packagist and others is not impossible, can be done for PyPY and others too? Maybe it's a stop-gap before all the fancy permissions feature build out (which seems hard)
- jsmeaton 4y agoThis is what systems like deb and rpm do - they curate a list of packages that can be installed to the system. But most people (in my experience, including myself) don’t use them because they get out of date really quickly and don’t lend themselves to things like virtual environments very well.
- 77pt77 4y agoDebian unstable is usually years behind the times.
- freeqaz 4y agoIt is possible to set your registry in NPM via the "npmrc" file. That will let you hit the specified HTTP server whenever you run commands like "npm install". I know this is also possible for Python because we did it at Uber. I don't remember the specific details anymore though. In either case though, a lot of people have written proxies for this use case (I helped write one for NPM at Uber). Companies like Bytesafe and Artifactory also exist in this space. We're working on something similar that's on GitHub here: https://github.com/lunasec-io/lunasec https://github.com/lunasec-io/lunasec Proxy support isn't built out yet but the data is all there already.
- jeffxtreme 4y agoIs there a way to check if you've been compromised by these PyPl packages? Does PyPl have a mechanism to let people know that they've downloaded a compromised package?
- riyakhanna1983 4y agoMalicious packages are yanked as and when they are found or reported by the community.
- est 4y agoIn a perfect world, outgoing network/file operations should be explicitly whitelisted in code using a decorator. And containers should limit which process/thread can access which port/path.
- Beltalowda 4y ago"collectively the packages listed above account for over 5700 downloads" Or about 190 downloads per package, and who knows how many of those are actually real downloads by victims. This is basically a non-issue; a few fools downloaded random code from the internet and ran it on their computer and, hopefully, learned a lesson. Shock and horror!
- emodendroket 4y agoFrankly it's surprising this doesn't happen more often.
- 77pt77 4y agoAnother one is just maintainer/packagers for popular distros like Arch. I'd be very surprised if something shady isn't there as of now.
- pabs3 4y agoAre any tools to detect such malicious modules, or are PyPI reliant on proprietary services by third parties to do that?
- ashishbijlani 4y agoI built Packj to flag such "risky" packages: https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
- HeavyStorm 4y agoA good strategy would be to not allow typosquatting by just blocking names that too similar (something simple as hamming distance would suffice here). Afaik there are two types of supply chain attacks strategy - you either compromise the a legitimate package by somehow getting a PR approved with malicious code, which is very hard to do, or you "typosquat". The latter is way easier and probably the dominant strategy, so package repositories such as PiPy need to invest into preventing it. Edit: formatting, grammar
- berkes 4y agoA third is to fill a niche. E.g. if there's no "storage library for DigitalOcean Block Storage"[1], one can make it and publish it[2]. It would work as advertised, but maybe do some additional stuff, like sending the API keys to malicious server too. Unknowing developers would be searching, seeing something that promises to solve their problem, and use that. I haven't encountered this in the wild yet, but IMO it's reasonably easy. More work than typosquatting, for sure, but probably less work than getting a malicious PR accepted in an existing project. [1] It's just an example, doesn't exist, and if (by now) it does, I never meant to hint it is malicious. DO is just an example, and I have nothing but good to say about their services (and libraries) where they exist. [2] The example here would be to just copy the S3 library, because DO block storage is fully compatible with S3 API. Which would also be the reason a dedicated library doesn't need to exist.
- Riverheart 4y agoCuration. Have a wide open repo and then have a repo of curated packages. There is no typo squatting in the curated repo because a human had to approve it. Pip install ansible --from curated.pypi.org Pip install anssible --from wildwest.pypi.org Let them typosquat all they want in the wildwest. I don't worry about this nonsense with Apt. Heck maybe curation becomes a revenue stream to pay to get in to support such activites.
- syrusakbary 4y agoThat's the main reason we should start using WebAssembly for distributing and using packages. Shamless plug: Wasmer [1] and WAPM [2] could help a lot on this quest! [1]: https://wasmer.io/ https://wasmer.io/ [2]: https://wapm.io/ https://wapm.io/
- prasadi 4y agowaestdryftugy