Discord RCE
Because Discord was being used for their Prototype Pollution study collaboration, the electrovolt team made the decision to pwn it. Since Discord uses ElectronJS for its desktop application, they must admit that at the time they started studying and programming, they had little knowledge about ElectronJS and thought it was merely a JavaScript application. The intriguing feature of ElectronJS Applications is that you can use the notation below to extract the JavaScript that was used to create the application. Source code auditing is the one activity I usually enjoy doing because, in contrast to lackBox testing, it is simpler. Whether it is a Web Application Frontend or JS-based Desktop Applications, you can usually access the source code when it comes to Javascript hacking.
After extraction, they discovered that using the typical Electron misconfiguration to achieve Remote Code Execution is difficult because they noticed that contextIsolation and nodeIntegration were both enabled. When contextIsolation is disabled, Masato pwns the Discord; you can read more about it in his blog, which is also a great place to start if you’re interested in developing ElectronJS applications.
In terms of the earlier RCEs on Electron Applications, webPreferences appear to be working OK so far. However, the sandbox flag for one import webPreference remains absent. The App runs by default without a sandbox if the sandbox setting is not set to true. The 9-x-y Electron version is still running on an outdated version of Chrome, 83.0.4103.122. Given the number of v8 flaws that are patchable in Chromium, it seems clear that getting RCE with that version of Chrome is not very difficult.
XSS
As the Discord front end leverages ReactJS, they made the decision to identify XSS on Discord Desktop. After a few days, they concluded that detecting XSS on the main Discord App was challenging and that, as far as they could tell, there were no intriguing ReactJS sinks. They became inspired by Masato’s blog and began searching for XSS in Discord Embeds.
Vimeo XSS
After some effort, they were able to obtain an XSS on one of the Vimeo endpoints while searching for an XSS on the Discord embeds. However, they encountered issues running an external script to activate the vulnerability because of Vimeo’s CSP implementation. Additionally, the CSP caused a minor problem when loading an external script and executing the exploit. The following CSP is the endpoint for Vimeo.
Funny enough, because the Discord Chrome version is outdated, they chose to load an external iframe in the video by avoiding the frame-src by using a CSP bypass that they had previously heard about on crbug.com.
An alert box appears in the vimeo video by hosting the following HTML and copying the link in the Discord Chat.
Sandbox Bypass by Escaping to Main Window
There is a hitch when using the v8 exploit in the Vimeo embed and popping the calculator. They believed the situation was resolved when they discovered that all of the iframes in the Discord Desktop Application are operating in sandbox mode by default, which appears to be a feature of Electron.
Masato remarked that it was feasible to start a new window owing to insufficient new-window event restriction by Discord while going on about this issue on the Discord channel.
Unfortunately, the sandbox is still active even after launching the exploit in a new window. After some time, they discovered that the sandbox is cleaned by performing a redirect to a different origin. The renderer process of the Vimeo embed might have been utilized for the newly generated window, and following the redirect, a new process without a sandbox might have been established.
Fix
Discord updated to the most recent Electron version and addressed the new-window event handler misconfiguration by forbidding the loading of external websites in the new window.
