Introduction to GitLab CVE-2023-2825
On May 23, 2023, GitLab unveiled version 16.0.1 to address a critical vulnerability named CVE-2023-2825 that was discovered in both the Community Edition (CE) and Enterprise Edition (EE) of GitLab version 16.0.0. A security researcher known as ‘pwnie’ discovered this GitLab CVE via HackerOne’s bug bounty program.
In this article, we delve into the specifics of CVE-2023-2825. This vulnerability, possessing a CVSS score of 7.5, enables an unauthenticated user to read arbitrary files on the server under certain conditions. We will guide you through the steps to exploit this GitLab CVE, highlighting its impact and the necessity of timely patching.
Understanding the GitLab CVE
CVE-2023-2825, as described by GitLab’s advisory, is a path traversal issue that can be taken advantage of by an unauthenticated malicious user. The GitLab CVE allows the attacker to read arbitrary files on the server, provided an attachment is present in a public project nested within a minimum of five groups. Classified as a high-severity issue, this vulnerability has a CVSS score of 7.5.
The uniqueness of CVE-2023-2825 lies in its particular requirement: the project needs to be nested within at least five groups. Tests showed a direct relationship between the number of groups and the directories that could be traversed. The rule appeared to be N + 1, which means if you aim to traverse 10 directories, you need 11 groups.
The Exploit: File Upload and Path Traversal
The exploit of CVE-2023-2825 revolves around a path traversal vulnerability, which allows an attacker to read arbitrary files on the server. Here’s a more detailed breakdown of the exploit process:
Identify a Suitable Repository: The attacker must first find a public repository nested within at least five groups. This is a requirement for the exploit to work.
For this attacker can use OSINT with Shodan Dork :-
application-77ee44de16d2f31b4ddfd214b60b6327fe48b92df7054b1fb928fd6d4439fc7e.css
Create Nested Group Items
The next step in exploiting this vulnerability is to create a nested group project. GitLab allows groups to nest within other groups, creating multiple subgroups. You’ll need to create a project nested within at least five groups for this exploit.
For example, you might create a project that can be accessed via the following URL: /a/b/c/d/e/f/g/proj
Add an Item Attachment
You must initiate an issue once you’ve created your nested group project. During this process, you’ll have the opportunity to add attachments. For this exploit, you’ll need to add at least one attachment.
Download the File
Next, you’ll need to modify the file download address. This will involve trial and error as you construct the correct path to exploit the vulnerability.
Successfully Read the File
Once you’ve correctly constructed the path, you can read the file. This demonstrates the successful exploitation of the CVE-2023-2825 vulnerability.
In conclusion, while this vulnerability requires a specific set of conditions to exploit (a public project nested within at least five groups and an attachment), it’s relatively simple to reproduce once those conditions are met.
The exploit is based on the fact that GitLab does not correctly sanitize the file path in the URL. This allows an attacker to manipulate the file URL to traverse the file system and access arbitrary files. The URL encoding step is crucial because it allows the attacker to bypass the standard routing of GitLab and directly access the file system.
It’s important to note that the number of directories that can be traversed is directly related to the number of groups the project is nested within. The attacker must create sufficient nested groups to traverse to the desired directory.
This exploit is quite complex due to the specific conditions required for it to work. However, once these conditions are met, the exploit can have a significant impact, allowing an attacker to read any file on the server.
The Code Behind CVE-2023-2825
The introduction and subsequent patching of the GitLab CVE-2023-2825 vulnerability is due to changes in how GitLab handles file paths when dealing with attachments.
In GitLab version 16.0.0, a new method named retrieve_from_store() was introduced in the file /app/uploaders/object_storage.rb to handle a variable, @filename. However, improper sanitization of the @filename variable led to the path traversal vulnerability, allowing attackers to manipulate the variable to include path traversal sequences (like ../), thereby accessing arbitrary server files.
In the patched version (16.0.1), GitLab introduced new filtering and validation functions to prevent path traversal elements’ injection. These changes are present in the Gitlab::Utils.check_path_traversal method, which checks the file path for any path traversal sequences and rejects them, effectively patching the vulnerability.
Additional validation logic and changes to two existing files: /app/uploaders/object_storage.rb and /app/controllers/concerns/uploads_actions.rb were introduced, thereby strengthening GitLab’s file handling security.
Mitigating the Risk
The risk associated with CVE-2023-2825 can be mitigated through several steps:
- Upgrade to GitLab 16.0.1 or later.
- Disable public projects to prevent unauthenticated users from exploiting the GitLab CVE.
- Filter attachments to prevent unauthenticated users from uploading attachments that could be used for exploitation.
If upgrading to GitLab 16.0.1 or later is not possible, you should:
- Disable public projects.
- Filter attachments.
- Monitor your system for signs of exploitation, like unauthorized file access or unusual network traffic, and investigate immediately.
Conclusion
Despite the specific conditions required for its exploitation, CVE-2023-2825 is a significant GitLab vulnerability that allows unauthenticated users to read arbitrary server files. This emphasizes the importance of keeping software up-to-date and maintaining robust cybersecurity practices to mitigate potential risks.
How can PingSafe help?
PingSafe can detect this CVE-2023-2825 vulnerability on your infrastructure without an agent. Request a free personalized demo to see how PingSafe protects your cloud infrastructure from this vulnerability and new zero-day vulnerabilities.
