Just before the New Years I published 140+ advisories on Node.js modules. I’ve been researching ways to compromise developers & node.js applications without compromising the npm registry or their CDN.
To start, I looked for modules with install hooks that downloaded and executed or used resources from the internet over HTTP, an insecure medium that’s susceptible to interception and manipulation, also known as a machine-in-the-middle attack.
What is Machine-In-The-Middle (MITM)?
Machine-in-the-Middle is a type of attack in which the attacker is able to put themselves between two parties and intercept and influence the traffic between the two parties.
This attack can affect the confidentiality, integrity, and availability of data you or your application is expecting. Explaining how an attacker might actually gain this kind of position in a network and exploit the flaw is beyond the scope of this post, but know that the only pre-requisite is that they are either on the same local network as you, or positioned somewhere upstream. A common scenario for an attack like this to be exploited would be working from a public network, like a coffee shop or library.
The example video above shows using bettercap to manipulate the files chromedriver is downloading during install. The end of the video shows the exploit running on a yarn install, to demonstrate that it is not isolated to npm.
What to do as a module author?
As a module author or maintainer you want to always make sure that when you download resources from the Internet you do so over HTTPS and you don’t allow for invalid certs to be ignored.
Additionally you will want to use a hashing function like sha256 to verify that the content you downloaded is what you expected (i.e. the hash matches).
You will also want to be sure to host the hashes over HTTPS as well, and preferably on another host in the event that the host serving the file is compromised.
For example, the hashes for npm packages are downloaded via the package json data from the npm registry, but the tarball comes down from their CDN.
Don’t take a URL you have configured at face value. I’ve run into at least one instance where tarballs and hashes were downloaded from a https:// URL but the URL redirected to an insecure http:// endpoint completely compromising the download and hash verification process. For this reason, you should always attempt to download the file from the configured URL first and verify that it doesn’t pass through any insecure redirects. Once a request passes through an unencrypted connection, the entirety of the rest of the request sequence cannot be trusted.
Module user?
If you are a module consumer, ultimately you need to be proactive in making sure that your applications aren’t vulnerable to exploits like this. When 140+ vulnerabilities were released in a single day, and it only takes one exploit to compromise your app, manually ensuring modules are updated in a timely manner is a lot of work and risk to take on.
Originally posted on Medium