สรุปสั้น

ช่องโหว่ร้ายแรงใน Issabel Framework ซึ่งเป็นเฟรมเวิร์กบนเว็บสำหรับซอฟต์แวร์ตู้สาขาโทรศัพท์ (PBX) ระบบสื่อสารรวมศูนย์แบบโอเพนซอร์ส กำลังตกอยู่ภายใต้การโจมตีจริง ช่องโหว่นี้ถูกติดตามในรหัส CVE-2026-89026 ได้คะแนนความรุนแรงสูงถึง 9.8 บนมาตร CVSS v3.1 และ 9.3 บนมาตร CVSS v4.0 โดยเปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถรันคำสั่งระบบปฏิบัติการตามอำเภอใจได้ ด้วยการอาศัยกุญแจเซ็นโทเค็น JWT ที่ถูกฝังตายไว้ในโค้ด

ต้นเหตุคือ Issabel Framework มีกุญแจเซ็น JWT แบบ HS256 ฝังอยู่ในไฟล์ index.php ของ pbxapi ซึ่งเป็นกุญแจดอกเดียวกันในทุกการติดตั้งทั่วโลก ทำให้ผู้โจมตีสามารถปลอมโทเค็น bearer ที่ถูกต้องขึ้นมาเองได้ แพตช์แก้ไขถูกปล่อยออกมาตั้งแต่วันที่ 1 สิงหาคม 2569 และมูลนิธิ Shadowserver ตรวจพบการโจมตีช่องโหว่นี้ครั้งแรกเมื่อวันที่ 9 กันยายน 2569 แม้ในเวลานี้ยังไม่มีรายละเอียดว่าใครอยู่เบื้องหลังและการโจมตีมีขนาดใหญ่เพียงใด แต่การที่ช่องโหว่ถูกใช้จริงแล้วทำให้ผู้ใช้ต้องรีบอัปเดตโดยด่วน

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 16 กันยายน 2569 ว่า บริษัท VulnCheck ได้ออกการแจ้งเตือนเกี่ยวกับช่องโหว่ CVE-2026-89026 ใน Issabel Framework โดยระบุว่าเฟรมเวิร์กนี้ “มีกุญแจเซ็น JWT แบบ HS256 ที่ฝังตายอยู่ในไฟล์ index.php ของ pbxapi ซึ่งเหมือนกันในทุกการติดตั้ง เปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถปลอมโทเค็น bearer ที่ถูกต้องได้”

VulnCheck อธิบายต่อว่า ผู้โจมตีสามารถใช้โทเค็นที่ปลอมขึ้นเรียกไปยังเอนด์พอยต์ ‘/pbxapi/manager/originate’ พร้อมพารามิเตอร์ System application ทำให้ Asterisk รันคำสั่งระบบปฏิบัติการตามอำเภอใจในสิทธิ์ของผู้ใช้ Asterisk ได้ แพตช์สำหรับช่องโหว่นี้ถูกปล่อยออกมาเมื่อวันที่ 1 สิงหาคม 2569 โดยอุดช่องโหว่ด้วยการแทนที่กุญแจ JWT ที่ฝังตายไว้ (ค่า “da893kasdfam43k29akdkfaFFlsdfhj23rasdf”) ด้วยกุญแจ JWT ที่จัดเก็บไว้ในไฟล์ “/etc/issabel.conf” ต่อมามูลนิธิ Shadowserver ได้ตรวจพบการใช้ช่องโหว่ CVE-2026-89026 โจมตีจริงครั้งแรกเมื่อวันที่ 9 กันยายน 2569 อย่างไรก็ตาม ในเวลานี้ยังไม่มีรายละเอียดว่าช่องโหว่ถูกนำไปใช้ในการโจมตีจริงอย่างไร ใครอยู่เบื้องหลัง และการโจมตีมีขนาดใหญ่เพียงใด

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

