Hunting Malicious IDE Extensions: Building Detection at Scale Across Developer Workstations

Hunting Malicious IDE Extensions: Building Detection at Scale Across Developer Workstations

Speakers: Vinod Tiwari, Staff Security Engineer, Story Protocol

Conference: BSides SF

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

Overview

In an era dominated by sophisticated supply chain attacks, the security of developer workstations has emerged as a critical yet often overlooked vulnerability. Vinod Tiwari's talk, "Hunting Malicious IDE Extensions: Building Detection at Scale Across Developer Workstations," delves into the pervasive and dangerous threat posed by malicious Integrated Development Environment (IDE) extensions. He highlights how these seemingly innocuous tools, designed to enhance developer productivity, can become potent vectors for data exfiltration, secret theft, and even remote code execution, particularly in high-value environments like Web3 development.

Tiwari, a Staff Security Engineer at Story Protocol, brings a practical, firsthand perspective to this problem. His presentation is a candid account of his journey to establish robust detection mechanisms for malicious IDE extensions within his own organization, leveraging existing security tools like Mobile Device Management (MDM) where specialized solutions were absent. The talk is crucial for any organization employing developers, as it exposes a significant blind spot in many security programs and offers actionable strategies for inventorying, monitoring, and mitigating the risks associated with the burgeoning ecosystem of IDE extensions.

The talk underscores the inherent trust developers place in their tools and the market's lack of transparent permission models for extensions, creating an environment ripe for exploitation. By demonstrating how he built a scalable detection system with limited resources, Tiwari empowers security teams to proactively address this threat, moving beyond reactive incident response to a more resilient security posture for their development environments.

Background

▶ Watch: Introduction: The growing threat of malicious IDE extensions (0:00)

The genesis of this problem lies in the inherent nature of modern software development and the rapid expansion of the IDE extension ecosystem. Developers frequently work with sensitive data, including .env files, API keys, and cryptographic secrets, often stored locally on their workstations. When an IDE extension is installed, it often gains extensive access to the local file system and user environment, creating a critical attack surface. Tiwari emphasizes that developer workstations are frequently a "blind spot" for security teams, with many organizations lacking visibility into what extensions are installed, let alone an approval process or active monitoring. A show of hands during the talk revealed that only two attendees actively monitored extensions with EDR or MDM, highlighting the widespread lack of awareness.

The threat is not theoretical; numerous real-world incidents underscore the severity. Tiwari cites several examples:

• A malicious VS Code extension that silently stole SSH keys for over two years before detection.
• Type-squatted NPM packages bundled with malware, specifically targeting crypto developers to steal secrets and API keys, or even run crypto miners.
• Data exfiltration incidents involving extensions with over a million installations.
• The Prettier VS Code Plus extension, a known incident where it downloaded a Trojan onto developer machines.

A key factor enabling these attacks is the silent update mechanism of IDE extensions. A legitimate extension can be compromised if its maintainer's account is hacked. Subsequent updates, pushed by the attacker, can then introduce malware without the user's knowledge, as most developers adhere to default auto-update settings. Unlike mobile app stores that prominently display permission requests, IDEs typically grant full access upon installation without explicit user consent or a sandbox environment. This means an extension, regardless of its stated purpose (e.g., a simple theme), can potentially read sensitive files, execute arbitrary commands, and exfiltrate data.

For Web3 companies, this issue is particularly acute. Smart contract developers often deploy code that manages millions of dollars. If their private wallet keys are compromised via a malicious extension, it can lead to immediate and irreversible draining of funds. While tools like Hardhat and Foundry SDKs have evolved to support more secure key management (e.g., using keychains instead of plain text environment variables), the default behavior often still involves direct access to sensitive keys, making developers a prime target.

Key Findings

▶ Watch: Speaker's motivation: Hunting extensions at his company (1:20)

Tiwari's investigation into IDE extension security revealed several critical findings that underscore the pervasive risks:

