ShadowRay：野生環境で悪用されたAIワークロードを標的とする初の既知の攻撃キャンペーン

要点（TL;DR）

Oligoのリサーチチームはこのたび、広く利用されているオープンソースAIフレームワーク「Ray」の脆弱性を標的とする、進行中の攻撃キャンペーンを発見しました。AIインフラを稼働させている数千の企業・サーバーが、見解の相違によりパッチが存在しない重大な脆弱性を通じて攻撃にさらされています。この脆弱性により、攻撃者は企業の計算資源を乗っ取り、機密データを漏えいさせることが可能になります。この欠陥は過去7か月間にわたり継続的に悪用されており、教育、暗号資産、バイオ医薬などを含む複数の分野に影響しています。Rayを使用しているすべての組織は、自社環境が露出していないことを確認し、不審な活動がないか分析することを推奨します。

イントロ

2023年後半、主にAIワークロードで使用される広く利用されているオープンソースフレームワークRayにおける5つの固有の脆弱性が、Rayの開発・保守を行うAnyscaleに開示されました。脆弱性はBishop Fox、Sierra Haex、Protect AIにより（いくつかは同時に）開示されました。

開示を受けてAnyscaleは、脆弱性への対応、経緯の明確化、各CVEへの対処内容の詳細を示すブログ [1] を公開しました。報告された脆弱性のうち4件はRay 2.8.1で修正されましたが、5件目のCVE（CVE-2023-48022）は見解が分かれているため、リスクと見なされず、即時の修正は行われませんでした。

CVE-2023-48022が「見解相違（disputed）」となっているため、多くの開発チーム（および大半の静的スキャンツール）は、この脆弱性が自分たちに関係することを認識していません。Rayのこのドキュメント節を見落としているチームもあれば、この機能自体を知らないチームもあります。

Oligo Securityの研究者は、CVE-2023-48022が野生環境で積極的に悪用されている事例を観測しており、この「見解相違」のCVEは「シャドー脆弱性」——静的スキャンには現れない一方で、侵害や重大な損失につながり得るCVE——であることが明らかになりました。

私たちの調査では、世界中で公開状態にあるRayサーバーが数千台、OligoのリサーチチームがShadowRayと名付けたこの新たな脆弱性の結果として、すでに侵害されていることが分かりました。影響を受けたマシンの中には、少なくとも7か月間侵害されていたものもありました。多くのマシンにはコマンド履歴が残っており、攻撃者が当該マシン上の内容を理解しやすくなるだけでなく、過去のコマンドで使用された本番環境の機密情報が漏えいしている可能性もあります。

侵害指標（IoC）の完全な一覧は、ブログ末尾に掲載しています。Rayを通じたリモートコード実行（RCE）に対して、数百社が公開状態でさらされており、現在もなお脆弱なままのケースもあります。

Oligoの研究者（シャドー脆弱性の発見で先端を走ってきたチーム）は、このCVEをShadowRayと命名しました。これは、現代のAIインフラの脆弱性を通じて、AIワークロードが野生環境で積極的に悪用された初の既知事例となります。

本研究の要約では、以下を掘り下げます：

• なぜAIインフラが攻撃者にとって金鉱なのか。
• Rayというオープンソースフレームワークとは何か、誰が使い、AIでどのように使われているのか。
• 野生環境で悪用されたRayクラスター：侵害されたデータの価値、侵害マシン群の総価値、攻撃者がどのように収益化しているか、など。

免責事項：
本ブログでは、Bishop Fox [2]、Sierra Haex [3]、Protect AI [4] により報告された、オープンソースRayフレームワークの最近の脆弱性について扱います。Anyscale（Rayの開発者）のSaaS提供や有償製品には関係しません。本ブログの唯一の目的は、Ray利用者を支援するために、セキュリティ面とよくある落とし穴への認識を高めることです。

この記事の内容：

1. AIインフラ：攻撃者にとっての金鉱
2. Rayとは
3. CVE-2023-48022の経緯：ShadowRayの解説
4. 侵害指標（IoC）
5. 謝辞

AIインフラ：攻撃者にとっての金鉱

典型的なAI環境には、企業全体を倒産に追い込むのに十分なほどの機密情報が大量に含まれています。なぜAI環境は攻撃者にとってこれほど魅力的なのでしょうか。構成要素と、それらがもたらすリスクを見ていきましょう。

