noone___'s blog
0%

THM打靶日寄58-Advent of Cyber 2024：Day22

发表于 更新于 分类于
k8s环境初识与取证

  • k8s 简介

    一个容器编排系统，例如当一个微服务在容器中运行，此时流量增加，该容器无法处理所有请求，那么可以让另一个容器为这个微服务启动以平衡两者流量。k8s 负责处理该解决方案，在需要时编排这些容器

  • 分析

    minikube start 来启动 k8s

    可以用 kubectl get pods -n wareville 来验证集群是否正在运行

    呃，重开了好几次都是这样子没加载好，以下只有文字

    连接到 pod

    1
    kubectl exec -n wareville naughty-or-nice -it -- /bin/bash

    查看 apache2 访问日志

    1
    cat /var/log/apache2/access.log

    在最后一条日志可以看到请求 shelly.php

    并且在 /home/ubuntu/dfir_artefacts 找到存储的访问日志 pod_apache2_access.log

    而由于 pod 是使用端口转发配置的，因此看不到用于连接实例的实际 ip ，而重启集群后 webshell 仍然存在，即其存在于 pod 本身的实际映像中，所以去调查 docker

    docker ps 拿到注册表容器 id

    1
    docker exec c398ebdec346 ls -al /var/log

    查看发现并没有日志，然而 docker 本身会为我们保留日志：

    1
    docker logs c398ebdec346

    已经被存储到 /home/ubuntu/dfir_artefacts/docker-registry-logs.log

    搜索 HEAD 并限制在第一页(即ip)来查看与注册表建立的所有不同链接：

    1
    cat docker-registry-logs.log | grep "HEAD" | cut -d ' ' -f 1

    可以看到大多数连接由预期ip:172.17.0.1 发起，但也有连接来自 10.10.130.253

    那么找到来自该 ip 的所有请求

    1
    cat docker-registry-logs.log | grep "10.10.130.253"

    注意到前几个请求：

    用户代理是 docker ，即是通过 dockerCLI 发出的拉取镜像请求

    考虑到他们能拉取镜像，那么也可能允许他们推送新镜像，将搜索范围缩小为 PATCH ，其用于格恩星注册表中的 docker 镜像

    1
    cat docker-registry-logs.log | grep "10.10.130.253" | grep "PATCH"

    可以看到对镜像进行了恶意更新

    那么回到 k8s 环境来看看是如何泄露的凭据

    检查角色绑定，再细看一下

    1
    2
    kubectl get rolebindings -n wareville
    kubectl describe rolebinding mayor-user-binding -n wareville

    看到有一个角色 mayor-user 与用户 mayor-malware 绑定

    1
    kubectl describe role mayor-user -n wareville

    再检查下张哥用户活动的审计日志

    1
    cat audit.log | grep --color=always '"user":{"username":"mayor-malware"' | grep --color=always '"resource"' | grep --color=always '"verb"'

    看到试图读 secret 但被 403 了，

    随后开始监视集群中存在哪些角色

    随后找到一个 job-runner 的角色，发现该角色有秘密读取权限

    那么攻击者开始尝试找到其角色绑定：

    找到 job-runner-binding ，发现该角色绑定到 job-runner-sa 的服务账户

    现在攻击者知道服务账户有其所需权限，并用 kubectl get pods 来列出在 Wareville 命名空间中运行的所有 pod

    随后找到了一个 morality-checker 的 pod ，其运行时附加了 job-runner-sa 账户。即如果能访问该 pod 则能够获得秘密读取权限

    然后发现在 k8s 中实施了过于宽松的访问控制，导致攻击者命令执行来拿到 morality-checker 的 shell 访问权限

    可以检索从 job-runner-sa 服务账户捕获的审计日志：

    1
    cat audit.log | grep --color=always '"user":{"username":"system:serviceaccount:wareville:job-runner-sa"' | grep --color=always '"resource"' | grep --color=always '"verb"'

    最后用：

    1
    kubectl get secret pull-creds -n wareville -o jsonpath='{.data.\.dockerconfigjson}' | base64 --decode

    确认攻击路径

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
What is the name of the webshell that was used by Mayor Malware?
shelly.php

What file did Mayor Malware read from the pod?
db.php

What tool did Mayor Malware search for that could be used to create a remote connection from the pod?
nc

What IP connected to the docker registry that was unexpected?
10.10.130.253

At what time is the first connection made from this IP to the docker registry?
29/Oct/2024:10:06:33 +0000

At what time is the updated malicious image pushed to the registry?
29/Oct/2024:12:34:28 +0000

What is the value stored in the “pull-creds” secret?
{“auths”:{“http://docker-registry.nicetown.loc:5000":{"username":"mr.nice","password":"Mr.N4ughty","auth":"bXIubmljZTpNci5ONHVnaHR5"}}}