นักวิจัยจาก Unit 42 (Palo Alto Networks) เปิดเผยเทคนิค Post-Exploitation ที่กระทบสภาพแวดล้อม Kubernetes ซึ่งใช้งาน SPIFFE (Secure Production Identity Framework for Everyone) และ SPIRE สำหรับออก Workload Identity แบบ Short-Lived โดยผู้โจมตีที่มีสิทธิ์ Root บน Kubernetes Node อยู่แล้วสามารถแก้ไขข้อมูล Linux Cgroup เพื่อสวมรอยเป็น Workload อื่นบน Node เดียวกัน และหลอกให้ SPIRE Agent ออก Credential ของ Workload เป้าหมายให้กับตนเองได้ ทั้งนี้ยังไม่พบหลักฐานว่าเทคนิคนี้ถูกนำไปใช้โจมตีจริงในวงกว้าง
รายละเอียดการโจมตี
SPIFFE/SPIRE คืออะไร และทำงานอย่างไร
SPIFFE เป็นมาตรฐานเปิดสำหรับกำหนดตัวตนให้กับ Workload ในสภาพแวดล้อม Cloud Native โดยแต่ละ Workload จะได้รับชื่อและเอกสารยืนยันตัวตนที่เรียกว่า SPIFFE Verifiable Identity Document (SVID) ซึ่งมีอายุการใช้งานสั้น (Short-Lived) เพื่อลดความเสี่ยงจาก Credential รั่วไหล ส่วน SPIRE คือ Implementation ที่ใช้งานจริงของมาตรฐาน SPIFFE โดย SPIRE Agent ที่ทำงานอยู่บนแต่ละ Node มีหน้าที่ตรวจสอบคุณสมบัติของ Process (Selector) ก่อนออก Credential ให้ เช่น ตรวจสอบ Namespace, Service Account หรือ Label ของ Container นั้นๆ
เทคนิคการโจมตีด้วยการแก้ไข Cgroup
Linux Cgroup (Control Group) เป็นกลไกที่ Kernel ใช้จัดกลุ่มและจำกัดทรัพยากรของ Process ซึ่ง SPIRE Agent นำข้อมูล Cgroup Path มาใช้เป็นส่วนหนึ่งในการระบุตัวตนของ Process และ Container บน Node Unit 42 พบว่าหากผู้โจมตีมีสิทธิ์ Root บน Node อยู่แล้ว จะสามารถสร้างหรือแก้ไข Cgroup Path ให้มีลักษณะคล้ายกับ Workload เป้าหมาย จากนั้นนำ Process ที่ตนควบคุมเข้าไปอยู่ใน Cgroup ปลอมนั้น เมื่อ SPIRE Agent ตรวจสอบ Selector ของ Process จะพบว่าตรงกับเงื่อนไขที่ลงทะเบียนไว้สำหรับ Workload เป้าหมาย และออก SVID Credentials ของ Workload เป้าหมายให้กับ Process ปลอมโดยไม่รู้ตัว
เครื่องมือพิสูจน์แนวคิด "Spooffe"
เพื่อสาธิตความเป็นไปได้ของเทคนิคนี้ นักวิจัย Unit 42 ได้พัฒนาเครื่องมือทดสอบชื่อ "Spooffe" ซึ่งทำหน้าที่สแกน Node เพื่อค้นหา Workload ที่กำลังทำงานอยู่ จากนั้นสร้าง Cgroup Path เลียนแบบ Workload เหล่านั้น และเรียกขอ Identity จาก Local SPIRE Agent เพื่อทดสอบว่าสามารถได้รับ Credential ของ Workload เป้าหมายจริงหรือไม่ ผลการทดสอบยืนยันว่าเทคนิคนี้สามารถใช้งานได้จริงในสภาพแวดล้อมที่พึ่งพา Selector แบบง่ายเพียงอย่างเดียว
เงื่อนไขเบื้องต้นของการโจมตี
จุดสำคัญที่ต้องเข้าใจคือเทคนิคนี้ไม่ใช่ช่องโหว่แบบ Remote Exploit ที่โจมตีจากภายนอกได้โดยตรง แต่เป็นเทคนิค Post-Exploitation ที่ผู้โจมตีต้องมีสิทธิ์ Root บน Kubernetes Node อยู่ก่อนแล้ว ไม่ว่าจะได้มาจากช่องโหว่อื่น การตั้งค่าที่ผิดพลาด หรือ Insider Threat กล่าวอีกนัยหนึ่งคือเทคนิคนี้เป็นการขยายผลกระทบ (Impact Amplification) หลังจากที่ Node ถูกบุกรุกแล้ว ไม่ใช่จุดเริ่มต้นของการโจมตี แต่ก็สะท้อนให้เห็นว่าการมี Root Access บน Node เพียงจุดเดียวสามารถขยายผลกระทบไปยัง Workload Identity ของ Container อื่นๆ ที่ใช้ Node เดียวกันได้ทั้งหมด
ผลกระทบที่อาจเกิดขึ้น
1. การสวมรอยเป็น Service ที่เชื่อถือได้ทั่วทั้งคลัสเตอร์
ผู้โจมตีที่ขโมย SVID Credentials ของ Workload เป้าหมายได้สำเร็จ สามารถสวมรอยเป็น Service ที่เชื่อถือได้และเข้าถึงระบบภายในองค์กรในฐานะ Workload จริง เช่น เชื่อมต่อกับ Database, API ภายใน หรือ Service Mesh อื่นๆ ที่ Workload เป้าหมายมีสิทธิ์เข้าถึง โดยระบบปลายทางจะไม่สามารถแยกแยะได้ว่าเป็นการเชื่อมต่อจาก Process ปลอม
2. ผลกระทบขยายวงกว้างถึงทุก Container บน Node เดียวกัน
เนื่องจากเทคนิคนี้อาศัยเพียงสิทธิ์ Root บน Node เดียว ผู้โจมตีจึงสามารถขโมย Identity ของ Workload ทุกตัวที่ทำงานอยู่บน Node เดียวกันได้ทั้งหมด ไม่ใช่เฉพาะ Workload ที่ถูกบุกรุกโดยตรง ซึ่งหมายความว่าความเสียหายจาก Node เดียวที่ถูกยึดสามารถขยายผลกระทบไปยัง Service จำนวนมากที่ใช้ Node ร่วมกัน
3. ความเสี่ยงสูงในสภาพแวดล้อมที่ใช้ Selector แบบง่าย
องค์กรที่ตั้งค่า SPIRE Registration Policy โดยพึ่งพา Selector พื้นฐานที่เลียนแบบได้ง่าย เช่น Namespace หรือ Label เพียงอย่างเดียว มีความเสี่ยงสูงที่สุด เนื่องจากผู้โจมตีสามารถปลอมแปลง Cgroup ให้ตรงกับเงื่อนไขเหล่านี้ได้ไม่ยาก
4. การตรวจจับทำได้ยากเนื่องจากใช้กลไกที่ถูกต้องตามการออกแบบ
เทคนิคนี้ไม่ได้อาศัยช่องโหว่ของซอฟต์แวร์ (Bug) แต่เป็นการใช้กลไกการตรวจสอบตัวตนที่ SPIRE ออกแบบไว้อย่างถูกต้องตามเงื่อนไข ทำให้การตรวจจับด้วยเครื่องมือ Security ทั่วไปที่มองหา Signature ของการโจมตีทำได้ยาก จำเป็นต้องอาศัยการเฝ้าระวังพฤติกรรมของ Cgroup และ Process ที่ผิดปกติแทน
สิ่งที่องค์กรควรทำ
1. จำกัดสิทธิ์ Root บน Kubernetes Node อย่างเข้มงวด
องค์กรควรพิจารณาว่าการมีสิทธิ์ Root บน Node เทียบเท่ากับการมีสิทธิ์เข้าถึง Workload Identity ทั้งหมดที่ทำงานอยู่บน Node นั้น จึงควรจำกัดผู้ที่สามารถเข้าถึงสิทธิ์ Root บน Node ให้น้อยที่สุดเท่าที่จำเป็น และใช้ Just-in-Time Access แทนการให้สิทธิ์ถาวร
2. บล็อก Privileged Container, Host Mount และ Host Networking ที่ไม่จำเป็น
ควรกำหนดนโยบาย Pod Security Standards หรือเครื่องมือควบคุมที่เทียบเท่า เพื่อป้องกันการรัน Privileged Container และการเข้าถึง Host Mount หรือ Host Networking โดยไม่จำเป็น เนื่องจากสิ่งเหล่านี้เป็นช่องทางที่ผู้โจมตีอาจใช้เพื่อยกระดับสิทธิ์เป็น Root บน Node ได้ในขั้นตอนก่อนหน้า
3. ใช้ Registration Policy ที่มากกว่า Selector แบบง่าย
องค์กรที่ใช้งาน SPIFFE/SPIRE ควรทบทวน Registration Policy ให้ใช้ Selector หลายชั้นร่วมกัน แทนการพึ่งพา Namespace หรือ Label เพียงอย่างเดียว เพื่อเพิ่มความยากในการปลอมแปลง Cgroup ให้ตรงกับเงื่อนไขทั้งหมด
4. แยก Workload สำคัญออกจาก Node ทั่วไป
Workload ที่มีความสำคัญสูงหรือเข้าถึงข้อมูลอ่อนไหวควรถูกแยกไปทำงานบน Node เฉพาะ (Dedicated Node) แทนที่จะรวมอยู่กับ Workload ทั่วไป เพื่อลดโอกาสที่การบุกรุก Node หนึ่งจะกระทบ Workload สำคัญด้วย
แนวทางลดความเสี่ยงระยะยาว
1. เฝ้าระวังการเปลี่ยนแปลง Process, Container และ Cgroup แบบต่อเนื่อง
องค์กรควรติดตั้งเครื่องมือ Runtime Security ที่สามารถตรวจจับพฤติกรรมผิดปกติในระดับ Process, Container และ Cgroup ได้แบบ Real-time เช่น การสร้าง Cgroup Path ใหม่ที่ไม่สอดคล้องกับ Workload ที่ Deploy จริง หรือ Process ที่ย้ายตัวเองเข้าไปใน Cgroup ของ Workload อื่น
2. รวมการหมุนเวียน Credential เข้าเป็นส่วนหนึ่งของ Incident Response
เมื่อสงสัยว่า Node ถูกบุกรุกหรือมีสิทธิ์ Root ตกอยู่ในมือผู้ไม่หวังดี ควรพิจารณาหมุนเวียน SVID Credentials ของ Workload ทั้งหมดที่เคยทำงานบน Node นั้น และทบทวน Session หรือการเชื่อมต่อที่เกิดขึ้นในช่วงเวลาที่สงสัย
3. จัดทำสถาปัตยกรรม Zero Trust ที่ไม่พึ่งพา Node เพียงจุดเดียว
องค์กรควรออกแบบสถาปัตยกรรมความปลอดภัยที่ไม่ถือว่า Node เป็นขอบเขตความน่าเชื่อถือ (Trust Boundary) เพียงจุดเดียว แต่เพิ่มการตรวจสอบสิทธิ์ในระดับ Service-to-Service เพิ่มเติม เพื่อลดผลกระทบหาก Identity ของ Workload ใดถูกขโมยไป
4. ทบทวนมาตรฐาน Selector และ Registration Policy ตามแนวทางที่ผู้พัฒนา SPIFFE/SPIRE เผยแพร่
เนื่องจากเทคนิคนี้เป็นที่รับทราบในวงกว้างแล้ว องค์กรควรติดตามคำแนะนำและแนวทางปฏิบัติที่ดีที่สุด (Best Practices) จากชุมชนผู้พัฒนา SPIFFE/SPIRE อย่างต่อเนื่อง เพื่อปรับปรุง Registration Policy ให้ทันกับเทคนิคการโจมตีที่อาจพัฒนาต่อยอดจากแนวคิดนี้ในอนาคต
วิเคราะห์ในมุมมองจาก TXEC
เทคนิคที่ Unit 42 เปิดเผยครั้งนี้เป็นตัวอย่างที่ชัดเจนของหลักการที่ว่า "Root Access บน Node เทียบเท่ากับการควบคุม Workload ทั้งหมดบน Node นั้น" แม้จะไม่ใช่ช่องโหว่ Remote Exploit ที่โจมตีได้โดยตรงจากภายนอก แต่สิ่งที่ TXEC เห็นว่าสำคัญคือการที่เทคนิคนี้อาศัยกลไกที่ถูกออกแบบมาอย่างถูกต้อง (SPIRE Agent ตรวจสอบ Selector ตามที่กำหนด) เพียงแต่ Selector นั้นสามารถถูกเลียนแบบได้หากผู้โจมตีมีสิทธิ์ Root ซึ่งสะท้อนว่าการออกแบบ Zero Trust Identity ต้องพิจารณาสถานการณ์ที่ Node ถูกบุกรุกไว้ด้วย ไม่ใช่เพียงป้องกันการโจมตีจากภายนอกเท่านั้น
องค์กรในประเทศไทยที่ใช้งาน Kubernetes ร่วมกับ SPIFFE/SPIRE หรือระบบ Workload Identity อื่นที่มีหลักการคล้ายกัน ควรถือว่านี่เป็นโอกาสในการทบทวนสถาปัตยกรรมความปลอดภัยของ Node ตั้งแต่การจำกัดสิทธิ์ Root ไปจนถึงการออกแบบ Registration Policy ที่รัดกุมขึ้น แม้ยังไม่พบการโจมตีจริงในวงกว้าง แต่เทคนิคที่เปิดเผยต่อสาธารณะพร้อมเครื่องมือพิสูจน์แนวคิดเช่นนี้มักถูกนำไปพัฒนาต่อยอดโดยผู้โจมตีในอนาคตอันใกล้ รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Unit 42 (Palo Alto Networks) ]