ML-OPS環境は、同一クラスター内およびクラスター間で相互に通信する多数のサービスで構成されています。

学習やファインチューニングに使用される場合、通常はディスク上またはS3バケットのようなリモートストレージ上のデータセットやモデルにアクセスできます。多くの場合、モデルやデータセットは、競合他社との差別化要因となる独自の非公開知的財産です。

さらにAI環境は、サードパーティトークン（可読なシークレットや環境変数）や、さまざまな種類の統合（HuggingFace、OpenAI、WanDB、その他のSaaSプロバイダー）にアクセスできるのが一般的です。

AIモデルは現在、企業のデータベースやナレッジグラフと接続されています。AIインフラはAI主導の企業にとって単一障害点になり得る一方、攻撃者にとっては隠れた宝の山です。

AIモデルは通常、高価で高性能なマシン上で動作するため、その計算資源は攻撃者にとって格好の標的となります。

Rayとは

Rayは、さまざまな目的のAIおよびPythonアプリケーションをスケールさせるための統合フレームワークです。

大まかに言うと、Rayは以下で構成されます：

1. Ray Coreとして知られる中核の分散ランタイム。
2. その上に構築される、または依存する補完的なAIライブラリと拡張群。ドメイン特化のMLワークロードを効率的に高速化・分散するためのものです。

誰がRayを使い、どのように使うのか？

現在、RayはGitHub [5]で3万スターを獲得しています。Anyscaleによれば、Uber、Amazon、OpenAIを含む世界最大級の組織の一部が本番環境でRayを使用しています。[6]

多くのプロジェクトが、主流のSaaS、データ、AIワークロードのためにRayに依存しており、高いスケーラビリティ、速度、効率性を活用しています。

AnyscaleはRayプロジェクトを保守しており、Ray Tune、Ray Serveなど多数のライブラリの基盤となっています。

Rayは、Helmチャートなどのクラウドネイティブ手法を用いて製品インストールとデプロイをブートストラップするボイラープレートコードを使用します。クラウドプロバイダーとの多数の統合により、マネージドサービスのユースケースも可能になります。

GPT-4のようなモデルは数十億のパラメータで構成され、膨大な計算能力を必要とします。このような大規模モデルは、単一マシンのメモリには到底収まりません。Rayは、これらのモデルを動かすことを可能にする基盤技術です。Rayは業界のベストプラクティスとして急速に定着しました。特にPythonに習熟し、複数GPUや複数マシンにまたがってモデルを実行・分散する必要があるAI実務者にとって顕著です。

AIにおけるRayの使われ方

Rayの能力はAIのニーズに完璧に合致します：

• Rayは、あらゆるアーキテクチャ／フレームワークのAIモデルの学習・提供（サービング）・チューニングのための分散ワークロードを可能にします。
• RayはPythonの習熟度をほとんど要求しません。最小限の設定で使える軽量なPython APIを備えています。
• Rayは堅牢で、パフォーマンス最適化のベストプラクティスを採用しており、強固で手間のかからないインストール、少ない依存関係、本番品質の実戦投入済みコードを備えています。
• RayはPythonにとどまらず、bashコマンドを含むあらゆる種類のジョブを実行できます。

RayはPythonistaとAI実務者のためのスイスアーミーナイフであり、AIアプリケーションを容易にスケールさせることを可能にします。

CVE-2023-48022の経緯：ShadowRayの解説

Bishop Fox、Sierra Haex、Protect AIによる5件の脆弱性開示を受け、Anyscaleは透明性と迅速な対応で困難な状況に対処し、Rayエコシステムの安全性と健全性へのコミットメントを示しました。AnyscaleはRay 2.8.1で4件の問題に迅速に対処し、脆弱性とその修正について説明する詳細なブログ投稿を提供しました [7]。

脆弱性の1つであるCVE-2023-48022は、RayのJobs APIに認可がないことに起因します。他のCVEがRayの新リリースで対処されたのとは異なり、このCVEはAnyscaleによって「見解相違」のまま残されました。実際、同社によれば、これは脆弱性やバグではなく、想定された挙動であり製品機能だという立場です。

