Making Myself at Chrome: Stealthy Local Backdoors for Signal, 1Password, Slack, and more

Making Myself at Chrome: Stealthy Local Backdoors for Signal, 1Password, Slack, and more

Speakers: Darius Houle, Senior Application Security Engineer, Trail of Bits

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=qC16qKRT89w

Overview

In this DistrictCon talk, Darius Houle, a Senior Application Security Engineer at Trail of Bits, unveils a critical vulnerability he discovered within the Electron framework. The presentation, titled "Making Myself at Chrome," meticulously details how a seemingly secure, code-signed Electron application can be subtly backdoored by an attacker with local access, turning it into a stealthy "proxy executor" for arbitrary JavaScript code. Houle demonstrates this by successfully tampering with a legitimate 1Password installation, highlighting a significant blind spot in how many Electron applications handle code integrity beyond the initial binary verification.

The core issue revolves around Electron's default settings, which often neglect to enforce integrity checks on the application's interpreted JavaScript logic, even when the executable itself is digitally signed and protected. This oversight creates a potent vector for persistent compromise, allowing attackers to inject malicious code that operates under the guise and trust of a legitimate application. The implications are particularly severe for applications handling sensitive data, such as Signal, 1Password, and Slack, which rely heavily on user trust and robust security. Houle argues for a re-evaluation of the local threat model for Electron apps, advocating for developers to adopt stricter integrity controls and modern packaging formats to mitigate this pervasive risk.

Background

▶ Watch: Introduction to Electron vulnerability and code integrity (0:00)

The foundation of trust in software execution hinges on two primary concepts: code signing and code integrity. When a user runs a program on a Windows computer, the operating system performs basic checks to verify the author's identity and confirm that the executable binary has not been tampered with since it was signed. This binary-level verification is a crucial first line of defense, ensuring that the core program file is authentic. However, this protection typically does not extend to the application's interpreted logic, such as JavaScript, Python, or Ruby scripts, which are loaded and executed by the main binary. It is the application developer's responsibility to implement additional mechanisms to safeguard this interpreted code from modification.

This distinction becomes particularly relevant in the context of the Electron framework. Electron, built on Google Chrome's rendering engine and V8 JavaScript engine, allows developers to create cross-platform desktop applications using web technologies like HTML, CSS, and JavaScript. While this offers significant development agility, it also introduces complexities regarding code integrity. Many Electron applications, particularly those installed without elevated privileges, reside in user-owned directories like appdata on Windows. This means that an attacker who has gained a foothold on a user's machine can easily modify files within these directories, including the application's JavaScript code.

The problem arises because, by default, Electron does not automatically enforce integrity checks on these JavaScript assets. Consequently, even if an Electron application's executable binary is perfectly signed and verified by the operating system, its core logic—the JavaScript that defines its functionality and user interface—can be altered without detection. This creates a scenario where a legitimate, trusted, and signed application can be coerced into executing arbitrary, malicious JavaScript, effectively turning it into a proxy executor for an attacker's commands. The talk emphasizes that this gap in integrity checking has been a long-standing oversight, with many developers unknowingly leaving their applications vulnerable to local tampering.

Key Findings

▶ Watch: Why it matters: compromising privacy for activists (3:18)

Darius Houle's central finding is that the Electron framework, by default, fails to protect the interpreted JavaScript logic of applications from local tampering, even when the executable itself is digitally signed and verified. This critical vulnerability allows an attacker with a foothold on a user's machine to inject malicious code into popular applications like Signal, 1Password, and Slack, turning them into stealthy backdoors.

Specifically, Houle identified that two crucial Electron "fuses" (feature flags) designed to ensure script integrity are disabled by default:

1. enable embedded ASAR integrity validation
2. only load app from ASAR

Without these fuses enabled, Electron applications will happily execute any JavaScript found alongside them, even if it has been modified by an attacker. This completely bypasses the security assurances provided by operating system-level code signing. The practical implication is that a legitimate, signed application can become a "proxy executor" for untrusted code, operating with the full trust and privileges of the original application, making it an ideal vector for stealthy persistence and data exfiltration.

The speaker demonstrated this live with 1Password, showcasing that even with the binary signed and basic integrity features seemingly active, an attacker could inject JavaScript to modify the application's behavior upon relaunch. This attack vector directly challenges the assumption that "code running as you does as you do" is inherently secure, especially when the integrity of the interpreted application logic is not explicitly protected. Houle further highlighted the inconsistency in security models, pointing out that Chrome itself integrity checks extensions before loading them, yet many Electron applications built on Chrome's foundation lack similar protections for their core application logic. This finding underscores a widespread issue affecting a vast number of Electron-based applications, prompting a critical re-evaluation of their local threat models.

Technical Deep Dive

▶ Watch: Electron's integrity checking "fuses" are off by default (6:20)

