CVE-2024-54148

Executive Summary

CVE-2024-54148 is a critical vulnerability in Gogs, an open-source self-hosted Git service. A malicious authenticated user can commit and edit a crafted symlink file to a repository, which, when accessed or processed by the server, allows the attacker to gain SSH access to the underlying server. This vulnerability stems from improper handling of symbolic links (symlinks) within repository files, leading to a path traversal or symlink following issue. The vulnerability is fixed in Gogs version 0.13.1. No public proof-of-concept (PoC) or exploit code has been released at this time.

Supply Chain & Package Security

Gogs is a Go-based application. This vulnerability does not directly affect the Go package ecosystem (e.g., Go modules) but rather the Gogs server software itself. Users should ensure they are not running vulnerable versions of the Gogs binary. The fix is included in the official Gogs release 0.13.1.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD) – However, based on the description and impact, a more realistic score is calculated below.

Calculated CVSS v3.1 Score: 8.8 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

• Attack Vector (AV): Network – The attacker can exploit this remotely.
• Attack Complexity (AC): Low – No special conditions required.
• Privileges Required (PR): Low – Attacker needs a valid user account on the Gogs instance.
• User Interaction (UI): None – No victim interaction needed.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High – Full server access leads to data exfiltration.
• Integrity (I): High – Attacker can modify server files.
• Availability (A): High – Attacker can disrupt services.

Threat Level: High. The ability to gain SSH access to the server is a severe compromise.

Deep Dive & Mechanics

The vulnerability lies in how Gogs processes symlinks within Git repositories. When a user with write access to a repository commits a file that is a symlink pointing to an arbitrary path on the server (e.g., /root/.ssh/authorized_keys), Gogs may follow that symlink during certain operations (e.g., repository browsing, file viewing, or Git hooks execution). This allows the attacker to overwrite or read sensitive files outside the repository.

Attack Flow:

1. Attacker creates a Git repository on the vulnerable Gogs instance.
2. Attacker creates a symlink file within the repository that points to a sensitive file, such as /home/git/.ssh/authorized_keys or /etc/ssh/sshd_config.
3. Attacker commits and pushes the symlink.
4. When Gogs processes the repository (e.g., during a git clone, git archive, or file preview), it follows the symlink and reads/writes the target file.
5. If the attacker can write to the SSH authorized_keys file, they can add their own SSH public key, gaining SSH access to the server.

Vulnerable vs. Patched Code

Vulnerable Code (Gogs < 0.13.1): The vulnerable code likely resides in the file handling logic where symlinks are not properly sanitized. For example, in a function that reads file content for display:

// Vulnerable: follows symlinks without checking
func readFileContent(repoPath, filePath string) (string, error) {
    fullPath := filepath.Join(repoPath, filePath)
    data, err := ioutil.ReadFile(fullPath) // Follows symlinks
    return string(data), err
}

Patched Code (Gogs >= 0.13.1): The fix involves checking if the file is a symlink and either rejecting it or resolving it safely within the repository boundaries.

// Patched: checks for symlinks and prevents following
func readFileContent(repoPath, filePath string) (string, error) {
    fullPath := filepath.Join(repoPath, filePath)
    // Check if the path is a symlink
    fi, err := os.Lstat(fullPath)
    if err != nil {
        return "", err
    }
    if fi.Mode()&os.ModeSymlink != 0 {
        return "", fmt.Errorf("symlinks are not allowed")
    }
    data, err := ioutil.ReadFile(fullPath)
    return string(data), err
}

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• A valid user account on a vulnerable Gogs instance (version < 0.13.1).
• Write access to a repository.

Steps:

1. Create a repository (or use an existing one where you have write access).
2. Create a symlink file that points to the SSH authorized_keys file of the Gogs user (typically git):

   git clone http://target-gogs-instance/user/repo.git
   cd repo
   ln -s /home/git/.ssh/authorized_keys evil_symlink
   git add evil_symlink
   git commit -m "Add symlink"
   git push origin main
   

3. Trigger processing by viewing the file in the web interface or performing a git clone on the server side.
4. Add your SSH public key to the evil_symlink file (which now points to authorized_keys). This can be done by editing the file through the Gogs web interface or by pushing another commit that modifies the symlink target content.
5. SSH into the server using the added key:

   ssh git@target-gogs-instance
   

Blue Team (Defender)

Detection:

• Monitor for unusual symlink creation in Git repositories.
• Look for commits that add files with names like evil_symlink or any file that is a symlink.
• Check for SSH login attempts from unexpected IPs.

Prevention:

• Immediately upgrade Gogs to version 0.13.1 or later.
• Restrict repository write access to trusted users only.
• Implement file integrity monitoring on the Gogs server, especially on /home/git/.ssh/authorized_keys.

Indicators of Compromise (IOCs)

• File System:
  • Unexpected symlink files in Git repositories (e.g., pointing to /home/git/.ssh/authorized_keys).
  • Modified /home/git/.ssh/authorized_keys file containing unknown SSH public keys.
• Network:
  • SSH connections from IPs not normally associated with the Gogs user.
• Logs:
  • Gogs audit logs showing creation of symlink files.
  • System logs showing SSH authentication with new keys.

Detection Engineering

YARA Rule

rule Detect_Gogs_Symlink_Exploit {
    meta:
        description = "Detects symlink files in Git repositories that may indicate CVE-2024-54148 exploitation"
        author = "Valters IT"
        date = "2024-12-01"
        reference = "CVE-2024-54148"
    strings:
        $symlink_magic = { 21 00 00 00 00 00 00 00 } // Symlink file mode in Git tree objects
        $authorized_keys = "/.ssh/authorized_keys"
        $root_ssh = "/root/.ssh/"
    condition:
        $symlink_magic and ($authorized_keys or $root_ssh)
}

Sigma Rule

title: Gogs Symlink Exploitation Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit CVE-2024-54148 by creating symlinks to sensitive files
author: Valters IT
logsource:
    product: gogs
    service: audit
detection:
    selection:
        EventID: 'REPO_FILE_CREATE'
        FileName|contains: '.ssh/authorized_keys'
        FileType: 'symlink'
    condition: selection
falsepositives:
    - Legitimate use of symlinks in repositories (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Gogs Symlink Exploit - CVE-2024-54148"; flow:to_server,established; content:"POST"; http_method; content:"/api/v1/repos/"; http_uri; content:"/contents/"; distance:0; content:"symlink"; nocase; pcre:"/\.ssh\/authorized_keys/R"; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Gogs to version 0.13.1 or later.
2. Review all repositories for suspicious symlink files, especially those pointing to system paths.
3. Rotate SSH keys for the Gogs service user (git).
4. Audit SSH authorized_keys files for unauthorized entries.

Long-term Mitigations:

• Implement strict file type validation in Git hooks to reject symlinks.
• Use a dedicated, non-privileged user for Gogs with minimal filesystem access.
• Enable filesystem auditing (e.g., auditd) to monitor symlink creation.
• Regularly apply security patches and updates.

Workaround (if upgrade is not possible):

• Disable repository write access for untrusted users.
• Manually patch the Gogs source code to reject symlinks (as shown in the patched code example).

Valters IT
DevSecOps & Cyber Threat Intelligence