エクスプロイト&脆弱性
Azure Machine Learning サービスに潜むセキュリティリスク - パート2
パート1では、Azure Machine Learning（AML）サービスで作成されたコンピュートインスタンス（CI）上で、認証情報がプレーンテキストで保存・記録される脆弱性とリスクについて解説しました。本稿のパート2では、AMLサービスで使用されるクラウドエージェントの情報漏えい関連の脆弱性を取り上げ、エージェントの機能を脅威モデリングすることの重要性と明らかにされたアタックサーフェスについて解説します。
パート1では、Azure Machine Learning（AML）サービスで作成されたコンピュートインスタンス（CI）上で、認証情報がプレーンテキストで保存・記録される脆弱性とリスクについて解説しました。本稿のパート2では、AMLサービスで使用されるクラウドエージェントの情報漏えい関連の脆弱性を取り上げ、エージェントの機能を脅威モデリングすることの重要性と明らかにされたアタックサーフェスについて解説します。
Azure Machine Learning (AML) では、コンピュートインスタンス（CI）とコンピュートクラスタを仮想ネットワーク（vNet）内のサブネットに配置することが可能です。ユーザがこのためにコンピュートインスタンスを作成する際、既存のvNetのサブネットにコンピュートインスタンスが接続されますが、このvNetはAMLワークスペースと同じリージョン内に存在する必要があります。この設定により、ユーザは環境を公開することなくvNetを通じてコンピュートインスタンスにアクセスすることが可能となります。なお、トレーニング環境のセキュリティを確保するため、Microsoft社は、AMLデプロイメントをvNet内に配置することを推奨しています。
図2では、コンピュートインスタンスを作成する際にvNetを有効にするオプションが示されています。
クラウドリソースを保護するためには、攻撃者の視点から侵入の可能性を探ることが有益な場合があります。vNetはユーザのサブスクリプションに属しているため、以下のようなシナリオを想定できます。あるvNet上にAzure VMとコンピュートインスタンスが存在し、攻撃者がAzure VMを掌握した場合、コンピュートインスタンスに対してどのような攻撃を行うことが可能かというシナリオです。
今回の調査で特筆すべきは、ネットワーク隣接の攻撃者制御下にあるVMがAMLのコンピュートインスタンスと同じサブネット内に存在する場合です。このような状況では、攻撃者が認証なしでコンピュートインスタンス上で実行されているサービスに関する機密情報をリモートから取得できることが判明しました。この情報は、攻撃者がコンピュートインスタンス上での活動を監視し、水平移動・内部活動を行うために悪用される可能性があります。
さらなる詳細
Azure VM からコンピュートインスタンス のアクセス可能なポートを調査中、ポート46802に遭遇しました。さらにコンピュートインスタンスへのアクセスが可能だったため、このポートを公開しているプロセスも特定しました。このプロセスは「dsimountagent」と命名されています。AML は コンピュートインスタンス を管理するために特定のエージェントを使用し、これらはサービスとして動作します。全てのコンピュートインスタンスにデフォルトでこのエージェントがインストールされている点も注意すべきでしょう。前回のパート1では、2つのエージェントの設定ファイルにストレージアカウントのアクセスキーが保存されていることについて詳しく説明しました。なお、プロセス「dsimountagent」は「Azure Batch AI DSI Mounting Agent」というサービスに由来します。このバイナリは Golang （Go言語）で作成され、ストリップされていないためデバッグシンボルが含まれています。
このサービスやバイナリ自体に関する参照を探した結果、このエージェントは WALinuxAgent や Open Management Infrastructure など、以前に検討された他のエージェントとは異なり、オープンソースではないことがわかりました。IDA を使用してバイナリを調査している際に、「hosttools」パッケージの「dsi.StartApiService」という関数を確認しました。この関数が前述の API を公開しています。これらの API には認証なしでアクセスできることが判明しました。各エンドポイントを検証した結果、コンピュートインスタンス上で以下のような操作が可能であることが明らかになりました。
上記エンドポイントを検証した後、特にエンドポイント「services」が注目に値しました。以下のサービスAPIに問い合わせることで、攻撃者はコンピュートインスタンス上にインストールされているサービスのリストと状態を確認できます。
/ci-api/v1.0/services/
また、以下に問い合わせることで、サービスのログを閲覧できます。
/ci-api/v1.0/services//logs?limit=5000
例えば、SSHサービスの最新5000件のログエントリを閲覧するためには、ポート46802でコンピュートインスタンスにGETリクエストを送信し、以下のURIを使用します。
/ci-api/v1.0/services/ssh/logs?limit=5000
サービスログは、機密情報が記録されている場合を除き、通常はそれほど興味深い対象とは言えないかもしれません。本稿執筆時点で、私たちが把握していたのは単純な情報開示の脆弱性でした。これらのサービスログは、攻撃者が次の攻撃段階の計画と実行に先立って環境をより深く理解するのに役立つ可能性があります。以下、AMLデプロイメントにおけるこの情報開示バグの影響を示す具体例について説明します。
データサイエンティストや開発者の情報が閲覧可能
コンピュートインスタンスにインストールされたサービスを調査中、オープンソースプロジェクトのJupyterがサービスとして設置されていることがわかりました。Jupyterを利用すると、ユーザは何もインストールや設定することなく、ブラウザからコンピュートインスタンスにアクセスできます。
この状況は、AMLのすべてのコンピュートインスタンスに当てはまります（図8参照）。
Jupyterのログは注目に値します。Jupyterベースの端末（Jupyter Notebook、JupyterLab、ブラウザ組み込み端末）で実行されたsudoコマンドがサービスログに記録されていることが確認できました。データサイエンティストや開発者がJupyterのコンポーネントを使用して、機密情報、パスワード、トークン、認証情報を含むコマンドをコマンドラインで実行した場合、同じvNetのサブネット内のVMを制御している攻撃者が容易にこれらのコマンドに不正アクセスし、AML環境内で深刻な侵害や水平移動・内部活動につながる可能性があります。また、これらのログを利用して端末の作成や削除、Jupyterサーバへのコマンドラインパラメータ、ロードされた拡張機能などを特定することもできます。
この脆弱性を悪用した挙動は以下のとおりです。
この脆弱性は、攻撃者がユーザのコンピュートインスタンスで行われている操作を見ることができるため「MLSee」と名付けられ、トレンドマイクロのZDI（Zero Day Initiative）を通じてMicrosoft社に報告されました。また、この脆弱性はCVE-2023-28312として修正対応され、深刻度が「重要」の情報開示に分類されています。この脆弱性が修正された後、サービスは全てのインターフェースでリッスンせず、ポート44224でリッスンするnginxプロキシを通じてのみアクセスできることを確認しました。
結論
セキュリティリサーチャーたちは長い間、クラウドプロバイダーが使用するエージェントの脆弱性について報告してきました。これらのエージェントは、顧客が気づかないうちに顧客の環境にインストールされます。しかし、今回紹介した脆弱性は、そのタイプとも異なるようです。全てのコンピュートインスタンスにインストールされ、Microsoft社によって管理されている「dsimountagent」という名前のエージェントが存在しているものであり、コンピュートもMicrosoft社が管理するリソースであり、影響は、ユーザのサブスクリプションの範囲に限定されることもありません。
攻撃者がこの情報漏えい関連の脆弱性を悪用する攻撃やセキュリティ侵害が発生した場合、クラウド環境のセキュリティにおける共有責任の概念を考えると、境界はかなり曖昧となってしまいます。脆弱性「MLSee」が悪用された場合、クラウドネイティブのログは生成されないため、エンドユーザはこの脆弱性を最初に検出することはできないでしょう。
これら機密情報を扱うエージェントにさまざまな機能が追加されるにつれ、さらなる攻撃の可能性も増加しています。Microsoft社は、AMLにおけるvNetの使用についてベストプラクティスを推奨しています。安全な設定で攻撃シナリオを把握することで、サービス自体の脆弱性を明らかにすることが可能となります。クラウドサービスプロバイダー（CSP）が使用するエージェントの特徴から生じるセキュリティリスクを考慮し、これらのエージェントを適切に理解し、懸念される攻撃シナリオを検討しておくべきでしょう。
現在の複雑でダイナミックなクラウド環境では、ゼロトラストの原則がサイバーセキュリティにおける基本的なアプローチとして登場しています。ゼロトラストの本質は、アクセス要求を出所や場所に関係なく検証することにあります。この戦略は、「暗黙の信頼」を「常に検証すること」に置き換え、アタックサーフェスを最小化し、侵害が発生した場合の潜在的な被害を減らす環境を整備します。
ゼロトラストの枠組み内でも特定の脆弱性は依然として生じ得ます。特定の仮想マシン（VM）にいる攻撃者が、サブネット内でコンピュートインスタンス上のコマンドなどの機密情報に不正アクセスするシナリオがこのケースに該当します。この事例は、ゼロトラストのより強固な実装が、外部アクセスの試みだけでなく、環境内の水平移動・内部活動へも導入されるべき点を強調していると言えます。
参考記事：
Uncovering Silent Threats in Azure Machine Learning Service - Part 2
By: Nitesh Surana
翻訳：与那城 務（Core Technology Marketing, Trend Micro™ Research）