关联漏洞
标题:
Google Kubernetes 安全漏洞
(CVE-2017-1002101)
描述:Google Kubernetes是美国Google公司的一套开源的Docker容器集群管理系统。该系统为容器化的应用提供资源调度、部署运行、服务发现和扩容缩容等功能。 Google Kubernetes中存在安全漏洞。攻击者可利用该漏洞访问文件/目录。以下版本受到影响:Kubernetes 1.3.x版本,1.4.x版本,1.5.x版本,1.6.x版本,1.7.14之前版本,1.8.9版本,1.9.4版本。
描述
Writeup of CVE-2017-1002101 with sample "exploit"/escape
介绍
# Sample Kubernetes Escape via [CVE-2017-1002101](https://nvd.nist.gov/vuln/detail/CVE-2017-1002101)
## Description
After hearing about the issue and following [this guide](https://www.twistlock.com/2018/03/21/deep-dive-severe-kubernetes-vulnerability-date-cve-2017-1002101/), I wanted to explore things a bit more. This repo contains a couple pod deployments and helper shell scripts that demonstrate the attack mechanism in the simplest way possible so that Kubernetes administrators and operators can fully understand the severity and potential risks. You must be an authenticated user or able to control a pod's spec/template at creation, so this escape is not likely going to be anonymous unless combined with other attacks like [this](https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c).
## Quick Explanation
When the Kubelet goes to mount a volume/secret/configmap, etc, it incorrectly follows symlinks inside the volume to locations outside the scope of where it should. Because the Kubelet is running as root, this means it can be tricked into mounting privileged parts of the host filesystem inside a non-privileged pod's container.
My approach was to use a single pod with two "normal" containers. One container creates the symlink to `/` or `/home/ubuntu` and the other crashloops until that succeeds (forcing the volume to be remounted and following that symlink path), allowing the user to exec into the second container and access the mount point.
## Quick Run
Note: These examples work without modification against an Ubuntu 16.04 host, but they can be easily tweaked for other setups.
1. Examine the files in the repo before running anything.
2. Run `./run-as-root.sh` if your cluster is fairly "stock".
3. Run `./run-as-root-no-chroot.sh` or `./run-as-user-1000.sh` for other variations.
[](https://asciinema.org/a/alFqdDOlyud1NJUCPABpgOf0v)
## Mitigation Strategy
It's really a "must-patch" situation. Unfortunately, the workarounds listed [here](https://github.com/kubernetes/kubernetes/issues/60813) aren't terribly practical for most folks. Nearly all prior versions are vulnerable.
## References
- [https://github.com/kubernetes/kubernetes/issues/60813](https://github.com/kubernetes/kubernetes/issues/60813)
- [https://nvd.nist.gov/vuln/detail/CVE-2017-1002101](https://nvd.nist.gov/vuln/detail/CVE-2017-1002101)
- [https://www.twistlock.com/2018/03/21/deep-dive-severe-kubernetes-vulnerability-date-cve-2017-1002101/](https://www.twistlock.com/2018/03/21/deep-dive-severe-kubernetes-vulnerability-date-cve-2017-1002101/)
文件快照
[4.0K] /data/pocs/8aecc3aa05ed5007e3471fa31776df15078fbd6f
├── [4.0K] asciinema
│ └── [ 32K] demo.json
├── [1.6K] exploit-pod-no-chroot.yaml
├── [1.6K] exploit-pod-user-1000.yaml
├── [1.5K] exploit-pod.yaml
├── [ 11K] LICENSE
├── [2.6K] README.md
├── [ 343] run-as-root-no-chroot.sh
├── [ 335] run-as-root.sh
└── [ 548] run-as-user-1000.sh
1 directory, 9 files
备注
1. 建议优先通过来源进行访问。
2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。