ช่องโหว่การตรวจสอบ Certificate ระดับ Critical ใน LXD และ Incus อาจเปิดทางให้แฮ็กเกอร์เข้าควบคุมโฮสต์ Linux

ช่องโหว่การตรวจสอบ Certificate ระดับ Critical ใน LXD และ Incus อาจทำให้ผู้โจมตีจากภายนอกสามารถ Bypass การตรวจสอบการเข้าสู่ระบบ และเข้าควบคุม Cluster รวมถึง Virtual Machine ที่อยู่ภายใต้การจัดการได้

ช่องโหว่นี้ส่งผลกระทบต่อ HTTPS Management Listener ทำให้ระบบ Linux ที่เปิดให้เข้าถึงจากภายนอกมีความเสี่ยง โดยผู้โจมตีไม่จำเป็นต้องใช้รหัสผ่าน Private Key ที่ขโมยมา หรืออาศัยการดำเนินการใด ๆ จากผู้ใช้ โดย Incus จัดระดับความรุนแรงของช่องโหว่นี้เป็น Critical โดยมีคะแนน CVSS 10.0

ประกาศด้านความปลอดภัยของ Incus ที่เผยแพร่เมื่อวันที่ 29 ตุลาคม ระบุว่า ช่องโหว่นี้มีอยู่ตั้งแต่โครงการเปิดตัวครั้งแรก ขณะที่ Canonical เผยแพร่ข้อมูลช่องโหว่ที่เกี่ยวข้องใน LXD ภายใต้หมายเลข CVE-2026-112816 เมื่อวันที่ 30 ตุลาคม แม้ Ubuntu จะจัดลำดับความสำคัญของช่องโหว่นี้ไว้ที่ระดับ Medium แต่รายละเอียดระบุว่า ผู้โจมตีสามารถเข้าถึง Cluster และ Virtual Machine ได้อย่างสมบูรณ์โดยไม่ต้องผ่าน Authentication

ช่องโหว่การตรวจสอบ Certificate ใน LXD และ Incus

ช่องโหว่นี้เกิดจากวิธีที่ Service ตรวจสอบ Certificate ที่ Client ส่งมาระหว่างการเชื่อมต่อ HTTPS โดยกระบวนการ TLS Handshake จะพิสูจน์ว่า Client ครอบครอง Private Key ของ Certificate แรกที่ส่งมา แต่ Certificate อื่น ๆ ที่อยู่ใน Chain เดียวกันสามารถถูกควบคุมโดย Client และไม่ได้ผ่านการตรวจสอบ

จากนั้นกระบวนการ Authentication จะนำ Certificate ทุกใบใน Chain ที่ส่งมาไปเปรียบเทียบกับ Trust Store ของเซิร์ฟเวอร์ ทำให้เกิดช่องว่างระหว่างการพิสูจน์ความเป็นเจ้าของ Certificate กับการยอมรับตัวตนที่ Certificate นั้นอ้างถึง ผู้โจมตีจึงสามารถนำส่วน Public ของ Certificate ที่ได้รับความเชื่อถือมาต่อท้าย Certificate Chain ของตนเอง และทำให้ระบบยอมรับว่าผู้โจมตีเป็นเจ้าของ Certificate ดังกล่าวได้ แม้จะไม่มี Private Key ที่ตรงกันก็ตาม

Public Certificate ไม่ใช่ข้อมูลลับ เนื่องจากเซิร์ฟเวอร์จะส่ง Certificate ของตนกลับมาในระหว่างกระบวนการ TLS Handshake ทำให้ผู้โจมตีสามารถรับ Certificate ได้โดยไม่จำเป็นต้องมีบัญชีผู้ใช้อยู่ก่อน ตามประกาศด้านความปลอดภัย การส่ง Certificate ของเซิร์ฟเวอร์เองจะทำให้เข้าถึง Database Gateway ได้ ส่วนการนำเสนอ Certificate ของสมาชิก Cluster รายอื่นจะทำให้เข้าถึงระบบภายใน Cluster และ Bypass การ Authentication ได้ทั้งหมด

