สรุปสั้น

บริษัท Red Hat เปิดเผยว่ามีช่องโหว่ใน FreeIPA ที่เปิดทางให้ไคลเอนต์ซึ่งไม่เคยล็อกอินเลยสร้างตัวตน Kerberos ตามชื่อที่ตัวเองเลือกลงในไดเรกทอรี แล้วจบลงด้วยการอยู่ในกลุ่มผู้ดูแลระบบ FreeIPA คือระบบที่กำหนดว่าใครล็อกอินได้บ้างทั่วโดเมนลินุกซ์ และเก็บตัวตนทั้งหมดไว้ในฐานข้อมูล 389 Directory Server ที่เข้าถึงผ่าน LDAP โดยการโจมตีนี้ต้องอาศัยช่องโหว่ตัวที่สองในซอฟต์แวร์ฐานข้อมูลนั้นประกอบด้วย

Red Hat ติดตามช่องโหว่ฝั่ง FreeIPA ในชื่อ CVE-2026-76578 จัดระดับร้ายแรงที่คะแนน CVSS 9.8 โดยหน้าเดียวกันระบุว่าคะแนนนี้ยังเป็นคะแนนเบื้องต้นและอาจถูกทบทวน ส่วนช่องโหว่ฝั่งไดเรกทอรีเซิร์ฟเวอร์คือ CVE-2026-76560 ที่ได้คะแนน 7.5 ซึ่ง Red Hat ระบุว่า Red Hat Directory Server ไม่ได้มาพร้อมกฎรูปแบบดังกล่าวโดยค่าเริ่มต้น ดังนั้นเมื่อพิจารณาลำพังช่องโหว่ตัวนี้จะมีความหมายเฉพาะกับการติดตั้งที่ผู้ดูแลเขียนกฎแบบนั้นขึ้นมาเอง แต่ FreeIPA คือการติดตั้งแบบนั้นพอดี เพราะกฎค่าเริ่มต้นที่ FreeIPA แถมมาให้มีรูปทรงตรงตามที่ว่า ซึ่งเป็นเหตุผลที่ห่วงโซ่นี้ทำงานได้กับการติดตั้งที่ยังไม่ถูกแก้ไขใด ๆ

โครงการ FreeIPA แก้ฝั่งของตนเองไปแล้วในเวอร์ชัน 4.13.4 และ Red Hat ระบุว่าได้ทำซ้ำห่วงโซ่การโจมตีนี้สำเร็จสองครั้งบนการติดตั้งแบบค่าเริ่มต้น โดยครั้งล่าสุดทำบนเครื่องที่ไม่มีสิทธิ์เข้าถึงใด ๆ เลย ทั้งนี้ยังไม่มีประกาศหรือรายงานบั๊กฉบับใดที่ระบุว่าช่องโหว่ชุดนี้ถูกใช้โจมตีจริง และไม่มีการเผยแพร่กฎตรวจจับหรือตัวบ่งชี้ใด ๆ

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 8 กันยายน พ.ศ. 2569 ว่า ช่องโหว่ใน FreeIPA เปิดทางให้ไคลเอนต์ที่ไม่เคยล็อกอินสามารถสร้างตัวตน Kerberos ตามที่ตัวเองเลือกในไดเรกทอรี และลงเอยด้วยการอยู่ในกลุ่มผู้ดูแลระบบ ตามที่ Red Hat ระบุ โดย Red Hat จำหน่าย FreeIPA ในชื่อผลิตภัณฑ์ Identity Management ซึ่งแพ็กเกจใช้ชื่อว่า ipa