หัวใจของช่องโหว่นี้คือปัญหากุญแจลับที่ฝังตายในโค้ด (hard-coded secret) Issabel Framework ใช้กุญแจเซ็น JWT แบบ HS256 เพียงดอกเดียวที่เขียนไว้ในไฟล์ index.php ของ pbxapi และเนื่องจากทุกการติดตั้งใช้กุญแจดอกเดียวกันหมด ผู้โจมตีที่รู้ค่ากุญแจนี้ (ซึ่งเปิดเผยอยู่ในซอร์สโค้ดโอเพนซอร์ส) จึงสามารถสร้างโทเค็น JWT ที่ระบบมองว่าถูกต้องได้เองโดยไม่ต้องมีบัญชีหรือรหัสผ่านใด ๆ นี่คือสาเหตุที่ช่องโหว่ได้คะแนนสูงถึงระดับวิกฤต เพราะข้ามการยืนยันตัวตนได้ทั้งหมด

เมื่อได้โทเค็นปลอมที่ผ่านการตรวจแล้ว ผู้โจมตีจะเรียกไปยังเอนด์พอยต์ของตัวจัดการ ‘/pbxapi/manager/originate’ พร้อมกำหนดพารามิเตอร์ให้ใช้แอปพลิเคชัน System ซึ่งเป็นกลไกของ Asterisk ที่ออกแบบมาให้เรียกใช้คำสั่งภายนอกได้ ผลลัพธ์คือ Asterisk จะรันคำสั่งระบบปฏิบัติการที่ผู้โจมตีป้อนเข้ามา ในสิทธิ์ของผู้ใช้ Asterisk บนเครื่อง เท่ากับเปลี่ยนช่องโหว่การปลอมโทเค็นให้กลายเป็นการรันโค้ดจากระยะไกล (RCE) เต็มรูปแบบบนระบบโทรศัพท์ขององค์กร

ผลกระทบ

ผู้ที่ได้รับผลกระทบคือองค์กรที่ใช้ระบบโทรศัพท์ PBX บน Issabel ซึ่งมักเป็นระบบสื่อสารหลักที่เปิดให้เข้าถึงได้เพื่อรองรับการโทรเข้าออก การที่ช่องโหว่ไม่ต้องยืนยันตัวตนและนำไปสู่การรันคำสั่งระบบได้ หมายความว่าเซิร์ฟเวอร์ Issabel ใดที่เปิดสู่อินเทอร์เน็ตและยังไม่ได้แพตช์ ล้วนตกเป็นเป้าที่ถูกยึดได้ทันที เมื่อผู้โจมตีรันคำสั่งบนเครื่องได้แล้ว ก็สามารถฝังตัว ขโมยข้อมูลการโทร ดักฟังหรือเปลี่ยนเส้นทางสาย ไปจนถึงใช้ระบบโทรศัพท์เป็นฐานโจมตีต่อภายในเครือข่าย รวมถึงความเสี่ยงการฉ้อโกงค่าโทร (toll fraud) ที่พบได้บ่อยกับระบบ PBX ที่ถูกเจาะ

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

คำแนะนำ

ผู้ดูแลระบบที่ใช้ Issabel Framework ควรอัปเดตเป็นเวอร์ชันล่าสุดที่มีแพตช์แก้ไขโดยด่วน โดยแพตช์จะแทนที่กุญแจ JWT ที่ฝังตายด้วยกุญแจเฉพาะของแต่ละการติดตั้งที่เก็บไว้ในไฟล์ /etc/issabel.conf หลังอัปเดตแล้วควรตรวจสอบว่ากุญแจใหม่ถูกสร้างขึ้นจริงและไม่ใช่ค่าเดิมที่รู้กันทั่วไป

ระหว่างที่ยังแพตช์ไม่ได้ ควรจำกัดการเข้าถึงหน้าเว็บและเอนด์พอยต์ pbxapi ของ Issabel ไม่ให้เปิดสู่อินเทอร์เน็ตโดยตรง เช่น วางไว้หลัง VPN หรือจำกัดด้วยไฟร์วอลล์ให้เข้าถึงได้เฉพาะเครือข่ายที่เชื่อถือได้ นอกจากนี้ควรตรวจสอบบันทึกล็อกย้อนหลังตั้งแต่ต้นเดือนกันยายนเป็นต้นมา เพื่อหาการเรียกที่น่าสงสัยไปยังเอนด์พอยต์ ‘/pbxapi/manager/originate’ และร่องรอยการรันคำสั่งระบบที่ผิดปกติจากผู้ใช้ Asterisk ซึ่งอาจบ่งชี้ว่าเครื่องถูกเจาะไปแล้ว

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