Embedded Malware in Coa

For anyone interested, the malicious code can be found in the following link:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;veged&#x2F;coa&#x2F;issues&#x2F;99#issuecomment-961536877" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;veged&#x2F;coa&#x2F;issues&#x2F;99#issuecomment-96153687...</a><p>TLDR: The attacker injected an attack code as coa&#x27;s `preinstall` script, which executes an obscurely-named file (&quot;compile.bat&quot;). This file is fully obfuscated, but what it does is basically to pull exploit DLLs from the attacker&#x27;s server and install &#x27;em.<p>I think the fortunate part of this accident is that the attacker failed to deploy the malware in his&#x2F;her first attempt; v2.0.3 only contained the half of the changeset that the exploit needs to work (which accidentally broke tons of CI builds); So some developers could notice that something is wrong a bit early.

Earlier post (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29111279" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29111279</a>).<p>The thing that should be causing concern is not so much these very loud obvious attacks, but how many better attacks that are harder to detect, are currently happening.<p>With 1.7M packages and an ecosystem that favours lots of 3rd party package usage, NPM is a large target. Whilst NPM isn&#x27;t the only repository to have this kind of issue, it&#x27;s definitely the largest attack surface.

Reminder that people should seriously consider disabling the install-scripts.<p>Personal system-wide config:<p><pre><code> npm&#x2F;yarn config set ignore-scripts true -g </code></pre> and add &amp; commit a .npmrc&#x2F;.yarnrc file with<p><pre><code> ignore-scripts true </code></pre> Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those specific packages.<p>And yes yes, as people love to point out, this isn&#x27;t exactly a bulletproof solution either. The attacker could just put the malicious code inside the package&#x27;s code and wait for it to be actually executed. But again and again, they don&#x27;t, they choose to use the package&#x27;s install scripts as the place to do their dirty work.<p>So in practice this policy would&#x27;ve alrady protected you from who knows how many of these attacks, and my guess is that it&#x27;ll continue to do so.

A separate advisory says the npm package &quot;rc&quot; is also compromised. That&#x27;s also a highly popular one, according to the npmjs stats (1,323 dependents; 14.2 million weekly downloads).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;advisories&#x2F;GHSA-g2q5-5433-rhrf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;advisories&#x2F;GHSA-g2q5-5433-rhrf</a> (<i>&quot; Embedded malware in rc&quot; &quot;critical severity&quot;</i>)<p>Notable that both advisories link to the virustotal entry for the same file hash (same malware).<p>@dang Could the title be updated to include the names of other affected packages?

For anyone else wondering, Coa is a CLI arg parser for Node.

This makes me appreciate Deno&#x27;s focus on security. Having things like file and network access &#x27;opt in&#x27; seems like a no brainer when we see how easy it is to simply install an npm package and find yourself vulnerable to malware.

Are other languages&#x2F;runtimes also that risky as Node with npm?<p>npm packages seem like a cardhouse.<p>I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts &quot;missing&quot; standard library?

It seems like this was caught soon because it broke many builds. Imagine if this change was hidden better.

What a worthless advisory, how about sharing who could possibly be affected at the very top, or at least anywhere?<p>Going to the issue, it seems the `preinstall` field was changed to `start &#x2F;B node compile.js &amp; node compile.js&quot;,` which means this would only run on Windows machines, everyone else seems to be unaffected.<p>Here is how you can find out if you have the affected package on your machine&#x2F;instance:<p><pre><code> find ~&#x2F;projects&#x2F; -name &quot;*coa*&quot; | xargs -I {} jq .version {}&#x2F;package.json 2&gt;&#x2F;dev&#x2F;null </code></pre> Assumes you have `find`, `xargs` and `jq` installed, will print all versions of coa it can find. Seems any version above 2.0.3 is bad.<p>Edit: is anyone sitting on the source for `compile.js` as mentioned? Would be interesting to see.

It seems that all of these should be cryptographically signed by a developer&#x27;s private key before publication and then verified by others before use. Is that not the case?

NPM seems to be a lot of issues <a href="https:&#x2F;&#x2F;github.com&#x2F;advisories?page=1&amp;query=malware" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;advisories?page=1&amp;query=malware</a>

The Coa NPM package has 8.8 million weekly downloads. The vast majority of the downloads is from being a dependency in other packages.<p>Is it possible to check how many downloaded the compromised versions?<p><a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;coa" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;coa</a>

Why can’t there just be multiple curated repositories like how Linux distros do it?<p>Having NPM just be a free-for-all is a ticking time bomb. It is only a matter of time before an event like this results in something very serious.

Your periodic reminder that modules have way more authority than they need by default, and that there are ways to fix this: <a href="https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-event-stream-incident-45653ecbda99" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-even...</a><p>(Of course <i>this</i> malware was in a preinstall script, which should also be disabled... but any module you import in a node app can do bad things when you run your app, preinstall script or no.)

If I&#x27;m reading this correctly, the malicious code was new (higher) versions of the releases.<p>Would this mean any project using a package.lock&#x2F;yarn.lock was &#x27;safe&#x27; going through deploys? So only new installs and builds without lock files could have grabbed the higher version?<p>If so, I wonder if it&#x27;s hard or impossible to swap a release version on NPM. Seems like that would hit a much wider audience before being detected.

My read of the headline was that this was malware in embedded hardware electronics systems, or describing some exploit &#x2F; attack surface for same.<p>May I suggest that a clearer phrasing would be ‘Malware embedded in Coa’? Or is ‘embedded malware’ a somewhat confusing term-of-art in the cybersec community?

As bad as this may sound, this is why a love Open Source, npm and the JavaScript ecosystem. It super easy to audit and check the code.<p>What is missing is more automated and recurrent checks in all the packages and downstream dependencies.

Using npm is like russian roulette. Someday it makes your head hurt really bad!

What exactly is the malicious code? I assume it&#x27;s in `compile.js` and only can be found in published (now removed) npm package instead of source code repo?

Is <a href="https:&#x2F;&#x2F;www.virustotal.com" rel="nofollow">https:&#x2F;&#x2F;www.virustotal.com</a> good? I saw it referenced but never used

Looks like you might be compromised by this rogue Coa package if you use Windows and you installed or updated npm packages on November 4.

How do you add a new version to npm? Was the devs account hacked or how does that work?

How long were the compromised versions available from npm?