กลับไปหน้าข่าวสาร

N-able เตือนช่องโหว่ N-central ถูกใช้โจมตีจริง แพตช์เดิมแก้ไม่ครบถ้วน (CVE-2026-18577)

แชร์:

N-able แจ้งเตือนลูกค้าว่าผู้ไม่ประสงค์ดีกำลังใช้ประโยชน์จากช่องโหว่ Authentication Bypass ใน N-central แพลตฟอร์ม Remote Monitoring and Management (RMM) ที่ Managed Service Provider (MSP) และทีม IT ใช้บริหารจัดการเครื่องของลูกค้าเป็นวงกว้าง โดยช่องโหว่ล่าสุดนี้เป็นผลจากการแพตช์ช่องโหว่ก่อนหน้าที่ไม่สมบูรณ์ ทำให้ผู้โจมตียังคงเจาะระบบได้ต่อเนื่อง


ที่มาของช่องโหว่: แพตช์เดิมแก้ไม่ครบถ้วน


CVE-2026-18577 เป็นช่องโหว่ประเภท Authentication Bypass Using an Alternate Path or Channel ซึ่งเป็นผลพวงจากการแก้ไขช่องโหว่ก่อนหน้าคือ CVE-2026-18576 ที่ไม่สมบูรณ์ ช่องโหว่เดิมกระทบ N-central ทุกเวอร์ชันจนถึง 2026.1 ขณะที่ช่องโหว่ใหม่นี้กระทบทุก Build ที่เก่ากว่า 2026.3.1.7


N-able เปิดเผยเมื่อวันที่ 1 สิงหาคม 2026 ว่าตรวจพบการโจมตีจริงกระทบทั้งลูกค้าที่ใช้บริการแบบ Hosted และแบบ On-premises


กลไกการโจมตี


เมื่อผู้โจมตีเข้าควบคุม N-central Server ได้สำเร็จในสิทธิ์ผู้ดูแลระบบผ่านช่องโหว่นี้ จะดำเนินการต่อดังนี้:


  1. ใช้ฟีเจอร์ Take Control ที่มีอยู่แล้วในตัวระบบ N-central เพื่อขยับต่อไปยัง Endpoint ของลูกค้าที่ถูกบริหารจัดการผ่าน Server นั้น
  2. ลงทะเบียน Cloudflare Tunnel เป็น Service บนเครื่อง Endpoint ที่เข้าถึงได้ เนื่องจาก Cloudflare Tunnel เชื่อมต่อออกไปยัง Edge ของ Cloudflare โดยตรง จึงไม่จำเป็นต้องเปิด Port หรือกฎ Firewall ขาเข้าใดๆ เลย
  3. การรัน Tunnel เป็น Service ทำให้ช่องทางนี้ยังคงทำงานต่อเนื่องได้แม้เครื่อง Endpoint จะถูก Restart แล้วก็ตาม เป็นกลไก Persistence ที่มีประสิทธิภาพและตรวจจับได้ยาก


ระบบที่ได้รับผลกระทบ


  • N-central ทุกเวอร์ชันที่เก่ากว่า Build 2026.3.1.7 ทั้งแบบ Hosted และ On-premises
  • CISA เพิ่มช่องโหว่นี้เข้าบัญชี Known Exploited Vulnerabilities (KEV) แล้ว หลังยืนยันพบลูกค้าถูกโจมตีจริง


ผลกระทบที่อาจเกิดขึ้น


  1. ผู้โจมตีเข้าควบคุม N-central Server ในสิทธิ์ผู้ดูแลระบบได้โดยไม่ต้องยืนยันตัวตน เปิดทางสู่การควบคุมระบบบริหารจัดการทั้งหมด
  2. ขยายผลกระทบไปยัง Endpoint ของลูกค้าที่ MSP บริหารจัดการอยู่ทั้งหมด ผ่านฟีเจอร์ Take Control ที่ถูกออกแบบมาเพื่อการดูแลระบบโดยชอบธรรม แต่ถูกนำมาใช้ในทางที่ผิด
  3. สร้างช่องทาง Persistence ที่หลบเลี่ยง Firewall แบบดั้งเดิมได้อย่างสมบูรณ์ เนื่องจาก Cloudflare Tunnel ไม่ต้องเปิด Port ขาเข้า ทำให้ตรวจจับด้วยการมอนิเตอร์ Firewall Rule แบบเดิมได้ยาก
  4. ความเสี่ยงกระจายเป็นวงกว้างในลักษณะ Supply Chain เนื่องจาก MSP รายเดียวดูแลลูกค้าหลายองค์กร การโจมตี N-central Server เพียงจุดเดียวจึงอาจกระทบลูกค้าปลายทางจำนวนมากพร้อมกัน


