【ITニュース解説】Grafana's SQL Expressions Reached DuckDB, and DuckDB Reaches the Filesystem

GrafanaのSQL Expressions機能に、深刻なセキュリティ上の脆弱性が発見された。この問題は「CVE-2024-9264」として識別され、Grafanaバージョン11.0.0から11.1.6、および11.2系の一部バージョンに影響を及ぼした。システムエンジニアを目指す皆さんにとって、このようなインフラ監視ツールの脆弱性は、システム全体のセキュリティを考える上で非常に重要な学びとなるため、詳しく解説する。

まず、Grafanaとは、様々なデータソースから情報を収集し、グラフやダッシュボードとして可視化する人気のオープンソース監視ツールだ。システムの状態を視覚的に把握するために多くの企業で利用されている。今回問題となった「SQL Expressions」機能は、ダッシュボード上で表示されるクエリの結果に対して、例えば「AとBの値を足し算する」といった簡単な算術演算を行うためのものだった。一見すると無害な機能に思える。

しかし、この機能の内部実装に落とし穴があった。GrafanaはSQL Expressionsの処理に、自ら解析を行うのではなく、「DuckDB」という別のデータベースエンジンをバンドルして利用していたのだ。DuckDBは、ファイルシステムへの読み書きや拡張機能のロードといった高度な機能を、SQLクエリを通じて実行できる分析データベースエンジンである。問題は、Grafanaがユーザーから受け取ったSQL式を、検証を十分にせずにこのDuckDBバイナリにそのまま渡していた点にあった。

この脆弱性が悪用されると、何が起こるのだろうか。攻撃者は、Grafanaのシステムに認証されたユーザーであれば、最も低い権限である「Viewer」ロールしか持っていなくても、悪意のあるSQL式をSQL Expressions機能を通じてDuckDBに送信することができてしまう。その結果、DuckDBのファイルシステムアクセス機能が起動し、Grafanaサーバーが稼働しているシステム上の「任意のファイル」を読み取ることが可能になる。さらに、Grafanaプロセスが持つ権限によっては、ファイルの書き込みまで行えてしまう可能性もあった。

なぜ、ファイルの読み取りだけでも極めて危険なのか。一般的なシステムでは、権限のないユーザーによるファイル読み取りは比較的軽微な問題と見なされがちだ。しかし、監視サーバーであるGrafanaにおいては、それは致命的な情報漏洩に直結する。Grafanaが稼働しているサーバーには、通常以下のような機密情報が保存されているからだ。 例えば、データソース接続設定ファイルには、データベースへの接続文字列や、クラウドサービスや他のシステムにアクセスするためのAPIトークンが、平文（暗号化されていない状態）で記述されていることが多い。また、Grafana自身のデータベースファイルには、ユーザーアカウント情報、さらにはGrafana自身のAPIキーやダッシュボードの定義などが含まれている。Kubernetesのようなコンテナ環境でデプロイされている場合、環境変数として渡されるシークレット情報や、クラスタAPIへの認証トークンなども読み取られる可能性がある。さらに、クラウド環境であれば、インスタンスのメタデータサービスを通じてクラウド環境の認証情報にアクセスされる危険性もある。 これらの情報が漏洩すれば、攻撃者はデータソースへの不正アクセス、他のシステムへの侵入、さらにはクラウド環境全体を乗っ取る足がかりを得てしまうことになる。ファイル読み取りからシステム全体への影響は「トークンからセッションへ」「接続文字列からデータウェアハウスへのアクセスへ」「サービスアカウントからコンテナの完全制御へ」と、数珠つなぎに深刻な事態へと発展しかねない。実際に、この脆弱性の情報が公開された後、すぐに一般に悪用可能な「Proof-of-Concept (PoC)」コードが出回ったため、攻撃の敷居が非常に低かった点も、事態を深刻にした。

この脆弱性が悪用されるための条件は二つあった。一つは「SQL Expressions機能が有効になっていること」。もう一つは「DuckDBバイナリがGrafanaサーバーのプロセス検索パス上に存在すること」だ。これらの条件は、常に満たされるわけではないが、多くの環境で容易に満たされうる設定であるため、単にGrafanaのバージョン番号だけでは、そのインスタンスが脆弱であるかを判断できなかった。 そして、この問題の根本的な原因は、Grafanaがユーザー入力を自ら厳密に検証せず、外部のデータベースエンジンに処理を委ねていた点にある。入力値の検証をGrafanaのコードベース内でどれだけ強化しても、フル機能のSQLを解釈できる外部プロセスに文字列を渡している限り、その外部プロセスが持つファイルシステム操作機能などを悪用される可能性は残るのだ。

実は、Grafanaではこのような外部連携に起因するセキュリティ問題は以前から発生している。Grafanaは、その設計上、多くの異なるシステムと連携し、外部への接続を行ったり、設定ファイルを読み込んだりする「統合ハブ」としての役割を担っている。このような特性を持つ製品では、小さなバグであっても、認証情報の漏洩やシステムへの不正アクセスといった重大なセキュリティリスクに繋がりやすいのだ。過去にも、SQL Expressions関連のリモートコード実行（RCE）脆弱性や、画像レンダリング機能を通じたRCE、特定の機能による任意のローカルファイル読み取りなど、類似の深刻な脆弱性が複数報告されている。

あなたのGrafanaインスタンスがこの脆弱性の影響を受けるかどうかを確認し、対策を講じるためには、以下の点を見直す必要がある。 まず、「Expressions機能」が現在有効になっているかを確認する。多くの環境では、一部のチームのために有効にされた後、見直されることなく放置されているケースがあるからだ。次に、DuckDBバイナリがGrafanaプロセスの検索パス上に存在するか、そしてGrafanaサービスアカウントがファイルシステム上のどこかにファイルを書き込む権限を持っているかを確認する。 もし脆弱性が存在した期間があった場合、Viewer権限を持つユーザーがサーバーファイルを読む能力を持っていた可能性を考慮し、その間にプロビジョニング設定やデータソース設定でアクセス可能なトークンがないかを確認する。もし漏洩の可能性がある場合は、それらのトークンを速やかに変更（ローテーション）することが不可欠だ。さらに、脆弱性露呈期間中にGrafanaのポッドから予期せぬ外部への接続が発生していないか、ネットワークログなどを確認することも重要になる。

最終的な解決策としては、もちろんパッチが適用された最新のリリースにアップグレードすることが第一だ。しかし、それだけでなく、今後の同様の脆弱性に備えるための根本的なセキュリティ強化策を講じるべきである。これは、監視サーバーであるGrafanaを単なるダッシュボードではなく、「重要な認証情報ストア」として扱い、厳重に管理するという考え方に基づいている。具体的には、データソースのシークレット（秘密情報）を、Grafanaの設定ファイルに直接記述するのではなく、専門のシークレットマネージャーで管理し、実行時に必要な期間だけ取得するような運用に切り替える。また、コンテナ化されているGrafanaインスタンスの場合、コンテナのファイルシステムからファイル書き込み権限を削除し、不必要なアクセスをブロックする。さらに、ネットワークレベルでクラウドインスタンスのメタデータへのアクセスを拒否したり、Grafanaが外部に接続できる宛先を、実際にクエリする特定のデータソースのみに制限したりすることも効果的だ。これらの対策は、今回のような特定のCVE（脆弱性）が公開されるのを待つのではなく、将来、必ず発生するであろう新たなファイル読み取り系の脆弱性に対して、その「被害範囲」を最小限に抑えるための本質的な防御策となる。