สรุปสั้น

หน่วยงาน CERT Polska ออกประกาศเตือนการโจมตีเมื่อวันที่ 5 กันยายน 2569 ว่าผู้โจมตีกำลังใช้ประโยชน์จากเราเตอร์ MikroTik ที่เปิดบริการเข้าถึงระยะไกลอย่าง SSH ออกสู่อินเทอร์เน็ต เพื่อเข้าควบคุมอุปกรณ์ในระดับผู้ดูแลระบบอย่างเต็มรูปแบบโดยไม่ต้องยืนยันตัวตนใด ๆ การโจมตีที่สำเร็จแล้วย้อนไปถึงอย่างน้อยวันที่ 2 กันยายน ขณะที่การทบทวนประกาศฉบับนี้ของ The Hacker News เมื่อวันที่ 6 กันยายน ไม่พบทั้งจำนวนเหยื่อและตัวตนของผู้โจมตี

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

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 6 กันยายน 2569 ว่า ผู้โจมตีกำลังใช้ประโยชน์จากเราเตอร์ MikroTik ที่เปิดบริการ SSH ให้เข้าถึงได้จากอินเทอร์เน็ต เพื่อยึดสิทธิ์ควบคุมระดับผู้ดูแลระบบอย่างสมบูรณ์โดยไม่ต้องยืนยันตัวตน ตามประกาศเตือนการโจมตีที่หน่วยงาน CERT Polska เผยแพร่เมื่อวันที่ 5 กันยายน

การโจมตีที่สำเร็จมีบันทึกย้อนไปถึงอย่างน้อยวันที่ 2 กันยายน ส่วนการทบทวนประกาศฉบับดังกล่าวของ The Hacker News เมื่อวันที่ 6 กันยายน ไม่พบทั้งตัวเลขจำนวนเหยื่อและข้อมูลระบุตัวผู้โจมตี ขณะที่ MikroTik ได้เผยแพร่อัปเดตความปลอดภัยพร้อมรายการรุ่น RouterOS ที่แก้ไขแล้ว โดย CERT ระบุว่าตัวแก้ดังกล่าวป้องกันการโจมตีที่สังเกตพบได้ และแนะนำให้ติดตั้งทันที จากนั้นจึงตามด้วยการตรวจสอบการเปลี่ยนแปลงการตั้งค่าที่ไม่ได้รับอนุญาต

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

The Hacker News ตรวจสอบช่วงเวอร์ชัน RouterOS ที่ CERT ระบุว่าได้รับผลกระทบเทียบกับรายการรุ่นแก้ไขของ MikroTik เมื่อวันที่ 6 กันยายน ได้ผลดังนี้ ช่วงตั้งแต่ 6.0.0 จนถึงต่ำกว่า 6.49.21 แก้ที่ 6.49.21 ผ่านรุ่นความปลอดภัยของ RouterOS 6, ช่วงตั้งแต่ 7.0.0 จนถึงต่ำกว่า 7.23.4 แก้ที่ 7.23.4 แต่แนะนำให้ใช้ 7.23.5 บนช่องทาง long-term, ช่วงตั้งแต่ 7.24 จนถึงต่ำกว่า 7.24.2 แก้ที่ 7.24.2 บนช่องทาง stable และสำหรับช่องทาง development ตัวแก้อยู่ที่ 7.25beta3 ซึ่ง CERT ไม่ได้ระบุช่วงเวอร์ชันของช่องทางนี้ไว้ในเอกสารเปิดเผย ทั้งนี้รุ่น 7.23.5 เป็นการแก้ปัญหาที่ถอยหลังของ IPv6 DHCP ซึ่งเกิดขึ้นใน 7.23.4 โดยยังคงตัวแก้ด้านความปลอดภัยไว้ครบ

ระหว่างที่ยังติดตั้งอัปเดตไม่ได้ CERT แนะนำให้ปิดบริการที่เปิดออกสู่ภายนอก หรือจำกัดการเข้าถึงให้เหลือเฉพาะเครือข่ายจัดการที่เชื่อถือได้ โดยเฉพาะ SSH, WWW/WWW-SSL และ bandwidth-test อีกทั้งยังแนะนำว่าอย่าเริ่มการเชื่อมต่อ TLS หรือใช้ไคลเอนต์ SSH ที่ติดมากับ RouterOS จากอุปกรณ์ที่ยังไม่ได้แพตช์ โดยย้ำว่าข้อจำกัดชั่วคราวเหล่านี้ครอบคลุมชุดช่องโหว่ในภาพกว้างกว่านั้น และไม่ใช่สิ่งที่ใช้แทนการอัปเดตได้

จุดที่ยังเป็นช่องว่างของข้อมูลคือ CERT เรียกการนำช่องโหว่ 2 รายการมาต่อกันที่รายงานไว้ว่า MikroTrick แต่เมื่อ The Hacker News เปรียบเทียบประกาศเตือนกับเอกสารเปิดเผยช่องโหว่ของ CERT เมื่อวันที่ 6 กันยายน กลับพบว่าไม่มีเอกสารใดระบุอย่างชัดเจนว่าช่องโหว่คู่ใดประกอบกันเป็นห่วงโซ่ที่สังเกตพบ และไม่มีคำอธิบายว่าทั้งสองรายการรวมกันแล้วมอบสิทธิ์ผู้ดูแลระบบได้อย่างไร นอกจากนี้บันทึกการเปลี่ยนแปลงของรุ่น 7.25beta3 ลงวันที่ 2 กันยายน ขณะที่รุ่นเบตาและรุ่นแก้ไขชุดแรกอื่น ๆ ถูกประกาศเมื่อวันที่ 3 กันยายน ซึ่ง The Hacker News เปรียบเทียบกับไทม์ไลน์การโจมตีของ CERT แล้วสรุปว่าวันที่เหล่านั้นไม่ได้ยืนยันว่ามีตัวแก้ให้สาธารณะใช้ก่อนการโจมตีหรือไม่ สถานะ zero-day จึงยังยืนยันไม่ได้ ทั้งนี้ The Hacker News ได้ติดต่อ CERT Polska และ MikroTik เพื่อขอความเห็นแล้ว

วิธีการโจมตี

สิ่งที่ยืนยันได้จากประกาศคือจุดตั้งต้นของการโจมตีคือบริการ SSH ของ RouterOS ที่เข้าถึงได้จากอินเทอร์เน็ต และผลลัพธ์คือสิทธิ์ควบคุมระดับผู้ดูแลระบบโดยไม่ต้องยืนยันตัวตน ส่วนกลไกระหว่างทางยังไม่ถูกเปิดเผย เพราะ CERT ไม่ได้ชี้ว่าช่องโหว่คู่ใดคือคู่ที่ถูกใช้จริง ผู้ดูแลระบบจึงไม่มีทางประเมินได้ว่าการปิดบริการใดบริการหนึ่งเพียงอย่างเดียวจะตัดห่วงโซ่ได้หรือไม่ ซึ่งเป็นเหตุผลที่คำแนะนำชั่วคราวของ CERT จึงกวาดครอบคลุมทั้ง SSH, WWW/WWW-SSL และ bandwidth-test พร้อมกัน แทนที่จะชี้ไปที่บริการเดียว

ร่องรอยที่ CERT ให้ไว้สำหรับการตรวจสอบย้อนหลังมี 2 อย่างที่ใช้ได้ทันที อย่างแรกคือบัญชีระดับสิทธิ์สูงชื่อกลุ่ม ops ที่โผล่ขึ้นมาโดยไม่มีที่มา และอย่างที่สองคือบันทึกการสร้างบัญชีที่มีสตริง ssh:-2@ ปรากฏอยู่ ซึ่งเป็นรูปแบบที่ไม่ควรเกิดจากการใช้งานปกติ

อีกกลไกหนึ่งที่ควรรู้จักคือสถานะ Flagged ตามคำอธิบายของ MikroTik RouterOS จะติดธงให้อุปกรณ์เมื่อการตรวจสอบตอนเริ่มระบบพบการตั้งค่าที่น่าสงสัย โดยระบบจะปิดการทำงานของรายการเหล่านั้นและจำกัดฟังก์ชันบางอย่าง หลังอัปเดตแล้วจึงควรตรวจล็อกและรันคำสั่ง /system/device-mode/print เพื่อดูสถานะดังกล่าว และแม้จะไม่มีคำเตือนใด ๆ ขึ้นมา ก็ยังต้องไล่ตรวจการตั้งค่าเพื่อหาผู้ใช้ที่ไม่รู้จัก สคริปต์แปลกปลอม และการเปลี่ยนแปลงอื่นที่ระบุที่มาไม่ได้อยู่ดี

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

ผลกระทบ

กลุ่มที่ได้รับผลกระทบคือผู้ที่รัน RouterOS แล้วเปิดพอร์ตจัดการออกสู่อินเทอร์เน็ต ซึ่งในทางปฏิบัติมักเป็นผู้ให้บริการอินเทอร์เน็ตรายย่อย ผู้ดูแลเครือข่ายหลายสาขาที่ต้องเข้าไปแก้ไขอุปกรณ์ปลายทางจากระยะไกล และองค์กรที่ใช้ MikroTik เป็นเราเตอร์ขอบเครือข่ายเพราะราคาถูกและยืดหยุ่น ส่วนอุปกรณ์รุ่นบ้านที่ยังคงกฎไฟร์วอลล์ค่าเริ่มต้นไว้จะปลอดภัยกว่าโดยปริยาย เพราะพอร์ตจัดการถูกบล็อกจากสาธารณะอยู่แล้ว

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

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

คำแนะนำ

  • อัปเดต RouterOS เป็นรุ่นที่แก้แล้วทันที ได้แก่ 6.49.21 สำหรับสาย 6, 7.23.4 ขึ้นไปสำหรับสาย 7 โดยแนะนำ 7.23.5 บนช่องทาง long-term เพราะแก้ปัญหา IPv6 DHCP ที่ถอยหลังใน 7.23.4 ไปด้วย และ 7.24.2 สำหรับช่องทาง stable โดยดาวน์โหลดจากหน้าดาวน์โหลดอย่างเป็นทางการของ MikroTik เท่านั้น
  • ระหว่างที่ยังอัปเดตไม่ได้ ให้ปิดบริการที่เปิดออกสู่ภายนอกหรือจำกัดให้เข้าถึงได้เฉพาะเครือข่ายจัดการที่เชื่อถือได้ โดยเฉพาะ SSH, WWW/WWW-SSL และ bandwidth-test และอย่าเริ่มการเชื่อมต่อ TLS หรือใช้ไคลเอนต์ SSH ที่ติดมากับ RouterOS จากอุปกรณ์ที่ยังไม่ได้แพตช์ — ทั้งหมดนี้เป็นมาตรการชั่วคราว ไม่ใช่สิ่งทดแทนการอัปเดต
  • หลังอัปเดตแล้ว ให้ตรวจล็อกและรัน /system/device-mode/print เพื่อดูสถานะ Flagged และไล่ตรวจการตั้งค่าหาผู้ใช้ที่ไม่รู้จัก สคริปต์ และการเปลี่ยนแปลงที่ระบุที่มาไม่ได้ แม้จะไม่มีคำเตือนขึ้นก็ตาม
  • ค้นหาสัญญาณที่ CERT ระบุไว้ 2 อย่าง คือบัญชีระดับสิทธิ์สูงกลุ่ม ops ที่โผล่มาโดยไม่มีที่มา และบันทึกการสร้างบัญชีที่มีสตริง ssh:-2@ อยู่ในนั้น
  • หากพบร่องรอยการถูกเจาะ ห้ามล้างสถานะ Flagged ก่อนเก็บหลักฐานให้เสร็จ จากนั้นแยกอุปกรณ์ออกจากเครือข่าย เก็บล็อกและการตั้งค่าไว้ก่อนรีเซ็ต แล้วคืนค่าโรงงานและสร้างการตั้งค่าขึ้นใหม่จากชุดที่ตรวจสอบแล้ว ห้ามคืนค่าจากไฟล์สำรองทั้งก้อนของอุปกรณ์ที่ต้องสงสัย และเปลี่ยนรหัสผ่าน กุญแจ และความลับทุกชิ้นที่ใช้อยู่
  • ทบทวนความจำเป็นของการเปิดพอร์ตจัดการออกสู่อินเทอร์เน็ตในระยะยาว โดยย้ายไปใช้ VPN หรือเครือข่ายจัดการแยกแทน เพราะเงื่อนไขตั้งต้นของการโจมตีรอบนี้คือการเข้าถึง SSH ได้จากภายนอก

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