Skip to content
GitLab Next
Closed
Created by Ethan Strike@estrikeDeveloper

DNS Rebind SSRF in Kubernetes Integration

Problem

As part of https://gitlab.com/gitlab-com/gl-security/engineering/issues/292 it was determined that the Kubernetes integration is vulnerable to a DNS rebind attack. This type of attack allows an attacker to bypass our SSRF protections by returning a valid IP address during validation, and a restricted/protected address when the actual connection is made.

Steps to Reproduce

  1. Setup a netcat listener on port 2345 of the GitLab server
  2. Create a Kubernetes Cluster in a project or group
  3. Input as the API URL http://rebind.gtest.dev:2345
  4. Click Add Kubernetes Cluster
  5. On resulting page Install Helm and look for connection on port 2345

Impact

SSRF protections are bypassed to make connections to internal services. The immediate impact seen is that an attacker can make connections. Network mapping is possible based on error message returned when port open.

Mitigation steps

  1. To reduce the ability to map ports, consider changing error message so that there is no differentiation based on result of connection.
  2. Review if it is possible to configure component to use a proxy, there is an on-going discussion of building an internal outbound proxy for all outbound connections. https://gitlab.com/gitlab-com/gl-security/engineering/issues/179
  3. If using 3rd party Gem/library, would it be feasible to internalize functionality and use Gitlab:HTTP?

Additional notes

There is additional discussion happening around using a dns cacher on gitlab.com with minimum TTL requirements DNS TTL. This would be considered a defense-in-depth measure.

Edited by Ethan Strike