What I’ve Got from Analyzing ~1K npm Packages Vulnerabilities
By: Ronauli Silva
Tags: Security, Application Security, Data Analysis, NPM, Vulnerability

Background

Last week, I got to deliver a tech talk. One of the topic is node security issues. Me, however, with my skeptical mind about security in our current tech stack, decided to pick this topic.

I’ve been throwing myself into node security articles for past months. Some wise words from my mentor, “you should really know tech stacks you use”, and it also pinged my common sense: How about vulnerabilities of the npm packages we are using? Is it well-tracked? How do I prevent myself from getting a serious trouble?

So, I’m looking for similar articles about seeing npm package’s vulnerabilities from broader perspective, but I found none. It’s strange, isn’t it, for the most known tech-stack in the world, no one wrote its vulnerabilities from the bigger picture.

Audience

This article is best fit for nodejs developers and package maintainers who uses public packages broadly across repositories, who often type npm i on their console. Especially to those who cannot tolerate security hole in their system— like financial institutions, federal data centers, sensitive-related data like hospitals, education institution and so on.

Analysis Method

There are several options for gathering vulnerability reports, but my choice goes to Snyk and Node Security Platform. NSP is interesting since it is the official — acquired by npm itself, but the strange things is Snyk got more vulnerabilities reports then NSP.

Here is the flow for gathering the data, in a nutshell

Gathering the data — in a nutshell

Finally, the final raw data shaped like this:

The CSV data contains each column of these

Findings

1. Node Modules are Growing Continuously

Module Counts of NPM, from first day of its life (credit: modulecounts)

Either a curse or a blessing, but open-source contributors are happy to add the numbers everyday. We get new 500++ packages daily, and this numbers is still counting.

2. Almost half of issues are unpatched

3. Directory Traversal and XSS are on top of the keyword matches.

Directory traversal may not critically impacted your system, but it helps the people with malicious intent obtaining required information regarding your system, and XSS is everyone’s nightmare.

3. Longest delivered patch is 3 months (and still counting), while the fastest one is on 5 days.

4. It could have been dependencies of your dependencies.

Thankfully, npm audit checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies (source).

What can I do to prevent malicious package?

Regularly scans (and update) your dependency. Or you can run npm audit every iterations of delivery. Do not let them stale.

every iterations of delivery. Do not let them stale. Before installing anything, check the package stat first. When was it last updated? Does the author actively contribute/moderate the package?

If it’s a bit old and unmaintained, you can look for alternatives with same functionality.

If it’s a bit old and unmaintained, you can look for alternatives with same functionality. Stay up to date with your tech-stack news feed.

I got malicious package now. What should I do?

Measure the impact. If it’s major, proceed to next step, but anyway you should discuss with Product Owner regarding the pros or cons of this fixes and re-prioritize with your project delivery.

Check logs — do some forensic. Is there any indication someone has poking the hole? If yes — proceed to next step. If no, add it to your backlog and fix it within fixed schedule.

Fix it. Either upgrade the malicious package to safe version (if maintained) — or fork the package, and patch the hole.

Do the prevention steps mentioned above, after it is fixed.

Takeaways

Broken window principle: one broken window would soon lead to many more windows being broken. It is easy to overlook security issues during feature delivery, especially when you’re on tight deadline. But remember, one security hole leads to another.

Never compromise on security — by neglecting security check is you’re intentionally putting your customer’s at risk. Even though you may not able fix it during this delivery, make sure you have a backlog with fixed timeline. Or do not deploy it at all.

In my personal experience — this type of vulnerability is rarely caught during penetration testing. They usually picked up missed things in your flow or some basic security, but not as deep as what we have discussed here.

Technical-wise, before we arrive at one specific malicious package is being used (black-box) at our system’s target, estimate how long it should be to do the homework & research (system elicitation, data gathering). That should take quite some time, right?

— —

PS: One of my habit is learn the reverse way. So if I want to avoid malicious package, I’d rather know how to create malicious package first. I will write how to write malicious package in next section. See ya!