Supply Chain Attack Using PyPI Packages “Colorslib”, “Httpslib”, and “Libhttps”

I <i>really</i> dislike this dilution of “zero-day” and “supply chain attack”: these are typosquats, not package takeovers. There’s no evidence that they’re widely affecting companies or individual developers whatsoever.<p>In general, you can apply a “repetition” test to these sorts of 0day claims: if the attacker can create infinite “0days” using the exact same technique, it’s not an 0day.<p>Edit: More generally, otherwise serious security companies should be ashamed to publish dreck like this. It’s one thing to highlight a tool that automatically detects new typosquats (this would be a genuinely useful contribution to most packaging ecosystems!); it’s another thing entirely to breathlessly hype non-existent attacks. This kind of false vigilance breeds <i>exactly</i> the kind of complacency that it’s supposedly intended to prevent.

As far as I understand, this is just a typosquatting attack, or more like Google SEO squatting attack. There does not exist any normal Python libraries anyone would use under these names. These packages are often made as a clone from an official package, just adding a new name. There is no reason to choose a cloned package with different name over the official one.<p>This is business as usual for PyPi. I reported ~3 cloned malicious packages last year and they were taken down. Only very inexperienced or unlucky software developer would fall for this attack, because these packages are not part of any supply chain. Thus, I feel calling this a supply chain attack is incorrect. Maybe a watering hole attack would be more closer to the truth.

It&#x27;s kind of amazing to me that this is still a thing.<p>Supply chain attacks <i>on the client machine</i> basically don&#x27;t exist in Linux distributions. If you&#x27;re downloading a Linux disto package from the distro&#x27;s official repositories, it has been signed by the distribution, and a human being working for the distro has entered that package into the repository as a real (not-malware) package.<p>These free-for-all ecosystems where anyone can put any package into the repository, and they don&#x27;t require signing, and nobody is gatekeeping even <i>the name of the package</i>, is just... insane. Do you want a free-for-all, or do you want curation and quality? You can&#x27;t have both.<p>Until there are new, curated, quality public repositories, I think the bare minimum requirement for all companies should be that they must host their own package repository, and 2 people must sign off on adding a package, with details about the package&#x27;s ownership, signing key, source repository, how recent the project is, how many releases they have, etc. The basic due diligence that a package maintainer normally does. Shipping <i>anything</i> to prod that someone just downloaded from PyPI should be a non-starter.

Somewhat related question, do you think there is a market for vetted&#x2F;audited&#x2F;curated mirrors of the major language package registries such as PyPI and NPM?<p>These &quot;uncurated&quot; package managers will always be vulnerable to someone uploading compromised builds. Would people pay for a mirror of these that contain a curated list of vetted builds? It would probably only have a small subset of the origin registry.<p>The vetting or auditing could be at a couple of different levels, automatic based on on &quot;trusted&quot; authors and signed packages, automatic code analysis, and higher level manual vatting. Customers could request packages that are on the open list be included in the curated and vetted version.<p>Obviously there will be some time lag between packages being uploaded to the origin before they have been vetted and places on the curated mirror. Some sort of expedited process would be needed to security releases.<p>&#x2F;random thought for the day

I don&#x27;t want to speculate on exactly how the developer at CircleCI was compromised, but it wouldn&#x27;t surprise me if it was something like this. They can be pretty easily targeted and it&#x27;s trivial to get RCE on a developer&#x27;s laptop during package install.<p>These are hard to detect for a few reasons:<p><pre><code> - Traditional endpoint protection is often disabled on developer machines - Developers require much more access to their machines to do their jobs - Installing packages in most programming languages still results in RCE at install time - Most solutions are aimed at protecting code once it makes it to CI and production, but developer machines are still the wild west </code></pre> If you&#x27;re not already operating in a world where you assume every developer laptop is compromised, you need to start. The only real protection here is requiring multi-party review for *everything*.

There needs to be some way of automatically flagging package upgrades that might be malware.<p>Introducing calls to things like is system or subprocess should be a red flag.<p>I feel like the pledge system would be a good model here: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@_neerajpal&#x2F;pledge-openbsds-defensive-approach-for-os-security-86629ef779ce" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@_neerajpal&#x2F;pledge-openbsds-defensive-app...</a>

We’ve (<a href="https:&#x2F;&#x2F;www.phylum.io" rel="nofollow">https:&#x2F;&#x2F;www.phylum.io</a>) been tracking this actor as well. There are more packages than this blog post notes, including: fredli, derkpy, and fredmi. The first packages from this actor appeared on Jan 1.<p>A bit of work has been done to RE the binary itself, and we’ve found references to the following GitHub <a href="https:&#x2F;&#x2F;github.com&#x2F;T4hg&#x2F;frek&#x2F;blob&#x2F;master&#x2F;__init__.py">https:&#x2F;&#x2F;github.com&#x2F;T4hg&#x2F;frek&#x2F;blob&#x2F;master&#x2F;__init__.py</a><p>Happy to chat with anyone that’s interested in this sort of thing. We’ve got a trove of samples that seems to grow daily!

STOP AUTOMATICALLY DOWNLOADING CODE FROM THE INTERNET AND INCLUDING IT IN YOUR PRODUCT AS PART OF YOUR BUILD CHAIN why do I need to say this out loud?