เทคนิคที่ถูกรายงานมายัง Red Hat ในตอนแรกเป็นการปลอมเป็นบัญชี admin ตัวจริงด้วยการสร้างชื่อ Kerberos ให้ชนกัน การแก้ไขก่อนหน้านี้สำหรับ CVE-2026-13097 ปิดการชนชื่อดังกล่าวไปแล้ว แต่ปล่อยให้การเขียนข้อมูลโดยไม่ต้องยืนยันตัวตนซึ่งเป็นรากของปัญหายังคงอยู่ Red Hat ระบุว่าการโจมตีในปัจจุบันจึงทำงานภายใต้ชื่อที่ผู้โจมตีเลือกเองแทน และ “ไปถึงผลลัพธ์เชิงปฏิบัติแบบเดียวกัน” ส่วนช่องโหว่เก่าที่แก้ไปใน FreeIPA 4.13.3 นั้นเป็นคนละปัญหา คือการตรวจว่าชื่อ Kerberos ไม่ซ้ำกันไม่ได้เผื่อวิธีเขียนชื่อเดียวกันในรูปแบบต่าง ๆ ทำให้ผู้ใช้ที่มีสิทธิ์เขียนสร้างตัวตนของบริการที่ปลอมเป็นตัวตนที่มีสิทธิ์สูงกว่าได้

สองโครงการอธิบายผลลัพธ์ต่างกัน Red Hat เรียกสิ่งที่เกิดขึ้นว่าเป็นการเป็นสมาชิกกลุ่มผู้ดูแลระบบของจริงและได้ข้อมูลรับรองผู้ดูแลระบบที่นำกลับมาใช้ซ้ำได้ ขณะที่โครงการ FreeIPA อธิบายในกรอบที่แคบกว่า โดยระบุว่าตัวตนที่ถูก inject เข้าไปต้องยังไม่มีอยู่เดิม การแก้ไข CVE-2026-13097 ป้องกันไม่ให้บัญชีที่มีอยู่แล้วถูกยึด และการโจมตีนี้ “อาจถูกใช้เป็นบันไดขั้นหนึ่ง” ไปสู่สิทธิ์ผู้ดูแลระบบ

Red Hat ระบุว่าได้รันห่วงโซ่การโจมตีนี้กับอิมเมจคอนเทนเนอร์ FreeIPA เซิร์ฟเวอร์แบบมาตรฐานที่รันเวอร์ชัน 4.13.1 และตรวจสอบผลลัพธ์ด้วยคำสั่งที่เฉพาะผู้ดูแลระบบเท่านั้นที่ใช้ได้ แทนที่จะเชื่อผลลัพธ์ที่โค้ดโจมตีพิมพ์ออกมา นอกจากนี้สำหรับการติดตั้งที่ใช้ security identifier แบบวินโดวส์ Red Hat ระบุว่าผู้โจมตียังได้ตั๋ว Kerberos ที่มีข้อมูลการอนุญาตอยู่ภายในด้วย ซึ่งขยายการเข้าถึงไปถึงบริการ HTTP และ Dogtag ของเซิร์ฟเวอร์ โดย Dogtag คือผู้ออกใบรับรองที่มาพร้อมกับ FreeIPA

Red Hat ยังเปิดเผยช่องโหว่ FreeIPA ตัวที่สองพร้อมกันคือ CVE-2026-79678 ซึ่งไม่เกี่ยวข้องกับห่วงโซ่ข้างต้นเลย และจัดระดับความสำคัญไว้ที่ important ด้วยคะแนน 8.1 ปัญหาอยู่ที่คำสั่ง idp-add ซึ่งส่งค่าสองค่าที่ผู้เรียกเป็นคนป้อน คือชื่อองค์กรและ base URL เข้าไปในการเรียก eval() ของภาษา Python และการเรียกนั้นเกิดขึ้น ก่อน การตรวจสิทธิ์ที่ตั้งใจจำกัดคำสั่งนี้ไว้ให้เฉพาะผู้ดูแลระบบฝั่ง identity provider ผลคือบัญชีใดก็ได้บนเซิร์ฟเวอร์เข้าถึงจุดนี้ได้ ไม่ว่าจะมีสิทธิ์ระดับใด

เครดิตการรายงานห่วงโซ่ FreeIPA และช่องโหว่ฝั่งไดเรกทอรีเซิร์ฟเวอร์เป็นของ นาย Gia Bui จาก Calif ส่วนช่องโหว่ idp-add Red Hat ให้เครดิต Calif ที่ทำงานร่วมกับ Anthropic

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

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

