# XSS to RCE Electron Desktop Apps
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
## Introduction
Electron is **based on Chromium**, but it is not a browser. Certain principles and security mechanisms implemented by modern browsers are not in place.\
You could see Electron like a local backend+frontend app where **NodeJS** is the **backend** and **chromium** is the **frontend**.
Usually you might find the electron app code inside an `.asar` application, in order to obtain the code you need to extract it:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
In the source code of an Electron app, inside `packet.json`, you can find specified the `main.js` file where security configs ad set.
```json
{
"name": "standard-notes",
"main": "./app/index.js",
```
Electron has 2 process types:
* Main Process (has complete access to NodeJS)
* Renderer Process (should have NodeJS restricted access for security reasons)
![](<../../../.gitbook/assets/image (307) (5) (1).png>)
A **renderer process** will be a browser window loading a file:
```javascript
const {BrowserWindow} = require('electron');
let win = new BrowserWindow();
//Open Renderer Process
win.loadURL(`file://path/to/index.html`);
```
Settings of the **renderer process** can be **configured** in the **main process** inside the main.js file. Some of the configurations will **prevent the Electron application to get RCE** or other vulnerabilities if the **settings are correctly configured**.
The desktop application might have access to the user’s device through Node APIs. The following two configurations are responsible for providing mechanisms to **prevent the application JavaScript from having direct access to the user’s device** and system level commands.
* **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the renderer process.
* **`contextIsolation`** - is `on` by default. If on, main and renderer processes aren't isolated.
* **`preload`** - empty by default.
* [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform.
* Node Integration in Workers
* **`nodeIntegrationInSubframes`**- is `off` by default.
* If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **loaded in iframes** within an Electron application.
* If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe
Example of configuration:
```javascript
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,
contextIsolation: false,
sandbox: false,
nodeIntegrationInSubFrames: false,
preload: _path2.default.join(__dirname, 'mainScreenPreload.js'),
nativeWindowOpen: true,
enableRemoteModule: false,
spellcheck: true
}
};
```
Some **RCE payloads** from [here](https://7as.es/electron/nodeIntegration\_rce.txt):
```html
Example Payloads (Windows):
Example Payloads (Linux & MacOS):
```
### Capture traffic
Modify the start-main configuration and add the use of a proxy such as:
```javascript
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
```
## RCE: XSS + nodeIntegration
If the **nodeIntegration** is set to **on**, a web page's JavaScript can use Node.js features easily just by calling the `require()`. For example, the way to execute the calc application on Windows is:
```html
```
## RCE: preload
The script indicated in this setting is l**oaded before other scripts in the renderer**, so it has **unlimited access to Node APIs**:
```javascript
new BrowserWindow{
webPreferences: {
nodeIntegration: false,
preload: _path2.default.join(__dirname, 'perload.js'),
}
});
```
Therefore, the script can export node-features to pages:
{% code title="preload.js" %}
```javascript
typeof require === 'function';
window.runCalc = function(){
require('child_process').exec('calc')
};
```
{% endcode %}
{% code title="index.html" %}
```html
```
{% endcode %}
{% hint style="info" %}
**If `contextIsolation` is on, this won't work**
{% endhint %}
## RCE: XSS + contextIsolation
The _**contextIsolation**_ introduces the **separated contexts between the web page scripts and the JavaScript Electron's internal code** so that the JavaScript execution of each code does not affect each. This is a necessary feature to eliminate the possibility of RCE.
If the contexts aren't isolated an attacker can:
1. Execute **arbitrary JavaScript in renderer** (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. RCE?
There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code:
{% content-ref url="electron-contextisolation-rce-via-preload-code.md" %}
[electron-contextisolation-rce-via-preload-code.md](electron-contextisolation-rce-via-preload-code.md)
{% endcontent-ref %}
{% content-ref url="electron-contextisolation-rce-via-electron-internal-code.md" %}
[electron-contextisolation-rce-via-electron-internal-code.md](electron-contextisolation-rce-via-electron-internal-code.md)
{% endcontent-ref %}
{% content-ref url="electron-contextisolation-rce-via-ipc.md" %}
[electron-contextisolation-rce-via-ipc.md](electron-contextisolation-rce-via-ipc.md)
{% endcontent-ref %}
### Bypass click event
If there are restrictions applied when you click a link you might be able to bypass them **doing a middle click** instead of a regular left click
```javascript
window.addEventListener('click', (e) => {
```
## RCE via shell.openExternal
If the Electron desktop application is deployed with proper `nodeIntegration`, `contextIsolation` settings; it simply means that **client-side RCE by targeting preload scripts or Electron native code from the main process can not be achieved**.
Each time a user clicks the link or opens a new window, the following event listeners are invoked:
{% code overflow="wrap" %}
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
{% endcode %}
The desktop application **overrides these listeners** to implement the desktop application’s own **business logic**. During the creation of new windows, the application checks whether the navigated link should be opened in a desktop application’s window or tab, or whether it should be opened in the web browser. In our example the verification is implemented with the function `openInternally`, if it returns `false`, the application will assume that the link should be opened in the web browser using the `shell.openExternal` function.
**Here is a simplified pseudocode:**
![](<../../../.gitbook/assets/image (638) (2) (1) (1).png>)
![](<../../../.gitbook/assets/image (620).png>)
Accordingly to Electron JS security best practices, the `openExternal` function **should not accept untrusted content** **because that could lead to RCE abusing different potocols** if the application does not limit users navigation through protocols such as https:// or http://.
Different OS support different protocols that could trigger RCE, for more info about them check [https://positive.security/blog/url-open-rce](https://positive.security/blog/url-open-rce#windows-10-19042) but here you have some Windows examples:
```html
```
For more info about this examples check [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) and [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
## Read Internal Files: XSS + contextIsolation
If `contextIsolation` set to false you can try to use \ (similar to \