Recently, the popular NPM package ua-parser-js was compromised by attackers. At least three malicious versions of the software were released by attackers with capabilities including password stealing, cryptomining, and more. While the attack was quickly detected by the community, it could have been avoided altogether. Techniques to prevent these types of attacks have been around for decades, but are unfortunately not used by all major platforms. This post will provide a quick background on the attack, how it could have been prevented, and a summary of which major platforms employ the preventative measures.

Attacking UA-Parser-JS

Cyber criminals target major software libraries and tools because it allows them to reach many victims from a single compromise – this is known as a supply chain attack. So, it is no surprise that a library that is used by large companies such as Microsoft, Google, Amazon, and Facebook and is downloaded over eight million times per week would be the target of an attack.

The maintainer of the package believes that the attackers were able to compromise his NPM account and then upload their malicious versions of the software. The attackers then uploaded three versions – 0.7.29, 0.8.0, and 1.0.0 – which have been found to steal passwords, browser cookies, and install cryptominers.

Unfortunately, that is all it takes to compromise a package on NPM – access to the maintainer’s account. Once compromised, it is up to the community and the package maintainer to quickly detect the issue and act upon it. Luckily, in this case the community acted quickly but some were still compromised and will need to properly clean their environments.

A Better Way

While securing access to the maintainer’s NPM account is a good first step, security should always be implemented in layers – i.e., defense-in-depth. Package signing (and/or code signing) provides a great way for downstream consumers of the package to verify the integrity of the package and who authored it. 

These signing techniques are not new and standards for them have existed for quite some time. In fact, a signing tool for NPM packages had been released back in 2018, but it didn’t get the community buy-in needed and ultimately was rarely used. 

NPM isn’t the only platform not making use of signing. In fact, a good number of systems either don’t provide a standardized approach to sign packages or don’t enforce signature checking. While signing provides strong security assurances, it is only useful if the signatures are checked, preferably at install and/or runtime. Additionally, just as the package maintainer’s account was compromised, an attacker can also compromise the signing keys if they are not properly protected. Always, protect signing keys in a hardware security module (HSM) or key management system (KMS) and provide secure proxied access to those keys. 

Looking to deploy a secure signing solution for your enterprise? Check out GaraSign.