The mailparser and getcookies npm Supply Chain Attack

What happened

An attacker hid a remote code execution backdoor in a chain of npm packages and then added the chain to mailparser. The npm security report describes it.

The chain was mailparser to http-fetch-cookies to express-cookies to getcookies. The last package had no real function. It read HTTP request headers for a pattern of the form gCOMMANDhDATAi. The control codes were 0xfffe to reset a buffer and 0xfffa to run the buffered code with vm.runInThisContext. Any other code loaded remote code into memory. An Express app that used the module directly can run attacker code from a web request.

npm got the first report at 5:23 AM PDT on 2 May 2018. The team removed the three malicious packages at 7:01 AM and the three mailparser versions at 7:26 AM. It also revoked the author's tokens. BleepingComputer reports that the account that published the packages was named dustin87. It reports that mailparser had about 66,000 weekly downloads. It also reports that no exploitation attempts were documented.

npm notes that the mailparser versions did not use the module in any way. So mailparser users were not exposed by the backdoor itself. The case still matters. A new dependency that parses requests and runs code is a capability that mailparser never had. Vigilance reports a change like this when it compares the trusted version with the new one.

Affected versions

mailparser 2.2.1, 2.2.2 and 2.2.3 contained the dependency. Version 2.2.0 is clean.

• mailparser 2.2.1, 2.2.2, 2.2.3: removed from npm.
• http-fetch-cookies: all versions removed.
• express-cookies: all versions removed.
• getcookies: all versions removed.

mailparser was rolled back to 2.2.0, per BleepingComputer.

Indicators of compromise

• Any of the packages getcookies, express-cookies or http-fetch-cookies in node_modules or in a lock file.
• A mailparser entry at 2.2.1, 2.2.2 or 2.2.3 in a lock file.
• A vm.runInThisContext call in a package that has no reason to run code.
• The publisher account dustin87.

How to check

List the three malicious packages in your dependency tree and check the mailparser version.

npm ls getcookies express-cookies http-fetch-cookies mailparser
grep -nE "getcookies|express-cookies|http-fetch-cookies" package-lock.json

An empty result for the first three packages means the chain is not installed. A mailparser version of 2.2.0 is clean. Run the check in each project and each CI cache.

What to do now

1. Move mailparser to 2.2.0 or a later release that does not contain the chain.
2. Delete node_modules and install again from a clean lock file.
3. Stop use of getcookies, express-cookies and http-fetch-cookies. npm removed all versions.
4. If an Express app used the packages directly, treat the server as exposed. Review the logs for odd request headers and rotate secrets.
5. Review new transitive dependencies when a minor version adds them.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 49

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    package.json
           It now downloads from the internet and runs other programs. It did not before.

Sources

1. blog.npmjs.org/post/173526807575/reported-malicious-module-getcookies
2. bleepingcomputer.com/news/security/somebody-tried-to-hide-a-backdoor-in-a-popular-javascript-npm-package/
3. theregister.com/2018/05/04/cookie_compromise_caper_caught_and_crumbled/