389 Directory Server มีกฎประเภทหนึ่งที่ตั้งใจให้หมายความว่า “เฉพาะเจ้าของรายการนี้ที่ผ่านการยืนยันตัวตนแล้วเท่านั้น” แต่การทำงานจริงคือเปรียบเทียบชื่อของไคลเอนต์กับค่าที่เก็บไว้แบบข้อความล้วน และไคลเอนต์ที่ยังไม่ได้ล็อกอินจะมีชื่อเป็นค่าว่าง ซึ่งไปตรงกับค่าที่เก็บไว้ที่เป็นค่าว่างพอดี ผลคือไคลเอนต์แบบไม่ระบุตัวตนสามารถสร้างรายการโทเค็นโดยเว้นฟิลด์ความเป็นเจ้าของไว้ว่าง ผ่านการตรวจความเป็นเจ้าของไปได้เพราะ “ไม่ได้เป็นใคร” แล้วเขียนตัวตน Kerberos พร้อมรหัสผ่านแนบไปกับรายการนั้น

Red Hat ยังทำซ้ำข้อบกพร่องฝั่งไดเรกทอรีเซิร์ฟเวอร์ได้ด้วยตัวเองบนบิลด์ 389-ds เปล่า ๆ ที่ไม่มีส่วนประกอบของ FreeIPA ติดตั้งอยู่เลย และการทดสอบควบคุมที่ใช้ค่าซึ่งไม่ใช่ค่าว่างถูกปฏิเสธอย่างถูกต้อง ผลการทดสอบชุดนี้ชี้ว่าข้อบกพร่องอยู่ในกลไกควบคุมการเข้าถึงเอง ไม่ได้อยู่ในสิ่งที่ FreeIPA ทำ

สำหรับช่องโหว่ idp-add การเรียก eval() ถูกจำกัดด้วยรูปแบบที่ห้ามใช้วงเล็บเหลี่ยม ซึ่งปิดกั้นการเรียกฟังก์ชันใด ๆ Red Hat จึงระบุว่า “ไม่สามารถรันโค้ดได้” สิ่งที่ผู้โจมตีทำได้จริงคืออ่านตัวแปรสภาพแวดล้อมของกระบวนการเซิร์ฟเวอร์ทีละตัวจากการสังเกตข้อความผิดพลาดที่เซิร์ฟเวอร์ตอบกลับ และใช้หน่วยความจำของเซิร์ฟเวอร์จนหมดด้วยนิพจน์ทางคณิตศาสตร์สั้น ๆ ความสำคัญของเรื่องนี้ขึ้นอยู่กับวิธีติดตั้ง FreeIPA — บนการติดตั้งแบบแพ็กเกจปกติ สภาพแวดล้อมของกระบวนการมีเพียงเส้นทางและการตั้งค่าที่มีเอกสารกำกับ แต่การติดตั้งแบบคอนเทนเนอร์ต่างออกไป เพราะอิมเมจ FreeIPA เซิร์ฟเวอร์อย่างเป็นทางการมักรับรหัสผ่านของ Directory Manager และผู้ดูแลระบบมาเป็นตัวแปรสภาพแวดล้อมตอนบูตครั้งแรก และรหัสผ่านเหล่านั้นอาจรั่วออกไปได้หากยังค้างอยู่หลังการติดตั้งเสร็จสิ้น

ผลกระทบ

ผู้ที่ได้รับผลกระทบคือองค์กรที่ใช้ FreeIPA หรือ Red Hat Identity Management เป็นศูนย์กลางการยืนยันตัวตนของโดเมนลินุกซ์ ซึ่งโดยธรรมชาติแล้วเป็นระบบที่การถูกยึดหนึ่งครั้งเท่ากับการยึดทุกเครื่องที่ผูกกับโดเมนนั้น ความร้ายแรงที่แท้จริงของห่วงโซ่นี้จึงไม่ได้อยู่ที่ตัวเลข 9.8 แต่อยู่ที่ตำแหน่งของระบบในสถาปัตยกรรม

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

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