The technical core of this vulnerability lies in the nuanced distinction between binary-level integrity and application logic integrity within the Electron framework. Electron applications are built upon the Chromium rendering engine and the V8 JavaScript engine, essentially packaging a web browser engine with a Node.js runtime to create desktop experiences. While the operating system (e.g., Windows) provides robust mechanisms like code signing to verify the authenticity and integrity of the main executable file (e.g., 1password.exe), these protections typically do not extend to the interpreted JavaScript, HTML, and CSS assets that constitute the bulk of an Electron app's functionality.

Most user-installed Electron applications, especially on Windows, are deployed into the user's appdata directory. This directory is owned by the user, meaning that any attacker who has achieved local user-level access can freely modify files within it. This includes modifying the application's JavaScript files or injecting new ones. The vulnerability exploits this permissive file system access combined with Electron's default behavior regarding script loading.

Electron offers a packaging format called ASAR (Atom Shell Archive), which allows developers to bundle all application scripts into a single, compressed archive file. This is analogous to a .zip file but optimized for Electron. The framework also provides specific fuses (feature flags) designed to enhance the integrity of these ASAR archives:

1. enable embedded ASAR integrity validation: When enabled, Electron calculates and verifies a cryptographic hash of the ASAR archive before loading any scripts from it. This ensures that the contents of the ASAR file have not been tampered with.
2. only load app from ASAR: This fuse dictates that the application should only load its primary application logic from the specified ASAR archive, preventing it from loading potentially malicious scripts from other locations on disk, such as loose JavaScript files placed next to the ASAR.

Crucially, Darius Houle's research revealed that these two fuses are disabled by default in many Electron applications. This default configuration means that even if an application uses an ASAR archive, Electron will not perform integrity checks on it, nor will it strictly adhere to loading scripts exclusively from it. Consequently, an attacker can place a malicious JavaScript file (e.g., app.js or a modified index.js) directly within the application's directory, and the Electron runtime will load and execute it, often in preference to or in conjunction with the legitimate ASAR-packaged scripts. This technique is effectively JavaScript side-loading, where untrusted code is executed by a trusted binary.

The result is that the legitimate, code-signed Electron application transforms into a proxy executor. It uses its inherent trust and permissions to run arbitrary code supplied by the attacker. This is a highly stealthy persistence mechanism, as the malicious activity is indistinguishable from the legitimate application's operations from an operating system perspective. The executable binary remains signed and untampered, passing all OS-level integrity checks, while the application's actual behavior is compromised.

Houle referenced Loki C2, a command-and-control (C2) suite, as an example of how attackers already leverage this type of stealthiness. Such C2 frameworks can integrate malicious JavaScript into legitimate Electron applications, allowing them to exfiltrate data (e.g., "every fetch that goes to Coinbase") or perform other malicious actions, all while masquerading as a trusted application.

The speaker also drew a parallel to the Chrome browser's own security model for extensions. Chrome rigorously integrity checks its extensions before loading them, preventing on-disk tampering. However, this same level of scrutiny is often absent for the core JavaScript logic of Electron applications, even though they share the same underlying V8 engine. This inconsistency, particularly in the context of heap snapshot clobbering (modifying the pre-parsed JavaScript state loaded by the engine), highlights a significant gap in the perceived security of Electron applications. The argument is that the "Chrome threat model" needs revisiting, as the assumption that code running as the user is inherently safe is no longer sufficient when interpreted logic can be so easily subverted.

Demo / Proof of Concept

▶ Watch: Key takeaways for developers and MSIX packaging (10:10)

Darius Houle commenced his talk with a compelling video demonstration, effectively illustrating the core vulnerability. The target for this Proof of Concept (PoC) was a copy of 1Password, a widely trusted and security-sensitive application built on the Electron framework.

The demonstration unfolded in several key steps:

1. Initial Verification: Houle first established the legitimate state of the 1Password application. He explicitly showed, using the Microsoft signing tool, that the 1Password executable binary was indeed signed by a trusted author and had not been modified. This confirmed that, at the operating system level, 1Password appeared to be a genuine and untampered application.
2. Electron Integrity Checks: He then highlighted that the specific Electron framework integrity checking features (the "fuses" mentioned in the technical deep dive, namely enable embedded ASAR integrity validation and only load app from ASAR) were enabled on this particular 1Password installation. This was a crucial point, as these settings should theoretically prevent tampering with the application's JavaScript.
3. JavaScript Side-loading: Despite the presence of binary signing and enabled Electron integrity fuses, Houle proceeded to copy what he described as an "inert file" next to the 1Password application's executable. This "inert file" was, in reality, attacker-controlled JavaScript designed to alter the application's behavior. The ease of this step underscored the local access requirement for the attack.
4. Backdoor Activation: Upon restarting 1Password, the application's user interface looked "a little bit different." While the specific visual modification was playfully presented as "Yay! So very fun, right?", the implication was clear: the injected JavaScript had successfully executed, altering the application's functionality or presentation. This confirmed that the legitimate, signed application had been successfully backdoored with arbitrary JavaScript code, despite all conventional integrity checks appearing to be in place.

