From 0518dbfa90eca3bc2aed24d0179261b9141441b6 Mon Sep 17 00:00:00 2001 From: Carlos Polop Date: Tue, 7 Jan 2025 19:06:04 +0100 Subject: [PATCH] electron remote --- .../electron-desktop-apps/README.md | 103 +++++++++++++++++- 1 file changed, 102 insertions(+), 1 deletion(-) diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index 58bbbb958..9c71c9999 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -205,7 +205,7 @@ window.addEventListener('click', (e) => { 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/) -hen deploying an Electron desktop application, ensuring the correct settings for `nodeIntegration` and `contextIsolation` is crucial. It's established that **client-side remote code execution (RCE)** targeting preload scripts or Electron's native code from the main process is effectively prevented with these settings in place. +When deploying an Electron desktop application, ensuring the correct settings for `nodeIntegration` and `contextIsolation` is crucial. It's established that **client-side remote code execution (RCE)** targeting preload scripts or Electron's native code from the main process is effectively prevented with these settings in place. Upon a user interacting with links or opening new windows, specific event listeners are triggered, which are crucial for the application's security and functionality: @@ -224,6 +224,8 @@ These listeners are **overridden by the desktop application** to implement its o Electron JS security best practices advise against accepting untrusted content with the `openExternal` function, as it could lead to RCE through various protocols. Operating systems support different protocols that might trigger RCE. For detailed examples and further explanation on this topic, one can refer to [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), which includes Windows protocol examples capable of exploiting this vulnerability. +In macos, the `openExternal` function can be exploited to execute arbitrary commands like in `shell.openExternal('file:///System/Applications/Calculator.app')`. + **Examples of Windows protocol exploits include:** ```html @@ -296,6 +298,104 @@ In the case the **regex** used by the function is **vulnerable to bypasses** (fo ``` +## Remote module + +The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks. + +> [!TIP] +> Althoigh the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information. + +> [!WARNING] +> Many apps that still use the remote module do it in a way that **require NodeIntegration to be enabled** in the renderer process, which is a **huge security risk**. + +Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**. + +To enable it, it'd first needed to **enable it in the main process**: + +```javascript +const remoteMain = require('@electron/remote/main') +remoteMain.initialize() +[...] +function createMainWindow() { + mainWindow = new BrowserWindow({ + [...] + }) + remoteMain.enable(mainWindow.webContents) +``` + +Then, the renderer process can import objects from the module it like: + +```javascript +import { dialog, getCurrentWindow } from '@electron/remote' +``` + +The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indicates some interesting **functions** exposed by the object **`app`** from the remote module: + +- **`app.relaunch([options])`** + - **Restarts** the application by **exiting** the current instance and **launching** a new one. Useful for **app updates** or significant **state changes**. +- **`app.setAppLogsPath([path])`** + - **Defines** or **creates** a directory for storing **app logs**. The logs can be **retrieved** or **modified** using **`app.getPath()`** or **`app.setPath(pathName, newPath)`**. +- **`app.setAsDefaultProtocolClient(protocol[, path, args])`** + - **Registers** the current executable as the **default handler** for a specified **protocol**. You can provide a **custom path** and **arguments** if needed. +- **`app.setUserTasks(tasks)`** + - **Adds** tasks to the **Tasks category** in the **Jump List** (on Windows). Each task can control how the app is **launched** or what **arguments** are passed. +- **`app.importCertificate(options, callback)`** + - **Imports** a **PKCS#12 certificate** into the system’s **certificate store** (Linux only). A **callback** can be used to handle the result. +- **`app.moveToApplicationsFolder([options])`** + - **Moves** the application to the **Applications folder** (on macOS). Helps ensure a **standard installation** for Mac users. +- **`app.setJumpList(categories)`** + - **Sets** or **removes** a **custom Jump List** on **Windows**. You can specify **categories** to organize how tasks appear to the user. +- **`app.setLoginItemSettings(settings)`** + - **Configures** which **executables** launch at **login** along with their **options** (macOS and Windows only). + +Example: + +```javascript +Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"}); +Native.app.exit() +``` + +## systemPreferences module + +The **primary API** for accessing system preferences and **emitting system events** in Electron. Methods like **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, and **setUserDefault** are all **part of** this module. + +**Example usage:** + +```javascript +const { systemPreferences } = require('electron'); + +// Subscribe to a specific notification +systemPreferences.subscribeNotification('MyCustomNotification', (event, userInfo) => { + console.log('Received custom notification:', userInfo); +}); + +// Get a user default key from macOS +const recentPlaces = systemPreferences.getUserDefault('NSNavRecentPlaces', 'array'); +console.log('Recent Places:', recentPlaces); +``` + +### **subscribeNotification / subscribeWorkspaceNotification** + +* **Listens** for **native macOS notifications** using NSDistributedNotificationCenter. +* Before **macOS Catalina**, you could sniff **all** distributed notifications by passing **nil** to CFNotificationCenterAddObserver. +* After **Catalina / Big Sur**, sandboxed apps can still **subscribe** to **many events** (for example, **screen locks/unlocks**, **volume mounts**, **network activity**, etc.) by registering notifications **by name**. + +### **getUserDefault / setUserDefault** + +* **Interfaces** with **NSUserDefaults**, which stores **application** or **global** preferences on macOS. + +* **getUserDefault** can **retrieve** sensitive information, such as **recent file locations** or **user’s geographic location**. + +* **setUserDefault** can **modify** these preferences, potentially affecting an app’s **configuration**. + +* In **older Electron versions** (before v8.3.0), only the **standard suite** of NSUserDefaults was **accessible**. + +## Shell.showItemInFolder + +This function whows the given file in a file manager, which **could automatically execute the file**. + +For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html) + ## **Tools** - [**Electronegativity**](https://github.com/doyensec/electronegativity) is a tool to identify misconfigurations and security anti-patterns in Electron-based applications. @@ -341,6 +441,7 @@ npm start - [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) - More researches and write-ups about Electron security in [https://github.com/doyensec/awesome-electronjs-hacking](https://github.com/doyensec/awesome-electronjs-hacking) - [https://www.youtube.com/watch?v=Tzo8ucHA5xw\&list=PLH15HpR5qRsVKcKwvIl-AzGfRqKyx--zq\&index=81](https://www.youtube.com/watch?v=Tzo8ucHA5xw&list=PLH15HpR5qRsVKcKwvIl-AzGfRqKyx--zq&index=81) +- [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html) {{#include ../../../banners/hacktricks-training.md}}