Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ElectroVolt: Pwning Popular Desktop Apps While ...

ElectroVolt: Pwning Popular Desktop Apps While Uncovering New Attack Surface On Electron

Electron based apps are becoming a norm these days as it allows encapsulating web applications into a desktop app which is rendered using chromium. However, if Electron apps load remote content of attackers choice either via feature or misconfiguration of Deep Link or Open redirect or XSS it would lead to Remote Code Execution on the OS.

Previously, it was known that lack of certain feature flags and inefficiency to apply best practices would cause this behavior but we have identified novel attack vectors within the core electron framework which could be leveraged to gain remote code execution on Electron apps despite the feature flags being set correctly under certain circumstances. This presentation covers the vulnerabilities found in twenty commonly used Electron applications and demonstrates Remote Code Execution within apps such as Discord, Teams (local file read), VSCode, Basecamp, Mattermost, Element, Notion, and others.

Need help? https://electrovolt.io
https://blog.electrovolt.io/

Mohan Sri Ramakrishna Pedhapati

September 12, 2022
Tweet

Transcript

  1. Electrovolt Pwning popular desktop apps while uncovering new Attack Surface

    on Electron Aaditya Purani, Mohan Sri Rama Krishna, Max Garrett, William Bowling
  2. whoami • Mohan Sri Rama Krishna Pedhapati aka s1r1us •

    I like browsers, CTFs and blockchain these days. • Web/Application Security @ Cure53 • Some Highlights: • 2021 – 4th Place of Top 10 Web Hacking Techniques. • Research published at Defcon, BlackHat and BSides Ahmedabad. • Captain of CTF Team Invaders @s1r1u5_
  3. Agenda • Electron Introduc-on • Case Studies • Known Electron

    Bugs • New A9ack Surface with compromised Renderers • Mi-ga-ons • Patch Gap • Conclusion
  4. What is Electron? • Popular Cross-Platform Desktop Application Framework •

    Chromium + Node JS = Electron • Used by VSCode, Teams, Discord, Slack and 500+ more Applications …
  5. Main Process: Menu, Tray, Node, ipcMain, creates Renderer Process using

    BrowserWindow Renderer Process: DOM API, Node.js API, ipcRenderer
  6. Sandboxed Renderer: (new BrowserWindow({ webPreferences: { sandbox: true, nodeIntegration: true,

    contextIsolation: false } })).loadURL(‘//example.com’) Non-Sandboxed Renderer: (new BrowserWindow({webPreferences:{ sandbox: false, nodeIntegration: true, contextIsolation: false } })).loadURL(‘//example.com’) XSS == RCE XSS == RCE
  7. Terminologies • Node Integration => NI • Context Isolation =>

    CI • Node Integration in Workers => NIW • Node Integration in Subframes => NISF (Exposes preload) • Sandbox => SBX
  8. NI: true, CISO: false, SBX: false • Easy to get

    a shell as node is exposed to the renderer • Find a way to embed your JavaScript Non-Sandboxed Renderer: (new BrowserWindow({webPreferences:{ sandbox: 0, nodeIntegration: 1, contextIsolation: 0 } })).loadURL(‘//example.com’)
  9. • Bypasses “Trust Codebase” checkbox, allowing RCE to work even

    if you open untrusted codebases. • Limited markdown XSS -> RCE chain Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908 Case Study 1: VS Code RCE bypassing Restricted Mode (CVE-2021-43908)
  10. • If CISO is enabled, node is not directly available

    in renderer. • Two ways to exploit 💡 - Can use Render Exploit because no sandbox - Disable Context Isolation somehow (more about this in coming slides) NI: false/true, CISO: true, SBX: false
  11. 1. Was using Electron/12.14.1, Chrome/83.0.4103.122 2. XSS in one of

    the video embeds but Iframes are sandboxed in electron. 3. Abused Electron new-window handler mis-config in Discord to open https://example.com/exp.html in new Electron Window which has no-sandbox enabled 4. Run chrome v8 renderer exploit (CVE-2021-21220) to get RCE Case Study 2: Discord RCE
  12. • Sandbox is enabled on renderers(seccomp, win32k lockdown) • No

    node modules exposed in renderer • No Isolation between website you load and preload/Electron internal code NI: false, CISO: false, SBX: true
  13. • Application • Preload.js • Electron Internal code • Application

    • Preload.js • Electron Internal code Electron App with Node Integration disabled & Context Isolation disabled
  14. How to get shell? Electron <10 • Use prototype pollution

    gadget to leak remote/IPC module. • Use Remote Module which gives node access. Electron 10<version<14 • Use prototype pollution gadget to leak remote/IPC module. • If Remote Module Explicitly Enabled • IPC Misconfiguration
  15. How to get shell? Electron >14 • Use prototype pollution

    gadget to leak IPC module. • Remote is deprecated • Only IPC Misconfigurations on the main process
  16. sandbox: true, nodeIntegration: false, contextIsolation: false ⚠ Leaks IPC Renderer

    Internal (i.e., ELECTRON_*, GUEST_*, etc. channels) and IPC Renderer (developer defined channels) Prototype Pollution
  17. Ref: https://github.com/electron/electron/security/advisories/GHSA-mpjm-v997-c4h4 (Credits to nornagon) Sandboxed renderers can obtain thumbnails

    of arbitrary files through the nativeImage API Windows: IThumbnailCache::GetThumbnail OSX: QLThumbnailCopyImage CVE-2021-39184
  18. 1. Using Electron <15 2. XSS in Renderer using 0day

    in CKEditor (CVE-2021-44165) 3. On new windows - CISO is disabled, and Sandbox is Enabled. Case Study 3: Local file read in MS Teams
  19. 4. Used prototype pollution gadget to leak IPC using XSS.

    5. Send an IPC to browser process which reads given file in file path. (CVE- 2021-39184) Case Study 3: Local file read in MS Teams
  20. • Used by most of the applications • No node

    modules exposed in renderer • IPC cannot be leaked via prototype pollution as CI is enabled • Sandboxed NI: false, CISO: true, SBX: true
  21. • nodeIntegra*onInSubFrames – Experimental op*on for enabling Node.js or preload

    support in sub-frames such as iframes and child windows For every sub-frames: • If NI is enabled and sandbox is disabled, then both preloads and Node.js will be available • If NI is disabled and sandbox is disabled/enabled, then all your preloads will load What is nodeIntegrationInSubFrames
  22. Renderer Process preload.js (Isolated World/context) Main Process Renderer Process (//google.com),

    Main window Iframe in Main Window (//pwn.af) – Error Thrown nodeIntegrationInSubFrames: false
  23. Renderer Process preload.js (Isolated World/context) Main Process Renderer Process (//google.com),

    Main window Iframe in Main Window (//pwn.af) – Works nodeIntegrationInSubFrames: true
  24. nodeIntegraGonInSubFrames: false • Most of the time we get XSS

    in the subframe or iframes • And nodeIntegrationInSubFrames is mostly disabled • No access to contextBridge exposed APIs 😔
  25. Implementa)on of Node Integra)on in SubFrames Electron patches blink WebPreferences

    and adds settings like node_integration_sub_frames, context_isolation, etc.
  26. Enabling NISF using renderer exploit • An astute reader will

    notice that the check is on the renderer process. • Use renderer exploit and we can set node_integration_in_sub_frames to 1 😈 Reference: https://github.com/electron/electron/blob/bd10b19b0cdc46cdbadb570af89305e64541b679/shell/renderer/electron_sandb oxed_renderer_client.cc#L217
  27. Case Study 4: Element RCE (CVE-2022- 23597) • Using Chrome/91.0.4472.164,

    Electron/13.5.1. • XSS on embed via deep link mis-config. • No contextBridge API on embed. • Run Chrome Renderer v8 Exploit to expose contextBridge API on embed.
  28. Preload.js Main.js Main window Website Iframe userDownloadOpen (RCE sink!) send(channel,

    args..) window.electron.send Our XSS (No API access) Preload.js Main window Website Stage-1: v8 Exploit Stage-2: Create Iframe To access send send(channel, args..) window.electron.send our XSS in iframe 😈 userDownloadOpen (RCE sink!) Main.js NISF 0 to 1 Goal: Pass file://Calc.app
  29. 1 2 3 If context_isolation on WebPreferences is true, create

    isolated context Implementation of Context Isolation
  30. • Same story using chrome v8 renderer exploit and we

    can set context_isolation to 0 😈 Reference: https://github.com/electron/electron/blob/35ac7fb8e61be744206918684a6881d460591620/shell/renderer/electron_render_frame_o bserver.cc#L133 Disabling CISO using Renderer exploit
  31. Preload.js Main.js Main window Website Iframe userDownloadOpen (RCE sink!) openExternalUrl

    (only allows https proto) window.electron.openExternal Url Our XSS (No API access) Preload.js Main window Website Iframe openExternalUrl (only allows https proto) window.electron.openExternal Url Our XSS (Access to openExternalUrl API) userDownloadOpen (RCE sink!) Main.js NISF 0 to 1 Goal: Pass file://Calc.app
  32. Preload.js Main.js Main window Website Stage 1 V8 Exploit userDownloadOpen

    (RCE sink!) openExternalUrl (only allows https proto) window.electron.openExternal Url Main.js Goal: Pass file://Calc.app CI 1 to 0 Stage 2 PP Exploit Redirect Iframe Leak IPC 😈
  33. • Using a pretty old version of Electron (11.4.5) with

    remote module enabled. • XSS in one of the embed. • Leverage it to disable Context Isolation • Leak Remote Module using Prototype Pollution Gadget • Get shell remote.process.binding(‘spawn_sync’) Case Study 6: RCE in Undisclosed app
  34. • In old electron, context_isolation is implemented differently. • Doesn’t

    use WebPreferences • Stores on renderer_client_ 1 2 Disabling CISO on old electron version
  35. • Prototype Pollution Gadget only work if the current window

    is MainFrame (top window) • We can make ourselves top by overwriting IsMainFrame to 1 😈 Reference: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/frame.h;l=139?q=ismainfram e&ss=chromium Disabling CISO on old electron version
  36. Patch Gap • There is a noticeable patch gap between

    chrome <-> Electron <-> Electron Apps which makes most of them susceptible to these attacks. • Sandbox Escapes from Chromium can also be used.
  37. Mitigations • Enable all the security flags • Don’t use

    embeds which don’t have good security track record (third party embed) • Mitigate security vulnerabilities (XSS, Open URL Redirection, etc.) on all your assets (even subdomains) • Upgrade Electron regularly to make sure patch gap is not large • Don’t implement sensitive IPC on main process • Ensure that all IPC message handlers appropriately validate senderFrame • Ensure Adequate Segregation is present if you’re rolling out your own library which combines browser and application-level code Read: https://www.electronjs.org/docs/latest/tutorial/security
  38. Epilogue • In total we were able to achieve RCE

    on 20 different Electron applications • Examples: JupyterLab, Mattermost, Rocket.Chat, Notion, Basecamp and the ones covered within this talk are few of them
  39. Takeaways • Dig deeper into the framework you’re auditing and

    don’t limit yourself to only the application layer. • Electron apps are an ideal adversarial (or red team) target as users will click anywhere or open messages. • Minimize attack surface on the apps as much as possible. (Open URL redirect can also be turned into RCE some day)
  40. Research Team • Mohan Sri Rama Krishna Pedhapati @S1r1u5_ •

    Aaditya Purani @knapstack • William Bowling @vakzz • Max Garrett @TheGrandPew
  41. Thanks to other collaborators • Yudai @ptr-yudai • Sergey Bobrov

    @Black2Fan • terjanq @terjanq • Masato Kinugawa @kinugawamasato • Harsh Jaiswal @rootxharsh