Each month, YesWeHack publishes articles on exploitation techniques, tools and tips to help hunters find vulnerabilities in their reconnaissance process and hunting routine. The goal is to provide ideas and keys to attack and understand the various web technologies hunters may face on their private programs.
Digitalization has increased to a great extent in the last couple of years, along with the technology evolution. In the past years, JavaScript frameworks such as Angular, React, Electron, Node, Vue, etc., were a trendy option for organizations and developers. However, a regular security assessment against such technologies and frameworks allows security researchers to discover various security vulnerabilities that may lead to a direct or indirect impact on the Confidentiality, Integrity and Availability of the applications built using these frameworks.
In this article, we will talk about performing a Security Assessment on Electron-based applications and, more specifically, looking at the “Electron Specific Vulnerabilities” and some common ways to exploit them.
Quick Introduction to Electron
According to the official documents of Electron.js, Electron is a framework for building desktop applications using JavaScript, HTML, and CSS. By embedding Chromium and Node.js into its binary, Electron allows you to maintain one JavaScript codebase and create cross-platform apps that work on Windows, macOS, and Linux — no native development experience required.
Introduction to Electron Application Penetration Testing
As mentioned in the introduction, the electron is a framework for building a cross-platform desktop application. The basic idea behind this is to embed a Chromium binary that powers the electron-based applications to run similar to the web applications.
When it comes to performing penetration testing, most of the checks that are found on the “Web & APIs” such as Missing Access Controls, Broken Authentication, “XXE & SSRF”, etc. and “Thick Client” such as “DLL Hijacking”, “Hardcoded Information”, “Insecure Logging” would still be present.
For assessing the Electron Application that calls the API endpoints, similar test cases to the API Pentesting can be performed. A quick reference about Web & API security issues can be found at: https://owasp.org/www-project-api-security/
In this article, we will be specifically looking at the Security Issues & Misconfigurations found in the Electron applications.
Navigating Electron Applications
While working on Electron-based applications, reading its base code and navigating to the storage directory can reveal interesting information and security loopholes. This process is fairly simple, one can follow the below steps to find the installation directory:
- Right-click on the application > Properties > Open File Location
- This will open the installation directory, often you can find some logs and configuration files there that may reveal sensitive information.
- Now, in the installation directory, navigate to the resources (or app-<version>/resources) directory.
- Observe the file app.asar, this is of our interest for further inspection and analysis.
Understanding .asar File Format
As per Fileinfo, an ASAR file is an archive used to package source code for an application using Electron, an open-source library used to build cross-platform programs. It is saved in a format similar to .TAR archives where files contained in the archive, such as .HTML, .JS, and .CSS files, are concatenated together without using compression.
In a nutshell, the .asar file format is similar to an archive that is used by the electron to package the various code files together. Since, the electron is a javascript framework and heavily relies upon it, decompressing the app.asar file enables one to perform code analysis in order to find security flaws.
Decompiling & Recompiling .asar
The process of decompiling and recompiling the .asar file is fairly simple. First of all, it is required to have the node and npm installed to get things working.
Installing asar
Run the following command to install the asar npm package:
Decompressing app.asar
Run the following command for decompression:
Repacking app.asar
Run the following command for repackaging:
Sensitive Information Extraction
Reading the source code may often allow an attacker to identify some interesting and sensitive piece of information such as credentials, API Keys, secrets, tokens and others.
There are multiple ways to identify the hardcoded information, however, a tester can use the below method to identify the sensitive information:
- Open the terminal and navigate to the directory having decompressed asar file.
- Use Grep or preferred tool for performing regex pattern based extraction.
- A list of sensitive keywords can be found here.
- Additionally, the gf patterns can also be used for identify sensitive information and vulnerable patterns.
Electron Security Best Practices
Electron’s official website itself provides a great set of security best practices and, if followed properly, help mitigate common security issues that one may encounter during the testing. Some of the security best practices to follow while developing Electron applications are:
- Ensure use of Secure Protocols: The application should use secure communication, data transfer and other activities. It is recommended to use HTTPS, FTPS, WSS, etc., over HTTP, FTP or WS.
Risk: An attacker might be able to eavesdrop on the communication over an insecure channel and perform a Man-in-the-Middle attack to steal sensitive information. - Disable nodeIntegration for Untrusted Sources/Remote Content: The application should not have nodeIntegration enabled in any renderer function such as BrowserWindows, BrowserView, etc that may load remote content. Ensure that the nodeIntegration is disabled by setting its value to “false”.
Risk: An attacker might be able to utilize the nodeIntegration to perform attacks such as arbitrary JavaScript execution leading to cross-site scripting, local file read or even code execution in certain scenarios. - Context Isolation: Electron provides a feature to run code in preload scripts and in Electron APIs in a dedicated JavaScript context. Along with disabled nodeIntegration, it is also recommended to use Context Isolation.
Risk: An attacker might be able to utilize the insecure preload scripts in absence of Context Isolation to bypass the nodeIntegration or Sandbox to perform further impactful attacks. - Enable WebSecurity: Disabling webSecurity will disable the same-origin policy and set allowRunningInsecureContent property to true. In other words, it allows the execution of insecure code from different domains. Ensure that the webSecurity is enabled.
Risk: An attacker might be able to perform multiple attacks as the protection layer, i.e. WebSecurity is disabled. - Implement a CSP: Content-Security-Policy (CSP) acts as a defence-in-depth mechanism against some attacks such as Cross-Site Scripting. Implementing a CSP can help to prevent cross-site scripting attacks. Although it is not a permanent solution, a strong CSP can prevent this type of attack from happening unless bypassed.
Risk: An attacker might be able to perform attacks such as Cross-Site-Scripting and impact the application & its users in the absence of CSP. - Disable Running Insecure Content: The electron doesn’t allow websites over HTTPS to load & execute content from insecure sources. However, if the property allowRunningInsecureContent is set to true , the protection is disabled.
Risk: An attacker might be able to load and execute content from insecure sources if the allowRunningInsecureContent is set to true. - Disable Popups: The applications using <webview> might require the pages and scripts to be loaded in <webview> tag to open new windows. The allowpopups attribute enables them to create new BrowserWindows using the window.open() method. <webview> tags are otherwise not allowed to create new windows.
Risk: An attacker might be able to abuse this behaviour for performing attacks such as UI Redressing. - Verify WebView Options: A WebView created in a renderer process that does not have Node.js integration enabled will not be able to enable integration itself. However, a WebView will always create an independent renderer process with its own webPreferences. It is a good idea to control the creation of new <webview> tags from the main process and to verify that their webPreferences do not disable security features.
Risk: Since <webview> live in the DOM, an attacker might be able to create them by a script running on the website even if Node.js integration is otherwise disabled. - Disable openExternal with Untrusted Content: Shell’s openExternal() allows opening a given external protocol URI with the desktop’s native utilities. For instance, on macOS, this function is similar to the ‘open’ terminal command utility and will open the specific application based on the URI and filetype association
Risk: An attacker might be able to utilize the misconfigured openExternal to compromise the user’s host. - Use Latest Version of Electron: It is recommended to use the latest version of the Electron in order to ensure that any previous/known vulnerabilities are not impacting the application.
Risk: An attacker would be able to enumerate known vulnerabilities and use the public exploits/write exploits in order to impact the application.
Hacking Electron Apps with Electronegativity
As per the official GitHub Repository, Electronegativity is a tool to identify misconfigurations and security anti-patterns in Electron-based applications. It leverages AST and DOM parsing to look for security-relevant configurations, as described in the “Electron Security Checklist — A Guide for Developers and Auditors” white paper.
Software developers and security auditors can use this tool to detect and mitigate potential weaknesses and implementation bugs when developing applications using Electron. A good understanding of Electron (in)security is still required when using Electronegativity, as some of the potential issues detected by the tool require manual investigation.
Tool Repository: https://github.com/doyensec/electronegativity
Installation
Using Electronegativity
a. Navigate to the Electron Application’s Installation Directory which contains the asar file.
b. Open the terminal and run the following command:
c. Observe that the tool returned with the misconfiguration and vulnerabilities.
