ทีมวิจัย Wiz Research เปิดเผยรายละเอียดช่องโหว่ร้ายแรงชื่อ CosmosEscape ใน Azure Cosmos DB ฐานข้อมูลหลักของ Microsoft Azure ซึ่งเกิดขึ้นผ่านช่องโหว่ใน Gremlin API โดยหากถูกใช้โจมตีจริง จะเปิดทางให้ผู้โจมตีเข้าถึงข้อมูลของลูกค้า Azure Cosmos DB ได้ทุกราย ข้าม Tenant ทั้งหมดในระบบ
ต้นตอของช่องโหว่
ช่องโหว่นี้เกิดจากจุดอ่อนใน Gremlin Query Engine ของ Azure Cosmos DB ซึ่งเป็น Engine ที่แปลง Query ภาษา Gremlin ให้เป็นโค้ด .NET เพื่อประมวลผล โดยระบบมีการตั้งข้อจำกัดไว้เพื่อป้องกันไม่ให้ Query สามารถทำงานเกินขอบเขตของคำสั่ง Gremlin ปกติได้
อย่างไรก็ตาม ข้อจำกัดดังกล่าว ไม่ได้ครอบคลุมถึงการใช้งาน .NET Reflection ซึ่งเป็นกลไกที่อนุญาตให้โค้ดตรวจสอบและเรียกใช้งาน Type หรือ Method ต่างๆ ในระบบได้แบบไดนามิก ทีมวิจัย Wiz ใช้ช่องว่างนี้พัฒนาความสามารถในการ อ่านไฟล์ (File Read), เขียนไฟล์ (File Write) และท้ายที่สุดคือ การรันโค้ดจากระยะไกล (Remote Code Execution) ได้สำเร็จ
ผลกระทบระดับแพลตฟอร์ม
หลังจากเจาะเข้าสู่ระบบได้ ทีมวิจัยพบ Credential ที่นำไปสู่สิ่งที่เรียกว่า "Cosmos Master Key" ซึ่งเป็นกุญแจลงนามระดับแพลตฟอร์ม (Platform-wide Signing Key) ที่แตกต่างจาก Key ทั่วไปที่จำกัดสิทธิ์เฉพาะบัญชีลูกค้ารายเดียว
Master Key นี้สามารถเข้าถึง Primary Key ของบัญชี Azure Cosmos DB ได้ทุกบัญชี โดยไม่จำกัดว่าจะอยู่ Tenant ใด ภูมิภาคใด หรือใช้ API Type ใดก็ตาม พูดง่ายๆ คือหากผู้โจมตีครอบครอง Key นี้ได้จริง จะสามารถเข้าถึงฐานข้อมูลของลูกค้า Azure Cosmos DB ได้แทบทั้งหมดบนแพลตฟอร์ม
Timeline การรายงานและแก้ไข
- 20 พฤศจิกายน 2025: Wiz Research รายงานช่องโหว่ให้ Microsoft ทราบ
- 22 พฤศจิกายน 2025 (ภายใน 48 ชั่วโมง): Microsoft ออก Hotfix ปิดกั้นช่องทางการโจมตีผ่าน Gremlin API ที่มีช่องโหว่
- Microsoft ยืนยันว่า ไม่พบหลักฐานว่ามีลูกค้ารายใดได้รับผลกระทบจริง ไม่มีการเข้าถึงข้อมูลลูกค้าโดยไม่ได้รับอนุญาต และไม่มีกิจกรรมผิดปกตินอกเหนือจากการทดสอบของทีมวิจัย Wiz
ผลกระทบที่อาจเกิดขึ้น (หากถูกโจมตีจริงก่อนแก้ไข)
- ผู้โจมตีที่ครอบครอง Master Key จะสามารถเข้าถึงฐานข้อมูล Azure Cosmos DB ของลูกค้ารายใดก็ได้แบบข้าม Tenant ไม่จำกัดเฉพาะบัญชีที่ถูกโจมตีโดยตรง
- แม้แต่ฐานข้อมูลที่ตั้งค่า Network Isolation ไว้ก็ได้รับผลกระทบ เนื่องจากช่องโหว่อยู่ในระดับ Platform ไม่ใช่ระดับ Network ของลูกค้าแต่ละราย
- มีความเสี่ยงต่อโครงสร้างพื้นฐานภายในของ Microsoft เองด้วย เนื่องจากบริการภายในหลายส่วนของ Microsoft ก็ใช้ Azure Cosmos DB เช่นกัน
- หากถูกใช้โจมตีจริง จะกระทบลูกค้า Azure Cosmos DB ในวงกว้างระดับ Global เนื่องจากเป็นบริการฐานข้อมูลหลักที่มีผู้ใช้งานจำนวนมาก
สิ่งที่องค์กรควรทำ
- ช่องโหว่นี้ได้รับการแก้ไขโดย Microsoft เรียบร้อยแล้วในระดับแพลตฟอร์ม ผู้ใช้งาน Azure Cosmos DB ไม่จำเป็นต้องดำเนินการอัปเดตหรือ Patch ใดๆ เพิ่มเติมด้วยตนเอง
- องค์กรที่ใช้ Azure Cosmos DB ควรตรวจสอบ Access Log ย้อนหลังในกรอบเวลาก่อนวันที่ 22 พฤศจิกายน 2025 เพื่อความมั่นใจ แม้ Microsoft จะยืนยันว่าไม่พบการใช้งานผิดปกติก็ตาม
- ทบทวนแนวทาง Credential Rotation สำหรับบริการ Cloud Database ที่ใช้งานอยู่เป็นประจำ เพื่อลดผลกระทบหากมีช่องโหว่ลักษณะเดียวกันเกิดขึ้นอีกในอนาคต
- ติดตามประกาศ Security Advisory จาก Microsoft Azure อย่างสม่ำเสมอ โดยเฉพาะสำหรับบริการที่องค์กรใช้งานเป็นโครงสร้างพื้นฐานหลัก
แนวทางลดความเสี่ยงระยะยาว
1. ใช้หลัก Least Privilege Access สำหรับ Key และ Credential ของบริการ Cloud Database ทุกประเภท
จำกัดสิทธิ์การเข้าถึง Key ให้เหลือเท่าที่จำเป็น และหลีกเลี่ยงการใช้ Key ระดับสูงในงานที่ไม่จำเป็นต้องใช้สิทธิ์นั้น
2. เปิดใช้งาน Monitoring และ Alert สำหรับกิจกรรมผิดปกติบนบริการ Cloud Database
เพื่อให้สามารถตรวจจับความพยายามเข้าถึงข้อมูลที่ผิดปกติได้ตั้งแต่เนิ่นๆ แม้ผู้ให้บริการ Cloud จะมีมาตรการป้องกันระดับแพลตฟอร์มอยู่แล้วก็ตาม
3. พิจารณาใช้ Multi-layered Security แทนการพึ่งพา Provider เพียงชั้นเดียว
เช่น การเข้ารหัสข้อมูลระดับ Application ก่อนบันทึกลง Cloud Database เพื่อลดผลกระทบหากเกิดช่องโหว่ระดับ Platform ในอนาคต
4. ติดตามงานวิจัยด้าน Cloud Security จากบริษัทวิจัยชั้นนำอย่าง Wiz อย่างต่อเนื่อง
เนื่องจากช่องโหว่ระดับ Cross-Tenant ในบริการ Cloud รายใหญ่มีแนวโน้มถูกค้นพบเพิ่มขึ้นเรื่อยๆ ตามความซับซ้อนของสถาปัตยกรรม Multi-tenant
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่ CosmosEscape เป็นตัวอย่างที่ชัดเจนของความเสี่ยงในสถาปัตยกรรม Multi-tenant Cloud ที่แม้ผู้ให้บริการจะออกแบบระบบแยกสิทธิ์ระหว่างลูกค้าแต่ละรายไว้อย่างรัดกุม แต่หากมีช่องโหว่เพียงจุดเดียวในกลไกระดับ Platform เช่น Master Key ก็อาจส่งผลกระทบข้าม Tenant ในวงกว้างได้ทันที สิ่งที่น่าชื่นชมในกรณีนี้คือกระบวนการตอบสนองของ Microsoft ที่ออก Hotfix ได้ภายใน 48 ชั่วโมงหลังได้รับรายงาน ซึ่งสะท้อนความพร้อมด้าน Incident Response ของผู้ให้บริการ Cloud รายใหญ่
อย่างไรก็ตาม TXEC มองว่าองค์กรไม่ควรมองข้ามความเสี่ยงประเภทนี้เพียงเพราะเป็นความรับผิดชอบของผู้ให้บริการ Cloud การพึ่งพา Provider เพียงชั้นเดียวโดยไม่มีมาตรการป้องกันเพิ่มเติม เช่น การเข้ารหัสข้อมูลระดับ Application หรือการ Monitor กิจกรรมผิดปกติ อาจทำให้องค์กรตกอยู่ในความเสี่ยงหากเกิดช่องโหว่ลักษณะเดียวกันขึ้นอีกครั้งในอนาคต โดยเฉพาะองค์กรที่เก็บข้อมูลสำคัญไว้บนบริการ Cloud Database เป็นหลัก
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Wiz Research, The Hacker News, CyberSecurityNews, GBHackers, TechTimes ]