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
- Setup a netcat listener on port 2345 of the GitLab server
- Create a Kubernetes Cluster in a project or group
- Input as the API URL
http://rebind.gtest.dev:2345
- Click
Add Kubernetes Cluster
- 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
- To reduce the ability to map ports, consider changing error message so that there is no differentiation based on result of connection.
- 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
- 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