File Hijacking Vulnerability: The Elephant in the Room

File Hijacking Vulnerability: The Elephant in the Room

Speakers: Chendong Yu

Conference: NDSS Symposium

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

Overview

In this NDSS Symposium talk, Chendong Yu presented "File Hijacking Vulnerability: The Elephant in the Room," a comprehensive analysis of File Hijacking Vulnerabilities (FHVulns). FHVulns represent a critical class of security flaws where an attacker can breach security boundaries by manipulating file content or file paths, leading to severe consequences such as arbitrary code execution, privilege escalation, and data loss. Despite their prevalence and impact, a systematic understanding of FHVulns has been largely overlooked by existing research and detection techniques.

The presentation highlighted a significant gap in the current security landscape, where traditional vulnerability detection often focuses on weak file permissions while missing the broader spectrum of hijacking mechanisms. To address this, the research team conducted an in-depth empirical study of 268 well-documented FHVuln CVE records and developed JERRY, a novel dynamic analysis tool. JERRY successfully uncovered 339 previously unknown zero-day FHVulns in popular software from major vendors like Microsoft, Google, Adobe, and Intel, leading to 84 confirmed fixes, 51 CVE IDs, and $83,400 in bug bounties.

This work not only sheds light on the origins and triggering mechanisms of FHVulns but also introduces new findings, such as the underestimated risk of reading operations and the prevalence of software-tailored search strategies. The findings underscore the urgent need for developers, administrators, and users to adopt more robust defensive strategies against these pervasive yet often-ignored vulnerabilities, particularly within Windows environments where FHVulns are significantly more common.

Background

▶ Watch: Introduction to File Hijacking Vulnerabilities (FHVulns) (0:00)

Files are fundamental to modern operating systems, yet their handling frequently introduces security weaknesses. The concept of File Hijacking Vulnerabilities (FHVulns) describes scenarios where an attacker can manipulate file paths or contents to force legitimate software to interact with malicious resources, thereby breaching security boundaries. A prime example illustrating this is CVE-2022-24765, a long-standing vulnerability in the official Git client that affected Windows, Linux, and macOS for 18 years. An attacker could create a malicious .git directory containing githooks in a common location. When a victim invoked git log, the client's recursive search for a .git directory could inadvertently locate and execute the attacker's malicious hooks, leading to arbitrary code execution.

Existing research has touched upon aspects of FHVulns, often focusing on narrow categories such as detecting files with weak permissions or identifying dangerous file operations like process creation, dynamic library loading, and temporary directory creation. Tools like PrivescCheck, Spartacus, Crassus, and LPET have contributed to identifying specific types of file-related vulnerabilities. However, these efforts have largely failed to provide a systematic and comprehensive understanding of the broader FHVuln landscape, overlooking the diverse origins and triggering mechanisms that contribute to their widespread existence. This lack of a holistic view has left a significant portion of FHVulns undetected, suggesting a high prevalence of zero-day vulnerabilities in deployed software.

The research established a threat model for FHVulns, assuming a local attacker with normal user privileges. For an FHVuln to be exploitable, two conditions must be met: first, the attacker must be able to hijack specific files or directories, meaning they can create or manipulate files in locations where vulnerable software expects legitimate ones. Second, the vulnerable software must interact with these hijacked files through sensitive operations. The empirical study, analyzing 268 CVEs from 2020-2022, aimed to answer three research questions: what are the origins of hijacked files, what operations trigger vulnerabilities, and when in the software lifecycle are they triggered. The study revealed that FHVulns are significantly more prevalent in Windows systems due to factors like more world-writable directories (e.g., C:\ProgramData, C:\) and less strict search strategies for executables and dynamically loaded libraries. The persistence of FHVulns is attributed to a general lack of developer awareness and the inadequacy of existing detection tools.

Key Findings

▶ Watch: Overview of our comprehensive FHVuln analysis and JERRY tool (2:00)

The empirical study and the subsequent application of the JERRY tool yielded several critical findings, fundamentally reshaping the understanding of FHVulns:

1. Diverse Origins Beyond Weak Permissions: Contrary to the focus of many existing detection techniques, the study found that 89.9% of hijacked files originate from five distinct search strategies employed by programs and operating systems, while only 10.1% come from files created with weak permissions. These strategies include Path Search Order (e.g., CWD before PATH in Windows), Linux Paths on Windows (defaulting to C: drive), Unquoted Paths (truncation issues with spaces), Symbolic Links (improper handling leading to data loss), and most notably, Dynamically Loaded Libraries (DLLs/SO files), which accounted for 45.5% of known FHVulns due to specific search orders.
2. Six Categories of Dangerous Operations: Not all file operations are dangerous. The research identified six types of sensitive operations that frequently lead to exploitation: Moving (1.1%), Creating (8.2%), and Deleting (10.1%) primarily via symbolic links; Reading (7.1%) of configuration files leading to malicious settings or arbitrary code execution; Process Creation (28.4%) for executing hijacked files; and Image Loading (45.1%) of DLLs/SO files, which is the most frequent exploitation vector for arbitrary code execution.
3. Vulnerability Across All Lifecycle Stages: FHVulns can be triggered at any stage of a software's lifecycle. While the majority (62.3%) occur during the Starting Up stage (due to initialization, library loading, configuration reading), significant numbers were also found during Installation (17.2%, often requiring high privileges), Uninstallation (4.5%, often involving symbolic links), Updating (1.9%), and Repairing (3.7%). Usage (10.4%) also presented opportunities, though less frequently.
4. JERRY's Superior Detection Capabilities: The dynamic analysis tool JERRY demonstrated exceptional effectiveness. On a suite of 51 known, reproducible CVEs, JERRY achieved 100% Precision and 98.04% Recall, detecting 50 out of 51 vulnerabilities with no false positives. This significantly outperformed baselines like PrivescCheck (39.2% Recall, 58.8% Precision) and JERRY-Crassus (72.5% Recall, 84.1% Precision). JERRY uniquely identified 13 vulnerabilities missed by all baselines.
5. Discovery of Numerous Zero-Day FHVulns: Applying JERRY to 438 popular real-world software programs, the researchers discovered an astonishing 339 previously unknown zero-day FHVulns in 176 programs. These were found in high-impact software from vendors like Adobe, Google, Microsoft, and VMware. To date, 84 of these have been confirmed or fixed, 51 CVE IDs assigned, and $83,400 in bug bounties earned.
6. New Findings from Zero-Days: The analysis of the newly discovered FHVulns revealed two critical insights:

