- Wiz Researchは、SAP AI Coreのテナント分離の脆弱性チェーンを通じて、通常のAI学習ジョブから始まったコード実行が、サービス掌握と顧客の機密へのアクセスにつながり得ることを確認した
- 攻撃経路は、Istioのネットワーク制限の回避、Loki設定でのAWSトークン露出、認証のないEFS共有、認証のないHelm v2 Tillerアクセスが連鎖的に組み合わさる構造だった
- 取得した権限により、SAP内部Docker Registry、Google Container Registry、内部Artifactoryのイメージとアーティファクトを読み書きでき、Kubernetesクラスターのcluster-admin権限も取得できた
- 潜在的な攻撃者は、顧客のAWS、Azure、SAP HANA Cloudの認証情報や、モデル・データセット・コードといった非公開AI成果物にアクセスしたり、内部アーティファクトを汚染したりできる可能性があった
- SAPは報告されたすべての脆弱性を修正し、関連するシークレットをローテーションした。Wizは顧客データ侵害はなかったと述べている
SAP AI Coreで明らかになったテナント分離の問題
- Wiz ResearchはAIサービスプロバイダーのテナント分離を調査しており、SAP AI CoreはHugging Face、Replicateに続く3本目のレポートである
- SAP AI Coreは、ユーザーがSAPのクラウドリソース上でAIサービスを開発・学習・実行できるようにするマネージドサービスである
- AI学習サービスは大量の機密顧客データにアクセスする必要があり、SAP AI CoreはHANAや他のクラウドサービスとの連携のため、顧客内部データにアクセスするクラウドアクセスキーを使用している
- 調査は、基本権限を持つSAP顧客アカウントでAIプロジェクトを作成し、SAP AI Coreが許可するArgo WorkflowファイルでKubernetes Podを生成する形で始まった
- ユーザーは設計上Pod内で任意コードを実行できたが、初期環境ではIstioプロキシのサイドカーがネットワークアクセスを制限しており、内部ネットワークのスキャンは困難だった
Bug #1: Istio制限の回避
- SAPのadmission controllerは危険なセキュリティオプションをブロックしており、コンテナを
rootで実行しようとする試みも阻止していた - ブロックされていなかった2つの設定が、ネットワーク制限の回避につながった
shareProcessNamespaceはサイドカーコンテナとプロセス名前空間を共有させるため、Istioプロキシ設定と中央Istiodサーバーへのアクセストークンを参照できたrunAsUserとrunAsGroupはroot以外のUIDを許可しており、IstioのUIDである1337で実行できた
- Istio自体はIstio iptables規則から除外されるため、UID
1337で実行されたプロセスはトラフィック制限なしで動作した - その後、Istioトークンを使ってIstiodサーバーの設定を読み取り、内部環境の情報を取得できた
Bug #2: Loki設定でのAWSトークン露出
- クラスター内部でGrafana Lokiインスタンスを発見し、
/configエンドポイントへのリクエストで完全な設定を確認できた - 応答には、LokiがS3アクセスに使用するAWSシークレットが含まれていた
- このシークレットはLokiのS3バケットへのアクセス権を提供し、そのバケットにはAI Coreサービスログや顧客Podログが多数保存されていた
- SAPは、これらのログは機微ではないとみなしている
Bug #3: 認証のないEFS共有によるユーザーファイル露出
- 内部ネットワークでポート
2049を待ち受けるAWS Elastic File System、すなわちEFSインスタンスを6つ発見した - これらのEFSインスタンスは、ネットワークアクセスさえあれば認証情報なしでファイルを閲覧・編集できる状態だった
- オープンソースのNFSツールだけで共有内容に自由にアクセスできた
- EFSには、顧客IDごとに分類されたコードや学習データセットなど、大量のAIデータが保存されていた
Bug #4: 認証のないHelm Tillerが内部RegistryとArtifactoryを露出
- 内部ネットワークでHelm v2のサーバーコンポーネントであるTillerサービスを発見した
- Tillerはポート
44134のgRPCインターフェースで通信し、デフォルトで認証なしに露出していた - Tillerを調査した結果、SAP Docker RegistryとArtifactoryサーバーに対する高権限のシークレットが露出していた
- 読み取り権限では、内部イメージやビルドを読み出して商業機密や顧客データを抜き取ることができた
- 書き込み権限では、イメージやビルドを汚染してSAP AI Coreサービスに対するサプライチェーン攻撃を実行できた
Bug #5: Helm Tillerの書き込み権限によるKubernetesクラスター掌握
- Tillerは読み取りだけでなく書き込み操作も許可していた
installコマンドはHelmパッケージを受け取ってKubernetesクラスターにデプロイするため、研究チームはcluster-admin権限を持つ新しいPodを作成する悪意あるHelmパッケージを作成してインストールした- この過程でクラスターに対する完全権限を取得した
- この権限は、他の顧客のPodに直接アクセスしてモデル、データセット、コードのような機密データを盗めるレベルだった
- また、顧客Podを妨害したり、AIデータを汚染したり、モデル推論を操作したりすることもできた
- 同じ権限により、SAP AI Coreの範囲を超える顧客シークレットも平文で参照できた
- 研究チームのAI Coreアカウントには、S3データアクセス用AWSアカウントのシークレットがあった
- Data Lakeアクセス用SAP HANAアカウントのシークレットがあった
- イメージpull用Docker Hubアカウントのシークレットがあった
- 同じ調査で、Google Container Registry向けSAPアクセスキーである
sap-docker-registry-secretも確認され、このキーは読み取りと書き込みの両方の権限を提供していた
確認されたアクセス範囲と潜在的影響
- 脆弱性チェーンによって可能だった操作は次のとおりだった
- SAP内部コンテナRegistryのDockerイメージの読み取り・改変
- Google Container Registry上のSAP Dockerイメージの読み取り・改変
- SAP内部Artifactoryサーバーのアーティファクトの読み取り・改変
- SAP AI Core Kubernetesクラスターのcluster-admin権限取得
- 顧客クラウド認証情報と非公開AI成果物へのアクセス
- 潜在的な攻撃者は、顧客データにアクセスし、内部アーティファクトを汚染して関連サービスや他の顧客環境へ影響を拡大できる可能性があった
- すべての脆弱性はSAPセキュリティチームに報告され、SAPが修正した。SAPはこれをセキュリティ研究者クレジットページで認めている
- 顧客データは侵害されなかった
防御の観点で明らかになった問題
- 主な防御線はIstioが内部ネットワークアクセスを遮断する構造だったが、この障壁を回避した後は複数の内部資産が追加認証を要求しなかった
- 内部ネットワークが信頼された領域のように扱われ、1つの回避がサービス掌握へと拡大した
- 内部サービスが強化されていれば、攻撃の影響は完全なサービス掌握ではなく小規模なセキュリティインシデントに抑えられた可能性がある
- Kubernetesベースのマネージドサービスでは、コントロールプレーンと顧客コンピュートがAPI、ID、共有コンピュート、ソフトウェアベースのネットワーク分離によって論理的に結びつくため、テナント分離の落とし穴が生じ得る
- AI学習は本質的に任意コード実行を必要とするため、信頼できないコードが内部資産や他テナントから適切に分離されるようガードレールが必要である
公開スケジュール
- 2024年1月25日: Wiz Researchがセキュリティ上の発見をSAPに報告
- 2024年1月27日: SAPが回答し、ケース番号を割り当て
- 2024年2月16日: SAPが最初の脆弱性を修正し、関連シークレットをローテーション
- 2024年2月28日: Wiz Researchが2件の新たな脆弱性でパッチを回避し、SAPに報告
- 2024年5月15日: SAPが報告されたすべての脆弱性に対する修正を展開
- 2024年7月17日: 公開
1件のコメント
Hacker News の意見
AI製品であることは理解するが、ここでの脆弱性は k8s の設定にある
AI製品そのものやAI学習、機械学習、生成AIとはあまり関係がなく、不十分な クラウドプラットフォームのセキュリティに近い
「攻撃者が悪意あるAIモデルと学習手順を実行できたこと」が根本原因であり、これは本質的にはコード実行だ
AI製品が広く普及しており、そのインフラに注意する必要があるため、研究・調査されたのだと理解している
セキュリティを適用すること、セキュリティの必要性を知ること、テストすること、安全になるまでリリースしないことは、すべてそのブランドが販売者として行うべきことだ
Wizの研究が クラスタ全体の管理者権限に到達する前になぜ遮断されなかったのか、SAPには厳しく振り返ってほしい
SAP側がこの活動に関する通知を受けていたのか、適切に調査したのかを知りたい。不審なネットワーク活動について十分な通知体制を整えることを求める規制がSAPにあるのか、そして今回の研究がそれを満たしていなかった証拠になり得るのかも気になる
問題は実際に守っているのか、それとも単に棚の上のバインダーに入っているだけなのかだ
バグバウンティプログラムでも、対象範囲内でこうしたルールを求めることが多い。研究者はセキュリティ企業所属なので、ここでもそうだったと予想する
研究者はたいてい、どの時点で追加の許可を求めたのかを記事に書くが、必ずしもそうではない
tiller インスタンスが動いていたとは衝撃だ。2020年からサポート終了になっている: https://helm.sh/blog/helm-v2-deprecation-timeline/
ここでは大企業で、tillerから抜け出すにはやや複雑な移行が伴うが、そうした酌量事情がなくても古いソフトウェアは簡単に見つかる
これは本当にまずい。単一のK8sクラスタを運用しながら、強いマルチテナンシー保証を期待していたのか？
主要クラウドはいずれも、顧客間で仮想マシン境界と別々のK8sクラスタを使っている。Microsoftも数年前、K8sを主要なセキュリティ境界として期待していた関数製品の一つで同じようにやられたことがある
たとえばモデル学習のように任意コードを実行する状況で、K8sのマルチテナンシーがどんな役割を果たすのかよく分からない
私には、プロキシ/ファイアウォールであるIstioの内側に入ると内部ネットワーク通信をすべて信頼していたことが主な問題に見える。ただし、私がk8sクラスタを十分理解していないだけかもしれない
動き続ける標的なので、アドミッションコントローラでこれを安全にしようとする計画もあまり良くない
敵対的テナントを想定した強いマルチテナンシーを考えるなら、まずVirtualClustersのようなものを見るべきだ（https://github.com/kubernetes-sigs/cluster-api-provider-nest...）。それも制御プレーンの話にすぎず、データプレーンには触れてすらいない
その追加レイヤーがあっても、どれほど安全かは分からない。仮想マシンの領域でも、何年にもわたってとんでもないVMエスケープ脆弱性があった
顧客ごとに別クラスタを用意するのはコストが途方もなく大きく、地球にも悪い。セキュリティ最優先のプレミアム製品なら可能だろうが、顧客別の専用クラスタは実質的に金を燃やすようなものだ
脆弱性を見つけてブログコンテンツを作るために、許可なくネットワークへ侵入する会社は起訴されるべきだと思う
この記事は特に、脆弱性公開で薄く包んだ 攻撃的な記事のように聞こえる。「協力に感謝した」という言い方も、少し恐喝のように聞こえる
その角度から見ると、かなり違って見えないか？
ただし法の実務が示すように、「数十億ドルを持っていれば、法はもはや適用されない」という方向に流れていく
Wizを使ったことがある人はいる？
エンタープライズソフトウェア企業の中で最速のロケットかもしれない。1.5年で1億ドルのARR、3年目の終わりには3.5億ドルに到達した
https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...
グラフ機能で、望めばすべてのアカウントにまたがって事実上何でもクエリできる
会社の人たちを説得して、製品の年次ペネトレーションテストを本番環境で実施し、本番インフラ全体をスコープに含めてもらえてよかった
焦点は特定の製品やシステムかもしれないが、すべてがスコープ内にある。最初のテストが進行中で、まだ誰も悲鳴を上げていないので、うまくいくことを願っている
Metasploitでざっとなぞる程度を超えて、きちんとやってくれるペネトレーションテスト会社を推薦できるかも気になる
私の読み方が正しければ、顧客のアカウントデータが同じ顧客に露出するということ？ ログの一部だけが例外に見える
セキュリティ研究者なら、テキストを隠すためにピクセル化するのは良くない選択だというくらいは分かっていそうだけど
https://www.bleepingcomputer.com/news/security/researcher-re...
ぼかしやピクセル化は、効果の有無に関係なく、実質的に不要に見える。隠されているデータはローカルホスト名とイメージハッシュの一部のように見える
追記: 見直すと、ある箇所はぼかしで、別の箇所はピクセル化したように見える