CVE-2024-49360

Executive Summary

CVE-2024-49360 is a high-severity vulnerability in Sandboxie, a sandbox-based isolation software for Windows NT-based operating systems. The flaw allows an authenticated low-privileged user (UserA) to read all files created in sandboxes belonging to other users (UserB) within the C:/Sandbox/ directory. This occurs because Sandboxie does not enforce proper access control lists (ACLs) on sandbox folders, and it fails to reset ACLs when a user creates a malicious folder with permissive permissions. The vulnerability has a CVSS score of 9.2, indicating critical severity, and no official patch has been released. Attackers can exploit this to steal sensitive data created during sandbox sessions, such as downloaded files, temporary documents, or credentials.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but affects a standalone Windows application. The risk is primarily to enterprise environments where Sandboxie is used for isolation, as an attacker with local access can pivot to read other users' sandbox data.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
• Base Score: 9.2 (Critical)
• Attack Vector: Local (AV:L) – requires authenticated access to the system.
• Attack Complexity: Low (AC:L) – no special conditions needed.
• Privileges Required: Low (PR:L) – attacker needs only a standard user account.
• User Interaction: None (UI:N) – no victim action required.
• Scope: Changed (S:C) – vulnerable component impacts resources beyond its security scope.
• Confidentiality: High (C:H) – complete read access to other users' sandbox files.
• Integrity: None (I:N) – no file modification possible.
• Availability: None (A:N) – no denial of service.

Threat Level: Critical. The vulnerability enables lateral data theft in multi-user environments, especially on shared workstations or terminal servers.

Deep Dive & Mechanics

The root cause is improper permission management on the C:/Sandbox/ directory. By default, Windows 7+ restricts C:/Users/UserA from being readable by UserB, but Sandboxie does not extend this protection to its sandbox folders. The vulnerability manifests in two ways:

1. Direct Read Access: UserA can navigate to C:/Sandbox/UserB/xxx and read any files created by UserB during sandbox sessions. This includes downloaded executables, documents, and cached data.

2. Malicious ACL Injection: If UserB creates a folder C:/Sandbox/UserA with permissive ACLs (e.g., granting Everyone read access), Sandboxie does not reset these ACLs when UserA later uses the sandbox. This allows UserB to pre-configure a folder that UserA will unknowingly write to, enabling cross-user data theft.

The vulnerability affects all files edited or created during sandbox processing. Files in C:/Users/ are safe due to Windows default permissions, but sandbox data is exposed.

Vulnerable vs. Patched Code

No patched version exists. The vulnerable behavior is inherent to Sandboxie's design:

• Vulnerable: Sandboxie does not enforce ACLs on C:/Sandbox/ subfolders. It trusts the OS default permissions, which are insufficient.
• Patched (Hypothetical): A fix would require Sandboxie to explicitly set ACLs on each user's sandbox folder to deny access to other users, and to reset ACLs on existing folders before use.

Since no patch is available, the "patched" state is theoretical.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Two local user accounts: UserA (attacker) and UserB (victim).
• Sandboxie installed and used by UserB.

Steps:

1. UserB runs an application in a sandbox (e.g., sandboxie.exe cmd.exe), creating files in C:/Sandbox/UserB/.
2. UserA logs in and opens File Explorer or cmd.exe outside any sandbox.
3. UserA navigates to C:/Sandbox/UserB/ and reads all files.

Proof-of-Concept (cmd.exe):

:: As UserA
dir C:\Sandbox\UserB\ /s
type C:\Sandbox\UserB\defaultbox\user\Downloads\secret.txt

Malicious ACL Injection:

:: As UserB, create a folder with permissive ACLs
mkdir C:\Sandbox\UserA
icacls C:\Sandbox\UserA /grant Everyone:(OI)(CI)R /T
:: When UserA later uses sandbox, files written here are readable by UserB

Blue Team (Detection & Hardening)

Detection:

• Monitor for unusual access to C:\Sandbox\ directories by non-owner users.
• Alert on icacls commands modifying C:\Sandbox\ permissions.

Hardening:

• Manually set restrictive ACLs on C:\Sandbox\:

  # Run as Administrator
  $acl = Get-Acl "C:\Sandbox"
  $acl.SetAccessRuleProtection($true, $false)
  $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Users","Read","ContainerInherit,ObjectInherit","None","Deny")
  $acl.AddAccessRule($rule)
  Set-Acl "C:\Sandbox" $acl
  

• Use Group Policy to restrict access to C:\Sandbox\ for non-administrators.
• Consider alternative sandbox solutions with proper ACL enforcement.

Indicators of Compromise (IOCs)

• File Paths: C:\Sandbox\*\* (any file under another user's sandbox folder)
• Processes: explorer.exe or cmd.exe accessing C:\Sandbox\ with unusual user context.
• Registry: No specific registry keys.
• Network: No network indicators (local vulnerability).
• Logs: Windows Security Event ID 4663 (An attempt was made to access an object) with ObjectName containing \Sandbox\ and AccessMask indicating ReadData.

Detection Engineering

YARA Rule

rule CVE_2024_49360_Sandboxie_ACL_Bypass {
    meta:
        description = "Detects attempts to read other users' Sandboxie sandbox files"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-49360"
    strings:
        $s1 = "C:\\Sandbox\\" nocase
        $s2 = "\\Sandbox\\" nocase
    condition:
        uint16(0) == 0x5A4D and // MZ header
        any of ($s*) and
        for any i in (1..#s1): (
            @s1[i] > 0 and
            // Check if the path is not the current user's sandbox
            not ($s1[i] contains "C:\\Sandbox\\" + username)
        )
}

Sigma Rule

title: CVE-2024-49360 Sandboxie Cross-User Sandbox File Access
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects when a user reads files from another user's Sandboxie sandbox directory.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-49360
author: Valters IT
date: 2025-04-10
logsource:
    product: windows
    service: security
    category: file_access
detection:
    selection:
        EventID: 4663
        ObjectName|startswith: 'C:\Sandbox\'
        AccessMask|contains: 'ReadData'
    filter:
        ObjectName|contains: 'C:\Sandbox\%USERNAME%'
    condition: selection and not filter
falsepositives:
    - Legitimate administrative access for troubleshooting
level: high

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-49360 Sandboxie Cross-User File Access"; content:"C:\\Sandbox\\"; nocase; pcre:"/C:\\Sandbox\\(?!%USERNAME%)[^\\]+\\/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Restrict Access: Manually set ACLs on C:\Sandbox\ to deny read access for non-owners (see Blue Team hardening).
2. User Education: Advise users not to store sensitive data in sandbox folders.
3. Monitor Logs: Enable auditing on C:\Sandbox\ and review Event ID 4663.

Long-Term Fix:

• No official patch exists. Consider migrating to alternative sandbox solutions (e.g., Windows Sandbox, Sandboxie Plus with custom ACLs, or third-party tools).
• Contact Sandboxie vendor for updates.

Workaround:

• Move sandbox storage to an encrypted volume with per-user permissions.
• Use Group Policy to disable Sandboxie for non-administrators.

Valters IT
DevSecOps & Cyber Threat Intelligence