• Overlooked Bottom-Up Search Strategy: A previously unrecognized, software-tailored, OS-neutral bottom-up search strategy was identified, starting from the CWD and navigating upwards through parent directories. This strategy led to 8 new FHVulns in fundamental software like Git and Dotnet SDK, some of which had persisted for 18 years (e.g., the Git client vulnerability, CVE-2023-33135).
• Underestimated Risk of Reading Operations: For the new FHVulns, reading operations accounted for 30.4% of dangerous operations, a substantial increase from the 7.1% observed in existing CVEs. These new reading-related FHVulns were more diverse and led to severe consequences, including arbitrary code execution, URL redirection, and sensitive information disclosure (e.g., CVE-2023-2939 affecting Chrome's settings.dat file), highlighting that reading operations pose a greater risk than previously acknowledged.

1. Efficiency Gains: An ablation study showed JERRY's path type inference heuristic significantly improved efficiency, making it at least 2.14 times faster in the usage stage and 7.13 times faster in the installation stage compared to a version without this feature.

Technical Deep Dive

▶ Watch: Understanding the FHVuln threat model and requirements (4:00)

The core of this research is JERRY, a novel dynamic analysis tool designed to systematically detect FHVulns at runtime by simulating attacker hijacking actions. JERRY operates through a sophisticated, four-step iterative process, as outlined in its methodology:

1. Event Trace Generator: This module is responsible for executing the target program across its entire software lifecycle to generate diverse execution traces. For automated stages like installation, uninstallation, updating, and repairing, JERRY integrates with package managers such as Chocolatey on Windows. For interactive stages like starting up and usage, it employs a customized UI explorer. For command-line interface (CLI) programs, it intelligently generates option combinations from configuration files. For graphical user interface (GUI) programs, JERRY utilizes an automated GUI testing tool, UIAutomation, to simulate basic user interactions like button clicks. During execution, JERRY meticulously monitors and records detailed file access events, capturing process information (ID, command-line/GUI event, executed program), comprehensive file information (name, existence, permissions/ACLs, type), and the specific Windows driver API operation (e.g., IRP_MJ_CREATE, IRP_MJ_READ). This detailed tracing is crucial for identifying potential hijacking points and understanding the context of file interactions.

1. FHVuln Detector: This module analyzes the event traces generated in the previous step to identify actual FHVulns. An event is flagged as a vulnerability if a dangerous operation (as identified in the empirical study's RQ2) is performed on a file that could be hijacked. For instance, if a git log process performs an IRP_MJ_READ operation on a potentially hijacked C:\.gitconfig file, JERRY reports it as a vulnerability. The detector directly links the identified sensitive operations to potential security impacts: process creation and image loading directly imply arbitrary code execution, while creating, moving, and deleting operations can lead to data corruption. Reading operations, however, are often ambiguous and require additional manual analysis to confirm their security impact, as reading content alone may not always be exploitable without further context.

1. Path Pool Maintainer: This component continuously collects all newly encountered file paths from the event traces and adds them to a path pool, inferring their types (file or directory). For existing files, type inference is straightforward. For non-existent paths, JERRY employs heuristics: if a program accesses a path without first checking its parent directory's existence, it's typically inferred as a directory. If a stub is opened for the path before other file-specific operations, it's inferred as a file. Common file extensions (e.g., .exe, .dll) and directory-specific operations also assist in accurate inference. A trial-and-error mechanism serves as a fallback for ambiguous cases. This intelligent inference is vital for reducing false positives and improving efficiency.

1. Path Hijacker: Mimicking an attacker's behavior, this module creates and hijacks non-existent files identified in the path pool. For executables (.exe) and dynamic libraries (.dll), JERRY replaces them with manually crafted malicious files. For other file types, it creates a blank file. If the operation involves creating, moving, or deleting, the path hijacker creates a symbolic link pointing to a special monitoring location. Crucially, the path hijacker runs as a standalone process with normal user permissions, without root or administrator rights, to accurately simulate the capabilities of a typical local attacker. This step triggers new execution traces, feeding back into the Event Trace Generator, and the entire process iterates until no new files are encountered, ensuring comprehensive path exploration.

JERRY is primarily implemented on Windows, leveraging approximately 4,500 lines of C code based on the Microsoft Windows Driver Kit and 2,500 lines of Python code. The Event Monitor Module, a kernel driver developed using the Minifilter framework, is responsible for hooking file operation functions to record detailed event traces, including file permissions and paths, as well as parent directory permissions for non-existent files. This kernel-level monitoring provides the granular detail necessary for accurate FHVuln detection. The evaluation of JERRY was conducted on a Windows 11 virtual machine, comparing its performance against baseline tools like PrivescCheck, JERRY-Crassus (an extended version of Crassus), and LPET using Precision and Recall metrics on both known and unknown vulnerability suites.

Demo / Proof of Concept

▶ Watch: Five main origins of hijacked files: search strategies (8:00)

The talk presented two compelling case studies of zero-day FHVulns discovered by JERRY, highlighting its practical impact and the severity of these vulnerabilities:

1. Case-A: Visual Studio Vulnerability (MSRC $30,000 Bounty)

JERRY's automated UI Explorer was used to interact with Visual Studio. Specifically, it simulated a user clicking on "Git" and then selecting "Open git in cmd." During this interaction, Visual Studio attempted to search for git.exe within the current working directory (CWD). JERRY, having identified that the CWD had weak permissions (allowing an attacker to write there), detected this search. It then dynamically planted a malicious git.exe in that location. JERRY subsequently confirmed that Visual Studio successfully loaded and executed this planted malicious executable, demonstrating a clear case of arbitrary code execution. This vulnerability was responsibly reported to the Microsoft Security Response Center (MSRC) and resulted in a significant $30,000 bug bounty, underscoring the critical nature of the flaw.

1. Case-B: Gem (Ruby Package Manager) Supply Chain Risk

In another instance, JERRY analyzed Gem, the Ruby package manager. During its startup sequence, Gem attempted to access a configuration file at C:\ProgramData\gemrc. Since this specific path did not exist on the system, JERRY's Path Hijacker component intervened and created a malicious gemrc file in that location. Gem then proceeded to access and load this newly created, malicious file. The crafted gemrc file contained a URL pointing to central repositories, which, if tampered with by an attacker, could redirect Gem to download packages from a malicious source. This vulnerability, detected by JERRY, represents a significant supply chain risk, as it allows attackers to potentially hijack software package downloads for any Ruby projects utilizing Gem, leading to widespread compromise.

These case studies exemplify how JERRY's methodical approach, combining lifecycle stage interaction, detailed event tracing, intelligent path inference, and realistic attacker simulation, can uncover sophisticated FHVulns that evade traditional detection methods.

Defensive Implications

▶ Watch: Six dangerous operations exploiting hijacked files (10:00)

The findings from this research provide crucial insights for strengthening software security against FHVulns. The talk thoroughly discussed the pervasive nature of these vulnerabilities, attributing their persistence to a lack of awareness among developers and the limitations of existing detection tools. It also delved into the complex question of responsibility and offered concrete recommendations for mitigation across different stakeholders.

Why FHVulns Persist and Who is Responsible:

FHVulns are more prevalent in Windows systems due to two primary reasons: the existence of more world-writable directories (e.g., C:\ProgramData, C:\ root) and less stringent search strategies for executables and DLLs compared to Unix-like systems. Despite their impact, FHVulns remain widespread because developers often lack awareness, sometimes disagreeing with the threat model, or failing to use secure API calls (e.g., not using LOAD_LIBRARY_SEARCH flags with LoadLibraryEx). Some developers also incorrectly believe that weak permissions are solely user-induced problems, not a software defense responsibility.

Responsibility is multi-faceted:

• Software developers are accountable if their software creates files or directories with weak permissions.
• System administrators bear responsibility for global configuration files they manage.
• The role of the user is complex; while users might provide hijacked files, developers should implement protective measures like Git's whitelisting.
• Ultimately, Windows operating system developers should revisit system design to address root-level FHVulns, though this faces significant backward compatibility challenges.

Recommendations for Defense and Mitigation:

For Software Developers:

• Avoid weak permission paths: Place sensitive files in directories with strict permissions (e.g., C:\Program Files) or actively set strong permissions on public paths (e.g., C:\ProgramData).
• Correct API usage: When loading dynamic libraries, use LoadLibraryEx with LOAD_LIBRARY_SEARCH flags to prevent the current working directory (CWD) from being included in the DLL search path. For file creation/deletion, use FILE_FLAG_OPEN_REPARSE_POINT with CreateFileA to prevent symbolic link resolution.
• Cautious search strategy design: Carefully design software-tailored search strategies, recognizing the risks of bottom-up searches.
• Verify file status: Before using a file, verify its ownership. If the ownership differs from expected, terminate the operation or prompt the user for confirmation.

For System Administrators:

• Change default installation directories: Install software in high-permission directories, or use custom installation modes to achieve this.
• Remove weak permissions: Remove write permissions from the Authenticated Users group on the C:\ root directory.

For Software Users:

• Avoid weak permission paths: Do not launch programs from paths with weak permissions (e.g., C:\ProgramData).
• Verify integrity: Always verify the integrity (e.g., checksum) of downloaded software before use.

Limitations and Future Work:

JERRY, while highly effective, has limitations. Its analysis of reading operations can lead to false positives, requiring manual analysis to confirm security impact. Future work could integrate taint analysis or program understanding techniques to track file content propagation and better assess the exploitability of read data. Furthermore, JERRY's automation, reliant on Chocolatey and simple UI interactions, might miss complex program behaviors, leading to false negatives. Incorporating static analysis or mutation-based techniques could help trigger hard-to-reach components or generate more diverse user-provided content. Future research also aims to explore other attack vectors beyond files, such as registries and named pipes, and investigate cross-OS FHVulns caused by system-independent search strategies.

Key Takeaways

• FHVulns are Widespread and Overlooked: File Hijacking Vulnerabilities (FHVulns) are a critical and pervasive class of security flaws, often leading to arbitrary code execution and privilege escalation, yet they are systematically underestimated.
• Search Strategies are Key Attack Vectors: Most FHVulns originate from diverse search strategies (e.g., DLL search order, unquoted paths, bottom-up searches) rather than just weak file permissions, highlighting a significant blind spot in traditional detection.
• JERRY's Dynamic Analysis is Highly Effective: The dynamic analysis tool JERRY significantly outperforms existing baselines, uncovering hundreds of zero-day FHVulns in popular software and leading to substantial security improvements and bug bounties.
• Reading Operations Pose Greater Risk: Reading operations, previously considered less dangerous, are a growing and underestimated source of FHVulns, capable of leading to severe consequences like arbitrary code execution and data disclosure.
• Windows Systems are More Vulnerable: FHVulns are significantly more prevalent in Windows due to more world-writable directories and less strict default search path behaviors compared to Unix-like systems.
• Multi-Stakeholder Responsibility and Mitigation: Addressing FHVulns requires collective effort from software developers (secure API usage, careful path design), system administrators (secure installations), and users (avoiding weak paths, verifying integrity).

About the Speaker(s)

Chendong Yu is the speaker for "File Hijacking Vulnerability: The Elephant in the Room" presented at the NDSS Symposium. The transcript and metadata provided do not specify Chendong Yu's title or organizational affiliation.