หน้าแรก Storage Database เตือนภัยความปลอดภัยร้ายแรงขั้นสูงสุด! พบช่องโหว่ Metabase ถูกแฮกเกอร์โจมตีแล้ว

เตือนภัยความปลอดภัยร้ายแรงขั้นสูงสุด! พบช่องโหว่ Metabase ถูกแฮกเกอร์โจมตีแล้ว

Metabase ซอฟต์แวร์วิเคราะห์และแสดงผลข้อมูลยอดนิยม ได้ออกเตือนภัยความปลอดภัยระดับร้ายแรงที่สุด โดยได้รับคะแนนความเสี่ยง CVSS เต็ม 10.0 หลังพบว่าถูกผู้ไม่หวังดีฉวยโอกาสโจมตีผ่านช่องโหว่ที่ไม่เคยพบมาก่อน (Zero-day) ในการใช้งานจริงเรียบร้อยแล้ว โดยช่องโหว่นี้กระทบกับซอฟต์แวร์ตั้งแต่เวอร์ชัน 1.58 ขึ้นไป

อันตรายของช่องโหว่นี้เปิดโอกาสให้แฮกเกอร์ภายนอกสามารถส่งคำสั่งอันตราย (SQL Injection) เข้าสู่ฐานข้อมูลของ Metabase ได้โดยตรงโดยไม่ต้องผ่านการยืนยันตัวตนหรือล็อกอินเข้าสู่ระบบ ส่งผลให้ผู้โจมตีสามารถยึดสิทธิ์ระดับผู้ดูแลระบบ  ของอินสแตนซ์นั้นๆ ได้อย่างสมบูรณ์แบบ

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

สำหรับผู้ที่ใช้งาน Metabase Cloud ทางผู้พัฒนาได้ทำการอัปเดตระบบให้เป็นเวอร์ชันล่าสุดเพื่อปิดช่องโหว่แล้ว แต่ผู้ใช้งานแบบติดตั้งและดูแลระบบเองจำเป็นต้องตรวจสอบเวอร์ชันที่ได้รับผลกระทบตั้งแต่ x.58.0 ถึง x.63.3 และเร่งปฏิบัติตามแนวทางการรับมือทันที

  • อัปเดตระบบทันที: ดำเนินการอัปเดต Metabase ให้เป็นเวอร์ชันที่แก้ไขแล้ว (ได้แก่ x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 หรือ x.63.5 ขึ้นไปตามสายเวอร์ชันที่ใช้งาน)
  • บล็อกทางเข้าชั่วคราว: หากยังไม่สามารถอัปเดตระบบได้ทันที ให้ตั้งค่าปิดการเข้าถึง /api/session/reset_password ไว้ชั่วคราว
  • ตัดการเชื่อมต่อผู้ใช้ทั้งหมด: เข้าไปที่ฐานข้อมูลหลักของ Metabase แล้วลบข้อมูลในตาราง core_session ทั้งหมดเพื่อยกเลิกเซสชันที่ค้างอยู่
  • ตรวจสอบสิทธิ์และ API Key: ตรวจสอบรายชื่อผู้ดูแลระบบรวมถึง API Key ทั้งหมด แล้วทำการลบบัญชีหรือคีย์ที่แปลกปลอมออกทันที
  • เปลี่ยนรหัสผ่านฐานข้อมูล: ทำการหมุนเวียน (Rotate) หรือเปลี่ยนรหัสผ่านของฐานข้อมูลทั้งหมดที่เคยเชื่อมต่อไว้กับ Metabase
  • ตรวจสอบประวัติการใช้งาน: ตรวจสอบ Server Log เพื่อหาพฤติกรรมสุ่มเสี่ยง โดยเฉพาะการเรียก POST /api/session/reset_password (ตอบกลับ 400) ตามด้วย GET /api/user/current (ตอบกลับ 200) รวมถึงตรวจเช็กล็อกของ Data Warehouse หาการเข้าถึงที่ไม่ได้รับอนุญาต

ที่มา : THN