สิ่งที่องค์กรควรทำ


  1. อัปเดต N-central เป็น Build 2026.3.1.7 หรือใหม่กว่าโดยเร็วที่สุด ลูกค้า Hosted จะได้รับอัปเดตอัตโนมัติ แต่ลูกค้า On-premises ต้องดำเนินการติดตั้งด้วยตนเอง
  2. ตรวจสอบ Cloudflare Tunnel หรือ Service แปลกปลอมที่ถูกลงทะเบียนไว้บน Endpoint ที่บริหารจัดการผ่าน N-central ทั้งหมด โดยเฉพาะ Service ที่ไม่ตรงกับ Baseline ปกติ
  3. ตรวจสอบ Log การเข้าถึง N-central Server ย้อนหลังหาสัญญาณ Take Control ที่ผิดปกติ โดยเฉพาะ MSP ที่ดูแลลูกค้าหลายรายควรตรวจสอบให้ครอบคลุมทุก Tenant
  4. แจ้งเตือนลูกค้าปลายทางที่ใช้บริการผ่าน MSP ที่ใช้ N-central ให้ทราบความเสี่ยงและร่วมตรวจสอบ Endpoint ของตนเองด้วย


แนวทางลดความเสี่ยงระยะยาว


1. จำกัดการเข้าถึง N-central Management Interface ให้เหลือเฉพาะเครือข่ายที่จำเป็น

ลดพื้นผิวการโจมตีจากภายนอกที่สามารถเข้าถึง Authentication Endpoint ของระบบได้โดยตรง


2. เพิ่ม Multi-Factor Authentication สำหรับบัญชีผู้ดูแลระบบของแพลตฟอร์ม RMM

เพื่อเพิ่มชั้นการป้องกันแม้ในกรณีที่ช่องโหว่ Authentication Bypass ยังไม่ถูกค้นพบหรือแก้ไข


3. ตรวจสอบ Baseline ของ Service และ Scheduled Task บน Endpoint ที่บริหารจัดการผ่าน RMM เป็นประจำ

เพื่อให้สามารถตรวจจับ Service แปลกปลอมอย่าง Cloudflare Tunnel ที่ถูกเพิ่มเข้ามาโดยไม่ได้รับอนุญาตได้อย่างรวดเร็ว


4. ประเมินความเสี่ยงของ Supply Chain จากผู้ให้บริการ RMM/MSP อย่างสม่ำเสมอ

เนื่องจากแพลตฟอร์ม RMM เป็นเป้าหมายที่มีมูลค่าสูงสำหรับผู้โจมตี ควรมีข้อตกลงด้าน Security Response Time และ Patch Management ที่ชัดเจนกับผู้ให้บริการ


วิเคราะห์ในมุมมองจาก TXEC


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


จุดที่ TXEC มองว่าน่ากังวลเป็นพิเศษคือกรณีนี้เป็นการแพตช์ครั้งที่สองสำหรับปัญหาเดียวกัน สะท้อนว่าการแก้ไขช่องโหว่ Authentication Bypass ในระบบที่ซับซ้อนอาจไม่ครอบคลุมทุกเส้นทางการโจมตีตั้งแต่ครั้งแรก องค์กรที่ใช้บริการผ่าน MSP ควรสอบถามผู้ให้บริการของตนโดยตรงว่าได้อัปเดต N-central เป็นเวอร์ชันล่าสุดแล้วหรือไม่ แทนที่จะรอให้ MSP แจ้งมาเพียงฝ่ายเดียว


รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า


[ แหล่งอ้างอิง: BleepingComputer, The Hacker News, Help Net Security, SecurityWeek, Huntress ]