Malicious javascript compromise on npmjs.com
These packages, about a billion downloads prior
supports-hyperlinks
chalk-template
simple-swizzle
slice-ansi
error-ex
is-arrayish
wrap-ansi
backslash
color-string
color-convert
color
color-name
Thread follows.
A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago. #threatintel #npm
If you want an idea of scale of trojan attempt - 'color' alone had 32m downloads in a week, the combined attempt was pushing a billion due to upstream dependencies.
Hunt tip: look for registry.npmjs.org in proxy logs, package names are in the URLs.
additional backdoored packages
ansi-styles
debug
chalk
supports-color
strip-ansi
ansi-regex
has-ansi
Weekly download stats for impacted packages prior to incident
ansi-styles (371.41m)
debug (357.6m)
backslash (0.26m)
chalk-template (3.9m)
supports-hyperlinks (19.2m)
has-ansi (12.1m)
simple-swizzle (26.26m)
color-string (27.48m)
error-ex (47.17m)
color-name (191.71m)
is-arrayish (73.8m)
slice-ansi (59.8m)
color-convert (193.5m)
wrap-ansi (197.99m)
ansi-regex (243.64m)
supports-color (287.1m)
strip-ansi (261.17m)
chalk (299.99m)
Total 2674m
@GossiTheDog Ooh, please change your retina every three months...
It's a pretty neat ploy though.
@leoluk @GossiTheDog Draconian systems that limit who can write and publish code are NOT the solution here.
The solution is not having LPMs (language package managers) that pull code from unvetted package repositories in an automated manner, and languages that encourage using thousands of random garbage microdependencies rather than well-vetted, versioned libraries.
@leoluk @GossiTheDog We should not be placing the burden of "users don't get hit with malware" on maintainers locking down their workflows in ways that might be exclusionary or inaccessible.
Instead, the platforms that want to deliver unvetted code as part of a "supply chain" 🤮 need to get their act together and find a way that newly-published unvetted code doesn't end up as part of anyone's build, but instead goes through multiple layers of delay where it's only available to people who intend to be testing an unvetted bleeding edge and understand the dangers. With channels to request rapid review of tiny security-critical changes when needed for expediting them.
@leoluk @GossiTheDog For the most part, none of these packages have any need for new versions to appear in anyone's builds for *months* if not years after publication, unless someone *specifically* has read the changes to the new version and sees a new feature they want from it.
LPM platforms should be designed around this basic principle that updates are mostly unwanted.
The only way anyone should ever get unexpected updates is if there's a serious security problem, in which case there should be a description of the problem and a small comprehensible patch prominently displayed.
IOW LPMs and similar platforms should behave like Debian Stable.
@dalias @leoluk That approach doesn't work. Suppose you're on version X, and as time goes by versions X+1, X+2... are released. You don't upgrade.
Then they release version X+N which contains a security fix you do need. By delaying your upgrades you now have a pile of unrelated changes to include, at exactly the wrong time.
@dalias @lanodan @leoluk @GossiTheDog I'd add "not need to download everything on every use", the way JS and docker runtimes like. We've grown complacent from high bandwidth downloads and the honesty of the majority of developers.
So looking forward to the first crypto-drainer attack which acquires the US treasury crypto assets and that post mortem which will follow.
@joby @leoluk @GossiTheDog Or even just copy&paste the 9 lines of code you needed!
It's about the same amount of code as the interface surface declaring the dependency you needed and binding to it - but without introducing any new interface surface or trust surface!
External dependencies that are not c&p into your own code make sense for something large and complex that's likely subject to bugs/fixes, changing requirements of third-party things they interface with, etc. Not for trivial stuff that's a couple lines of js.
@dalias @joby @leoluk @GossiTheDog
Indeed. I've been openly criticizing language built-in package managers for over a decade now. Having them encourages sloppy coding and short circuits developers' brains not to apply due diligence.
NPM, Pip, Cargo… IMHO those are inherently problematic. My personal motto in software development is: Find the dependencies and eliminate them!
That's a clever phish.
It looks similar to requests that companies already make.
I wonder how suspicious that link looked.
I haven't seen a 2 factor authentication rollover email before either, but it only takes a few people to click without thinking carefully.
Github has nagged me about my reviewing my recovery codes both on the site and via email.
@fazalmajid @ShadSterling @GossiTheDog
That's how you'd have to do it.
I do think Yubikey has a point that one should have a backup yubikey locked up somewhere in case you lose your primary key.
@GossiTheDog But, but, but... They said 2FA prevented phishing!
When is 2FA not 2FA? When it is 2SV.
Even I got that email and I haven't touched npm since about 2017.
This is called spear phishing: targeting a specific person with a tailored and therefore much more credible phishing attack than the usual broad attack surface.
@GossiTheDog Do you have a list of the compromised versions?
A few of these, when I check I see that the version published this morning is still present and the latest version. But a quick glance at the code and I don't see the compromise; I'm just doing a quick scan, but some of these packages are so simple that there's really not many places you could hide it:
https://www.npmjs.com/package/has-ansi?activeTab=code
I'm just trying to compile a list of compromised versions so I can do a quick scan of our systems, but for some of these I haven't been able to find an exploited version.
Maybe the attackers script failed to insert the exploit, as we do see a number of these packages all updated at the same time, but I don't see the exploit code in them. Packages fitting that pattern:
* color
* supports-color
* strip-ansi
* ansi-regex
* has-ansi
(note: all of this is based on a quick glance using the code tab on the NPM registry; it's possible that I could have missed the right file, or missed it when scanning visually, or the code tab might not be showing the version it claims, or the like)
@GossiTheDog Here's my best attempt at a list of the bad versions:
- supports-hyperlinks 4.1.1
- chalk-template 1.1.1
- simple-swizzle 0.2.3
- slice-ansi 7.1.1
- error-ex 1.3.3
- is-arrayish 0.3.3
- wrap-ansi 9.0.1
- backslash 0.2.1
- color-string 2.1.1
- color-convert 3.1.1
- color 5.0.1
- color-name 2.0.1
- ansi-styles 6.2.2
- debug 4.4.2
- chalk 5.6.1
- supports-color 10.2.1
- strip-ansi 7.1.1
- ansi-regex 6.2.1
- has-ansi 6.0.1
Edit: updated with confirmed versions from author who was pwned: https://news.ycombinator.com/item?id=45169794
@GossiTheDog Also, holy hell the left-pad nature of some of these deps. Here's the entire source of has-ansi:
import ansiRegex from 'ansi-regex';
const regex = ansiRegex({onlyFirst: true});
export default function hasAnsi(string) {
return regex.test(string);
}
@GossiTheDog We could see that coming for a long time 😢. In a text I published in German magazine last year I even predicted that color packages would be used.
But what good did it do us to foresee it? Rather little or next to none…
Kevin Beaumont
David Penfold 
Leo@ALLES
Cassandrich
Nik
Ray—Golden Retriever Whisperer—🔝Insights
Steve Loughran
Haelwenn /элвэн/ 
Joby 
(he/him)
datenwolf
Diane
ShadSterling
Fazal Majid
VessOnSecurity
Edwin Martin
Simon Lucy
Martijn Vos
Bitslingers-R-Us
Brian Campbell
Adrian Sanabria
Erlend Oftedal
Martin Seeger