A new security vulnerability, CVE-2024-9596, has been discovered in GitLab Enterprise Edition (EE). This issue affects all versions starting from 16.6 up to but not including 17.2.9, from 17.3 up to 17.3.5, and from 17.4 prior to 17.4.2.
In simple terms, this vulnerability allows anyone on the internet (even those not logged in) to find out the exact version number of a GitLab instance. While this might sound minor, version disclosure is frequently the first step for attackers. Knowing the version helps them decide which attacks or exploits to attempt next.
Let’s break down what this bug means, how it can be exploited, and what you can do to protect yourself.
What is Version Disclosure?
Version disclosure means a software product leaks its current version number to outsiders. In many cases, software tries to hide version information. But if someone can find it (like through a web request), attackers can look up public vulnerabilities for that version and strike with targeted exploits.
Impact: Version Disclosure
Official Advisory:
GitLab Security Release: 17.4.2, 17.3.5, and 17.2.9
Step 1: Send an HTTP Request
Attackers can make a simple GET request to the affected GitLab server.
In many cases, the version information is leaked via HTTP headers, or within a visible resource such as a JavaScript or CSS file served by GitLab.
Example using curl
curl -I https://gitlab.example.com/
This command fetches just the headers of the main GitLab page.
Step 2: Look for the Version Number
In vulnerable GitLab EE installs, the response may contain headers such as X-GitLab-Version or a link to an asset like /assets/application-[version].js.
Example vulnerable HTTP response
HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
X-GitLab-Version: 17.3.2-ee
...
Or, in the page source/JavaScript link
<script src="/assets/application-17.3.2ee.js"></script>
The attacker now knows you're running version 17.3.2-ee.
Step 3: Use the Version Information
With the version info in hand, attackers search for public vulnerabilities or exploits targeting that specific release. If you were slow to patch previous critical bugs, you could be at risk of remote code execution, privilege escalation, or other dangerous attacks.
Real-World Demo
curl -I https://your-gitlab-server/
Sample Output
HTTP/2 200
X-GitLab-Version: 17.3.3-ee
Content-Type: text/html; charset=utf-8
...
Or scanning the homepage HTML for assets with the version suffix
curl https://your-gitlab-server/ | grep application-
Sample Output
<script src="/assets/application-17.3.3ee.js"></script>
Why This Matters
Even though version disclosure seems harmless, it's important to realize that most serious attacks START with attackers gathering information. If you keep your version information secret, you make an attacker's job harder.
Mitigation and Patching
Immediate Action:
Update GitLab EE to one of the fixed versions:
17.2.9 or later
Upgrade Instructions:
- Read the official upgrade documentation by GitLab.
References
- GitLab Security Release - 17.4.2, 17.3.5, 17.2.9
- GitLab Upgrade Guide
- CVE record for CVE-2024-9596
Conclusion
CVE-2024-9596 might seem "harmless" at first, but it’s a reminder that even small leaks can be the first domino in a chain of dangerous attacks. If you run GitLab EE, be sure to patch immediately.
If you need help auditing your installation or want to know more about securing self-hosted tools, keep your software up-to-date, and subscribe to security alerts from your key vendors!
Timeline
Published on: 10/10/2024 10:15:08 UTC
Last modified on: 10/10/2024 12:51:56 UTC