HPE iLO 7 ก่อน 1.25.00 มีช่องโหว่ Critical: อย่าปล่อย management plane ไว้หลังคำว่า internal

HPE ออก security bulletin สำหรับ HPE Integrated Lights-Out 7 หรือ iLO 7 เรื่อง user validation failure หมายเลข CVE-2026-79820 ซึ่งหน่วยงานเตือนภัยจัดเป็นระดับ Critical ครับ Canadian Centre for Cyber Security ระบุชัดว่ารุ่นก่อน 1.25.00 ได้รับผลกระทบ และแนะนำให้ตรวจประกาศ HPE แล้วอัปเดต

iLO คือ management plane นอกระบบปฏิบัติการ ใช้เปิดปิดเครื่อง เปิด remote console, mount media และจัดการ firmware ความผิดพลาดที่ข้ามการตรวจผู้ใช้จึงไม่เหมือนบั๊กหน้าเว็บทั่วไป ผู้ที่เข้าถึง network ของ iLO อาจได้อำนาจระดับผู้ดูแล hardware แม้ host OS จะ patch ครบ

สรุป 30 วินาที

• ผลิตภัณฑ์ในขอบเขตคือ HPE iLO 7 ก่อน firmware 1.25.00 ตาม advisory ภาครัฐแคนาดาที่อ้าง bulletin HPE
• ปัญหาเป็น user validation failure/authorization bypass และแหล่งประสานเหตุระบุว่าผู้โจมตีอาจได้ administrative access
• management interface ไม่ควรเปิด internet และไม่ควรแชร์ flat network กับ user/workload traffic
• ให้อัปเดตเป็น 1.25.00 หรือใหม่กว่าที่ HPE รับรองกับรุ่น server ของคุณ พร้อมตรวจ signature/checksum ผ่านช่องทาง HPE
• หลัง patch ต้องตรวจ account, role, login/audit log, certificate, network setting และ firmware state เพราะการปิดช่องโหว่ไม่ได้พิสูจน์ว่าไม่เคยถูกใช้
• ถ้า patch ทันทีไม่ได้ ให้จำกัด management VLAN ผ่าน jump host/VPN/MFA/firewall และปิด route ที่ไม่จำเป็นเป็นมาตรการชั่วคราว

ทำไมเรื่องนี้เกี่ยวกับคุณ

หลายทีมคิดว่า iLO “อยู่หลังบ้าน” จึงปลอดภัย แต่ internal network ไม่ใช่ตัวตนผู้ใช้ หาก workstation, VPN account หรือ workload ใน segment เดียวถูกยึด ผู้โจมตีอาจมองเห็น management plane ต่อได้ เหมือนห้องควบคุมไฟของอาคารที่ล็อกประตูหน้าแน่น แต่มีทางเดินจากโรงอาหารถึงตู้ควบคุมโดยไม่ตรวจบัตร

อำนาจของ out-of-band management สูงมาก เพราะอยู่ต่ำกว่า OS Agent บนเครื่องอาจมองไม่เห็นทุกการกระทำจาก remote console หรือ virtual media และการเปลี่ยน boot order/firmware สามารถข้าม control ที่ทีม endpoint คุ้นเคยได้ ดังนั้น inventory ของ iLO ต้องอยู่ใน vulnerability program แยกจากรายการ package ของ Linux/Windows

องค์กรที่เช่า colo หรือมีสาขายิ่งต้องรู้ว่าใครรับผิดชอบ firmware, ใครถือ credential, management network วิ่งผ่านอะไร และ backup config อยู่ที่ไหน ช่องโหว่ critical ที่แก้ด้วย firmware มักติด bottleneck ไม่ใช่ความรู้ แต่เป็น ownership ไม่ชัด

ทำงานยังไง: บัตรผ่านห้องควบคุมที่ตรวจไม่ครบ

คำอธิบายสาธารณะจัดปัญหาเป็น user validation failure นั่นหมายถึงขั้นตอนที่ควรยืนยันว่า request มาจากผู้ใช้ที่ถูกต้องหรือมีสิทธิ์เพียงพอทำงานผิดพลาด รายละเอียด exploit ไม่จำเป็นต่อการตัดสินใจ patch และเราไม่ควรทดสอบ bypass กับอุปกรณ์ production

คิดเป็นประตูสองชั้น: network path คือรั้วชั้นนอก ส่วน authentication/authorization ใน iLO คือเครื่องอ่านบัตร ช่องโหว่กระทบเครื่องอ่านบัตร ดังนั้น segmentation ยังช่วยลดคนที่เดินมาถึงประตู แต่ไม่แก้เครื่องอ่าน HPE firmware 1.25.00 จึงเป็นการแก้หลัก

หลังได้ admin access ผู้โจมตีอาจเปลี่ยน account/config หรือใช้ความสามารถจัดการเครื่องตามสิทธิ์ที่ระบบให้ ขอบเขตจริงขึ้นกับรุ่น hardware, license, configuration และ network egress จึงต้องประเมิน asset ขององค์กร ไม่ควรแต่งรายการ action เกินข้อมูล bulletin

การ patch firmware ต้องรักษาพลังงานและความต่อเนื่องตามคู่มือ อุปกรณ์บางชุดต้องเรียง dependency กับ system ROM หรือ component อื่น ใช้ HPE Service Pack/ช่องทางที่องค์กรอนุมัติ ตรวจ compatibility matrix และทำ canary ก่อน fleet rollout

เงินและผลกระทบ

