สรุปสั้น

บริษัท Metabase ออกประกาศเตือนว่าช่องโหว่ระดับรุนแรงสูงสุดในซอฟต์แวร์ business intelligence และแสดงผลข้อมูลของตนถูกนำไปใช้โจมตีจริงแล้วในฐานะซีโรเดย์ ช่องโหว่นี้ได้คะแนน CVSS 10.0 ซึ่งเป็นคะแนนเต็ม แต่ยังไม่ได้รับหมายเลข CVE กำกับ ลักษณะของช่องโหว่คือเปิดทางให้ผู้โจมตีระยะไกลที่ไม่ต้องยืนยันตัวตนแทรกคำสั่ง SQL ตามอำเภอใจลงในฐานข้อมูลของตัวแอปพลิเคชัน Metabase เอง ผลลัพธ์คือผู้โจมตีได้สิทธิ์ผู้ดูแลระบบของอินสแตนซ์นั้นไปเต็ม ๆ และเมื่อได้สิทธิ์ระดับนั้นแล้วก็สามารถเปลี่ยนค่ากำหนดของแอปพลิเคชัน ขโมย credential ที่เก็บไว้สำหรับเชื่อมต่อฐานข้อมูลปลายทาง อ่านข้อมูลทุกอย่างที่มองเห็นผ่านการเชื่อมต่อเหล่านั้น และส่งออกข้อมูลได้ตามต้องการ

Metabase ระบุในคำแนะนำด้านความปลอดภัยว่า “เราเพิ่งตรวจพบว่า Metabase Cloud ถูกโจมตีโดยผู้ที่ใช้ช่องโหว่ที่ยังไม่เป็นที่รู้จัก หรือซีโรเดย์ ในเวอร์ชัน 1.58 ขึ้นไป” โดยอินสแตนซ์บน Metabase Cloud ได้รับการอัปเดตเป็นเวอร์ชันล่าสุดเรียบร้อยแล้ว ขณะที่ผู้ใช้ที่ติดตั้งระบบเองบนเซิร์ฟเวอร์ของตัวเองต้องรีบติดตั้งแพตช์ด้วยตนเองโดยด่วน บริษัทแนะนำมาตรการชั่วคราวให้บล็อก endpoint ชื่อ /api/session/reset_password ระหว่างรอแพตช์ และหนึ่งในองค์กรที่ได้รับผลกระทบคือบริษัท Framework ผู้ผลิตคอมพิวเตอร์แบบซ่อมเองได้ ซึ่งได้แจ้งลูกค้าทั้งหมดว่าข้อมูลบางส่วนถูกเข้าถึงในเหตุการณ์นี้

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 8 สิงหาคม พ.ศ. 2569 ว่า Metabase ได้ออกคำเตือนเกี่ยวกับช่องโหว่ระดับรุนแรงสูงสุดที่กระทบชุดซอฟต์แวร์ business intelligence และแสดงผลข้อมูลของบริษัท โดยยืนยันว่าช่องโหว่นี้ถูกใช้โจมตีจริงในลักษณะซีโรเดย์ กล่าวคือผู้โจมตีรู้และใช้ประโยชน์จากช่องโหว่ก่อนที่ผู้พัฒนาจะรับรู้และออกแพตช์

สิ่งที่ผิดปกติของกรณีนี้คือช่องโหว่ที่ได้คะแนน CVSS เต็ม 10.0 กลับไม่มีหมายเลข CVE กำกับ ทำให้การอ้างอิงและติดตามในระบบบริหารจัดการช่องโหว่ขององค์กรทำได้ยากกว่าปกติ ทีมที่ใช้ระบบตรวจสอบอัตโนมัติซึ่งอิงหมายเลข CVE เป็นหลักอาจไม่ได้รับการแจ้งเตือนใด ๆ จากช่องโหว่ตัวนี้เลย จึงต้องอาศัยการติดตามประกาศจากผู้ผลิตโดยตรง

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

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

Metabase ยังไม่เปิดเผยรายละเอียดใด ๆ เกี่ยวกับกิจกรรมของผู้โจมตี ไม่ว่าจะเป็นจำนวนอินสแตนซ์ที่ถูกเจาะ ช่วงเวลาที่การโจมตีเริ่มต้น หรือตัวตนของผู้ก่อเหตุ แต่ได้เผยแพร่ตัวบ่งชี้การถูกบุกรุกในรูปแบบของรูปแบบล็อกให้ผู้ดูแลระบบนำไปตรวจสอบเอง นายสมีร์ อัล-ซาคราน (Sameer Al-Sakran) ประธานเจ้าหน้าที่บริหารของ Metabase ระบุว่า “หากคุณพบรูปแบบดังกล่าวในล็อกของแอปพลิเคชันหรือในล็อก ingress ของเซิร์ฟเวอร์ Metabase มีความเป็นไปได้สูงว่าอินสแตนซ์ของคุณถูกบุกรุกแล้ว”

