20 ms·
Embedded Malware in Coa
- EdwardDiego 5y agoFor anyone else wondering, Coa is a CLI arg parser for Node.
- haunter 5y agoIs https://www.virustotal.com https://www.virustotal.com good? I saw it referenced but never used
- deleted 5y ago[deleted]
- TonyTrapp 5y agoIt gives you a good glance how likely it is that something is a threat - if an overwhelming majority of AV products detect it, it's quite likely that it's bad, and if only a few products find it, it's either very new or really just a bunch of false positives. Like many things, there's no simple "yes" or "no" answer, thus interpreting Virustotal output still requires some literacy on that topic. The site can also help software vendors to find which AV products reject their software, so that they can file false-positive requests to those AV vendors.
- david_allison 5y agoYes. There's signal if there's detections There's signal if something is old and there's no detections There's no signal if something is recent with no detections
- jart 5y agoIt's very good.
- perihelions 5y agoA separate advisory says the npm package "rc" is also compromised. That's also a highly popular one, according to the npmjs stats (1,323 dependents; 14.2 million weekly downloads). https://github.com/advisories/GHSA-g2q5-5433-rhrf https://github.com/advisories/GHSA-g2q5-5433-rhrf (" Embedded malware in rc" "critical severity") Notable that both advisories link to the virustotal entry for the same file hash (same malware). @dang Could the title be updated to include the names of other affected packages?
- capableweb 5y agoWhat a worthless advisory, how about sharing who could possibly be affected at the very top, or at least anywhere? Going to the issue, it seems the `preinstall` field was changed to `start /B node compile.js & node compile.js",` which means this would only run on Windows machines, everyone else seems to be unaffected. Here is how you can find out if you have the affected package on your machine/instance: find ~/projects/ -name "*coa*" | xargs -I {} jq .version {}/package.json 2>/dev/null 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. Edit: is anyone sitting on the source for `compile.js` as mentioned? Would be interesting to see.
- perihelions 5y ago"Bleeping Computer" published screenshots of it (and also has some analysis), https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/ https://www.bleepingcomputer.com/news/security/popular-coa-n...
- d3nj4l 5y agoThis should be a top-level comment, if not a post in its own right - it explained the entirety of the situation way better than TFA.
- strogonoff 5y agoThat post doesn’t say much about `coa`, besides “new versions started appearing and builds started failing”. The bug report linked from GitHub advisory does a good job of describing the issue, though: https://github.com/veged/coa/issues/99 https://github.com/veged/coa/issues/99
- d3nj4l 5y agoThat's fair, but it describes the change in great detail, and makes it easier to figure out that the primary issue was only on Windows systems.
- keewee7 5y agoThe Coa NPM package has 8.8 million weekly downloads. The vast majority of the downloads is from being a dependency in other packages. Is it possible to check how many downloaded the compromised versions? https://www.npmjs.com/package/coa https://www.npmjs.com/package/coa
- thrdbndndn 5y agoWhat exactly is the malicious code? I assume it's in `compile.js` and only can be found in published (now removed) npm package instead of source code repo?
- perihelions 5y agoThere's some details here: https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/ https://www.bleepingcomputer.com/news/security/popular-coa-n... >"Based on our analysis and information seen thus far, the malware is likely the Danabot password-stealing Trojan for Windows."
- raesene9 5y agoEarlier post (https://news.ycombinator.com/item?id=29111279 https://news.ycombinator.com/item?id=29111279). 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. With 1.7M packages and an ecosystem that favours lots of 3rd party package usage, NPM is a large target. Whilst NPM isn't the only repository to have this kind of issue, it's definitely the largest attack surface.
- strogonoff 5y agoIt seems like this was caught soon because it broke many builds. Imagine if this change was hidden better.
- qwertox 5y agoCorrect: [0] -> Error: Cannot find module '/Users/me/.npm/_npx/27078/lib/node_modules/@svgr/cli/node_modules/coa/compile.js' What happened there was that he got the broken update, 2.0.3 which just referenced and used compile.js, but didn't include the file. Then 2.0.4 came out which included compile.js and compile.bat. Had he updated a couple of minutes later, this error would not have appeared. Not sure if /Users/ is a MacOS thing, but it is a Windows path structure, which might indicate that he was running this on Windows. And in that case he would have been compromised. [0] https://github.com/veged/coa/issues/99 https://github.com/veged/coa/issues/99
- jcfrei 5y agoHow do you add a new version to npm? Was the devs account hacked or how does that work?
- SahAssar 5y agoThe most common ways these things seem to happen is either password reuse with no 2fa or that the npm token (in ~/.npmrc) was harvested by another compromised package/program. IIRC there were a few that were due to phishing too.
- jacques_chester 5y agoAlmost certainly one of these. It's not a typosquatting attack, since it's an existing package. And it's not a repository compromise, since they had to create new versions instead of silently altering an existing version.
- jart 5y agoIt's been suggested a recent Travis CI breach was responsible. https://github.com/veged/coa/issues/99#issuecomment-961696885 https://github.com/veged/coa/issues/99#issuecomment-96169688...
- cloudbonsai 5y agoFor anyone interested, the malicious code can be found in the following link: https://github.com/veged/coa/issues/99#issuecomment-961536877 https://github.com/veged/coa/issues/99#issuecomment-96153687... TLDR: The attacker injected an attack code as coa's `preinstall` script, which executes an obscurely-named file ("compile.bat"). This file is fully obfuscated, but what it does is basically to pull exploit DLLs from the attacker's server and install 'em. I think the fortunate part of this accident is that the attacker failed to deploy the malware in his/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.
- __void 5y agoahhh nice, it's been years since i've seen a obfuscated .bat! very nice use of substring, but a bit too linear... with some input redirects and nested spaced variables it would have become more robust and unpredictable, but i suppose nowadays batch chiselers are rare. edit: by the way in the article is missing a -useless- decoded line (n.4)
- rafaelturk 5y agoAs 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. What is missing is more automated and recurrent checks in all the packages and downstream dependencies.
- rafaelturk 5y agoQuestion for all folks downvoting this. How do you perform same audits with C++ libraries? CocoaPods? Pip?
- zibzab 5y agoThat exists already, for example github does it automatically for you. However, that is dependent on first finding and flagging issues, which is exactly what this post is about.
- 0xdeadb00f 5y agoThis is a really odd comment. Npm, and the strange, insecure JavaScript packaging ecosystem is the reason this happened in the first place.
- Kiro 5y agoWhat makes npm more insecure than other packaging systems?
- jacques_chester 5y agoI would say that it's not that different from others I've seen, just more visible because of the size and activity of the repository. One thing NPM does (and I believe Python too) is to allow install scripts -- this has been a reliable vector for attackers to steal credentials. Not every package repository system has that.
- avereveard 5y agoauthors cannot revoke their compromised keys to immediately halt all distribution, and you don't have any process to verify package<->author ownership beyond the upload secrets.
- _wldu 5y agoIt seems that all of these should be cryptographically signed by a developer's private key before publication and then verified by others before use. Is that not the case?
- qwerty2021 5y agoand who is going to actually audit all that garbage? lmao
- smhg 5y agoThere seems to be a call for action [0] directed at NPM. [0] https://www.change.org/p/npm-please-secure-package-releasing https://www.change.org/p/npm-please-secure-package-releasing
- jacques_chester 5y agoI agree that all software package repositories -- NPM, Rubygems, PyPI, Maven, NuGet, Crates, etc -- should have two minimum baseline security policies: 1. All accounts are MFA, no exceptions. Only CI/CD usecases justify some laxity. Only push tokens should be non-MFA-able for CI/CD purposes, and they should only be usable for push. Tokens should only be obtainable with MFA. Ideally these too would be part of a multi-step OAuth2 or OIDC refresh token to access token flow, so that any given access token is only used once and CI/CD jobs never get to see the refresh token. And while we're on tokens: they should all expire, after a short period of time, without exception. 2. Signing packages is opt-out, not opt-in. The two reasons package signing is relatively rare are that (1) in most ecosystems it is unwieldy, (2) not actually that effective at providing guarantees (self-signed certs are no better than a pinky promise). But once these are solved, and I believe they can be, making signing opt-out means that we'd see signing rate percentages in the 90s, instead of languishing in single digits as they do today. If you work on NPM and would like to swap notes, I would love to talk to you with my professional hat on -- email in profile.
- dromma 5y agoNPM seems to be a lot of issues https://github.com/advisories?page=1&query=malware https://github.com/advisories?page=1&query=malware
- ChrisLTD 5y agoLooks like you might be compromised by this rogue Coa package if you use Windows and you installed or updated npm packages on November 4.
- loa44hh100 5y agoThis makes me appreciate Deno's focus on security. Having things like file and network access 'opt in' seems like a no brainer when we see how easy it is to simply install an npm package and find yourself vulnerable to malware.
- Ginden 5y agoAny protection offered by Deno isn't robust. Only OS-level protection is secure. Any tooling will require access to file system - and file system access is enough to compromise developer system. Let's assume that you have Deno compiler for other language. You run it through seemingly innocent deno run "https:// https://..." --allow-write=. src/ (you use optional parameter to --allow-write, right?). Unfortunately, webpage hosting script was compromised. Now our compiler can write to .git/hooks, .npmrc (npm can do arbitrary script execution in version 6 or lower, even on npm --version), .idea/ etc.
- jacquesm 5y agoSorry, but no. This should not rely on an individual, it should rely on a bullet proof process.
- inbx0 5y agoReminder that people should seriously consider disabling the install-scripts. Personal system-wide config: npm/yarn config set ignore-scripts true -g and add & commit a .npmrc/.yarnrc file with ignore-scripts true 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. And yes yes, as people love to point out, this isn't exactly a bulletproof solution either. The attacker could just put the malicious code inside the package's code and wait for it to be actually executed. But again and again, they don't, they choose to use the package's install scripts as the place to do their dirty work. So in practice this policy would've alrady protected you from who knows how many of these attacks, and my guess is that it'll continue to do so.
- jacques_chester 5y agoI think NPM should consider flipping the default on this. Code that requires an install script should be the odd case that draws scrutiny.
- salzig 5y agoor, cause enabled is the default right now, it's way easier to spot malicious packages right now?
- jacques_chester 5y agoI disagree. We don't know how many such packages run installation scripts without noticeably breaking.
- notpublic 5y agoYou can find out which packages require postinstall scripts and then run them manually: $ grep postinstall node_modules/*/package.json node_modules/esbuild/package.json: "postinstall": "node install.js" $ cd node_modules/esbuild $ npm run postinstall
- peanut_worm 5y agoWhy can’t there just be multiple curated repositories like how Linux distros do it? 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.
- jacques_chester 5y agoScale, basically. There are too many packages to fully curate.
- chakkepolja 5y agoThere are just too many micropackages to properly look at. A basic react app created using official method (CRA) was 200MB something last time I tried. NpmJS echo system is cancer.
- r6203 5y agoAre other languages/runtimes also that risky as Node with npm? npm packages seem like a cardhouse. I know that the node_modules folder is often times criticized for its sheer amount of 3rd party libraries. Is it because of JavaScripts "missing" standard library?
- jacquesm 5y agoNpm is pretty unique in the low bar it sets for security. What is really frightening is how these cases are discovered, more or less by accident, rather than by some kind of verification process that ensures this simply can not happen before QA catches it on the way to a release.
- Aulig 5y agoI think pip occasionally has comparable attacks, last I heard they were mostly from typo-squatting packages though.
- chakkepolja 5y agoI will be downvoted to hell for saying this. But javascript ecosystem is where most newbies come. (Low barrier to entry and it also seems hip). With no regards to security, maintainability or reliability, fashion chasing blog-happy hipsters. The amount of churn in JS ecosystem, security incidents like this and general crappiness of websites can be generally explained by how immature these hipsters are.
- heurisko 5y agoPHP has a similarly low barrier to entry, but doesn't seem to suffer as much as JS. Perhaps because dependencies are more curated in PHP due to clusters of dominant frameworks, rather than a proliferation of smaller libraries.
- chakkepolja 5y agoNot disagreeing with organization around frameworks in PHP, but apparently PHP suffered a lot from low barrier, in terms of security especially. That was the time package management wasn't that widespread yet, which IMO limited this kind of stuff. But there were, for sure, many applications where PHP could be blamed for security incidents and general unreliability. PHP improved quite well though. Now PHP isn't hip anymore, node js is super popular hip thing, and every tom dick and harry from art school in US or 3rd tier engineering college in India will slap together three todo list applications on Resume and wants to call himself full stack developer. Internet is fast, hardware is fast, no one cares about pile of dependencies sitting beneath them. Add to that resume driven development where every JS wants to write libraries and become github-famous. 30-line libraries will be considered a joke and it will be shameful to brag about such things in any other ecosystem.
- ricksunny 5y agoMy read of the headline was that this was malware in embedded hardware electronics systems, or describing some exploit / attack surface for same. 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?
- eqmvii 5y agoIf I'm reading this correctly, the malicious code was new (higher) versions of the releases. Would this mean any project using a package.lock/yarn.lock was 'safe' going through deploys? So only new installs and builds without lock files could have grabbed the higher version? If so, I wonder if it's hard or impossible to swap a release version on NPM. Seems like that would hit a much wider audience before being detected.
- ryukafalz 5y agoYour periodic reminder that modules have way more authority than they need by default, and that there are ways to fix this: https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... (Of course this 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.)
- BonoboIO 5y agoUsing npm is like russian roulette. Someday it makes your head hurt really bad!
- joshuanapoli 5y agoHow long were the compromised versions available from npm?