Gitlab.com's Kubernete Gitlab-Runner installed by Helm Tiller is Outdated and vulnerable to Kubernete Server Takeover
HackerOne report #418018 by ngalog on 2018-10-03:
Summary: The current implementation with Google Kubernete is problematic and is causing a few security risks to Gitlab user. Gitlab.com/EE introduced one-click integration with GCP Kubernete, and user could install all required apps such as gitlab-runner, Ingress, Jupyter Hub with a few clicks. I am reporting two findings with regards of this integration. Outdated gitlab-runner is installed on kubernete integration and it is vulnerable to Kubernete instance takeover by using the metadata endpoints in GCP.
Description:
Outdated gitlab-runner is installed
On gitlab.com, properly setup the GCP account with enough free credits, and install gitlab-runner on kubernete, you will notice the installed version is 10.3 -- which is too old, the current version (as in 3rd Oct) is 11.3.0 and vulnerable to a lot of security bug. PoC:
Steps To Reproduce:
- Setup GCP for free credit
- Visit https://gitlab.com/:project_name_space/clusters/new and sign in with GCP credential
- After successful creation of the cluster, install Helm Tiller
- Then install Gitlab-runner
- Go to GCP panel, you will see the installed version of gitlab-runner is outdated - 10.3
Kubernete Instance Takeover
This kubernete gitlab-runner is actually much more dangerous then the shared runner installed in gitlab.com, because it is running on kubernete, and you can execute command on the instance with the private key of kubernete, according to https://hackerone.com/reports/341876, and in this case, it is much easier to obtain the cert of this kubernete instance with gitlab-runner
Steps To Reproduce:
- Follow the steps above
- And add the below snippet to your project's
.gitlab-ci.yml
# This file is a template, and might need editing before it works on your project.
# Full project: https://gitlab.com/pages/octopress
image: ruby:latest
aaa:
script:
- curl http://metadata.google.internal/computeMetadata/v1beta1/instance/attribute?recursive=true
- curl http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true
- run pipeline, you will be able to view all the sensitive info of the kubernete instance
Even gitlab-runenr did fix the SSRF bug in latest version, kubernete integration will still be vulnerable because it keeps installed the outdated version of gitlab-runner
Impact
Gitlab-runner installed on GCP kubernete is outdated and vulnerable to instance takeover/command injection
Attachments
Warning: Attachments received through HackerOne, please exercise caution!