Metabase 零時差漏洞已有人偷資料:自行託管管理員要即刻更新兼查 log
Tech News

Metabase 零時差漏洞已有人偷資料:自行託管管理員要即刻更新兼查 log

圖片:via iThome — https://www.ithome.com.tw/news/178029
TechLab 編輯部(譯)·

重設密碼 API 成入口,未登入攻擊者都可搶管理員權限

一個公開 API,足以打入成套數據系統

Metabase 已經推出 CVE-2026-72898 嘅修補;呢個漏洞評分係最高嘅 10.0,而且官方確認攻擊者已經實際用過。攻擊者唔使登入,亦唔使等管理員撳連結,只要連到有漏洞嘅 API,就可以向 Metabase 自己嘅應用資料庫注入 SQL,再搶到管理員權限。去到呢一步,佢可以改設定、攞走已儲存嘅資料庫憑證,亦可以讀取同匯出 Metabase 原本有權睇嘅資料。

Metabase 話,事件由 Metabase Cloud 遭人用未知漏洞攻擊 開始,團隊之後封鎖相關 endpoint,再搵出問題同推出修補。Metabase Cloud 客戶已由官方完成更新;真正要即刻郁手嘅,係自己用 Docker、JAR 或其他方式託管 Metabase,又畀外界連到服務嘅公司。就算後台冇刻意公開,reverse proxy、VPN 設定錯誤或者遺留測試環境,都可能令相關 API 出咗公網。

Metabase 官方安全更新文章嘅主圖

圖片:Metabase

v58 至 v63 要對清楚版本

官方現時列出六條要更新嘅版本線,最低安全版本分別係 x.58.24、x.59.21、x.60.17、x.61.11、x.62.9 同 x.63.5;當中 x 可對應開源版嘅 0.x 或 Enterprise 版嘅 1.x,例如 0.58.6 至少要升上 0.58.24。Metabase 指 v58 以下唔受今次漏洞影響,不過舊版本身會少咗其他保安修補,唔應該當成長期避險方法。暫時升唔到級,就先喺 proxy 或防火牆封鎖 /api/session/reset_password,但呢個只係臨時頂住。

Framework、Tally、Kilo Code 同 n8n 都報稱受影響

iThome 報道,Framework Computer、表單平台 Tally、Kilo Code 同 n8n 都向部分客戶交代過 Metabase 遭未授權存取。各間公司公開嘅範圍都唔相同:Anaconda 話部分 Kilo Code 用戶嘅 prompt 或姓名、電郵、帳單地址等資料可能曝光,暫時冇理由相信付款卡資料受影響;n8n 就確認攻擊者查到 136 筆姓名同電郵紀錄,當中 5 筆包含 bcrypt 密碼雜湊。Framework 同 Tally 嘅細節主要來自客戶收到嘅通知,總受影響人數同完整外洩範圍仍未有統一官方數字。

呢批事件反映,BI 工具一旦失守,攻擊者仲可能經原有連線存取背後嘅資料庫。Metabase 本身未必存放完整客戶資料,但通常持有資料庫查詢權限同連線憑證,dashboard 亦會顯示重要資料放喺邊,所以失守後嘅影響可以好大。公司或者 startup 如果貪方便,直接畀分析工具讀取正式環境大批資料表,漏洞嘅實際破壞力自然會大好多。

更新完,第一時間清 session 同查帳戶

裝好安全版本只係堵住入口,唔會自動踢走之前入侵成功嘅人。如果 /api/session/reset_password 曾經公開,Metabase 建議清除應用資料庫 core_session 表入面全部紀錄,強制所有使用者重新登入;跟住逐個檢查 API key,刪走唔認得嘅 key,再核對管理員名單、電郵、權限同近期改動。落手前最好先保留應用資料庫同相關 log 副本,否則清理期間可能一併抹走調查線索。

官方亦畀咗一組幾實用嘅 log 特徵:先有 POST /api/session/reset_password 回傳 400,緊接住 GET /api/user/current 回傳 200。如果喺 Metabase 應用 log、server ingress 或 reverse proxy log 見到呢個次序,官方話系統好可能已經失守。查嗰陣要對埋時間、來源 IP、user agent 同之後嘅查詢活動;冇見到亦唔代表一定安全,因為 log 保留期、proxy 設定同採集範圍都可能有缺口。

憑證要換,資料外洩範圍亦要逐層追

下一步係輪換所有連接資料庫嘅憑證,再查 Metabase activity、query history 同 data warehouse audit log,搵陌生查詢、大量讀取、異常匯出或者平時冇人掂嘅資料表。確認可疑時段後,要列清楚相關資料庫、schema、資料表同紀錄種類;如果查詢內容掂過 API token、客戶個人資料或其他登入資料,輪換同通報範圍亦要跟住擴大。單純改 Metabase 管理員密碼,處理唔到已俾人攞走嘅資料庫密碼。

今次最麻煩嘅位係攻擊發生喺修補推出之前,等更新通知先郁手已經可能太遲。自行託管 v58 至 v63 嘅團隊,而家應該當成一次可能已發生嘅入侵處理:先封入口同升級,再保留證據、清走存取權、輪換憑證,最後用幾層 log 對清楚資料有冇俾人攞過。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook