นักวิจัยด้านความปลอดภัยอ้างว่า Microsoft ได้แก้ไขช่องโหว่ Azure Backup for AKS อย่างเงียบ ๆ หลังจากที่ก่อนหน้านี้ได้ปฏิเสธรายงานช่องโหว่ของเขา และไม่มีการออกหมายเลข CVE
รายงานของนักวิจัยได้ระบุถึงช่องโหว่ประเภทการยกระดับสิทธิ์ระดับ Critical ซึ่งทำให้ผู้ใช้ที่มีสิทธิ์ระดับต่ำอย่าง "Backup Contributor" สามารถขยับไปเข้าถึงสิทธิ์ระดับผู้ดูแลคลัสเตอร์ได้
Microsoft ได้ออกมาโต้แย้งข้อกล่าวหาดังกล่าว โดยระบุกับ BleepingComputer ว่า พฤติกรรมของระบบเป็นเรื่องปกติที่คาดไว้อยู่แล้ว และไม่มีการเปลี่ยนแปลงผลิตภัณฑ์ใด ๆ แม้ว่านักวิจัยจะบันทึกว่ามีการเปลี่ยน permission checks ใหม่ และความพยายามในการโจมตีที่ไม่สำเร็จภายหลังจากเปิดเผยข้อมูล ซึ่งแสดงให้เห็นว่ามีการแก้ไขแบบเงียบ ๆ
CERT เห็นด้วยว่าเป็นช่องโหว่ แต่ Microsoft กลับบล็อกการออก CVE
นักวิจัยด้านความปลอดภัยไซเบอร์ Justin O'Leary ได้ค้นพบช่องโหว่ดังกล่าวเมื่อเดือนมีนาคมที่ผ่านมา และได้รายงานไปยัง Microsoft เมื่อวันที่ 17 มีนาคม
ศูนย์ตอบสนองปัญหาด้านความปลอดภัยของ (MSRC) ปฏิเสธรายงานเมื่อวันที่ 13 เมษายน โดยอ้างว่าประเด็นนี้เป็นเพียงการเข้าถึงสิทธิ์ผู้ดูแลคลัสเตอร์ในระบบที่ผู้โจมตีมีสิทธิ์ผู้ดูแลระบบอยู่ก่อนแล้ว ซึ่ง O'Leary แย้งว่า การให้คำจำกัดความดังกล่าวเป็นการบิดเบือนรูปแบบการโจมตีไปอย่างสิ้นเชิง
นักวิจัยระบุว่า "นี่เป็นข้อมูลที่ไม่ถูกต้อง ช่องโหว่นี้ทำให้ผู้ใช้ที่ไม่มีสิทธิ์ใน Kubernetes เลย สามารถเข้าถึงสิทธิ์ผู้ดูแลระบบคลัสเตอร์ได้ การโจมตีในลักษณะนี้ไม่ได้ต้องการสิทธิ์การเข้าถึงคลัสเตอร์ มันแค่ให้สิทธิ์นั้นมา"
O'Leary ยังเผยข้อมูลเพิ่มเติมอีกว่า Microsoft ได้ชี้แจงกับทางหน่วยงาน MITRE ว่ารายงานที่เขาส่งไปนั้นเป็นเพียงเนื้อหาที่สร้างขึ้นโดย AI ซึ่งเขาบอกว่าไม่ได้กล่าวถึงข้อมูลทางเทคนิคของรายงาน
หลังจากถูกปฏิเสธ O'Leary ได้ส่งเรื่องต่อไปยังศูนย์ประสานงาน CERT ซึ่งได้ตรวจสอบช่องโหว่ดังกล่าวอย่างอิสระในวันที่ 16 เมษายน และตามที่นักวิจัยระบุ ได้กำหนดหมายเลขให้กับช่องโหว่นี้ คือ VU#284781:
เดิมที CERT/CC ได้กำหนดวันที่จะเปิดเผยข้อมูลช่องโหว่นี้ต่อสาธารณะในวันที่ 1 มิถุนายน 2026 ทว่าการเปิดเผยดังกล่าวกลับไม่เคยเกิดขึ้น
ต่อมาในวันที่ 4 พฤษภาคม มีรายงานว่าทีมงานของ Microsoft ได้ติดต่อไปยัง MITRE เพื่อเสนอแนะไม่ให้มีการออกหมายเลข CVE ให้กับกรณีนี้ โดยยังคงหยิบยกข้ออ้างเดิมมาใช้ว่า ช่องโหว่ดังกล่าวจำเป็นต้องอาศัยสิทธิ์การเข้าถึงระดับผู้ดูแลระบบที่มีอยู่ก่อนแล้วจึงจะสามารถโจมตีได้:
ในเวลาต่อมา CERT/CC ได้ปิดเคสนี้ลงตามกฎการจัดลำดับชั้นของ CNA ซึ่งในทางปฏิบัติแล้ว เท่ากับเป็นการปล่อยให้ Microsoft (ซึ่งเป็นหน่วยงาน CNA เช่นกัน) มีอำนาจในการตัดสินใจออกรหัส CVE สำหรับผลิตภัณฑ์ของตนเอง
วิธีการโจมตี
Azure Backup for AKS จะใช้ฟีเจอร์ Trusted Access เพื่อให้สิทธิ์ Cluster-admin กับ extensions การสำรองข้อมูลที่ทำงานอยู่ภายใน Kubernetes clusters
ตามข้อมูลของ O'Leary ช่องโหว่นี้ ทำให้ใครก็ตามที่มีเพียงสิทธิ์ระดับต่ำอย่าง "Backup Contributor" ใน backup vault สามารถทำให้ระบบ Trusted Access ทำงานได้ โดยที่ผู้โจมตีไม่จำเป็นต้องมีสิทธิ์ใด ๆ ใน Kubernetes อยู่ก่อนเลย
ผู้โจมตีสามารถเปิดใช้งานฟีเจอร์สำรองข้อมูลบน AKS cluster เป้าหมาย ซึ่งจะส่งผลให้ Azure ทำการตั้งค่า Trusted Access โดยอัตโนมัติด้วยสิทธิ์ cluster-admin จากนั้นผู้โจมตีจะสามารถดึงข้อมูลสำคัญออกมาผ่านกระบวนการสำรองข้อมูล หรือกู้คืน workloads ที่เป็นอันตรายเข้าไปในคลัสเตอร์ได้
O'Leary ได้จัดประเภทช่องโหว่นี้ว่าเป็นช่องโหว่ประเภท Confused Deputy (CWE-441) ซึ่งเกิดจากการที่ขอบเขตการกำหนดความเชื่อถือ ระหว่าง Azure RBAC และ Kubernetes RBAC ทำงานร่วมกันในลักษณะที่ bypass authorization controls ที่กำหนดไว้
Microsoft ยืนกรานไม่ได้ปรับแก้ แต่การทำงานของระบบกลับเปลี่ยนไปอย่างชัดเจน
BleepingComputer ได้ติดต่อไปยัง Microsoft เพื่อสอบถามว่าสิ่งที่ค้นพบคือช่องโหว่ด้านความปลอดภัยที่แท้จริงหรือไม่
โฆษกของ Microsoft ได้ชี้แจงกับ BleepingComputer ว่า:
"จากการประเมินของเรา ข้อสรุปคือรายงานนี้ไม่ใช่ช่องโหว่ด้านความปลอดภัย แต่เป็นพฤติกรรมการทำงานปกติที่คาดไว้อยู่แล้ว ซึ่งจำเป็นต้องอาศัยสิทธิ์ผู้ดูแลระบบที่มีอยู่ก่อนแล้วภายในสภาพแวดล้อมของลูกค้า ดังนั้น จึงไม่มีการเปลี่ยนแปลงผลิตภัณฑ์ใด ๆ เพื่อจัดการกับรายงานฉบับนี้ และไม่มีการออกรหัส CVE หรือ CVSS แต่อย่างใด"
อย่างไรก็ตาม หลังจากการเปิดเผยรายงานของเขาในเดือนนี้ O'Leary กลับสังเกตเห็นว่า เส้นทางการโจมตีแบบเดิมนั้นไม่สามารถใช้งานได้อีกต่อไปแล้ว
O'Leary ระบุว่า "พฤติกรรมปัจจุบันของระบบมีการแสดงข้อผิดพลาด ซึ่งไม่เคยปรากฏมาก่อนในช่วงเดือนมีนาคม 2026"
ERROR: UserErrorTrustedAccessGatewayReturnedForbidden "The Trusted Access role binding is missing/has gotten removed"
ข้อมูลจาก O'Leary ระบุว่า ปัจจุบัน Azure Backup for AKS บังคับให้ผู้ใช้ต้องกำหนดค่า Trusted Access ด้วยตัวเองก่อน จึงจะสามารถเปิดใช้งานการสำรองข้อมูลได้ ซึ่งเป็นการกลับลำจากพฤติกรรมก่อนหน้านี้ที่ Azure จะกำหนดค่าส่วนนี้ให้โดยอัตโนมัติ
เขายังสังเกตว่ามี permission checks เพิ่มเติม ซึ่งไม่มีอยู่ในการทดสอบครั้งแรกของเขาเมื่อเดือนมีนาคม โดยปัจจุบัน Vault MSI จำเป็นต้องมีสิทธิ์ระดับ Reader ทั้งบน AKS cluster และบน Snapshot resource group ในขณะที่ AKS cluster MSI จำเป็นต้องมีสิทธิ์ระดับ Contributor บน Snapshot resource group
กล่าวอีกนัยหนึ่งคือ ช่องโหว่นี้ดูเหมือนจะได้รับการแก้ไขไปเรียบร้อยแล้ว แต่ทาง Microsoft กลับไม่เคยออกประกาศแจ้งเตือนต่อสาธารณะ และไม่ได้แจ้งให้ลูกค้าทราบ
ปัญหาด้าน visibility สำหรับทีม Security
หากไม่มี CVE หรือคำแนะนำ ทีม Security จะสามารถตรวจสอบช่วงเวลาที่ช่องโหว่เปิดอยู่ หรือไทม์ไลน์ในการแก้ไขได้น้อยมาก
นักวิจัยระบุว่า "องค์กรที่อนุญาตให้ Backup Contributor ให้กับผู้ใช้งาน ในช่วงเวลาใดเวลาหนึ่งที่ระบุไม่ได้ และเดือนพฤษภาคม 2026 มีความเสี่ยงต่อการยกระดับสิทธิ์"
"หากไม่มี CVE ทีมรักษาความปลอดภัยไม่สามารถติดตามช่องโหว่นี้ได้ การแก้ไขแบบเงียบ ๆ ปกป้องผู้ให้บริการ ไม่ใช่ลูกค้า"
กรณีนี้เน้นให้เห็นถึงปัญหาเชิงโครงสร้างที่แก้ไขได้ยาก
ข้อพิพาทระหว่างนักวิจัยด้านความปลอดภัย และผู้จำหน่ายรายใหญ่เกี่ยวกับ severity, ความสามารถในการโจมตี และการเปิดเผยข้อมูลกลายเป็นเรื่องที่พบเห็นได้ทั่วไป โดยเฉพาะอย่างยิ่งเมื่อโปรแกรมการรับแจ้งเตือนช่องโหว่เผชิญกับรายงานที่หลั่งไหลเข้ามามหาศาล
ผู้ดูแล open-source บางรายยังได้ออกมาบ่นผ่านสื่อสาธารณะด้วยว่า รายงานที่ใช้ AI ช่วยนั้นกำลังทำให้ระบบการให้รางวัลสำหรับการค้นหาช่องโหว่ และการคัดกรองความปลอดภัยทำงานหนักเกินไป ทำให้การค้นพบที่ถูกต้องได้รับความสนใจอย่างทันท่วงทีได้ยากขึ้น กรณีที่บริษัทเทคโนโลยีขนาดใหญ่เพิกเฉยต่อการแก้ไขช่องโหว่ที่ถูกต้อง แม้ว่าจะมีการติดต่อจากนักวิจัยหลายคนซ้ำแล้วซ้ำเล่า ก็ไม่ใช่เรื่องแปลก
หากไม่มีกรอบการทำงานที่ช่วยปรับสมดุลผลประโยชน์ และแรงจูงใจให้กับทุกฝ่าย กระบวนการเปิดเผยช่องโหว่อย่างมีความรับผิดชอบ อาจกลายเป็นกระบวนการที่ไม่เป็นประโยชน์ต่อใครเลย
ที่มา : Bleepingcomputer
You must be logged in to post a comment.