Phylum Blog

So we're specifically talking about the tea.yaml spam. More than any other topic that seems like one that is worth digging into details on rather than just shrugging and saying isolating causality is hard. If we look at the chart in the original article [0] that this one is a follow up to, the NPM spam suddenly picked up around the end of February, with new packages per day first doubling and then tripling. So this 70% figure is specific to the last 6 months, not something that has been the case with the ecosystem for a long time. That makes tracing causality much simpler: the Tea protocol seems to be pretty clearly the source of the problem. The big open question is why NPM, but the way that people jump to the conclusion that NPM being the target of this attack must have something to do with the flaws in the ecosystem smacks of victim blaming. Isn't it just as possible that NPM was targeted because it's huge? If you're going to run a massive spam campaign you do it where the people are. Could NPM learn from this and start controlling spam better? Yes! But That's not the same thing as attributing this tea.yaml nonsense to systemic flaws in the ecosystem—spam prevention has to be balanced with usability, and the balance was pretty decent until 6 months ago. [0] https://blog.phylum.io/digital-detritus-unintended-consequences-of-ope…

Happy to see this on HN! I'm one of the co-founders @ Phylum. We actively monitor and report on malware and software supply chain attacks across multiple ecosystems. Most notably, we were the first to identify and report on attacks carried out by North Korean state actors in NPM [1], prevented an early typosquat campaign against Rust developers on crates.io [2] and recently a faux email validation utility with a fairly complicated attack chain [3]. We've been monitoring npm the longest, and while I wouldn't classify this particular attack as complex or sophisticated, it's interesting in that it continues the trend of targeting build systems (and more generally, developers). Our goal is to help clean up as many of these registries as possible, and to provide developers with the tooling to better protect themselves from attack. In doing so, we're open sourcing as many things as we can. We recently open sourced our sandbox [4] that helps lock down disk/networking/env during process execution and have baked this into our open source cli so you can do things like: phylum npm install <pkg> To be clear, this particular package did not execute code during install, so the sandbox wouldn't have come into play, but it would have been blocked by the pre-check against Phylum's API. Would greatly appreciate any feedback on our extensions and suggestions for improving our sandbox! We recently had a few individuals submit some great issues and suggestions, which we absolutely…

a)"Thanks to backwards compatibility, a package offered only as a source distribution and with the legacy setup.py file for configuration and metadata specification will run the code in setup.py as part of the installation." https://blog.phylum.io/python-package-installation-attacks/ b) pip now has an option _not_ to run arbitrary code by disallowing source distributions, by passing --only-binary :all: "By default, pip does not perform any checks to protect against remote tampering and involves running arbitrary code from distributions. It is, however, possible to use pip in a manner that changes these behaviours, to provide a more secure installation mechanism." https://pip.pypa.io/en/stable/topics/secure-installs/

Another thing that Austral gets right is capability-based permissions for packages, in recognition of the growing danger of supply chain attacks. See for example https://blog.phylum.io/pypi-malware-replaces-crypto-addresses-in-devel… - a bunch of typo-squatting Python packages that use setup.py to write a JavaScript file into the developer’s filesystem (specifically the Windows Start Menu) and register it as a background process inspecting and altering the clipboard to replace crypto wallet addresses with the attacker’s own wallet address. Why can a setup.py in /home/user/.local/lib/python3.6/site-packages or wherever access the Windows Start Menu folder and write files there? Well, because code is almost universally permission-less. Austral’s solution is to give granular permissions: “capabilities can be arbitrarily granular. Beneath the capability to access the entire filesystem, we can have a capability to access a specific directory and its contents, or just a specific file, further divided into read, write, and read-write permissions. For network access, we can have capabilities to access a specific host, or capabilities to read, write, and read-write to a socket.”