しかし、企業がRayをクラウド環境にデプロイするのを支援する多くのGitHubボイラープレートリポジトリでは、Rayは修正済みのCVE（2.6.3〜2.8.0のRayを実行している場合）だけでなく、ShadowRayにも脆弱なままです。なぜなら、Rayのダッシュボードは常に0.0.0.0（全ネットワークインターフェース）にバインドし、さらに0.0.0.0へのポートフォワーディングと組み合わさることで、デフォルトでインターネットにマシンを露出させてしまう可能性があるためです [8]。

認可の欠如はどのように悪用され得るのか？

RayのJobs APIには、いかなる種類の認可も含まれていません。その結果、ダッシュボードへのネットワークアクセス（HTTPポート8265）を持つ者は誰でも、認可なしにリモートホスト上で任意のジョブを呼び出せる可能性があります。 

Ray公式のドキュメントによれば、セキュリティのベストプラクティスは次の記述から始まります：

「… セキュリティと分離はRayクラスターの外側で強制されなければならない。 Rayは安全なネットワーク環境で動作し、信頼できるコードに基づいて動作することを前提としている。開発者およびプラットフォーム提供者は、Rayクラスターの安全な運用を確保するために、以下の不変条件を維持しなければならない…」 [9]

Rayは設計上コード実行機能を含むため、Anyscaleは、そのローカリティとセキュリティについては利用者が責任を負うべきだと考えています。ダッシュボードはインターネットに面していないか、信頼できる当事者のみにアクセス可能であるべきです。Rayが認可を欠くのは、適切なルーティングロジックがある安全な環境で動作するという前提（ネットワーク分離、Kubernetes名前空間、ファイアウォールルール、セキュリティグループ）に基づいています。

私たちが業界の専門家とこれらの問題について議論したところ、Rayダッシュボード内のJobs APIを知らない、またこのCVE開示について聞いたことがない、というケースがあることが分かりました。

例えば、Ray公式のKubernetesデプロイガイド [10] と、KuberayのKubernetesオペレーターは、ダッシュボードを0.0.0.0で公開することを推奨しています：

AIの専門家はセキュリティの専門家ではありません——そのため、AIフレームワークがもたらす非常に現実的なリスクに対して、危険なほど無自覚である可能性があります。

RayのJobs APIに認可がない場合、ベストプラクティスに従っていないとAPIがリモートコード実行攻撃にさらされ得ます。このCVEは「disputed（見解相違）」とタグ付けされています。こうしたケースでは、CVEプログラムはどちらの当事者が正しいかを判断しません。

CVEレコードの「DISPUTED」タグは、例えば正確性、完全性、あるいは問題のバグがそもそもセキュリティホールなのかどうか、といった点に疑義があるなど、さまざまな理由で付与され得る [11]

「disputed」タグは、この種の攻撃を検知しにくくします。多くのスキャナーは見解相違のCVEを単に無視するためです。市場で利用可能な最先端のソリューションを用いていても、利用者がリスクを認識できない可能性があります。

Anyscaleによれば、この問題は脆弱性ではなく、クラスター内でジョブをトリガーし動的コードを実行できるようにする、Rayの設計に不可欠な機能です。認可機能は将来のバージョンで対処すべき技術的負債として認識されているものの、実装は複雑で破壊的変更を招く可能性があります。そのためAnyscaleは追加を先送りし、CVE-2023-48022 [6] を「disputed」としました。

このアプローチは、セキュリティ強化を優先しつつRayの機能性を維持するというAnyscaleの姿勢を反映しています。またこの判断は、ソフトウェア開発におけるセキュリティと利便性のバランスの難しさを浮き彫りにし、Rayのようなネットワークアクセスを持つ重要システムや他のオープンソースコンポーネントに変更を加える際には慎重な検討が重要であることを示しています。

可視性の欠如

それが脆弱性に当たるかどうかを巡る見解相違のため、ShadowRay（CVE-2023-48022）は複数のデータベースに掲載されませんでした。これにより盲点が生まれ、世界中のセキュリティチームは自分たちがリスクにさらされ得ることを把握できませんでした。 例えばMITREやOSVでShadowRayがどのように扱われているかを見てみましょう。

野生環境で悪用されたRayクラスター：どの機密データが侵害されたのか？

攻撃者がRayの本番クラスターを手に入れたとき、それは大当たりです。価値ある企業データに加え、リモートコード実行が可能になることで、攻撃を収益化しやすくなります——しかも影に隠れたまま、完全に検知されず（そして静的セキュリティツールでは検知不能のまま）実行できます。

