The NPM security team removed a package masquerading as a cookie parser that actually contained a malicious backdoor, along with three other packages depending on it. The backdoor allowed attackers to inject arbitrary code into a running server and execute it.
The NPM report established the getcookies package contained malicious code that parsed the HTTP header looking for data formatted as gCOMMANDhDATAi. Three different commands were available:
0xfffeto reset the code buffer.0xfffato execute the code located in the buffer. This was accomplished by executingvm.runInThisContext.defaultto load the remote code into memory for execution.
Along with getcookies, three other packages were removed from the registry: express-cookies, http-fetch-cookies, and the popular albeit deprecated mailparser.
According to the NPM staff :
No packages published to the npm Registry used the malicious modules in a way that would have allowed the backdoor to be triggered.
This leaves open the possibility, though, that external applications using the malicious packages are at risk of being exploited or have actually been.
To add some mystery to the whole story, the mailparser package, which still receives about 64,000 weekly downloads, did not use the malicious module in any way. According to the NPM security team, this could be explained as a preparatory step to be able to carry through an attack in the future, or as a way to bump up the reputation of get-cookies and http-fetch-cookies and trick more developers into using them.
This announcement sparked many reactions among Node developers. While it is generally agreed that this kind of issue is not exclusive of NPM, several commenters argued that some traits specific to NPM make it more likely that such issues actually happen. In particular, given NPM packages tendency to be small and focus on a reduced set of features, it is usually the case that an application depends on a very large number of external modules, often hundreds of them. This makes it particularly hard to audit all of the dependencies to ensure they are all legit. Additionally, NPM allows developers to express a dependency though a minimum version, e.g. mailparser@^2.2.0, which means any higher version that does not change the major number is considered compatible and thus installed when running npm install. This makes an even harder case for dependency audits.
It is not clear how a successful package such as mailparser, that is not maintained anymore and had received no updates for a few months, got three new versions that include an unused dependency. Indeed, mailparser GitHub repository does not show any sign of the changes that went into the malicious versions published on NPM, 2.2.1, 2.2.2, and 2.2.3. Thus, it remains to be seen whether mailparser author was tricked into adding the malicious dependency, or some yet unknown NPM vulnerability was exploited to publish new versions without him knowing. InfoQ will keep reporting on this as soon as new details become available.
