4分で読めます
Metabase Cloudに存在するSQLインジェクションのゼロデイ脆弱性が、実際の攻撃で悪用されています。この脆弱性は、多くの下流組織にも影響を及ぼしかねない深刻な事態を招く可能性があります。
AI駆動型のビジネス分析ツールを提供するMetabaseは先週、自社のMetabase Cloudプラットフォームが、バージョン1.58以降に影響するゼロデイ脆弱性を悪用した攻撃者によって侵害されたことを明らかにしました。
MetabaseのCEOであるSameer Al-Sakran氏は、先週投稿したブログ記事の中で、「攻撃に使われたエンドポイントを即座にブロックし、その後速やかに脆弱性を特定してパッチを適用しました」と述べています。
この脆弱性には現時点でCVE識別子は付与されていませんが、MetabaseはCVSSスコアで最大深刻度となる10を割り当てています。GitHubに公開された関連アドバイザリによると、この脆弱性を悪用することでリモートの攻撃者はSQL文を注入し、Metabaseのアプリケーションデータベースに侵入して、インスタンスへの管理者権限を取得できてしまいます。
同社はアドバイザリの中で、「これにより攻撃者はアプリケーションの設定を変更したり、接続先データベースの認証情報を窃取したり、その接続を通じてアクセス可能なあらゆるデータを読み取り、さらにはデータをエクスポートしたりすることが可能になります」と説明しています。
しかし、このゼロデイ攻撃はMetabaseの顧客にとどまらず、それ以外の組織にも大きな影響を及ぼす可能性があります。
Metabase Cloudのゼロデイ脆弱性、影響を受けるのは誰か
Al-Sakran氏の投稿によれば、Metabase Cloudの顧客は自動的に修正版へアップグレードされているため、対応の必要はないとのことです。しかし、Metabaseインスタンスを自前でホスティングしており、/api/session/reset_passwordエンドポイントを公開インターネット上に露出させている顧客は、依然として攻撃を受ける可能性があります。
どれだけの数の顧客が影響を受けたのか、またこのゼロデイ攻撃がMetabase Cloudに限定されたものだったのか、それとも自前でホスティングされたオープンソース版のインスタンスも侵害されたのかは、現時点では明らかになっていません。Dark ReadingはMetabaseに追加情報を求めて問い合わせましたが、本稿の締め切りまでに同社からの回答はありませんでした。
SANS Internet Storm CenterのJohannes Ullrich氏はDark Readingに対し、この攻撃が成立するためには脆弱なAPIエンドポイントに外部からアクセスできる状態になっている必要があると説明しています。「Metabaseは、Dockerコンテナとしても、また単体のJavaアプリケーションとしてもインストールできます。いずれの方法であっても、APIはポート3000でネットワークに公開されます」と同氏は述べています。「ポート3000にアクセスできるかどうかは、ネットワークファイアウォールが設定されているかどうかに左右されます」
Ullrich氏は、個々のAPIエンドポイントを制限するにはより細かい単位でのプロキシ設定が必要になるとみられることから、大半のユーザーは個別のエンドポイントを制限するのではなく、インスタンス自体を公開する形をとっていたのではないかと推測しています。同氏は「パスワードリセットAPIをユーザーが必要とする場面もあり得るため、これを公開しない明白な理由は特にありません」と語ります。
SQLインジェクションの脆弱性は、世界中で最も一般的で、なおかつ厄介なソフトウェアの欠陥の一つであり、OWASP Top 10のリストで常に上位に挙がっています。Ullrich氏はこのゼロデイ脆弱性について、「あえて特筆すべき点を挙げるとすれば、今日に至ってもなお私たちはSQLインジェクションの欠陥と戦い続けているという事実そのものでしょう」と語ります。
同氏の説明によると、今回のケースでは、Metabaseのデータベースアプリケーションにおけるごく単純な問題が原因になっているといいます。
「Metabaseはどうやら、この問題を解決できるはずのプリペアドステートメントを使用していないようです。とはいえ、Metabaseのようなソフトウェアがプリペアドステートメントを効果的に活用するのは難しい場合があります」と同氏は述べています。「これを使うと、同社が対応している幅広い種類のデータベースをサポートすることがより難しくなりますし、Metabaseのようなツールにとっては実装そのものも困難なのです」
Metabase攻撃がもたらす影響範囲
Ullrich氏の指摘によれば、Metabaseは幅広い種類のSQLデータベースからデータを処理するためのフロントエンドとして機能しています。そのため、Metabase Cloudが侵害されたことに加え、把握しきれていない数の自前ホスティング型インスタンスも侵害された可能性があることを踏まえると、攻撃者はかなりの量の機密データにアクセスできる状態にあり、それがMetabaseの顧客だけでなく、その顧客のさらに下流にいる顧客に対する二次攻撃に悪用されるおそれがあります。
今回のMetabase攻撃による被害はすでに複数明らかになっています。例えば、ワークフロー自動化を専門とするスタートアップ企業n8nは8月8日、自前ホスティング版とn8n Cloud版の両方のユーザーについて、氏名とメールアドレスを含む顧客レコード136件が攻撃者によって取得されたことを公表しました。
n8nによると、これらのレコードのうち5件にはクラウドアカウントのbcryptハッシュ化パスワードが含まれており、さらに別の25件のアカウントについては、過去に修正済みの脆弱性が原因で、パスワードが平文のまま保存されていたといいます。n8nは、これらのアカウントが今回の攻撃で実際にアクセスされた可能性は「低い」としながらも、念のためこの25件のアカウント保有者には個別に連絡を取ったとしています。
オープンソースのAIコーディングエージェントを手がけるスタートアップ企業Kilo Codeも、今回のMetabaseゼロデイ攻撃による被害を受けました。同社は8月7日の公表の中で、Metabase Cloudの侵害は8月2日に発生し、約4時間にわたって続いたこと、その間に攻撃者が「Kiloの一部ユーザーの氏名、メールアドレス、その他のデータ」を含む顧客レコードにアクセスしたことを明らかにしています。
8月9日に公開された続報の中でKiloは、今回の侵害に関する調査の結果、同社のSlackbotも影響を受けており、この機能を利用していた「Kiloユーザーの一部」のSlackアクセストークンが露出していたことが判明したと発表しました。同社は「万全を期すため、これらユーザーのKilo Slackbot認証トークンをすべて無効化しました。影響を受けたKilo Slackbotユーザーには個別に連絡しています」と述べています。
Metabaseは、自前ホスティング型インスタンスを利用している顧客に対し、「できるだけ早く」修正版のプラットフォームへアップグレードするよう強く呼びかけています。パッチを適用できない場合は、/api/session/reset_passwordエンドポイントをブロックすべきだとしています。
エンドポイントが外部に露出していた組織に対し、Metabaseはインシデント対応策として、アクティブな全ユーザーセッションの無効化、すべてのAPIキーの確認と身に覚えのないキーの削除、プラットフォームに接続されている全データベースの認証情報のローテーションなど、複数の対策を推奨しています。
翻訳元: https://www.darkreading.com/vulnerabilities-threats/metabase-sql-zero-day-attacks-wide-blast-radius