侵害されたサーバーを通じて、大量の機密情報が漏えいしていました。私たちが明らかにした具体的な情報を見ていきましょう。

• AI本番ワークロードが侵害されました。つまり攻撃者はAIモデルの整合性や精度に影響を与えたり、モデルを盗んだり、学習フェーズ中にモデルへ感染させたりできる可能性があります。影響を受けた組織は、医療企業、動画解析企業、名門教育機関など、多様な業界にわたっていました。
  ‍

• 本番DB認証情報が露出し、攻撃者が完全なデータベースを静かにダウンロードできる状態でした。一部のマシンでは、攻撃者がデータベースを改ざんしたり、ランサムウェアで暗号化したりできた可能性があります。

• パスワード – 攻撃者がマシンからパスワードハッシュを盗んだ証拠を確認しました。ジョブ履歴内で、単純な「cat /etc/shadow」が複数回成功して実行されていました。

• 秘密SSH鍵 – 攻撃者が、同一VMイメージテンプレート（AMIなど）から作成された他のマシンへ接続するために利用できる秘密SSH鍵を複数発見しました。これにより、暗号資産マイニングキャンペーンの計算能力をさらに拡大したり、環境内で永続化を得たりすることが可能になります。

• OpenAIトークン – 攻撃者がOpenAIアカウントへアクセスするために利用できるOpenAIトークンを発見しました。これにより、影響を受けた企業のOpenAIプラットフォーム上のクレジットを使い切られる可能性があります。発見した侵害トークンはすべて、公式のバグバウンティプログラム [15] を通じてOpenAIへ開示しました。

• HuggingFaceトークン -（プライベートリポジトリへのアクセス）- 既存モデルの追加や上書きを可能にするHuggingFaceトークンを発見しました。攻撃者は当該アカウントのリポジトリをサプライチェーン攻撃に利用し、モデルをプラットフォームへアップロードしたり既存のものを上書きしたりすることで、他のマシンへ到達する可能性があります。

• Stripeトークン – 攻撃者がStripeトークンを用いて本番プラットフォーム上で取引に署名し、決済アカウントから資金を引き出す可能性があることを確認しました。

• クラウド環境（AWS、GCP、Azure、Lambda Labs）へのアクセス – 多くのクラスターは高権限（root）で稼働していました。

• KubernetesAPIアクセス – 攻撃者がクラウドワークロードへ感染させたり、Kubernetesシークレットを盗んだりすることなどを可能にします。

‍

• Slackトークン – 攻撃者が影響組織のSlackメッセージを読み取ったり、特定チャンネルへ任意のメッセージを送信したりするために利用できるSlackトークンを発見しました。

‍

金銭面：侵害されたマシン群の総価値は？

私たちが侵害を確認したGPUモデルの多くは、現在在庫切れで入手困難です。例えば、上のマシンに搭載されていたA6000 GPUは、NVIDIAのウェブサイトで在庫切れとなっています：

‍

現時点でOligoは、侵害されたクラスターを数百件発見しています。各クラスターは多数のノード（ネットワーク越しにクラスターへ接続されたマシン）で構成されています。多くのノードにはGPUが搭載されており、攻撃者は暗号資産マイニングにそれらを利用しているため、このインフラはさらに大きな攻撃対象となっています。

つまり攻撃者がこれらのマシンを侵害するのは、価値ある機密情報を得られるからだけではなく、GPUが非常に高価で入手困難——特に昨今は——だからです。

GPUマシンのオンデマンド価格は主にGPUの種類とメモリに依存します。執筆時点で、AWSのGPUオンデマンド価格は年間で1台あたり858,480ドルに達することがあります。

ここ数週間だけで観測したクラスターに基づくと、侵害された可能性のあるマシン数と計算資源の総額は、ほぼ10億米ドル相当に達すると推定できます。さらに、私たちが観測した攻撃の最初の証拠は9月5日であり、攻撃者は少なくとも7か月間ハードウェアを活用できたことになります。

攻撃者も同じ計算をしています。

標的となったクラスターに共通点はあるか？（暗号資産マイナー）

Oligo Researchが特定し報告したクラスターの大半は、すでに暗号資産マイナーやリバースシェルによって侵害されていました。侵害されたクラスター群にはいくつかのパターンが見られ、同一の攻撃者によって狙われたことを示唆しています。

Oligo Research Teamは、ShadowRayを悪用して組織へ侵入し、複数種類の暗号資産マイナーをインストールする暗号資産マイニングキャンペーンを特定しました。

