The conventional-changelog Supply Chain Attack

What happened

Attackers used compromised npm credentials to publish a malicious conventional-changelog 1.2.0. Sonatype wrote about it on 14 February 2018 and says the version allegedly included a Monero miner. Sonatype warns that anyone who installed it could run a miner and could pass it to their own downstream users or customers.

A user opened issue 282 on the project on 13 February 2018. It asked the maintainers to say what the malicious version did and whether it stayed inside node_modules. The issue page itself holds the question and not the answer.

A search of public reports gives more detail, but I could not confirm it on a page I fetched. One report says the version went live on 12 February 2018 and ran the miner when a package called the exported function. Treat that as unconfirmed.

The record for this attack says the 1.2.0 tarball gained the ability to write a binary to disk and run it during install. That matches a miner delivery, but no fetched source states it.

Affected versions

• conventional-changelog 1.2.0: malicious, later unpublished
• conventional-changelog 1.1.11: the last clean release before it

Other packages in the conventional-changelog family are not named as affected in the sources I fetched. Tools such as Lerna and standard-version use this package, so check them as well.

Indicators of compromise

No fetched source lists file hashes, domains or addresses for this incident. These signs are general.

• conventional-changelog version 1.2.0 in a lockfile or node_modules
• An unexpected cryptocurrency mining process on a build machine
• High CPU use after an install of the package

How to check

List the installed version in your dependency tree.

npm ls conventional-changelog

Search lockfiles for the bad version.

grep -rn -A1 '"conventional-changelog"' package-lock.json yarn.lock 2>/dev/null | grep 1.2.0

What to do now

1. Update to a later release and reinstall from a clean lockfile.
2. If a build machine installed 1.2.0, look for an unknown mining process and remove it.
3. Rotate credentials that machine held, including npm tokens.
4. If you publish packages, check whether you shipped the bad version to your own users.
5. Turn on two-factor authentication on your npm account.

Vigilance compares the version you trust with a new one and reports the file that gained a new capability. See all attacks.

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: 84

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

CHANGED    package.json
           It now runs a command on its own when it is installed, downloads from the internet and runs other programs. It did not before.

Sources

1. sonatype.com/blog/malicious-intent-open-source-developers-please-protect-your-users
2. github.com/conventional-changelog/conventional-changelog/issues/282