Security Bloggers Network 
SBN

Detecting CVE-2024–32002

by AJ King on June 7, 2024

Detecting CVE-2024–32002 Git RCE

Detecting CVE-2024–32002 Git RCE

Introduction

Cloning a git repository without thoroughly reviewing the code is a common practice, but it can lead to severe consequences if you’re running a version of Git (Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4) vulnerable to CVE-2024–32002. This vulnerability allows a malicious repository to execute remote code on your system just by cloning the repo. While the exploitation of this vulnerability requires specific conditions, such as running git bash as an administrator, having symlinks enabled, and recursively cloning the repository with its submodules, it’s crucial to understand how it works, how to detect it, and how to protect yourself from falling victim to it.

If you prefer video over written text we have Threat SnapShot on this very topic.

To follow along, register for a FREE community account to access SnapAttack’s collection of Threats and Detections for this CVE: https://app.snapattack.com/collection/vulnerability/CVE-2024-32002

Exploitation Technique

CVE-2024–32002 Exploitation

The exploitation of CVE-2024–32002 relies on the way git handles case-insensitive file systems, such as those found in Windows and macOS. To exploit this vulnerability, an attacker needs to create two repositories: a main repository and a submodule repository.

  1. In the main repository, the attacker creates a symlink, for example, a pointing to .git.
  2. The attacker then creates a .gitmodules file specifying the path of the submodule repository.
  3. Let’s assume the symlink is a -> .git, and the submodule is set to A/modules/x. Due to the case-insensitive nature of the file system, this translates to .git/modules/x.
  4. The second repository, which serves as the submodule, contains a file named y/hooks/post-checkout. In Git, post-checkout is one of the many hook options available, and it is executed after any checkout operation.

When an unsuspecting user clones the main repository using the command git clone –recursive, the following sequence of events occurs:

  1. The main repository is cloned, and the main branch is checked out.
  2. The submodules are cloned, and a specific commit is checked out.
  3. However, due to the symlink setup for .git, the submodules are placed in .git/modules/x/y/hooks/post-checkout.

This scenario is problematic for two reasons:

  1. Hooks should not be created automatically.
  2. Files in the .git directory have execute permissions.

As a result, once the post-checkout script is dropped into the .git directory, it is executed due to the recent checkout command, leading to remote code execution.

To view SnapAttack’s Threat Capture for this CVE, check out: https://app.snapattack.com/threat/ffd05aae-6827-797d-735a-c86eb4c9da28

MITRE

T1036.005: Masquerading: Match Legitimate Name or Location: Adversaries may match or approximate the name or location of legitimate files or resources when naming/placing them.

T1059: Command and Scripting Interpreter: Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries.

T1203: Exploitation for Client Execution: Adversaries may exploit software vulnerabilities in client applications to execute code.

Detection Opportunities

Hook Created by Git.exe

Git should never create a hook automatically. Hooks need to be setup manually. A repository may contain the scripts needed to setup a hook but even then you would need to manually configure it after cloning a repository. Therefore, if you clone a repo and git automatically sets up a hook then something suspicious is going on.

Below you’ll find a partial log demonstrating what it looks like when git is automatically creating a hook. Detecting on this log will provide you with a high confidence alert on this CVE-2024–32002 being exploited.

EventID: 11
action: created  
ProcessName: git.exe
TargetFilename: C:\Users\localuser\git_rce\.git\modules\x\y\hooks\post-checkout

MITRE

T1036.005: Masquerading: Match Legitimate Name or Location: Adversaries may match or approximate the name or location of legitimate files or resources when naming/placing them.

Hook Executed by Git.exe

Hooks are a legitimate feature in Git. However, if hooks aren’t widely used in your environment, detection on their execution could be a helpful indicator of suspicious activity.

Below you’ll find a partial log demonstrating what it looks like when a hook is triggered by git. Notice the `ParentCommandLine` containing the checkout command that triggered the execution of the hook.

EventID: 1
ParentProcessName: git.exe
CommandLine: bash C:/Users/localuser/git_rce/.git/modules/x/y/hooks/post-checkout 308b41503040c0c847aa38c4df3baedfd03fc3af 270dacf296edbc2f47ac673e296f80446a1f3764 1
ParentCommandLine: git checkout -q -f 270dacf296edbc2f47ac673e296f80446a1f3764

MITRE

T1059: Command and Scripting Interpreter: Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries.

T1203: Exploitation for Client Execution: Adversaries may exploit software vulnerabilities in client applications to execute code.

Prevention Measures

To protect yourself from falling victim to CVE-2024–32002, consider the following preventive measures:

  1. Ensure that you are using an updated version of Git that includes the necessary patches for this vulnerability.
  2. Avoid running git bash with administrative privileges unless absolutely necessary.
  3. Disable symlinks in your git configuration if they are not required for your workflow.
  4. Be cautious when cloning repositories from untrusted sources, and review the code before recursively cloning submodules.

Conclusion

Understanding the exploitation techniques of CVE-2024–32002 is crucial for effectively detecting and responding to this vulnerability. By implementing robust detection mechanisms, such as monitoring for automatically created hooks by Git.exe and the execution of hooks in environments where they are not commonly used, you can quickly identify potential exploitation attempts.

In addition to detection, proactive prevention measures play a vital role in safeguarding your git environment. Regularly updating Git to the latest patched versions, restricting administrative privileges, disabling symlinks when not needed, exercising caution when cloning from untrusted sources, and continuously educating yourself and your team about secure git practices are all essential steps in reducing the risk of falling victim to CVE-2024–32002.

SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other community detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!

Resources

Detecting CVE-2024–32002 was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from SnapAttack - Medium authored by AJ King. Read the original post at: https://blog.snapattack.com/detecting-cve-2024-32002-a641d4f6c502?source=rss----3bac186d1947---4

AJ King , , , ,