最初に確認した暗号資産マイナーは2024年2月21日にインストールされていました。公開Webインテリジェンスツールを用いたところ、当該IPは2023年9月5日以降、標的ポートへの接続を受け付けていたことが分かり、侵害は脆弱性が開示される前に始まっていた可能性があります。攻撃規模と一連の経緯から、脅威アクターは確立されたハッキンググループの一部である可能性が高いと考えています。

私たちは以下を含む暗号資産マイナーを確認しました：

• XMRigマイナー – 一部は揮発的に、メモリ内で実行され、ディスクへダウンロードされない形で動作していました。

‍

• NBMiner

• JavaベースのZephyrマイナー

リバースシェル（永続化の獲得）

私たちは複数のリバースシェルを発見しました。これにより攻撃者は本番環境で任意コードを実行し、マシン上で永続性を獲得できます：

• アクティブなリバースシェル

• 攻撃者がリバースシェルを正常に開く：

‍

侵害指標（IoC）

IPジオロケーション：

‍

責任ある開示

Oligoのリサーチチームは、責任ある開示を通じて多数の企業へ積極的に通知し、修復に関する追加の詳細と支援を提供してきました。

ランタイムでの検知と緩和

シャドー脆弱性は常に存在しますが、ビルド時に可視なCVEがなければ、これらの脆弱性はSCAやSASTのアプローチからは見えません。コードと静的テストだけでは、何がデプロイされているかという完全な文脈を把握できません。

シャドー脆弱性を検知するには、エクスプロイト指標を含むランタイム環境を継続的に監視する必要があります。エクスプロイトの兆候はさまざまで、特別に細工された入力、信頼できないソースからのデータ読み込み、欠落したファイアウォールルール、考慮されていない依存関係の挙動などによって引き起こされ得ます。

緩和策

• Rayデプロイを保護するためのベストプラクティスに従う [9]
  • まず、Rayを保護された信頼できる環境内で実行する。
  • 常にファイアウォールルールまたはセキュリティグループを追加し、不正アクセスを防止する。
• Rayダッシュボードのポート（デフォルト8265）の前段に認可を追加する：
  • Rayのダッシュボードをアクセス可能にする必要がある場合は、ネットワーク越しに公開する際にRay APIへ認可レイヤーを追加するプロキシを実装する。
• Ray内部も含め、本番環境とAIクラスターを継続的に監視し、異常を検出する。
  • Rayは動作のために任意コード実行に依存している。コードスキャンや設定不備検出ツールでは、こうした攻撃を検知できません。なぜならRayのオープンソース保守者（Anyscale）がこれを「disputed」とし、バグではない——執筆時点では機能である——と確認しているためです。
  • 楽をするために0.0.0.0へバインドしない – ローカルネットワークのサブネット内のIPや、信頼できるプライベートVPC/VPNなど、明示的なネットワークインターフェースのIPを使用することが推奨されます。
  • デフォルトを信用しない – ツールはドキュメントを読んでいる前提であることがあります。読みましょう。
  • 適切なツールを使う – オープンソースを安全にする技術的負担はあなたにあります。保守者に頼り切らず、役立つツールを活用して、ランタイムでのオープンソース利用リスクから本番ワークロードを保護してください。

また、ShadowRayの潜在的影響と重要な緩和ステップを解説する脅威ブリーフィングも開催しています。

謝辞

まず、真に素晴らしいオープンソースフレームワークであるRayを作り上げたAnyscaleに感謝します。また、迅速に対応し、私たちのチームと全面的に協力してくれたAnyscaleのセキュリティチームにも深く感銘を受けました。これはRay利用者とコミュニティの安全に対する真摯な関心を明確に示すものでした。さらに、発見に関する素晴らしい先行研究と責任ある脆弱性開示を行ったBishop Fox [2]、Sierra Haex [3]、Protect AI[4]にも感謝します。

Oligo Research Team

Oligo Research Teamは、オープンソースソフトウェアにおける新たな攻撃ベクトルに注力する経験豊富な研究者の集団です。同チームは重大な問題を特定し、その発見についてOligoの顧客および技術コミュニティへ警告します。これまでにApache Cassandra、Atlassian Confluence、PyTorchなど、人気のOSSプロジェクトやライブラリにおいて数十件の脆弱性を報告してきました。