ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ช่องโหว่ด้านความมั่นคงปลอดภัยใน Xen Orchestra ซึ่งเป็นแพลตฟอร์มสำหรับบริหารจัดการระบบ Virtualization และ XCP-ng พบรายงานช่องโหว่ประเภท Authentication Bypass ระดับ Critical ที่ถูกนำไปใช้โจมตีจริงแล้ว โดยผู้โจมตีที่สามารถเข้าถึง Management Interface ของ Xen Orchestra อาจหลีกเลี่ยงกระบวนการยืนยันตัวตนและได้รับสิทธิ์ระดับผู้ดูแลระบบ (Admin) ซึ่งอาจนำไปสู่การสั่งรันคำสั่งบนระบบที่บริหารจัดการและเข้าควบคุม XCP-ng Host ด้วยสิทธิ์ root ได้ [1]
1. รายละเอียดช่องโหว่
ช่องโหว่ดังกล่าวถูกติดตามภายใต้หมายเลข VSA-2026-062: Empty-object login token [2] และยังไม่มีการกำหนดหมายเลข CVE และคะแนน CVSS โดยช่องโหว่เกิดจากข้อบกพร่องในการประมวลผล Authentication Token ผ่าน REST API ของ Xen Orchestra ซึ่งระบบสามารถตีความค่า Authentication Cookie ที่ถูกสร้างขึ้นเป็นพิเศษเป็น Empty JSON Object ({}) และส่งต่อไปยัง Token Provider ที่ไม่มีการตรวจสอบประเภทข้อมูลให้เป็น String อย่างถูกต้อง ส่งผลให้ Token Collection ประมวลผล Empty Object เป็นการค้นหา Token โดยไม่มีเงื่อนไข และเลือก Token รายการแรกที่ยังไม่หมดอายุ ทำให้ผู้โจมตีสามารถผ่านกระบวนการยืนยันตัวตนในฐานะเจ้าของ Token ดังกล่าวได้โดยไม่จำเป็นต้องทราบชื่อผู้ใช้งานหรือรหัสผ่าน จากนั้นอาจเข้าถึง REST API เพื่อดึง Reusable Authentication Token สำหรับใช้เข้าถึงระบบเพิ่มเติม
2. รูปแบบการโจมตี
จากรายงานของ Vates พบว่าช่องโหว่ดังกล่าวถูกนำไปใช้โจมตีจริงแล้ว (Actively Exploited) โดยผู้โจมตีที่สามารถเชื่อมต่อมายัง Management Interface ของ Xen Orchestra จะส่ง HTTP Request ที่มี Authentication Cookie ซึ่งถูกสร้างขึ้นเป็นพิเศษ เพื่อทำให้ระบบตีความ Token เป็น Empty Object และหลีกเลี่ยงกระบวนการยืนยันตัวตน เมื่อโจมตีสำเร็จ ผู้โจมตีอาจดำเนินการดังนี้
2.1 เข้าถึง Xen Orchestra โดยอาศัยสิทธิ์ของ Authentication Token ที่ระบบเลือกจาก Token Collection
2.2 เข้าถึง REST API เพื่อดึง Reusable Authentication Token สำหรับใช้เข้าถึงระบบอย่างต่อเนื่อง
2.3 ใช้สิทธิ์ระดับ Admin ที่ได้รับเพื่อควบคุม Xen Orchestra และระบบ Virtualization ที่เชื่อมต่ออยู่
2.4 แก้ไขหรือสร้าง Virtual Machine รวมถึงอาจสั่งรันคำสั่งบน Managed Pool และเข้าควบคุม XCP-ng Host ด้วยสิทธิ์ root
นอกจากนี้ Vates ยังเปิดเผยตัวบ่งชี้การบุกรุก (Indicators of Compromise: IoCs) ที่เกี่ยวข้องกับการโจมตี ได้แก่ HTTP Request ที่มีรูปแบบ authenticationToken=j:%7B%7D หรือ authenticationToken=j:{} การพบ Virtual Machine ชื่อ pivot2 การตั้งค่า VM ที่มีพารามิเตอร์ hvm_serial: file ตลอดจนไฟล์ต้องสงสัย เช่น /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 และ /.ustar6 รวมถึง IP Address 91.211.251[.]112:8001 ซึ่งมีข้อมูลบน VirusTotal ระบุว่าเกี่ยวข้องกับเซิร์ฟเวอร์ควบคุมและสั่งการ (Command and Control: C2) ของมัลแวร์ RedLine Stealer [3] และ TOR Domain ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid[.]onion:3333 ที่พบว่าเกี่ยวข้องกับผู้โจมตี อย่างไรก็ตาม IoCs ดังกล่าวเป็นข้อมูลจากแคมเปญการโจมตีที่ตรวจพบเท่านั้น ผู้โจมตีรายอื่นอาจใช้เทคนิคหรือโครงสร้างพื้นฐานที่แตกต่างกัน ดังนั้น การไม่พบ IoCs ข้างต้นจึงไม่สามารถยืนยันได้ว่าระบบไม่ถูกบุกรุก
3. ผลิตภัณฑ์ที่ได้รับผลกระทบและแนวทางการแก้ไข
ผลิตภัณฑ์ที่ได้รับผลกระทบ ได้แก่ Xen Orchestra เวอร์ชันก่อน 6.9.2 ใน Stable Channel และเวอร์ชันก่อน 6.10.1 ใน Latest Channel รวมถึง Xen Orchestra Appliance (XOA) ที่ยังไม่ได้รับการอัปเดตแก้ไขช่องโหว่ดังกล่าว โดยผู้พัฒนา Vates ได้เผยแพร่การอัปเดตความมั่นคงปลอดภัยแล้ว ผู้ดูแลระบบควรเร่งอัปเดต Xen Orchestra เป็นเวอร์ชัน 6.9.2 หรือใหม่กว่า สำหรับ Stable Channel และเวอร์ชัน 6.10.1 หรือใหม่กว่า สำหรับ Latest Channel รวมถึงอัปเดตองค์ประกอบ xo-server เป็นเวอร์ชัน 5.211.2 และ 5.213.1 ตามลำดับ สำหรับระบบที่ติดตั้งจาก Source Code ควรอัปเดตเป็นเวอร์ชันล่าสุดจากสาขา master ตามคำแนะนำของผู้พัฒนา
4. แนวทางลดความเสี่ยงหากยังไม่สามารถดำเนินการอัปเดตได้ทันที
4.1 ไม่เปิด Management Interface ของ Xen Orchestra ให้สามารถเข้าถึงได้โดยตรงจากอินเทอร์เน็ต และควรแยกไว้บน Dedicated Management Network
4.2 จำกัดการเข้าถึง Management Interface ผ่าน Firewall, VPN หรือระบบ Access Control เฉพาะผู้ดูแลระบบและแหล่งที่ได้รับอนุญาต
4.3 กำหนด WAF หรือ Reverse Proxy ให้ตรวจจับและบล็อก Authentication Token ที่มีลักษณะ Empty Object เช่น authenticationToken=j:{} และ authenticationToken=j:%7B%7D ทั้งนี้ Vates เตือนว่าการใช้ Regular Expression เพียงอย่างเดียวอาจถูกหลีกเลี่ยงได้ด้วยรูปแบบการเข้ารหัสอื่น
4.4 บล็อกการติดต่อกับโครงสร้างพื้นฐานของผู้โจมตีและพิจารณาจำกัด Tor Traffic ตามนโยบายของหน่วยงาน
5. คำแนะนำด้านความปลอดภัยเพิ่มเติม
5.1 ตรวจสอบประวัติ HTTP Traffic และ Network Traffic ที่เข้าสู่ Xen Orchestra เพื่อค้นหารูปแบบ Authentication Cookie ที่ผิดปกติ โดยเฉพาะ authenticationToken=j:{} และ authenticationToken=j:%7B%7D เนื่องจาก Vates ระบุว่าการโจมตีที่สำเร็จอาจไม่ปรากฏหลักฐานการเข้าถึงแบบไม่ผ่านการยืนยันตัวตนใน Log ของ Xen Orchestra โดยตรง
5.2 ตรวจสอบ Virtual Machine ที่ไม่รู้จัก โดยเฉพาะ VM ชื่อ pivot2 และตรวจสอบ VM Configuration ที่มีค่า hvm_serial: file รวมถึงตรวจสอบไฟล์ต้องสงสัย /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5, /.ustar6 และ /etc/ld.so.preload บน XCP-ng Host
5.3 ตรวจสอบการสร้างหรือเปลี่ยนแปลงบัญชีผู้ดูแลระบบ, Authentication Token, VM, Scheduled Task, Cron Job ตลอดจนการเปลี่ยนแปลงค่าคอนฟิกที่ไม่สามารถระบุผู้ดำเนินการได้
5.4 หากพบหลักฐานหรือสงสัยว่าระบบถูกบุกรุก ให้แยกระบบที่ได้รับผลกระทบออกจากเครือข่ายและดำเนินกระบวนการ Incident Response โดยเร็ว พร้อมเปลี่ยน Password, Authentication Token และ Secret ทั้งหมด ที่ Xen Orchestra สามารถเข้าถึงได้ เช่น Root Credential, Pool Secret, User Account, OTP Secret, Proxy Credential, Backup Repository และข้อมูลรับรองสำหรับ NFS, SMB, S3 หรือ Azure เป็นต้น
5.5 กรณียืนยันได้ว่า Xen Orchestra ถูกบุกรุก Vates แนะนำให้ดำเนินการติดตั้งระบบใหม่ทั้งหมด (Full Reinstallation) เนื่องจากการลบไฟล์หรือ Backdoor ที่ตรวจพบเพียงอย่างเดียวไม่สามารถรับประกันได้ว่าผู้โจมตีไม่ได้สร้างช่องทาง Persistence อื่นไว้ในระบบ
5.6 ควรจำกัด Xen Orchestra ให้เป็นระบบบริหารจัดการภายใน แยก Management Network ออกจาก User Network และ Production Network รวมถึงใช้ Firewall/VPN และหลักการ Least Privilege เพื่อลด Attack Surface ของระบบ Virtualization
แหล่งอ้างอิง
[1] https://dg.th/qohtd9n5bz
[2] https://dg.th/3x8loj71k0
[3] https://dg.th/1djnq9wicu