K8s RBAC Misconfiguration leads to resource hijacking

#kubernetes #misconfiguration #typosquating #cryptominer

Original Blogpost by : AquaSec

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