K8s RBAC Misconfiguration leads to resource hijacking
Tags: kubernetes, misconfiguration, typosquating, cryptominer
Published: 2023-04-27 17:53:25

Photo by [Unsplash](https://unsplash.com/@nampoh?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Maxim Hopman</a> on <a href="https://unsplash.com/photos/PEJHULxUHZs?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
  
Original Blogpost by : [AquaSec](https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters
)

## TL;DR;
Kubernetes Cluster ที่มีการตั้งค่าอย่างไม่ถูกต้อง เช่นยอมให้เกิด Unauthenticated request และ anonymous user มี privileges บางอย่าง สามารถถูก Resource Hijacking และเคสนี้มีการทำ Typo Squating ที่น่าสนใจด้วยครับ


---

เคสนี้เป็นการวิเคราะห์โดยอาศัยข้อมูลที่ได้จากการตั้ง Kubernetes  Honeypots ของทีม Aqua โดยได้ข้อมูลดังนี้

- Kubernetes มีการตั้งค่าที่ไม่ถูกต้อง โดยยอมให้มี unauthenticated request และ anonymous user มี Privileges บางประการ ในที่นี้คือสามารถ list Kubernetes resources รวมถึง secrets มาได้
  verb หรือการกระทำที่สามารถทำได้ใน Kubernetes ในระดับ ClusterRole มี ["get", "list", "watch", "create", "update", "patch", "delete"]
- มีการ List Secrets ออกมา ซึ่งรวมถึง Secrets ของ User สิทธิ์สูงคนอื่นๆ ทำให้สามารถใช้ Secrets ที่ได้มาเข้าใช้งานด้วยสิทธิ์ที่สูงได้
- ทำการตรวจเช็คชื่อ Deployment ที่รันอยู่ใน namespace kube-system ซึ่งเป็น namespace ที่ปกติจะมี container ของ control plane รันอยู่ ทำให้เกิดความเนียนและตรวจจับยากยิ่งขึ้น ณ จุดนี้ Attacker จะมองหา Deployment ชื่อ kube-controller ถ้ามีอยู่จะทราบได้ว่าเคยมีการโจมตี Kubernetes Cluster นี้แล้ว แต่หากยังไม่มี ก็จะสร้าง Deployment นี้ขึ้นมาไว้
- ตรวจ namespace kube-system ต่อว่ามี Deployment ชื่อ 'kube-secure-fhgxtsjh', 'kube-secure-fhgxt', 'api-proxy', and 'worker-deployment' อยู่หรือไม่ หากมีจะทำการลบ
  ในเคสนี้เป็นไปได้สองกรณีครับ คือลบเวอร์ชั่นเก่าๆ ที่เคยเข้ามา เพราะชื่อเดิมยังตรวจจับได้ง่าย แล้วแทนที่ด้วยชื่อใหม่คือ kube-controller ที่ตรวจจับได้ยากกว่า
  อีกกรณีคือ เป็นการลบ Deployment ของ Attacker เจ้าอื่นๆ เพื่อแย่งการใช้งาน Resources บนเครื่องไว้เพียงคนเดียว
- ถัดมาจะเป็นการทำ Persistence ครับ เพื่อให้สามารถเข้าถึง Cluster ในภายหลังได้แม้ระบบที่ไม่ปลอดภัยถูกแก้ไขแล้ว โดยสร้าง service account ชื่อ "kube-controller" ใน namespace kube-system และสร้าง ClusterRole ชื่อ 'system:controller:kube-controller' และให้สิทธิ์สูง จากนั้น binding service account และ ClusterRole เข้าด้วยกัน
- มีข้อสังเกต เมื่อ Attacker เข้ามาได้แล้ว สามารถที่จะสร้าง Account ใหม่ แล้ว bind เข้ากับ cluster-admin role ซึ่งเป็น role ที่มีสิทธิ์สูงได้ แต่ Attacker เลือกที่จะสร้าง ClusterRole ใหม่ โดยไม่ยุ่งกับ cluster-admin เดิม ทำให้ยากต่อการตรวจจับมากยิ่งขึ้น เช่น กรณีที่มี User ที่มีสิทธิ์ระดับ cluster-admin อยู่จำนวนจำกัด หากมี User เพิ่มเข้ามาก็จะถูกตรวจพบได้ง่าย
- ใน Kubernetes Honeypots มีการจงใจใส่ AWS access keys ไว้ด้วย เมื่อ Cluster ถูกโจมตี พบว่ามีความพยายามในการใช้ AWS access keys ที่ได้ไปใช้งาน Services อื่นๆ ของ AWS จากนอก Kubernetes Cluster. แสดงว่าน่า Attacker สำรวจ Cluster แล้วนำสิ่งที่ได้ไปใช้งานต่อ
- มาถึงการเก็บเกี่ยวผลประโยชน์ครับ หลังจากที่ Attacker เข้า Cluster มาได้ จะสร้าง daemonset ซึ่งจะรัน Container อยู่ในทุก ๆ Worker node เรียกได้ว่าใช้งาน Resources ที่มีอย่างเต็มที่นั่นเอง  ใช้ Image ชื่อ 'kuberntesio/kube-controller:1.0.1' ซึ่งอัพโหลไว้บน Docker Hub เมื่อ 5 เดือนที่แล้ว และมียอด Pull รวม 14,399 ครั้ง และมี tag ทั้งหมด 3 tag
- Image นี้เมื่อทดสอบกับ Virustotal จะพบว่าเป็น cryptominers
- มีการ Track ไปถึง XMR Wallet และสรุปออกมาว่า Attacker ได้เงินไปแล้วอย่างน้อย 5XMR

เทคนิคการทำ Typo Squating ที่ใช้
- ชื่อ User บน Docker Hub ใช้ชื่อ 'kuberntsio' ซึ่งคล้ายกับชื่อ 'kubernetesio' ต่างกันที่มี e และไม่มี e โดย User kubernetesio นั้นมี image ที่มีคนใช้งานจำนวนมาก 1M+ pull จึงเพิ่มความน่าเชื่อถือหากดูเผิน ๆ ว่าเป็น User เดียวกัน
- ชื่อของ Image โดย image มาตรฐานที่ใช้งานจะเป็น kube-controller-manager ซึ่งจะรัน container อยู่ใน controlplane เป็นปกติ แต่ Attacker ตั้งชื่อ Image ว่า kube-controller ซึ่งคล้ายกับชื่อที่ใช้กันแพร่หลาย แตกต่างที่ไม่มี -manager ต่อท้าย ทำให้แม้ถูกตรวจพบ อาจถูกมองว่าเป็น container ใน kube-system ปกติ
- ClusterRole นอกจาก Attacker เลือกที่จะไม่ยุ่งกับ cluster-admin role เดิมแล้ว การสร้าง ClusterRole ด้วยชื่อ system:controller:kube-controller ก็ดูคล้ายชื่อของ object ใน Kubernetes


ผลกระทบ
- จากที่อยู่ Wallet, Aqua เคลมว่า Attacker ได้เงินไปแล้วอย่างน้อย 5XMR และจะได้อีก 5XMR/Node/Year
- มีเป้าหมายที่ถูกโจมตีแล้ว 60 Clusters

Mitigation:
- ตรวจเช็คสิทธิ์ของ Anonymous User ไม่ควรมีสิทธิ์ในการเรียกดู Secrets ได้
- Container Security หลาย Product สามารถช่วยตรวจสอบ Cluster Configuration โดยให้ดูว่า Solution นั้นๆ รองรับการตรวจสอบ Cluster configuration หรือไม่

อ้างอิงจาก : [AquaSec](https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters
)