ส่วนประกอบสิ่งที่ต้องติดตั้งสถานะเมื่อตรวจสอบ
FreeIPA จากโครงการโดยตรงFreeIPA 4.13.4แก้ช่องโหว่ FreeIPA ทั้งสองตัว · release notes ไม่ระบุวันที่และไม่บอกว่าเวอร์ชันเก่ากว่านั้นได้รับผลกระทบตัวไหนบ้าง
389-ds-base บน RHEL และ Red Hat Directory Serverประกาศแก้ไขตามรุ่นที่ใช้มี 14 ประกาศเผยแพร่วันที่ 8 กันยายน ระหว่างเวลา 01:56 ถึง 05:07 UTC · RHSA-2026:64785 ครอบคลุม RHEL 10 ด้วย 389-ds-base-3.2.0-10.el10_2 จัดระดับร้ายแรง และครอบคลุมช่องโหว่ 389-ds อีก 4 ตัวนอกเหนือจากตัวนี้
แพ็กเกจ ipa บน RHELยังไม่มีรายการรายงานบั๊กของ Red Hat สำหรับช่องโหว่ FreeIPA ทั้งสองตัวยังไม่แสดงเวอร์ชันที่แก้แล้วและไม่มีประกาศ เมื่อตรวจสอบวันที่ 8 กันยายน
389-ds-base บน Fedoraอัปเดตยังอยู่ในขั้นทดสอบตัวติดตามของ Fedora ถูกทำเครื่องหมายเป็น ON_QA เมื่อตรวจสอบวันที่ 8 กันยายน

ไม่มีประกาศสำหรับ Red Hat Enterprise Linux 9 แบบธรรมดาปรากฏในรายการ 14 ประกาศดังกล่าว ซึ่งเป็นสิ่งที่รายงานบั๊กแสดงเมื่อวันที่ 8 กันยายน ไม่ใช่คำยืนยันว่ารุ่นนั้นจะไม่มีตัวแก้ไขตามมา

คำแนะนำ

จนกว่าจะมีแพ็กเกจที่แก้แล้ว Red Hat ให้มาตรการชั่วคราวสองข้อสำหรับห่วงโซ่การโจมตีนี้ ข้อแรกคือจำกัดการเข้าถึงบริการ LDAP ซึ่งโดยทั่วไปคือพอร์ต 389 และ 636 ให้เฉพาะโฮสต์ที่เชื่อถือได้ ด้วยกฎไฟร์วอลล์หรือการแบ่งเขตเครือข่าย ข้อที่สองคือปิดการ bind แบบไม่ระบุตัวตนของ LDAP ซึ่ง Red Hat ระบุว่าปิดกั้นเส้นทางนี้ได้ แต่ต้องตรวจสอบก่อนว่าไม่มีส่วนอื่นในการติดตั้งที่จำเป็นต้องใช้งานฟีเจอร์นั้น

สำหรับช่องโหว่ idp-add ไม่มีทางเลือกแบบนั้น Red Hat ระบุว่าไม่มีการตั้งค่าใดที่กันบัญชีผู้ใช้ทั่วไปซึ่งผ่านการยืนยันตัวตนแล้วออกจากโค้ดส่วนนั้นได้ และจำเป็นต้องใช้แพ็กเกจที่แก้แล้วเท่านั้น พร้อมเสริมว่าผู้ที่รันการติดตั้งแบบคอนเทนเนอร์ควรตรวจสอบว่ารหัสผ่านที่ตั้งไว้ตอนบูตครั้งแรกไม่ได้ค้างอยู่ในสภาพแวดล้อมของกระบวนการที่กำลังรันอยู่

สิ่งที่เอกสารที่เผยแพร่ออกมายังไม่ตอบมีสองเรื่อง เรื่องแรกคือทั้ง Red Hat และโครงการ FreeIPA ไม่ได้ระบุว่าการอัปเดต 389-ds เพียงลำพังหยุดการโจมตี FreeIPA บนเซิร์ฟเวอร์ที่แพ็กเกจ ipa ยังเก่าอยู่ได้หรือไม่ เรื่องที่สองคือไม่มีใครระบุว่าการติดตั้งตัวแก้ไขจะลบตัวตนที่ผู้โจมตีสร้างไว้ก่อนหน้าออกไปหรือไม่ และผู้ดูแลระบบควรมองหาอะไรเพื่อตรวจสอบเรื่องนี้ ทั้งประกาศและรายงานบั๊กก็ไม่ได้เผยแพร่กฎตรวจจับหรือตัวบ่งชี้ใด ๆ

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

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