エクスプロイト&脆弱性
オブザーバビリティの流出：クラウドサービスのメトリクスに潜むリスク
Container Advisor（cAdvisor）は、オープンソースによるコンテナ監視ツールであり、クラウドサービスで広く使用されています。本ツールは、対象コンテナのネットワークI/OやディスクI/O、CPU利用率などのメトリクス（測定値）を記録、監視する機能を提供します。一方、設定に不備があると、機密性の高いPrometheusメトリクスや環境変数を、意図せずに公開させる危険性があります。本稿では、こうしたリスクに対する分析結果や発見事項の他、注意を要する危険な設定パターンについて解説します。
はじめに
クライドネイティブの環境では、その複雑な構成や、リソースが頻繁に自動削除される性質も相まって、稼動中のサービスを常に監視する必要があります。その監視性能を表す指標として、「オブザーバビリティ（observability）」が挙げられます。本指標は、ログやメトリクス、トレース情報をもとに、ある時点におけるシステムの状態をどれだけ細かく正確に測定できるかを示すものです。メトリクスは、環境内で実行される処理の内容や時刻を調べる際に役立つ情報であり、サイト信頼性エンジニアリング（SRE：Site Reliability Engineering）やセキュリティ運用（SecOps：Security Operations）のタスクで重宝されています。
コンテナの技術推進を目的とする財団「CNCF（Cloud Native Computing Foundation）」によると、一重に「監視」と言っても、その内容は多岐に渡ります。具体的には、各ノードにおけるディスク容量やCPU利用率、メモリ使用量などの細かな測定値から、システム上でトランザクションが実行された際に返される応答の精度や速度といった総合的な指標までを、幅広く含みます。
CNCFの卒業（graduated）プロジェクトである「Prometheus」は、メトリクスの採取、ルール式の評価、結果の表示を一定時間毎に行い、所定の条件を満たした場合にアラートを発する機能を有します。メトリクスは、アプリケーションが示す不審な挙動の原因を突き止める際に役立ちます。
例として、Webアプリケーションの動作が普段よりも明らかに遅く、その原因を突き止めようとしている状況を考えます。動作遅延の一般的な原因としては、リクエスト数の異常な増加などが挙げられます。ここでもし、リクエスト数に相当するメトリクスを取得できるのであれば、それが本当に遅延の原因であるかを判別し、サーバ増設による負荷分散といった対策を検討することも可能になるでしょう。
（出典：Prometheus）
図2の通りPrometheusは、登録済みのアプリケーションやエクスポータからメトリクスを収集、加工します。エクスポータは、外部システムから得たメトリクスをPrometheus側に伝達するライブラリやサーバに相当します。Prometheusがサポートするエクスポータは200を超え、その種別もデータベースからハードウェア、問題追跡システム、メッセージシステム、ストレージ、HTTPサーバ、API、ロギング・ソリューションに至るまで、多岐に及びます。こうして収集、加工されたメトリクスは、さまざまなルールに基づいて評価され、結果に基づいてアラート発信の判別が行われます。また、加工済みのメトリクスをユーザ側で視覚的に確認するツールとして、Webユーザインターフェース（UI）やGrafanaプロジェクトなどが提供されています。
Prometheusの公式GitHub wikiで述べられている通り、エクスポータは、特定ポートのエンドポイント「/metrics」上でメトリクスを公開します。一般的にこれらのメトリクスには、環境に関する平易なデータが含まれていると考えられています。
Prometheusのセキュリティガイドラインによると、メトリクスは機密データに該当しないものとされています。2018年にサイバーセキュリティ企業「Cure53」が実施したペネトレーションテストでは、情報流出の懸念事項「PRM-01-002」が指摘されました。これに対してPrometheusのチームは、当該の動作を仕様通りのものと結論付けました。一方、2022年にクラウドセキュリティ企業「Sysdig」が実施した調査では、インターネットに公開されたPrometheusインスタンスのリスクに関する指摘が上がりました。この結果、Prometheusのダッシュボードを公開する危険性については、コミュニティ内で認知されるようになりました。しかし、別のケースとして、エクスポータ側のメトリクス用エンドポイントを公開した場合のリスクについても、十分に認知されているでしょうか。2016年には、cAdvisorの公開ポートによってネットワーク・アタックサーフェス（攻撃対象領域）が拡大する可能性について、議論に上がりました。以上を踏まえて今回は、cAdvisorにおける危険な設定パターンや、その影響に関する検証を行いました。
cAdvisorの概要
Container Advisorの略称として記されるcAdvisorは、GoogleがGo言語によって開発したオープンソースのコンテナ監視ツールです。本ツールはデーモンとして動作し、起動中のコンテナに関するさまざまな情報を収集、集計、処理した上で、その結果を送信します。トレンドマイクロの調査、および一般公開されている資料に基づくと、cAdvisorは主にKubelets、Azure Machine Learning、Azure Kubernetes Service（AKS）の他、コンテナ監視を必要とするさまざまなサービスで使用されています。
cAdvisorの利用形態として、Prometheusの公式ガイドに従ってDockerコンテナの監視ソリューションを構築する方式や、Linuxホスト上にスタンドアローンのバイナリを起動する方式が挙げられます。以降、インターネットに公開されたcAdvisor用エンドポイントの分析結果について解説します。はじめに、cAdvisorをデフォルト設定で起動すると、Webユーザインターフェース（Web UI）がポート8080に公開されます。
Web UI
ユーザは、ポート8080を介してcAdvisorのWeb UIにアクセスできます。本Web UIは、下図のような外観を持ちます。
本Web UIは、主に下記の情報を提供します。
- cgroup（コントロールグループ）毎のメモリ制限
- 各cgroup内で起動しているプロセスの一覧情報（psコマンドの実行結果）
- リアルタイムによるCPU利用率
- リアルタイムによるネットワークI/O
- リアルタイムによるファイルシステム利用率
- Dockerのバージョン
- DockerのAPIバージョン
- カーネルのバージョン
- オペレーティングシステムのバージョン
- ホスト名
- 全コンテナイメージの名前
分析の結果、本Web UIは、ホスト内に存在する全コンテナイメージの一覧情報を含んでいることが判明しました。対象イメージの中には、紐づくコンテナが起動していないものも含まれます。特記事項として、本情報はWeb UI上に直接表示されるものではなく、後述のREST APIから取得できるものでもなく、ユーザ自身がWebリソースを解析することではじめて得られるものです。
REST API
Web UIは、各種情報の取得に際してREST APIを使用します。当該のREST APIについては、cAdvisorのGitHubリポジトリ内で述べられています（cAdvisor REST APIのバージョン1および2）。REST APIから取得可能なホスト情報を、下記に示します。
- コア数
- RAM容量
- ストレージ容量
- カーネルのバージョン
- オペレーティングシステムのバージョン
- Dockerのバージョン
- コンテナ名
- ネットワークおよびディスクのI/O
- クラウドプロバイダ
- cgroup毎にpsコマンドを実行した結果
- 監視対象の各サービスに属するcgroupの一覧
攻撃者の視点に立つと、こうした情報は、偵察活動の一環として標的の価値を判断する際に役立つものです。
エンドポイント「/metrics」から取得できる環境変数
cAdvisorが提供する起動オプション（フラグ）の中で特に目を引くものとして、以下が挙げられます。
--env_metadata_whitelist:
これは、コンテナから取得する環境変数の一覧をカンマ区切りで指定するものです。現状、本機能はDocker用ランタイムとcontainerdでのみサポートされています。
図7に示すように、本オプションを用いることで、メトリクスを含む環境変数をDockerコンテナから取得、監視できます。
上図のハイライト箇所が示すように、メトリクスとして記録される環境変数のラベル名は、以下から始まります。
container_env_
今回の場合、対象の環境変数名は「Hi」であるため、全体的なラベル名は、以下となります。
container_env_hi
一方、上図の左上では、以下の起動オプションとして「Hi」ではなく、頭文字の「H」のみが指定されています。それにも関わらず今回は、先頭部のみが一致（大文字、小文字を問わず）する環境変数「Hi」がメトリクスとして記録されました。
env_metadata_whitelist
従って、cAdvisorの実装仕様では、以下の起動オプションで指定した名前に「前方一致」する全ての環境変数が、記録対象として扱われます。
--env_metadata_whitelist
結果、ユーザが「AWS」という環境変数の監視を望んでいた場合でも、「AWS」から始まる全ての環境変数が記録されることになります。以上のことを実際に環境構築を行って確認されたい方は、こちらのDocker Compose用YAMLをご利用いただけます。なお、当該オプションの処理に該当するコードを調べたところ、確かに、前方一致で環境変数をピックアップする旨が記載されていました。
これまでに確認された事項を、下記にまとめます。
- メトリクス用エンドポイントには、環境変数を記録する機能がある。
- Web UIから抽出できる情報の中には、REST APIから取得できないものも含まれる。その代表例として、ホスト内に存在する全コンテナイメージのリストが挙げられる。当該イメージの中には、紐づくコンテナがまだ作成されていないものも含まれる。
- その他、ホストや稼働しているコンテナに関するさまざまな情報を取得できる。
Web UIのセットアップ時には、認証方式として「HTTPの基本認証」または「ダイジェスト・ベースの認証」を適用できます。しかし、デフォルト設定は「認証なし」であり、この場合、REST APIやメトリクス用エンドポイントが認証不要で公開されることとなります。
デフォルト設定、または特定の設定下で公開される情報の量を踏まえ、今回は、実際にインターネット上に公開されているcAdvisorを対象に非侵入形のスキャンを実施し、セキュリティ上の問題点がないかを調べました。その結果、機密情報が流出しかねないケースや、デフォルト設定に潜む危険性が浮上しました。以降、これらの点について詳しく解説します。
実際にインターネット上で公開されているcAdvisor
今回は、公開状態のcAdvisorインスタンスについて調べたいため、インターネット上で実際に公開されているcAdvisorのWeb UIを検索しました。検索条件として、タイトルに「cAdvisor - /」を含むWebサイトを指定しました。また、Shodanを含む複数のサーバ検索エンジンを利用しました。
クラウドプロバイダ
REST APIを用いることで、cAdvisorのインストール先となっているクラウドプロバイダに関する情報が得られます。現状では、AWS、Azure、GCEがサポート対象となっています。クラウドプロバイダに関する情報の取得元として、下記のファイルが挙げられます。
- /sys/class/dmi/id/bios_vendor
- /sys/class/dmi/id/product_version
- /sys/class/dmi/id/product_uuid
- /sys/class/dmi/id/sys_vendor
- /sys/class/dmi/id/product_name
- /etc/os-release
cAdvisorのバージョン
コア数
メモリ容量
公開されているcAdvisorインスタンスの中には、RAM容量が251GBに及ぶものも発見されました。確認した範囲において、これらのインスタンスは、本番レベルで稼動するシステムの一部と考えられます。さらに、コア数が200を超えるインスタンスも、少数ながら発見されました。こうした強力なcAdvisorインスタンスが公開されていると、それが攻撃者の目にとまり、不正な暗号資産マイニングの計算リソースとして付け狙われる可能性があります。
メトリクスとして公開される環境変数
各インスタンスがエンドポイント「/metrics」上で記録、公開している環境変数を調べたところ、下記が確認されました。
1. AWSのアクセスキーIDおよびシークレット・アクセスキー
2. AmazonのRelational Database Service（RDS）に使用される認証情報
3. Redisの認証情報
4. API鍵
5. Azureのサービス・プリンシパルに使用されるシークレット
環境変数は、アプリケーションの認証情報を共有する手段として広く使用され、ファイル保存よりも安全な方式と見なされがちです。しかし、cAdvisorのように環境変数を記録するサービスが同時稼動していると、リスクも増大します。先述の実演でも示した通り、環境変数は多くの場合、コンテナを開始するタイミングで初期化されます。トレンドマイクロでは以前にも、認証情報を環境変数に記録することによって生じるさまざまな危険性について、注意喚起を行ってきました。
影響
以上に挙げた経路で重要な情報が誤って公開された場合、攻撃者は、遠隔から下記の不正行為に及ぶ可能性があります。
- 偵察活動：攻撃者は、価値のある標的を選定する際の判断材料として、ホストに関するさまざまな情報を入手、利用する可能性があります。こうした情報の具体例として、稼動しているオペレーティングシステムやカーネルのバージョン、メモリ容量、ストレージ容量、Dockerのバージョン、cAdvisorのバージョン、起動しているプロセス一覧（psコマンドの実行結果）、クラウドプロバイダ（AWS、GCP、Azure）、コア数、稼動しているサービスの一覧、ネットワークI/O、ディスクI/Oなどが挙げられます。
- 環境変数の流出を突いた水平移動・内部活動、権限昇格：ユーザが先述の起動オプションによって環境変数をメトリクスに記録しようとした場合、意図しない形で機密情報までもが記録され、流出する可能性があります。こうした機密情報として、AWSの認証情報やPostgres/MySQL/Grafanaの管理者パスワード、API鍵（本調査で実際に確認されたように）などが挙げられます。当該情報を入手した攻撃者は、それを利用して初期アクセス、水平移動・内部活動、権限昇格を目論む可能性があります。
- コンテナレジストリの設定不備を突いたサプライチェーン攻撃：すでに述べたように、攻撃者は、リモートから認証なしで標的ホストのコンテナイメージ・リストを入手できる場合がある。これに乗じた攻撃者は、さらに、外部アクセスが可能なコンテナレジストリにも探りを入れる可能性がある。該当するコンテナレジストリに設定不備があれば、リスクの範囲はコンテナイメージにとどまらず、デプロイ済みアプリケーションを含めたサプライチェーンの全体に及ぶと考えられる。
- コンテナイメージに含まれる脆弱性の不正利用：コンテナイメージの内部に脆弱な機能やサービス（未知、既知と問わず）が含まれる場合、そこを攻撃者に突かれ、初期アクセスから水平移動・内部活動、権限昇格に至る各活動に利用される可能性がある。
問題の開示履歴
デフォルト設定下で重要情報が公開される危険性を確認した後、トレンドマイクロでは、当該の問題をゼロデイ・イニシアティブの課題「ZDI-24-369」として提起し、Google側に連絡しました。これを受けてGoogle側では2024年1月31日に、cAdvisorのGitHubドキュメント内で、本件に言及しました。
NOTE: The Web UI authentication only protects the /containers endpoint, and not the other cAdvisor HTTP endpoints such as /api/... and /metrics. Some of these endpoints can expose sensitive information, so it is not advised to expose these endpoints publicly.
（上記の訳）注意：Web UIの認証によって保護されるのは、エンドポイント「/containers」のみであり、cAdvisorによる他のHTTPエンドポイント（「/api/...」、「/metrics」など）は含まれません。こうしたエンドポイントの中には、機密情報を提供するものも含まれるため、外部に公開することは推奨されません。
セキュリティ対策
cAdvisorのインスタンスを保護する上で特に有効なセキュリティ対策を、下記に示します。
- 攻撃者に先んじてアタックサーフェス（攻撃対象領域）を狭める手段として、cAdvisorからは、下記オプションの利用が推奨されています。
- Web UIに対し、HTTPの基本認証またはダイジェストベースの認証を設定する（--http_auth_file、--http_auth_realm、--http_digest_file、--http_digest_realm）
- 不要なメトリクスを無効化する（--disable_metrics）
- デフォルトとは異なるポート番号（8080以外）を利用する（--port）
- 独自のメトリクス用エンドポイントを指定する（--prometheus_endpoint）
- メトリクスをインターネットに公開することについては、脅威モデルを踏まえた十分な熟慮と検討が行われた場合を除き、推奨されません。情報流出のリスクを抑え込む上では、Prometheusのダッシュボードやオンプレミスサーバ、クラウド環境だけではなく、メトリクス用エンドポイントを保護することが重要です。
参考記事：
Observability Exposed: Exploring Risks in Cloud-Native Metrics
By: Nitesh Surana
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）