That was the reality for a lot of companies after the ua-parser-js supply chain attack. On October 22 three malicious versions of the popular package ua-parser-js were released. A package which has almost 8M weekly downloads. If your company has used compromised versions of this package directly or indirectly, consider your system as fully compromised.
So you might think how the heck is this even possible? After all, “it’s just JavaScript”?
The maintainer account for ua-parser-js was taken over, meaning attackers had control and deployed malware versions. These versions in turn were downloaded by many users around the world. Silently the malicious versions installed a trojan and a crypto mining application.
The impact is critical with the file system made public, screenshots taken as well as downloading and execution of unknown binaries.
The result
A lot of companies are still vigorously trying to figure out if they were exposed. Often by spending resources and money on manually making sure no one inside their organization used the affected malicious versions.
I fully understand the need for companies to be sure they’re not affected - but this problem also indicates that companies lack proper control over external dependencies. An investment into proper protection is something that would save money in the long run.
TL;DR
Malicious and packages with vulnerabilities. You need to protect you team, environments and organization without depending on specific individuals when it comes to dependency security. Here's a free downloadable checklist (PDF) .
How could this happen?
The component ua-parser-js is used to detect browser user data and is used indirectly by many others. For example the popular web ui framework angular.js has a dependency to test framework karma which in turn has a dependency to ua-parser-js. This is commonplace in JavaScript where applications on average depend on up to 700 other components - and most of these are indirect.
As you know, to be able to use a JavaScript app, you need to install its dependencies first. Something which is very easy, but where things can go really wrong. If the packages you’re installing, or any of the indirect dependencies, contain vulnerabilities, then you might be out of luck.
It’s crucial to secure your whole software supply chain, including software build environments (CI/CD), test, development and similar.
The problem lies in that a lot of environments are not restricted in what packages can be downloaded and installed. And with as little as 10% of all maintainers using two-factor authentication, the companies need to take dependency security as a serious threat and act accordingly.
So, what's the solution?
Quite a few people have contacted us asking how this could have been prevented and how to stay secure.
1. You need automated tooling where you are able to secure your existing workflows. This way developers and systems are secured by default. Unfortunately, many companies fail in this regard which is a major gamble. It works until it no longer does.
2. Companies need to enforce dependency policies and make sure they have the right tools to be able to control what packages are allowed in the organization. Make sure neither automated systems nor developers install the latest versions of packages without first taking a conscious decision. Avoiding outdated and vulnerable components is of course not an option either!
3. Companies need tooling to keep track of what components are used and where. Manually reviewing every piece of software or line of code is neither efficient nor possible in many cases when an incident occurs. Be proactive and secure your supply chain before it’s an emergency.
Download a checklist on dependency security
We are in the final sprint of the Cybersecurity Awareness Month - so why not spread some awareness 😊. Here's a one page cheat sheet on what measures you can take to protect your organization, link to blog post with a free downloadable PDF.
Top comments (3)
Thanks for reading and commenting! Dependabot and services like Bytesafe help. It’s important to protect the whole organization.
If developers happened to upgrade their application dependencies before the vulnerabilities were known - then they would easily be compromised. What I’m saying is that dependency security is very often dependent on individual developers, rather than company-level policies, which require some sort of dependency firewall to enforce.
This is a great article! Great stuff!
Glad you like it @cdthomp1 ! If you're interested in more in-depth info, here's a blog post you might be interested in: bytesafe.dev/posts/case-study-prot...