The PoC powerfully demonstrated that even with what developers might consider robust security measures (code signing, Electron's integrity fuses), a fundamental flaw in the default configuration or interpretation of these features allowed for stealthy local compromise. The ability to modify a trusted application like 1Password to execute arbitrary code, without invalidating its digital signature or triggering standard integrity alerts, served as a stark warning about the overlooked attack surface in many Electron-based applications.

Defensive Implications

▶ Watch: Future research on stealthy proxy executors and acknowledgments (11:40)

The findings presented by Darius Houle carry significant implications for both developers building Electron applications and security professionals defending against advanced persistent threats. The primary takeaway is that relying solely on operating system-level code signing for executable binaries is insufficient to ensure the integrity of applications, particularly those utilizing interpreted languages like JavaScript within frameworks like Electron.

For Electron application developers, a fundamental shift in their local threat modeling is imperative:

• Comprehensive Code Integrity: Developers must extend their integrity checking beyond the binary to encompass all application logic, especially interpreted JavaScript. This means treating JavaScript assets with the same level of security rigor as the main executable.
• Enable Electron Fuses: Crucially, developers must explicitly enable the Electron fuses: enable embedded ASAR integrity validation and only load app from ASAR. These fuses ensure that the application's scripts are bundled into a single, integrity-checked ASAR archive and that no other untrusted scripts can be loaded from adjacent directories. Since these are off by default, developers must consciously opt into this enhanced security.
• Modern Packaging Formats: The talk strongly advocates for adopting modern application packaging formats like MSIX on Windows. MSIX provides built-in isolation, robust integrity checking, and a more secure permission model out-of-the-box, significantly mitigating the type of JavaScript side-loading attack demonstrated. Houle pointed out that the latest version of 1Password has moved to MSIX, making it resistant to the "heap snapshot clobbering attack" previously possible.
• Scrutinize User-Writable Data: Developers must carefully consider what data and files are stored in user-writable locations (like appdata). Any application components placed in such locations, if not adequately protected by integrity checks, become potential vectors for an attacker to turn the application into a proxy executor.
• Leverage OS and Framework Best Practices: Beyond Electron-specific fuses, developers should integrate all available operating system and framework best practices for securing shared libraries, data storage, and execution environments.

For security teams and defenders, the talk highlights a stealthy and potent vector for persistence:

• Rethink Local Persistence: Attackers with local access can achieve highly stealthy and persistent footholds by backdooring legitimate, signed applications. Traditional indicators of compromise (like unsigned binaries) may not trigger, as the core executable remains untouched.
• Focus on Application-Level Integrity: Security monitoring should ideally extend to detecting unauthorized modifications of application-specific data and script files, particularly for high-value targets like communication apps (Signal, Slack) and credential managers (1Password).
• User Education: Emphasize the risks of downloading applications from unofficial sources, even if they appear legitimate and signed. A malicious actor could distribute a pre-modified Electron app that still passes OS-level signing checks but has its JavaScript backdoored.

The speaker's acknowledgement of the Electron team, 1Password, Signal, and Slack for taking the vulnerability seriously and patching it "pretty much immediately" underscores the severity and widespread applicability of this finding. This issue is not isolated; it represents a systemic problem in how code integrity is handled for interpreted application logic, making it a "tip of the iceberg" for many other potential "stealth proxy executors" waiting to be discovered.

Key Takeaways

• Electron's Default Insecurity: By default, the Electron framework does not protect the interpreted JavaScript logic of applications from local tampering, even if the main executable binary is digitally signed.
• Binary Signing is Insufficient: A valid code signature on an Electron application's executable does not guarantee the integrity of its core application logic (JavaScript), leading to a false sense of security.
• Proxy Executors: This vulnerability allows attackers with local access to turn legitimate, trusted, and signed Electron applications into "proxy executors" for arbitrary, malicious JavaScript code, providing a stealthy persistence mechanism.
• Enable ASAR Fuses: Electron developers must explicitly enable the enable embedded ASAR integrity validation and only load app from ASAR fuses to ensure robust integrity checking of their application's JavaScript assets.
• Adopt Modern Packaging: Utilizing modern packaging formats like MSIX on Windows offers significant out-of-the-box security benefits, including isolation and comprehensive integrity checking, making applications more resilient to these types of attacks.
• Revisit Local Threat Models: Developers and security professionals must critically re-evaluate their local threat models for Electron applications, focusing on protecting all components, especially interpreted code, from user-level modification.

About the Speaker(s)

Darius Houle is a Senior Application Security Engineer at Trail of Bits. His work focuses on identifying and documenting interesting persistence avenues and vulnerabilities, particularly within application frameworks. As demonstrated in this talk, he has a keen interest in code signing, code integrity, and how these concepts apply to offensive security scenarios. Houle's research aligns with efforts to document common attack techniques, drawing parallels to platforms like LOLBAS (Living Off the Land Binaries, Scripts, and Libraries) which catalog legitimate system tools abused by attackers. He actively collaborates with vendors, such as the Electron team, 1Password, Signal, and Slack, to responsibly disclose and remediate security flaws.