สรุปสั้น

Incus คือ ระบบจัดการคอนเทนเนอร์และเครื่องเสมือน (VM) แบบโอเพนซอร์สที่แยกสายมาจาก LXD ของบริษัท Canonical ทั้งคู่นิยมใช้สร้างคลาวด์ส่วนตัวและคลัสเตอร์บน Linux ล่าสุดผู้ดูแลโครงการ Incus และ Canonical เปิดเผยช่องโหว่ตรวจสอบใบรับรองระดับ CVSS 10.0 ที่ให้ผู้โจมตีซึ่งเข้าถึงพอร์ต HTTPS สำหรับจัดการระบบได้ ปลอมตัวเป็นเครื่องหรือผู้ใช้ที่ระบบเชื่อถือ โดยไม่ต้องมีรหัสผ่านหรือกุญแจส่วนตัว (private key) ต้นเหตุ คือ ระบบเอาใบรับรองทุกใบที่ไคลเอนต์ส่งมาไปเทียบกับรายชื่อที่เชื่อถือ แต่พิสูจน์การถือกุญแจแค่ใบแรก

ผลที่ตามมา คือ ผู้โจมตีปลอมเป็นสมาชิกในคลัสเตอร์ได้ เพราะใบรับรองของเซิร์ฟเวอร์เปิดเผยให้ทุกคนเห็นระหว่างเชื่อมต่อ TLS และเมื่อเข้าได้ก็คุมคอนเทนเนอร์และ VM ที่คลัสเตอร์ดูแลทั้งหมด ช่องโหว่นี้มีมาตั้งแต่ Incus รุ่นแรกและไม่มีการตั้งค่าใดแก้ได้ ผู้ดูแลระบบจึงควรอัปเดต Incus เป็น 7.6.0 และ LXD เป็นรุ่นที่แก้แล้วโดยเร็ว ระหว่างนั้นให้จำกัดพอร์ตจัดการให้เข้าได้เฉพาะเครื่องที่เชื่อถือ

รายละเอียดข่าว

เว็บไซต์ GBHackers รายงานเมื่อวันที่ 2 พฤศจิกายน 2569 ว่าพบช่องโหว่ตรวจสอบใบรับรองระดับวิกฤตใน Incus และ LXD ฝั่ง Incus ติดตามด้วยรหัส GHSA-xg75-xf37-cph9 บน GitHub ได้คะแนน CVSS สูงสุด 10.0 กระทบทุกรุ่นก่อน 7.6.0 และผู้ดูแลโครงการระบุว่าพฤติกรรมนี้มีมาตั้งแต่รุ่นแรก ประกาศของ Incus ยังไม่มีเลข CVE และจัดประเภทเป็นการยืนยันตัวตนไม่ถูกต้อง (improper authentication) และการตรวจใบรับรองไม่ถูกต้อง (improper certificate validation)

ด้าน Canonical ติดตามช่องโหว่ฝั่ง LXD ด้วยรหัส CVE-2026-112816 ซึ่งเผยแพร่เมื่อวันที่ 30 ตุลาคม 2569 ประกาศระบุรุ่นที่ได้รับผลกระทบ คือ 4.0.14, 5.0.10, 5.21.8 และ 6.9 และรุ่นที่แก้แล้ว คือ 4.0.15, 5.0.11, 5.21.9 และ 6.10.1 ตามลำดับ โดยอธิบายว่าผู้โจมตีที่ไม่ต้องยืนยันตัวตนเข้าถึงคลัสเตอร์และ VM ที่ระบบดูแลได้ผ่านชุดใบรับรองที่สร้างขึ้นเฉพาะ ข้อจำกัดของข้อมูล คือ ทั้งสองประกาศไม่ได้ระบุว่ามีการโจมตีจริงแล้วหรือไม่ และรายงานไม่ได้ให้คะแนน CVSS ของฝั่ง LXD

อัปเดต 2 พ.ย. 2569: MicroCloud ได้รับผลกระทบด้วย และรุ่นที่แก้แล้ว

