Remember npm library 'colors'? There's no such thing as 'colors-2.0'

March 15, 2022 By Ax Sharma

5 minute read time

The popular npm package, 'colors' made headlines earlier this year when its dev Marak Squires had sabotaged the component by adding an infinite loop to it, printing zalgo text incessantly for everyone using the dependency.

'colors' is used heavily, raking in 20 million weekly downloads on npm alone, and has around 19,000 open source projects relying on it. And that explains why threat actors would attempt to typosquat it.

Sonatype's automated detection systems, offered as part of Nexus Firewall, have spotted the following malicious npm packages this time:

These packages are tracked as sonatype-2022-1497, sonatype-2022-1501, sonatype-2022-1504, and sonatype-2022-1476 in our security vulnerability data.

To a casual observer, colors-2.0, colors-3.0, and other few may appear to be "newer" versions of the 'colors' library when that's far from the case. These packages are tactfully named in a manner that may confuse a novice developer into mistaking them for the latest versions of official 'colors.'

Last year, PyPI took down mitmproxy2—a fork of the original 'mitmproxy' package with an "artificially introduced" code execution vulnerability that could, once again, cause confusion and lead to developers adopting the less-secure mitmproxy2 as opposed to the official package under the false assumption they were on the later version of the package.

It is worth noting, in November 2021, months before the news of Squires corrupting his own 'colors' library emerged, a 'colors-2.0.0' and 'colors-2.0' (notice the dash) were also published in an identical typosquatting attack by an author, and later removed by npm. 

In the case of 'colors-XX' typosquats, these packages contain legitimate files borrowed from 'colors'—except the 'lib/colors.js' file that contains heavily obfuscated and minified JavaScript code.

Minified JS has legitimate use-cases as it enables the developers to ship code that consumes lesser resources and loads faster. But threat actors can also leverage minification and obfuscation code to scramble and completely hide malicious bits of code within an application:

My colleagues, Cody Nash who’s part of the development team behind the automated malware detection system, and security researchers Juan Aguirre and Ali ElShakankiry, noticed these 'colors-XX' packages contained Discord token stealers and code that peeks into your web browser's 'leveldb' files, a pattern we have repeatedly seen before in attacks [1, 2]:

  • C:/Users/.../AppData/Roaming/discord/Local Storage/leveldb
  • C:/Users/.../AppData/Local/Google/Chrome/User Data/Default/Local Storage/leveldb
  • C:/Users/.../AppData/Roaming/discordcanary/Local Storage/leveldb
  • C:/Users/.../AppData/Roaming/Opera Software/Opera Stable/Local Storage/leveldb
  • C:/Users/.../AppData/Local/BraveSoftware/Brave-Browser/User Data/Default/Local Storage/leveldb
  • C:/Users/.../AppData/Local/Yandex/YandexBrowser/User Data/Default/Local Storage/leveldb

Select versions of these packages contained unobfuscated code with Discord Webhook URLs intact further confirming our findings:

Whereas, 'wixdev2022-1' has a Busybox Linux (ELF) executable packed within it and uses it to establish a TCP reverse shell connection to xhc[.]vg (on port 9001). Based on the origins of this domain, 'wixdev2022-1' appears to be a dependency confusion package published by a pentester.

We reported our findings to npm prior to publishing and all of these malicious packages were taken down.

This isn't the first time we've caught Discord token stealers lurking on open source registries either. 

Just last month, Sonatype had discovered malicious Roblox cookie and Discord token stealers on PyPI. Whether it being the "fallguys" npm package from 2020, or its successor discord.dll, or an entire family of Discord token stealing malware, CursedGrabber, we continue to be at the forefront of timely discovering and reporting attacks targeting OSS developers and the gaming community.

Nexus Firewall users remain protected

Users of Nexus Firewall can rest easy knowing that such malicious packages would automatically be blocked from reaching their development builds. 

U-cofx0-oAHuk7B8hQ_0YBbx7E9LQSW04uag5iP4Q7mdyUWkjohGvAiYYykP8LnvXzbz7CUADYOIt3X4KVAozG7Sxz7PFEffVVl_TP2LufuKfXcPzVvjvk3Br_IPtFK9776-HbUE

Nexus Firewall instances will automatically quarantine any suspicious components detected by our automated malware detection systems while a manual review by a researcher is in the works, thereby keeping your software supply chain protected from the start. 

Sonatype’s world-class security research data, combined with our automated malware detection technology safeguards your developers, customers, and software supply chain from infections.

Update March 16th, 03:16 AM ET: Added info on the xhc[.]vg domain.

Tags: vulnerabilities, Nexus Firewall, npm, featured, malicious code npm, DevZone

Written by Ax Sharma

Ax is a Security Researcher at Sonatype and Engineer who holds a passion for perpetual learning. His works and expert analyses have frequently been featured by leading media outlets. Ax's expertise lies in security vulnerability research, reverse engineering, and software development. In his spare time, he loves exploiting vulnerabilities ethically and educating a wide range of audiences.