ต้นทุนตรงคือ maintenance window, การทดสอบ remote console และความเสี่ยง firmware update ล้มเหลว ต้นทุนของการไม่แก้สูงกว่าได้ตั้งแต่ incident response ถึง downtime หลายเครื่อง เพราะ management plane มีสิทธิ์ควบคุม host จำนวนมากและมักใช้ credential รูปแบบคล้ายกัน

จัดลำดับจาก iLO ที่เข้าถึงผ่าน internet/VPN กว้าง, เครื่อง production สำคัญ, shared/admin account และระบบที่ไม่มี MFA/jump host ก่อน สร้าง dashboard ที่แสดง firmware จริงจาก inventory ไม่ใช้ spreadsheet ที่อัปเดตด้วยมือเพียงครั้งเดียว

อย่าซื้อเครื่องมือใหม่ก่อนปิดทางพื้นฐาน: management VLAN, firewall allowlist, named accounts, MFA ที่ jump layer, certificate ที่ตรวจได้, log forwarding และ backup config แบบเข้ารหัส มาตรการเหล่านี้ลด blast radius ทั้งช่องโหว่นี้และ credential theft รอบหน้า

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

HPE bulletin เป็นแหล่ง authoritative สำหรับรายละเอียดผลิตภัณฑ์ ขณะที่หน้า HPE อาจเข้าถึงยากจากบางเครือข่าย หน่วยงานแคนาดาจึงให้ข้อมูลยืนยันขั้นต่ำที่ใช้งานได้คือ iLO 7 ก่อน 1.25.00 ส่วน CSIRT Toscana อธิบายผลกระทบเชิง administrative access

แหล่งรองอาจใช้คำว่า authentication bypass หรือ user validation failure ต่างกัน เราควรยึด CVE และ affected/fixed version จาก bulletin ไม่ขยายเป็น remote-code execution หากต้นทางไม่ได้ระบุ ช่องโหว่สิทธิ์สูงก็ร้ายแรงพอโดยไม่ต้องเติมคำ

ข้อมูลสาธารณะในวันที่ตรวจไม่ได้ตอบว่ามี exploitation จริงหรือไม่, มี proof-of-concept สาธารณะหรือไม่, ต้องมี network adjacency แบบใดครบทุกกรณี และ configuration ใดลดผลกระทบ องค์กรจึงต้องถือว่า exposure ที่เข้าถึงได้มีความเสี่ยง แล้วตรวจ log ของตน

ยังต้องยืนยันว่า 1.25.00 รองรับ server generation/firmware bundle ของแต่ละ asset อย่างไรจาก HPE support matrix ไม่ควร flash image ข้ามรุ่นเพราะเลขเวอร์ชันเหมือนกัน และห้ามดาวน์โหลด firmware จาก mirror ที่ publisher ไม่รับรอง

แล้วเราควรทำอะไร

เริ่มจาก discovery: ดึงรายการ iLO 7, รุ่น server, serial/asset owner, firmware, management IP, exposure, account และ log destination ผ่านเครื่องมือ inventory ที่ได้รับอนุญาต เปรียบเทียบกับ DHCP/DNS/firewall เพื่อหาอุปกรณ์หลุดรายการ โดยไม่ยิง exploit scanner

วาง canary สองสามเครื่องที่แทน hardware/role ต่างกัน ดาวน์โหลด firmware ผ่าน HPE channel ตรวจ signature/checksum ตามคู่มือ ทำ backup config และมี recovery path จากนั้น patch เป็น 1.25.00 หรือใหม่กว่าที่รองรับ ทดสอบ login, RBAC, remote console, power control, monitoring, certificate และ log forwarding

ระหว่างรอ window ให้ firewall อนุญาตเฉพาะ jump host/administration subnet ตัด internet route บังคับ VPN/MFA ที่ทางเข้า ปิด shared account ที่ไม่จำเป็นและหมุน credential จาก clean admin workstation มาตรการนี้ลด exposure แต่ไม่เลื่อน deadline patch

หลัง rollout ตรวจทุก asset จาก runtime ว่า version เปลี่ยนจริง ไล่ account/role ใหม่หรือผิดปกติ, login failure/success, configuration change, virtual-media event และ certificate change ถ้าพบร่องรอยให้แยก management network, เก็บหลักฐานและเข้า incident response ไม่ reboot/clear log โดยไม่มีแผน

สุดท้ายกำหนด owner กับ SLA ถาวรสำหรับ BMC/iLO firmware ให้เหมือน OS patching และซ้อม recovery อย่างน้อยเป็นรอบ เพราะ management plane ที่ไม่มีเจ้าของจะกลับมาเป็น blind spot แม้รอบนี้ปิดแล้ว

Recap

• หา iLO 7 ทุกเครื่องและยืนยัน firmware จาก runtime
• อัปเดตรุ่นก่อน 1.25.00 ผ่าน HPE channel ที่ตรวจ provenance
• แยก management VLAN และ allowlist เฉพาะ jump host
• ใช้ named accounts/MFA ที่ access layer และเลิก shared credential
• ทดสอบ remote console, RBAC, monitoring และ recovery หลัง patch
• ตรวจ audit log กับ account/config change ย้อนหลัง
• ตั้ง owner/SLA ให้ firmware management plane ถาวร

คำว่า internal ช่วยอธิบาย topology แต่ไม่ใช่ control ครับ ถ้าคนที่ไม่ควรเข้าเดินมาถึงเครื่องอ่านบัตรได้ เราต้องทั้งซ่อมเครื่องอ่านและทำรั้วให้เส้นทางสั้นที่สุด