อัปเดต 2 พ.ย. 2569: เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 1 พฤศจิกายน 2569 ว่าประกาศของ Canonical ระบุว่า MicroCloud ซึ่งใช้รวมเครื่องที่รัน LXD หลายเครื่องเป็นคลัสเตอร์เดียว ได้รับผลกระทบจาก CVE-2026-112816 ด้วย และมีจุดอ่อนเฉพาะ คือ ผู้โจมตีที่ดักเก็บใบรับรองสาธารณะของเครื่องสมาชิกได้ระหว่างที่เครื่องนั้นเข้าร่วมคลัสเตอร์ จะล็อกอินเป็นเครื่องนั้นได้ Canonical ระบุว่าถ้าบัญชีที่ถูกปลอมมีสิทธิ์สูง ผู้โจมตีอาจได้ “สิทธิ์ root บนเครื่อง host” ส่วน LXD แบบเครื่องเดียวไม่เปิด API ทางเครือข่ายเป็นค่าเริ่มต้น จะเสี่ยงเมื่อผู้ดูแลเปิดผ่านค่า core.https_address เท่านั้น

รุ่น snap ที่แก้แล้วตามประกาศของ Canonical ได้แก่ LXD 6.10.1 (6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable), 4.0.15 (4.0/stable) และ MicroCloud 3.4.1 (3/stable), 2.1.5 (2/stable) ส่วนแพ็กเกจ LXD ในคลังของ Ubuntu เองระบุว่าไม่ได้รับผลกระทบหรือไม่ได้จัดส่ง ช่วงที่ออกประกาศ รุ่นแก้ของ LXD ยังทยอยเลื่อนจาก candidate channel ไป stable ผู้ดูแลจึงควรตรวจรุ่นที่ติดตั้งจริงหลังสั่ง sudo snap refresh lxd และ sudo snap refresh microcloud แทนการเชื่อว่าแพตช์มาถึงแล้ว ด้านสถานะการโจมตี ระเบียน CVE มีผลประเมินของ CISA ลงวันที่ 30 ตุลาคมว่ายังไม่พบการโจมตีจริง ช่องโหว่นี้ไม่อยู่ในรายการ KEV และยังไม่มี exploit ที่ใช้งานได้เผยแพร่ ส่วน Incus 7.6.0 แก้ช่องโหว่ความปลอดภัยอีก 17 รายการไปพร้อมกัน

รายละเอียดช่องโหว่

ต้นเหตุ: พิสูจน์กุญแจแค่ใบแรก แต่เทียบรายชื่อทุกใบ — ระหว่างเชื่อมต่อ TLS ตัวรับ HTTPS ของ Incus และ LXD ขอใบรับรองจากไคลเอนต์ แต่ไม่ตรวจความถูกต้องของชุดใบรับรอง (certificate chain) ที่ส่งมา ขั้นตอน TLS พิสูจน์เพียงว่าไคลเอนต์ถือกุญแจส่วนตัวของใบรับรองใบแรก ส่วนใบที่ตามมาไคลเอนต์ใส่อะไรก็ได้ แต่ขั้นตรวจสิทธิ์กลับเอาทุกใบในชุดไปเทียบกับรายชื่อที่เชื่อถือ (trust store) ผู้โจมตีจึงสร้างใบรับรองของตัวเอง แล้วแนบใบรับรองสาธารณะของเครื่องที่ระบบเชื่อถือต่อท้าย ระบบก็ยอมรับว่าเป็นเครื่องนั้นโดยที่ผู้โจมตีไม่ต้องมีกุญแจของเครื่องนั้นเลย

ใบรับรองของเซิร์ฟเวอร์หาได้ระหว่างเชื่อมต่อ — ใบรับรองสาธารณะไม่ใช่ความลับ และเซิร์ฟเวอร์ส่งใบรับรองของตัวเองให้ทุกคนที่เชื่อมต่อในขั้น TLS handshake ผู้โจมตีจึงหาวัตถุดิบได้ง่าย การแนบใบรับรองของเซิร์ฟเวอร์เป้าหมายทำให้เข้าถึงช่องทางฐานข้อมูลของคลัสเตอร์ (database gateway) ได้ ส่วนการแนบใบรับรองของสมาชิกคลัสเตอร์เครื่องอื่นทำให้ได้สิทธิ์แบบการสื่อสารภายในคลัสเตอร์ ซึ่งข้ามการตรวจสิทธิ์ทั้งหมด ใบรับรองของไคลเอนต์และระบบเก็บ metrics ที่ได้รับความเชื่อถือก็ถูกปลอมได้เช่นกันถ้าผู้โจมตีหาใบรับรองสาธารณะมาได้