Firstly, and most significantly, IDE extensions operate with full system access and minimal to no sandboxing. Both VS Code and JetBrains, two of the most popular IDE platforms, explicitly document that their extensions have unfettered access to the user's file system and environment. For VS Code, extensions run in a Node.js runtime, granting them capabilities like child process execution and direct system file access. JetBrains extensions, running in a JVM, can leverage JNI to load Java class files and libraries, making them equally powerful and potentially dangerous. This fundamental architectural decision means that installing any extension is akin to running an arbitrary program with user-level privileges.

Secondly, the talk highlights specific, highly dangerous APIs accessible to VS Code extensions, which demonstrate their potent capabilities:

• VS Code Workspace FS: This API allows extensions to read all user files, including sensitive configuration files, .env files, and secrets.
• Child process exact: This enables extensions to spawn arbitrary system commands, such as curl for data exfiltration or wget for downloading additional malware.
• .env clipboard API: Perhaps one of the most alarming, this API grants access to the user's clipboard. Tiwari notes that a keylogger extension exists on the VS Code marketplace purely for educational purposes, demonstrating how easily an attacker could siphon sensitive information like API keys or code snippets that developers frequently copy and paste.

Thirdly, Tiwari's internal audit within his company, Story Protocol, revealed the sheer scale of the problem in a real-world development environment. Across 30 active developer hosts, he found 556 unique extensions, with a total count exceeding 1,000. One developer alone had 157 extensions installed, illustrating the unrestrained nature of extension usage. This finding underscores the significant attack surface that goes unnoticed in many organizations. The lack of an approval process, inventory, or monitoring means that developers are often installing extensions based on convenience or aesthetic appeal, without proper security vetting.

Finally, Tiwari observed a significant gap in existing security tooling. While MDMs and EDRs are widely deployed, they often treat IDEs as single processes (e.g., an Electron app), making it challenging to differentiate between legitimate IDE operations and malicious activity originating from an extension's child processes. EDRs might detect known Indicators of Compromise (IOCs) but struggle with novel or custom malicious extensions, as evidenced by incidents where malicious activity went undetected for years despite EDR presence. This gap necessitated the development of custom detection capabilities.

Technical Deep Dive

▶ Watch: Why developer workstations are a critical blind spot (3:00)

The core technical vulnerability explored in this talk stems from the architectural design of popular IDEs like VS Code and JetBrains, which grant extensions powerful, unsandboxed access to the host system.

For VS Code extensions, the underlying technology is Node.js. These extensions are essentially Node.js application packages bundled into a .vsix file. Each package contains a manifest file, typically package.json, which dictates the extension's metadata, dependencies, and crucially, its entry point. When a developer opens VS Code, the IDE's Node.js runtime executes the extension's code. This grants the extension direct access to Node.js APIs, enabling it to interact with the underlying operating system. Specifically, an extension can:

• Access the file system directly, reading and writing files anywhere the user has permissions.
• Spawn child processes via Node.js's child_process module, allowing it to execute arbitrary shell commands (e.g., curl, wget, ssh) and potentially download or exfiltrate data.
• Leverage specific VS Code APIs that expose powerful capabilities. Tiwari highlighted:
• VS Code Workspace FS: This API provides programmatic access to the user's workspace files, allowing extensions to read the contents of any file within the open workspace or even the broader file system if not properly restricted.
• Child process exact: As mentioned, this is a direct gateway to executing system commands, a critical primitive for malware.
• .env clipboard API: This API allows an extension to read and write to the system clipboard, making it a prime candidate for keylogging or stealing sensitive data that developers frequently copy.

JetBrains extensions operate under a similar principle but within a Java Virtual Machine (JVM) environment. These extensions are typically packaged as .zip or .jar files containing a plugin.xml manifest. This XML file defines the extension's properties, dependencies, and entry points. Because they run within the JVM, JetBrains extensions have access to Java Native Interface (JNI), which allows them to call native libraries and execute code outside the JVM's sandbox (if any). This means a malicious JetBrains extension can:

