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.
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
- A detailed guide for understanding and exploring the Electron framework can be found here: https://www.electronjs.org/docs
- A list of applications that are built using Electron can be found here: https://www.electronjs.org/apps.
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.
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.
Run the following command to install the asar npm package:
npm install -g asar
Run the following command for decompression:
asar extract app.asar destfolder
Run the following command for repackaging:
asar pack <folder> app.asar
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
Grepor preferred tool for performing
regexpattern based extraction.
- A list of sensitive keywords can be found here.
- Additionally, the
gfpatterns 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 insecure preload scripts in absence of Context Isolation to bypass the nodeIntegration or Sandbox to perform further impactful attacks.
- Enable WebSecurity: Disabling
webSecuritywill disable the same-origin policy and set
true. In other words, it allows the execution of insecure code from different domains. Ensure that the
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
allowRunningInsecureContentis set to
true, the protection is disabled.
Risk: An attacker might be able to load and execute content from insecure sources if the
allowRunningInsecureContentis set to
- Disable Popups: The applications using
<webview>might require the pages and scripts to be loaded in
<webview>tag to open new windows. The
allowpopupsattribute enables them to create new
<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.
<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
npm install @doyensec/electronegativity -g
a. Navigate to the Electron Application’s Installation Directory which contains the
b. Open the terminal and run the following command:
CMD: electronegativity.cmd -i /file_path
Ex: electronegativity.cmd -i .
c. Observe that the tool returned with the misconfiguration and vulnerabilities.
References & Resources
The use of cross-platform applications is increasing and thus the popularity of electron for building the cross-platform desktop application. It is one of the less travelled roads in bug bounty and still has a lot of potentials when it comes to finding impressive security issues. We hope this blog post will help you understand electron security best practices and vulnerabilities in a better way.