ช่องโหว่นี้แตกต่างจากช่องโหว่ Container Escape ที่ Cyber Security News เคยรายงานไว้ในข่าวช่องโหว่ของ runc เนื่องจากไม่ได้อาศัยการ escape ออกจาก Workload ที่ถูกแยกสภาพแวดล้อม แต่เป็นการโจมตี Management Layer ที่ได้รับความเชื่อถือ ซึ่งมีหน้าที่ควบคุมการเข้าถึงสภาพแวดล้อมดังกล่าว

ประกาศของ Incus ระบุว่า ผู้โจมตีสามารถปลอมตัวโดยใช้ Certificate ของ Client, Metrics หรือ Server ที่ได้รับความเชื่อถือได้ หากมี Public Certificate ที่เกี่ยวข้อง ช่องโหว่เดียวกันนี้ยังเปิดทางให้ต่ออายุ หรือลบรายการใน Trust Store ผ่านช่องทาง Self-service ได้ รวมถึงส่งผลกระทบต่อกระบวนการ Authentication สำหรับการเชื่อมต่อ Agent ระหว่างโฮสต์กับ Virtual Machine

อีกส่วนที่ได้รับผลกระทบคือ Authorization Scriptlet ซึ่งเป็น Script ที่ใช้ตัดสินใจเกี่ยวกับสิทธิ์การเข้าถึง โดย Incus ส่ง Certificate Chain ที่ยังไม่ได้ผ่านการตรวจสอบไปยัง Script นี้ ทำให้ Certificate ที่ผู้โจมตีเลือกสามารถมีอิทธิพลต่อการตัดสินใจด้านสิทธิ์การเข้าถึงได้ ปัญหานี้ยังส่งผลกระทบต่อการเชื่อมต่อที่ใช้ Token หรือ OpenID Connect เนื่องจาก Client เหล่านี้ยังสามารถส่ง Certificate ระหว่างกระบวนการ Handshake ได้เช่นกัน

เวอร์ชันที่แก้ไขช่องโหว่แล้ว และแนวทางป้องกันเร่งด่วน

Incus ระบุว่าเวอร์ชันก่อน 7.6.0 ได้รับผลกระทบจากช่องโหว่นี้ ขณะที่เวอร์ชัน 7.6.0 เป็นต้นไปได้รับการแก้ไขแล้ว ส่วนประกาศของ Canonical สำหรับ LXD ระบุว่า มีการแก้ไขช่องโหว่ในเวอร์ชัน 4.0.15, 5.0.11, 5.21.9 และ 6.10.1 สำหรับสายเวอร์ชันที่ได้รับผลกระทบ ผู้ดูแลระบบควรตรวจสอบเวอร์ชันที่ติดตั้งอยู่ และเปรียบเทียบกับประกาศด้านความปลอดภัยจากผู้พัฒนาที่เกี่ยวข้อง

ระหว่างที่ยังไม่ได้ติดตั้งอัปเดต Incus แนะนำให้จำกัดการเข้าถึง HTTPS Listener เฉพาะโฮสต์ที่เชื่อถือได้ เนื่องจากไม่มีวิธีแก้ไขชั่วคราวด้วยการปรับ Configuration ที่สามารถแก้ปัญหาการตรวจสอบ Certificate ซึ่งเป็นต้นเหตุของช่องโหว่ได้ การจำกัดการเข้าถึงผ่านเครือข่ายช่วยลดความเสี่ยงจากการถูกโจมตี แต่ไม่สามารถใช้ทดแทนการติดตั้ง Patch ได้

คู่มือความปลอดภัยของ Linux Container จาก Cyber Security News ให้ข้อมูลเพิ่มเติมเกี่ยวกับการปกป้อง Container โดยทั่วไป แต่สำหรับช่องโหว่นี้ สิ่งที่ต้องให้ความสำคัญโดยตรงคือการอัปเดต Service ที่ได้รับผลกระทบ และจำกัดผู้ที่สามารถเข้าถึง Management Interface ได้ ทั้งนี้ ประกาศด้านความปลอดภัยทั้งสองฉบับที่อ้างถึงยังไม่มีรายงานว่าพบการ Exploit ช่องโหว่นี้ในการโจมตีจริง จึงไม่ควรตีความว่าระบบที่มีความเสี่ยงเป็นระบบที่ได้รับการยืนยันว่าถูกเจาะระบบแล้ว

ที่มา : cybersecuritynews.com