นี่ไม่ใช่ครั้งแรกที่ Metabase เผชิญช่องโหว่ระดับร้ายแรง เมื่อสามปีก่อนพอดีบริษัทเคยต้องเร่งแก้ช่องโหว่ที่ถูกอธิบายว่า “รุนแรงอย่างยิ่ง” อีกตัวหนึ่งคือ CVE-2023-38646 ซึ่งได้คะแนน CVSS 9.8 และอาจนำไปสู่การรันโค้ดจากระยะไกลบนระบบที่ติดตั้งไว้โดยไม่ต้องยืนยันตัวตนเช่นกัน

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

เวอร์ชันที่ได้รับผลกระทบครอบคลุมตั้งแต่รุ่น 1.58 ขึ้นไป โดย Metabase ระบุช่วงเวอร์ชันและรุ่นที่แก้ไขแล้วไว้ดังนี้ ตั้งแต่ x.58.0 จนถึงก่อน x.58.23 แก้ไขใน x.58.24 · ตั้งแต่ x.59.0 จนถึงก่อน x.59.20 แก้ไขใน x.59.21 · ตั้งแต่ x.60.0 จนถึงก่อน x.60.16 แก้ไขใน x.60.17 · ตั้งแต่ x.61.0 จนถึงก่อน x.61.10 แก้ไขใน x.61.11 · ตั้งแต่ x.62.0 จนถึงก่อน x.62.8 แก้ไขใน x.62.9 และตั้งแต่ x.63.0 จนถึงก่อน x.63.3 แก้ไขใน x.63.5

มาตรการชั่วคราวที่บริษัทแนะนำระหว่างรอติดตั้งแพตช์คือบล็อก endpoint /api/session/reset_password ซึ่งเป็นจุดที่ใช้ในการรีเซ็ตรหัสผ่าน การที่ endpoint นี้ถูกระบุเป็นทั้งจุดที่ต้องบล็อกและเป็นส่วนหนึ่งของรูปแบบตัวบ่งชี้การบุกรุก บ่งชี้ว่าเส้นทางการโจมตีเริ่มต้นที่จุดนี้

Metabase เผยแพร่ตัวบ่งชี้การถูกบุกรุกเป็นลำดับของคำขอสองรายการที่เกิดต่อเนื่องกัน คือการเรียก POST ไปยัง /api/session/reset_password ที่ได้รับสถานะตอบกลับ 400 ตามด้วยการเรียก GET ไปยัง /api/user/current ที่ได้รับสถานะ 200 รูปแบบนี้อ่านได้ว่าคำขอรีเซ็ตรหัสผ่านถูกปฏิเสธด้วยรหัสข้อผิดพลาด แต่ทันทีหลังจากนั้นผู้เรียกกลับสามารถดึงข้อมูลผู้ใช้ปัจจุบันได้สำเร็จ ซึ่งหมายความว่าผู้โจมตีมีเซสชันที่ใช้งานได้แล้วทั้งที่คำขอก่อนหน้าล้มเหลว

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

ผลกระทบ

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

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

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

คำแนะนำ

ผู้ที่ติดตั้ง Metabase เองควรอัปเดตเป็นเวอร์ชันที่แก้ไขแล้วตามรายการข้างต้นโดยทันที และหากยังทำไม่ได้ ให้บล็อก endpoint /api/session/reset_password ไว้ก่อนเป็นมาตรการชั่วคราว สำหรับลูกค้าที่เคยเปิด endpoint ดังกล่าวให้เข้าถึงได้จากสาธารณะ Metabase แนะนำให้ทำตามขั้นตอนต่อไปนี้หลังอัปเดตเสร็จ ได้แก่ เพิกถอนเซสชันผู้ใช้ที่ยังใช้งานอยู่ทั้งหมดด้วยการเข้าไปที่ฐานข้อมูลของแอปพลิเคชันแล้วลบทุกแถวในตาราง core_session · ตรวจสอบคีย์ API และลบคีย์ที่ไม่รู้จัก · ตรวจสอบบัญชีผู้ดูแลระบบว่ามีการเปลี่ยนแปลงที่ไม่ได้คาดหมายหรือไม่ · หมุนเวียน credential ของฐานข้อมูลทุกตัวที่เชื่อมต่ออยู่ · ตรวจสอบล็อกของคลังข้อมูลเพื่อหาร่องรอยการเข้าถึงโดยไม่ได้รับอนุญาต และตรวจสอบประวัติกิจกรรมและคำสั่งค้นหาใน Metabase เพื่อหาพฤติกรรมผิดปกติ

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

Indicators of Compromise (IoCs)

ตัวบ่งชี้ประเภทคำอธิบาย
POST /api/session/reset_password → สถานะ 400รูปแบบล็อกคำขอรีเซ็ตรหัสผ่านที่ถูกปฏิเสธ เป็นขั้นแรกของรูปแบบการโจมตี
GET /api/user/current → สถานะ 200รูปแบบล็อกคำขอที่ตามมาทันทีและสำเร็จ บ่งชี้ว่าผู้เรียกได้เซสชันที่ใช้งานได้แล้ว

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