• Load arbitrary Java class files and libraries, potentially executing malicious payloads.
• Interact with the underlying operating system through Java's extensive I/O and process execution capabilities.

A critical point emphasized by Tiwari is the absence of explicit permission prompts during extension installation. Unlike modern mobile operating systems that request specific permissions (e.g., access to camera, location), IDEs largely grant extensions full user-level access by default. This "all or nothing" approach means users are often unaware of the extensive capabilities they are granting, relying instead on perceived trust or popularity metrics that can be easily manipulated (e.g., fake reviews, type-squatting). This lack of transparency and granular control is a foundational weakness that attackers readily exploit.

Demo / Proof of Concept

▶ Watch: Real-world incidents: SSH key theft and type-squatted packages (4:48)

Vinod Tiwari demonstrated a practical, scalable approach to gaining visibility and establishing detection for malicious IDE extensions, leveraging tools commonly available in enterprise environments. His solution centered around using Jamf, an MDM (Mobile Device Management) solution, to orchestrate custom scripts on developer workstations.

The core of his visibility mechanism was a bash script designed to:

1. Enumerate IDEs: Identify all installed IDEs (e.g., VS Code, JetBrains IDEs) on a user's machine.
2. Inventory Extensions: For each identified IDE, list all installed extensions. This involves locating the specific directories where extensions are stored (e.g., ~/.vscode/extensions for VS Code).
3. Cache Output: Save the enumerated list of extensions into a local cache file on the developer's machine.

This bash script was then deployed and managed via Jamf policies. Tiwari implemented two distinct Jamf policies:

1. Periodic Cache Update Policy: This policy ran regularly on all developer machines to execute the bash script, ensuring the local cache file was always up-to-date with the latest installed extensions.
2. Detection and Alerting Policy: This policy also ran periodically. It read the cache file from the developer's machine and compared the list of installed extensions against a pre-defined allow list. If any extension was found that was not on the allow list, the policy would trigger an alert, which was then sent to a Slack channel for security team triage.

The creation of the allow list was a collaborative process. Tiwari engaged with developers, particularly those working on smart contracts, to understand their essential tooling needs. He identified legitimate extensions for critical SDKs like Hardhat and Foundry, and used their official domains to build a trusted list. This allowed for a focused approach, flagging only those extensions that were not explicitly sanctioned. Through this process, his team discovered one user with an astonishing 157 extensions, prompting a cleanup effort where MDM was used to remove unnecessary extensions from developer machines after appropriate communication.

Recognizing the limitations of relying solely on MDM for deep analysis, Tiwari also developed a custom IDE extension scanner tool, which he named ID viewer. While not yet open-sourced (he plans to release it on GitHub), this tool is designed to:

• Scan installed IDEs and their extensions.
• Analyze the permissions each extension acquires (e.g., by parsing manifest files and identifying API calls).
• Apply a scoring mechanism to assess the risk level of each extension, providing an indication of whether it's "risky to look into."
• Output its findings in JSON format, facilitating ingestion into other security tools or platforms for further analysis and automation.

The ID viewer complements the MDM-based inventory by providing deeper insights into what an extension can do, allowing security teams to differentiate between an overly permissive but legitimate extension and a potentially malicious one. This enables a more nuanced triage playbook, where extensions flagged by the MDM policy can then be subjected to a deeper scan by ID viewer.

Defensive Implications

▶ Watch: Massive scale of extensions and missing permission models (6:05)

The insights from Vinod Tiwari's talk provide a clear roadmap for defenders to address the critical security blind spot of IDE extensions on developer workstations. Implementing these strategies can significantly reduce the risk of supply chain attacks and data breaches originating from compromised development environments.

1. Establish Comprehensive Inventory and Monitoring: The first step is to gain visibility. Leverage existing MDM tools (e.g., Jamf) or EDR solutions (e.g., CrowdStrike) to enumerate all installed IDEs and their extensions across developer machines. If direct EDR capabilities are insufficient for granular extension data, custom bash scripts or PowerShell scripts can be deployed via MDM to collect this information periodically. The goal is to build a complete inventory of all extensions in use.