ผลลามไปถึง trust store และเอเจนต์ใน VM — ช่องโหว่ไม่จบที่การเข้าสู่ระบบ ผู้โจมตีใช้ช่องทางบริการตนเอง (self-service) ต่ออายุหรือลบรายการใน trust store ได้ และการยืนยันตัวตนระหว่างเครื่องแม่ข่ายกับเอเจนต์ใน VM ก็ได้รับผลกระทบด้วย นอกจากนี้ใบรับรองที่ไม่ผ่านการตรวจยังถูกส่งต่อให้ authorization scriptlet ซึ่งเป็นสคริปต์กำหนดสิทธิ์ ทำให้ข้อมูลใบรับรองที่ผู้โจมตีเลือกเองมีผลต่อการตัดสินสิทธิ์ได้ แม้กับไคลเอนต์ที่ใช้ token หรือ OpenID Connect

ไม่มีทางแก้ด้วยการตั้งค่า — ผู้ดูแล Incus ระบุว่าไม่มีการตั้งค่าใดแก้ช่องโหว่นี้ได้ การจำกัดเครือข่ายช่วยลดโอกาสถูกโจมตี แต่ไม่ได้แก้ความผิดพลาดในการตรวจใบรับรอง ทางออกเดียว คือ อัปเดตเป็นรุ่นที่แก้แล้ว

ผลกระทบ

กลุ่มที่โดนโดยตรง คือ องค์กรและผู้ให้บริการที่ใช้ Incus รุ่นก่อน 7.6.0 หรือ LXD รุ่นที่ยังไม่แก้ และเปิดพอร์ต HTTPS สำหรับจัดการระบบ (ค่าเริ่มต้นพอร์ต 8443) ให้เครือข่ายอื่นเข้าถึงได้ ระบบแบบคลัสเตอร์เสี่ยงที่สุด เพราะการปลอมเป็นสมาชิกคลัสเตอร์ข้ามการตรวจสิทธิ์ทั้งหมด และใบรับรองที่ต้องใช้ปลอมก็หาได้จากการเชื่อมต่อธรรมดา

ถ้าถูกโจมตีสำเร็จ ผู้โจมตีจะคุมคอนเทนเนอร์และ VM ที่คลัสเตอร์ดูแลได้ทั้งหมด ในทางปฏิบัติ คือ อ่านข้อมูลในเครื่อง รันคำสั่ง หรือลบเครื่องทิ้งได้ ระบบที่ใช้ Incus หรือ LXD เป็นฐานของคลาวด์ส่วนตัว สภาพแวดล้อม CI หรือแล็บที่มีผู้ใช้หลายราย จึงเสี่ยงถูกยึดทั้งแพลตฟอร์มจากจุดเดียว ความเร่งด่วนอยู่ในระดับวิกฤต เพราะไม่ต้องมีบัญชี ไม่ต้องมีกุญแจ และไม่มีทางแก้ด้วยการตั้งค่า แม้ยังไม่มีรายงานการโจมตีจริงก็ตาม

คำแนะนำ

  • ทำทันที (ผู้ใช้ Incus): อัปเดต Incus เป็นรุ่น 7.6.0 ขึ้นไป
  • ทำทันที (ผู้ใช้ LXD): อัปเดตเป็น 4.0.15, 5.0.11, 5.21.9 หรือ 6.10.1 ตามสายที่ใช้ ผู้ที่ติดตั้งผ่าน snap ตรวจรุ่นด้วย snap info lxd แล้วอัปเดตด้วย snap refresh lxd
  • ระหว่างรออัปเดต: จำกัดพอร์ต HTTPS จัดการ (ค่า core.https_address ค่าเริ่มต้น 8443) ให้เข้าได้เฉพาะเครื่องที่เชื่อถือ ด้วยไฟร์วอลล์หรือผูกไว้กับเครือข่ายจัดการเท่านั้น ซึ่งลดความเสี่ยงแต่ไม่แก้ต้นเหตุ
  • ตรวจว่าโดนแล้วหรือยัง: เปิดรายการ trust store ด้วย incus config trust list หรือ lxc config trust list หาใบรับรองที่ไม่รู้จัก ถูกลบ หรือถูกต่ออายุโดยไม่ได้สั่ง
  • ตรวจว่าโดนแล้วหรือยัง: ไล่ล็อกการทำงานของคลัสเตอร์หาการสร้าง แก้ไข หรือรันคำสั่งในคอนเทนเนอร์และ VM ที่ไม่ได้สั่ง
  • ถ้าพบร่องรอย: ถือว่าคอนเทนเนอร์และ VM ในคลัสเตอร์อาจถูกแก้ไขแล้ว ตรวจสอบเครื่องเหล่านั้นและเปลี่ยน secret ที่เก็บไว้ภายใน
  • ระยะยาว: ทบทวน authorization scriptlet ที่ตัดสินสิทธิ์จากข้อมูลใบรับรอง หลังอัปเดตแล้ว

แหล่งอ้างอิง