“ช่องโหว่ร้ายแรงใน Nagios Log Server (CVE-2025-44823) — API Key หลุดแบบ plaintext เสี่ยงถูกยึดระบบทั้งองค์กร”
นักวิจัยด้านความปลอดภัยได้เปิดเผยช่องโหว่ระดับวิกฤตใน Nagios Log Server ซึ่งเป็นระบบจัดการล็อกที่นิยมใช้ในองค์กรขนาดใหญ่ โดยช่องโหว่นี้มีรหัส CVE-2025-44823 และได้รับคะแนนความรุนแรง CVSS สูงถึง 9.9 เต็ม 10 ซึ่งถือว่า “Critical” เพราะเปิดโอกาสให้ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำ ก็สามารถดึงข้อมูลผู้ใช้ทั้งหมดรวมถึง API key ของผู้ดูแลระบบในรูปแบบ plaintext ได้ทันที
ช่องโหว่นี้อยู่ใน endpoint /nagioslogserver/index.php/api/system/get_users ซึ่งเมื่อเรียกใช้งานด้วย token ที่ถูกต้อง ระบบจะตอบกลับเป็น JSON ที่มีข้อมูลผู้ใช้ทั้งหมด รวมถึงชื่อ อีเมล และ API key แบบไม่เข้ารหัส เช่น "apikey": "dcaa1693a79d651ebc29d45c879b3fbbc730d2de" ซึ่งสามารถนำไปใช้แอบอ้างเป็นผู้ดูแลระบบได้ทันที
ผลกระทบคือผู้โจมตีสามารถเข้าควบคุมระบบ Nagios Log Server ได้เต็มรูปแบบ เช่น เปลี่ยนการตั้งค่า เข้าถึงข้อมูลล็อกที่ละเอียดอ่อน หรือแม้แต่ลบข้อมูลเพื่อปกปิดร่องรอยการโจมตีอื่น ๆ
นอกจากนี้ยังมีช่องโหว่ CVE-2025-44824 ซึ่งอนุญาตให้ผู้ใช้ที่มีสิทธิ์แค่ read-only สามารถหยุดบริการ Elasticsearch ได้ผ่าน endpoint /api/system/stop?subsystem=elasticsearch โดยระบบจะตอบกลับว่า “error” ทั้งที่จริงแล้ว Elasticsearch ถูกหยุดไปแล้ว ทำให้ผู้ดูแลเข้าใจผิด และอาจถูกใช้โจมตีแบบ DoS เพื่อปิดระบบตรวจสอบแบบเรียลไทม์
Nagios ได้ออกแพตช์ในเวอร์ชัน 2024R1.3.2 ซึ่งแก้ไขทั้งสองช่องโหว่ โดยจำกัดการเข้าถึงข้อมูลผู้ใช้ และเพิ่มการตรวจสอบสิทธิ์ก่อนอนุญาตให้ควบคุมบริการ พร้อมปรับข้อความตอบกลับให้ตรงกับสถานะจริง
ข้อมูลสำคัญจากข่าว
ช่องโหว่ CVE-2025-44823 เปิดเผย API key ของผู้ดูแลระบบในรูปแบบ plaintext
อยู่ใน endpoint /api/system/get_users ของ Nagios Log Server
ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำก็สามารถดึงข้อมูลได้
JSON ที่ตอบกลับมีชื่อผู้ใช้ อีเมล และ API key แบบไม่เข้ารหัส
ช่องโหว่ CVE-2025-44824 อนุญาตให้หยุดบริการ Elasticsearch ด้วยสิทธิ์ read-only
ระบบตอบกลับว่า “error” ทั้งที่บริการถูกหยุดจริง
ส่งผลให้ระบบตรวจสอบแบบเรียลไทม์ถูกปิด และข้อมูลล็อกไม่ถูกบันทึก
Nagios ออกแพตช์ในเวอร์ชัน 2024R1.3.2 เพื่อแก้ไขช่องโหว่ทั้งสอง
แพตช์เพิ่มการตรวจสอบสิทธิ์และปรับข้อความตอบกลับให้ถูกต้อง
ข้อมูลเสริมจากภายนอก
Nagios Log Server ใช้ในการตรวจสอบระบบและความปลอดภัยในองค์กรขนาดใหญ่
API key แบบ plaintext สามารถใช้เข้าระบบโดยไม่ต้องผ่านการยืนยันตัวตน
Elasticsearch เป็นระบบจัดเก็บและค้นหาข้อมูลล็อกแบบเรียลไทม์
การหยุด Elasticsearch อาจทำให้ทีมรักษาความปลอดภัย “ตาบอด”
ช่องโหว่แบบนี้สามารถใช้ร่วมกับการโจมตีอื่นเพื่อปกปิดร่องรอย
https://securityonline.info/critical-nagios-flaw-cve-2025-44823-cvss-9-9-leaks-plaintext-admin-api-keys-poc-available/
นักวิจัยด้านความปลอดภัยได้เปิดเผยช่องโหว่ระดับวิกฤตใน Nagios Log Server ซึ่งเป็นระบบจัดการล็อกที่นิยมใช้ในองค์กรขนาดใหญ่ โดยช่องโหว่นี้มีรหัส CVE-2025-44823 และได้รับคะแนนความรุนแรง CVSS สูงถึง 9.9 เต็ม 10 ซึ่งถือว่า “Critical” เพราะเปิดโอกาสให้ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำ ก็สามารถดึงข้อมูลผู้ใช้ทั้งหมดรวมถึง API key ของผู้ดูแลระบบในรูปแบบ plaintext ได้ทันที
ช่องโหว่นี้อยู่ใน endpoint /nagioslogserver/index.php/api/system/get_users ซึ่งเมื่อเรียกใช้งานด้วย token ที่ถูกต้อง ระบบจะตอบกลับเป็น JSON ที่มีข้อมูลผู้ใช้ทั้งหมด รวมถึงชื่อ อีเมล และ API key แบบไม่เข้ารหัส เช่น "apikey": "dcaa1693a79d651ebc29d45c879b3fbbc730d2de" ซึ่งสามารถนำไปใช้แอบอ้างเป็นผู้ดูแลระบบได้ทันที
ผลกระทบคือผู้โจมตีสามารถเข้าควบคุมระบบ Nagios Log Server ได้เต็มรูปแบบ เช่น เปลี่ยนการตั้งค่า เข้าถึงข้อมูลล็อกที่ละเอียดอ่อน หรือแม้แต่ลบข้อมูลเพื่อปกปิดร่องรอยการโจมตีอื่น ๆ
นอกจากนี้ยังมีช่องโหว่ CVE-2025-44824 ซึ่งอนุญาตให้ผู้ใช้ที่มีสิทธิ์แค่ read-only สามารถหยุดบริการ Elasticsearch ได้ผ่าน endpoint /api/system/stop?subsystem=elasticsearch โดยระบบจะตอบกลับว่า “error” ทั้งที่จริงแล้ว Elasticsearch ถูกหยุดไปแล้ว ทำให้ผู้ดูแลเข้าใจผิด และอาจถูกใช้โจมตีแบบ DoS เพื่อปิดระบบตรวจสอบแบบเรียลไทม์
Nagios ได้ออกแพตช์ในเวอร์ชัน 2024R1.3.2 ซึ่งแก้ไขทั้งสองช่องโหว่ โดยจำกัดการเข้าถึงข้อมูลผู้ใช้ และเพิ่มการตรวจสอบสิทธิ์ก่อนอนุญาตให้ควบคุมบริการ พร้อมปรับข้อความตอบกลับให้ตรงกับสถานะจริง
ข้อมูลสำคัญจากข่าว
ช่องโหว่ CVE-2025-44823 เปิดเผย API key ของผู้ดูแลระบบในรูปแบบ plaintext
อยู่ใน endpoint /api/system/get_users ของ Nagios Log Server
ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำก็สามารถดึงข้อมูลได้
JSON ที่ตอบกลับมีชื่อผู้ใช้ อีเมล และ API key แบบไม่เข้ารหัส
ช่องโหว่ CVE-2025-44824 อนุญาตให้หยุดบริการ Elasticsearch ด้วยสิทธิ์ read-only
ระบบตอบกลับว่า “error” ทั้งที่บริการถูกหยุดจริง
ส่งผลให้ระบบตรวจสอบแบบเรียลไทม์ถูกปิด และข้อมูลล็อกไม่ถูกบันทึก
Nagios ออกแพตช์ในเวอร์ชัน 2024R1.3.2 เพื่อแก้ไขช่องโหว่ทั้งสอง
แพตช์เพิ่มการตรวจสอบสิทธิ์และปรับข้อความตอบกลับให้ถูกต้อง
ข้อมูลเสริมจากภายนอก
Nagios Log Server ใช้ในการตรวจสอบระบบและความปลอดภัยในองค์กรขนาดใหญ่
API key แบบ plaintext สามารถใช้เข้าระบบโดยไม่ต้องผ่านการยืนยันตัวตน
Elasticsearch เป็นระบบจัดเก็บและค้นหาข้อมูลล็อกแบบเรียลไทม์
การหยุด Elasticsearch อาจทำให้ทีมรักษาความปลอดภัย “ตาบอด”
ช่องโหว่แบบนี้สามารถใช้ร่วมกับการโจมตีอื่นเพื่อปกปิดร่องรอย
https://securityonline.info/critical-nagios-flaw-cve-2025-44823-cvss-9-9-leaks-plaintext-admin-api-keys-poc-available/
🔓 “ช่องโหว่ร้ายแรงใน Nagios Log Server (CVE-2025-44823) — API Key หลุดแบบ plaintext เสี่ยงถูกยึดระบบทั้งองค์กร”
นักวิจัยด้านความปลอดภัยได้เปิดเผยช่องโหว่ระดับวิกฤตใน Nagios Log Server ซึ่งเป็นระบบจัดการล็อกที่นิยมใช้ในองค์กรขนาดใหญ่ โดยช่องโหว่นี้มีรหัส CVE-2025-44823 และได้รับคะแนนความรุนแรง CVSS สูงถึง 9.9 เต็ม 10 ซึ่งถือว่า “Critical” เพราะเปิดโอกาสให้ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำ ก็สามารถดึงข้อมูลผู้ใช้ทั้งหมดรวมถึง API key ของผู้ดูแลระบบในรูปแบบ plaintext ได้ทันที
ช่องโหว่นี้อยู่ใน endpoint /nagioslogserver/index.php/api/system/get_users ซึ่งเมื่อเรียกใช้งานด้วย token ที่ถูกต้อง ระบบจะตอบกลับเป็น JSON ที่มีข้อมูลผู้ใช้ทั้งหมด รวมถึงชื่อ อีเมล และ API key แบบไม่เข้ารหัส เช่น "apikey": "dcaa1693a79d651ebc29d45c879b3fbbc730d2de" ซึ่งสามารถนำไปใช้แอบอ้างเป็นผู้ดูแลระบบได้ทันที
ผลกระทบคือผู้โจมตีสามารถเข้าควบคุมระบบ Nagios Log Server ได้เต็มรูปแบบ เช่น เปลี่ยนการตั้งค่า เข้าถึงข้อมูลล็อกที่ละเอียดอ่อน หรือแม้แต่ลบข้อมูลเพื่อปกปิดร่องรอยการโจมตีอื่น ๆ
นอกจากนี้ยังมีช่องโหว่ CVE-2025-44824 ซึ่งอนุญาตให้ผู้ใช้ที่มีสิทธิ์แค่ read-only สามารถหยุดบริการ Elasticsearch ได้ผ่าน endpoint /api/system/stop?subsystem=elasticsearch โดยระบบจะตอบกลับว่า “error” ทั้งที่จริงแล้ว Elasticsearch ถูกหยุดไปแล้ว ทำให้ผู้ดูแลเข้าใจผิด และอาจถูกใช้โจมตีแบบ DoS เพื่อปิดระบบตรวจสอบแบบเรียลไทม์
Nagios ได้ออกแพตช์ในเวอร์ชัน 2024R1.3.2 ซึ่งแก้ไขทั้งสองช่องโหว่ โดยจำกัดการเข้าถึงข้อมูลผู้ใช้ และเพิ่มการตรวจสอบสิทธิ์ก่อนอนุญาตให้ควบคุมบริการ พร้อมปรับข้อความตอบกลับให้ตรงกับสถานะจริง
✅ ข้อมูลสำคัญจากข่าว
➡️ ช่องโหว่ CVE-2025-44823 เปิดเผย API key ของผู้ดูแลระบบในรูปแบบ plaintext
➡️ อยู่ใน endpoint /api/system/get_users ของ Nagios Log Server
➡️ ผู้ใช้ที่มี API token แม้จะเป็นระดับต่ำก็สามารถดึงข้อมูลได้
➡️ JSON ที่ตอบกลับมีชื่อผู้ใช้ อีเมล และ API key แบบไม่เข้ารหัส
➡️ ช่องโหว่ CVE-2025-44824 อนุญาตให้หยุดบริการ Elasticsearch ด้วยสิทธิ์ read-only
➡️ ระบบตอบกลับว่า “error” ทั้งที่บริการถูกหยุดจริง
➡️ ส่งผลให้ระบบตรวจสอบแบบเรียลไทม์ถูกปิด และข้อมูลล็อกไม่ถูกบันทึก
➡️ Nagios ออกแพตช์ในเวอร์ชัน 2024R1.3.2 เพื่อแก้ไขช่องโหว่ทั้งสอง
➡️ แพตช์เพิ่มการตรวจสอบสิทธิ์และปรับข้อความตอบกลับให้ถูกต้อง
✅ ข้อมูลเสริมจากภายนอก
➡️ Nagios Log Server ใช้ในการตรวจสอบระบบและความปลอดภัยในองค์กรขนาดใหญ่
➡️ API key แบบ plaintext สามารถใช้เข้าระบบโดยไม่ต้องผ่านการยืนยันตัวตน
➡️ Elasticsearch เป็นระบบจัดเก็บและค้นหาข้อมูลล็อกแบบเรียลไทม์
➡️ การหยุด Elasticsearch อาจทำให้ทีมรักษาความปลอดภัย “ตาบอด”
➡️ ช่องโหว่แบบนี้สามารถใช้ร่วมกับการโจมตีอื่นเพื่อปกปิดร่องรอย
https://securityonline.info/critical-nagios-flaw-cve-2025-44823-cvss-9-9-leaks-plaintext-admin-api-keys-poc-available/
0 Comments
0 Shares
23 Views
0 Reviews