After the first public release of Electronegativity, we had a great response from the community and the tool quickly became the baseline for every Electron app’s security review for many professionals and organizations. This pushed us forward, improving Electronegativity and expanding our research in the field. Today we are proud to release version 1.3.0 with many new improvements and security checks for your Electron applications.
We’re also excited to announce that the tool has been accepted for Black Hat USA Arsenal 2019, where it will be showcased at the Mandalay Bay in Las Vegas. We’ll be at Arsenal Station 1 on August 7, from 4:00 pm to 5:20 pm. Drop by to see live demonstrations of Electronegativity hunting real Electron applications for vulnerabilities (or just to say hi and collect Doyensec socks)!
If you’re simply interested in trying out what’s new in Electronegativity, go ahead and update or install it using NPM:
$ npm install @doyensec/electronegativity -g # or $ npm update @doyensec/electronegativity -g
To review your application, use the following command:
$ electronegativity -i /path/to/electron/app
Electronegativity 1.1.1 initially shipped with 27 unique checks. Now it counts over 40 checks, featuring a new advanced check system to help improve the tool’s detection capabilities in sorting out false positive and false negative findings. Here is a brief list of what’s new in this 1.3.0 release:
--severity) and by confidence (
--confidence), useful for tailored Electronegativity integration in your application security pipelines or build systems.
sandboxflags value or the presence of the
affinityflag used acrossed different windows).
-lflag along with a list of enabled checks (e.g.
-l "AuxClickJsCheck,AuxClickHtmlCheck"). Another command line flag has been introduced to show relative paths for files (
nodeIntegrationInSubFramesexperimental option for enabling NodeJS support in sub-frames (e.g. an iframe inside a
This new release also comes with new and updated checks. As always, a knowledge-base containing information around risk and auditing strategy has been created for each class of vulnerabilities.
When specified, renderers with the same affinity will run in the same renderer process. Due to reusing the renderer process, certain
webPreferences options will also be shared between the web pages even when you specified different values for them. This can lead to unexpected security configuration overrides:
In the above demo, the
affinity set between the two
BrowserWindow objects will cause the unwanted share of the
nodeIntegration property value. Electronegativity will now issue a finding reporting the usage of this flag if present.
Read more on the dedicated AFFINITY_GLOBAL_CHECK wiki page.
allowpopups attribute is present, the guest page will be allowed to open new windows. Popups are disabled by default.
Read more on the ALLOWPOPUPS_HTML_CHECK wiki page.
This check detects if there are security patches available for the Electron version used by the target application. From this release we switched from manually updating a safe releases file to creating a routine which automatically fetches the latest releases from Electron’s official repository and determines if there are security patches available at each run.
This check will compare the custom command line arguments set in the package.json
configuration objects against a blacklist of dangerous arguments. The use of additional command line arguments can increase the application attack surface, disable security features or influence the overall security posture.
Read more on the CUSTOM_ARGUMENTS_JSON_CHECK wiki page.
Electronegativity now checks if a Content Security Policy (CSP) is set as an additional layer of protection against cross-site-scripting attacks and data injection attacks. If a CSP is detected, it will look for weak directives by using a new library based on the csp-evaluator.withgoogle.com online tool.
Read more on the CSP_GLOBAL_CHECK wiki page.
Looks for occurrences of
setImmediate with user-supplied input.
Read more on the DANGEROUS_FUNCTIONS_JS_CHECK wiki page.
Detects if the
on() handler for
new-window events is used. This setting can be used to limit the exploitability of certain issues. Not enforcing navigation limits leaves the Electron application under full control to remote origins in case of accidental navigation.
The tool will check if Electron’s warnings and recommendations printed to the developer console have been force-disabled by the developer. Disabling this warning may hide the presence of misconfigurations or insecure patterns to the developers.
Not enforcing custom checks for permission requests (e.g. media) leaves the Electron application under full control of the remote origin. For instance, a Cross-Site Scripting vulnerability can be used to access the browser media system and silently record audio/video. Because of this, Electronegativity will also check if a
setPermissionRequestHandler has been set.
Read more on the PERMISSION_REQUEST_HANDLER_GLOBAL_CHECK wiki page.
…and more to come! If you are a developer, we encourage you to use Electronegativity to understand how these Electron’s security pitfalls affect your application and how to avoid them. We really believe that Electron deserves a strong security community behind and that creating the right and robust tools to help this community is the first step towards improving the whole Electron’s ecosystem security stance.
See you in Vegas!