Whenever I give a talk about software supply chains, I always enjoy asking the audience: Would you allow some random stranger off the street to commit their code to your application repository?
Thankfully the answer is a resounding no. But if we then flip this to how software libraries are used within applications, this is often the exact case. Libraries are pulled directly from public repositories, to which anyone can submit their artifacts with little to no scrutiny. Developers are placing trust in complete strangers to include their code (via these libraries) and incorporate it into their applications.
Don’t believe me? May I present to you my favorite example: the totally pointless NPM library: “-”. Yes, that’s really the name of the library!
I first came across this library via a report on Bleeping Computer. Besides the name, the other thing about this library is that it does absolutely nothing. It provides zero value. Below is a screenshot of the contents of the library:
Image 1: Screenshot of the contents of the NPM library, “-”
There is only a single source file, index.js, and as you can see by the screenshot, it is absolutely useless. You can view the library itself on the official NPM repository. Thankfully, this library has recently been taken over by the official maintainers of NPM (npm-support):
Image 2: Screenshot showing the current ownership of the NPM library, “-”.
This is important because while there is only a single version of this library that achieves nothing, it is difficult to tell what the original intentions of this library were. Perhaps the author wanted to use this as an experiment; or worse, perhaps they wanted this library to be included to the extent that it currently is and then introduce a malicious payload into it. Regardless, the original intentions behind it remain a mystery.
Back to the library itself. The first, and only, version was published two years ago. Using the WayBackMachine, we can see this library was first archived by this service towards the end of 2020:
Image 3: WayBackMachine archive of the NPM package – on the official NPM repository.
At that time, there were only 9,351 weekly downloads and 26 libraries that included this library as a dependency (and it had been around for eight months at this time):
Image 4: Screenshot of the WayBackArchived page of the NPM library “-” on 8 August 2020.
Now fast forward to the current figures: 19,669 weekly downloads and 74 libraries include this library as a dependency:
Image 5: Screenshot of the current statistics of the NPM library “-”.
Even following Bleeping Computer’s article published in August 2021, there has been an increase of 5,025 weekly downloads and 18 dependent libraries! All for a software library that provides absolutely no value.
So, to the whole point of this post: we can clearly see that many are blindly using libraries without performing the appropriate review. Just because a library is hosted on a public repository does not necessarily mean that it should be trusted. Oftentimes this code has been created by a complete stranger.
In the interests of your organization, it should be appropriately vetted to ensure that it is not harbouring something malicious and that it actually serves a legitimate purpose. Thankfully such instances are rare; however, they are growing in number – especially when it comes to legitimate libraries that have been compromised by attackers. The most recent examples include the coa library, as well as the ua-parser-js library, which was recently hijacked and used to install malware.
In fact, just recently The Register reported that attackers were actively targeting a popular library for Roblox gamers. In this attack, the cyber criminals attempted to create malicious packages with very similar names to the official package (an attack known as typosquatting). Unfortunately, with the sheer explosion of the usage of libraries, this also helped to compound the issue and allow attackers to stay undetected in the expanding volume of libraries now being used by applications.
This is why it is extremely important for organizations to, at the very least, have some appropriate package and dependency management in place. Being able to determine what applications are using which libraries, and more specifically which versions of those libraries is really your first line of defense. The next step is to put appropriate safeguards in place that allow some control over what libraries developers can use within their applications. There are products out there that allow for this. My advice, however, is to approach this cautiously. Due to the immense number of libraries used, you will most likely want to start off slowly. For instance, block libraries with a CVSS rating over a certain threshold, then move your way on from that. Otherwise, your security team will become overwhelmed, and your development teams will get held up. Most importantly, have development teams do some homework as well, ensuring that the libraries they use are legitimate – and they’re not blindly including any library that they come across.
If you’d like to learn more about what we’ve discussed in this blog, and you have an Immersive Labs AppSec license, check out our labs on npm: Package Hijack – UAParser.js and Dependency Confusion.
Otherwise, why not book a demo to get the full low down on our platform?
Sean Wright,
Principal AppSec Engineer, Immersive Labs
@seanwrightsec
