WIZ K8S LAN Party Writeup

前言

Kubernetes CTF靶场，记录一下解题过程

“Welcome to the Kubernetes LAN Party! A CTF designed to challenge your Kubernetes hacking skills through a series of critical network vulnerabilities and misconfigurations. Challenge yourself, boost your skills, and stay ahead in the cloud security game.”

START

1.RECON

Description

You have shell access to compromised a Kubernetes pod at the bottom of this page, and your next objective is to compromise other internal services further.

As a warmup, utilize DNS scanning to uncover hidden internal services and obtain the flag. We have “loaded your machine with dnscan to ease this process for further challenges.

All the flags in the challenge follow the same format: wiz_k8s_lan_party{}

提供了两个链接

以及，”loaded your machine with [dnscan]”

点进去第一个链接开头就表达了

再结合当前Pod自带了dnscan，也就是说让扫网段探测发现其他Pod

通过env确认apiserver的地址

而apiserver大部分都在B段

请求下即可获得flag

2.FINDING NEIGHBOURS

Description

Sometimes, it seems we are the only ones around, but we should always be on guard against invisible sidecars reporting sensitive secrets.

题目描述给出了Sidecar的介绍

也就是说如果是Sidecar模式，Pod中会运行一个容器外加另一个容器(或更多)，它们共同运行在同一个 Pod 中，共享网络和存储资源，以完成协同工作。

看一下网络连接，可以发现本地的192.168.1.51 一直向 10.100.171.123:80 通信

tcpdump抓包

请求包中发现flag

3.DATA LEAKAGE

Description

The targeted big corp utilizes outdated, yet cloud-supported technology for data storage in production. But oh my, this technology was introduced in an era when access control was only network-based.

意思是网络共享存储

看一下挂载文件情况

这里留意到有一个fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com和/efs路径

cd过去没有权限打开

GPT分析了这个域名

查看一下挂载点和挂载详情

这里有这么一行

就是说路径 /efs采用了 NFS v4 协议

根据Hint#1，得知了一个NFS开源的客户端库，以及命令示例

nfs-cat 和 nfs-ls 是 NFS的一些常见工具，用于从 NFS 服务器上读取文件内容和列出目录内容

提示没有权限

根据Hint#2得知还需要提供gid和uid

最终成功获取

4.BYPASSING BOUNDARIES

Description

Apparently, new service mesh technologies hold unique appeal for ultra-elite users (root users). Don’t abuse this power; use it responsibly and with caution.

Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: istio-get-flag
  namespace: k8s-lan-party
spec:
  action: DENY
  selector:
    matchLabels:
      app: "{flag-pod-name}"
  rules:
  - from:
    - source:
        namespaces: ["k8s-lan-party"]
    to:
    - operation:
        methods: ["POST", "GET"]

简单看下，Policy描述了Istio 的安全策略，AuthorizationPolicy表示授权策略资源，控制了对flag-pod-name的访问权限，在k8s-lan-party 命名空间下，如果是GET或POST请求则拒绝

先走一遍dnscan

因为Policy策略，请求被拒绝

到处搜一下

最终找到了很详细的一篇文章 Istio outboundTrafficPolicy Egress Control Bypass

这里有这么一句

“An attacker who has root user access in a pod can use to switch to a UID which matches the iptables rules highlighted above and bypasses the restriction”

那就看一下当前的权限

打开passwd确认其中也有一个uid为1337的账号

使用这个1337的账号请求

成功获取flag

5.LATERAL MOVEMET

Description

Where pods are being mutated by a foreign regime, one could abuse its bureaucracy and leak sensitive information from the administrative services.

Policy

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: apply-flag-to-env
  namespace: sensitive-ns
spec:
  rules:
    - name: inject-env-vars
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - name: "*"
                env:
                  - name: FLAG
                    value: "{flag}"