1. Implement an Extension Allow List: Develop and maintain a strict allow list of approved extensions. This list should be curated in collaboration with development teams to ensure essential tools are included. Any extension not on this list should trigger an alert for investigation. This proactive approach helps control the attack surface by limiting the approved software developers can install.

1. Analyze Extension Permissions: Do not rely solely on an extension's popularity or perceived trustworthiness. Actively analyze the manifest files (e.g., package.json for VS Code, plugin.xml for JetBrains) and the APIs an extension requests or can access. Flag extensions that demand excessive or unnecessary permissions for their stated function (e.g., a theme extension requesting access to SSH keys or clipboard). Tools like Tiwari's ID viewer can automate this permission analysis and risk scoring.

1. Review Source Code for Suspicious Extensions: For critical or suspicious extensions, especially those not widely vetted, review their source code if it's publicly available (e.g., on GitHub). Look for unusual network calls, obfuscated code, or functionality unrelated to its advertised purpose. This is a time-intensive task but crucial for high-risk extensions.

1. Scrutinize Marketplace Listings and Developer Reputation: While not foolproof, consider factors beyond just star ratings. Look for active community support, frequent updates, responsiveness to issues, and the overall reputation of the maintainers. Be wary of newly published extensions with few downloads or generic-sounding names that might be type-squatted versions of popular tools.

1. Disable Automatic Updates: Educate developers and enforce policies to disable automatic updates for IDE extensions. While this might slightly impact developer convenience, it provides a critical window for security teams to vet updates for potential malicious changes before they are silently deployed across the fleet. Developers can be instructed to update extensions manually after security approval.

1. Integrate with SIEM/SOAR for Alerting and Triage: Ensure that alerts generated by MDM/EDR or custom scripts (like those sent to Slack in Tiwari's example) are integrated into a Security Information and Event Management (SIEM) or Security Orchestration, Automation, and Response (SOAR) platform. This enables centralized logging, correlation with other security events, and a defined triage playbook for investigating flagged extensions.

1. Educate Developers: Conduct regular security awareness training for developers, emphasizing the risks of installing unvetted extensions, the importance of allow lists, and how to identify suspicious behavior. Foster a culture where developers are part of the security solution, not just a potential vulnerability.

Key Takeaways

• IDE Extensions are a High-Privilege Threat: Both VS Code and JetBrains extensions operate with full user-level access and minimal to no sandboxing, making them incredibly powerful and dangerous vectors for supply chain attacks.
• Developer Workstations are a Blind Spot: Many organizations lack basic visibility, inventory, or approval processes for IDE extensions, creating a significant, unmonitored attack surface.
• Silent Updates & Lack of Permission Prompts Increase Risk: Extensions often auto-update silently, and IDEs typically grant full system access without explicit permission requests, facilitating the covert deployment of malware.
• Leverage Existing Tools for Initial Detection: MDM solutions like Jamf can be effectively repurposed with custom scripts to inventory extensions and enforce allow lists, providing a foundational layer of detection without specialized security tools.
• Permission Analysis is Crucial: Defenders must analyze the specific permissions extensions acquire (e.g., file system access, clipboard access, child process execution) to identify overly permissive or potentially malicious behavior, especially for extensions like themes that should require minimal access.
• Build Custom Tools to Fill Gaps: Where commercial EDRs or MDMs fall short in granular extension analysis, custom scanners like the "ID viewer" can provide deeper insights into extension capabilities and risk scores.

About the Speaker(s)

Vinod Tiwari is a Staff Security Engineer at Story Protocol, a layer one blockchain company focused on intellectual property registration and DeFi protocols. Prior to his current role, Vinod gained experience at prominent technology companies such as Amazon and Zapier. He has also served as a penetration tester for platforms like HackerOne and Cobalt. Vinod began his career as a web security engineer, later transitioning into cloud security, and currently specializes as a generalist with a strong passion for developer tooling security. This presentation at BSides SF marked his inaugural speaking engagement at a conference.