本文へ
ハクソク

世界を動かす技術を、日本語で。

PyPIのLiteLLM 1.107.0が侵害され、認証情報窃取ツールとバックドアをインストールする

元記事: 原文(safedep.io)

概要

LiteLLM 1.107.0 のPyPIリリースに 認証情報窃取 と リモートコード実行バックドア が含まれていた事例。 全OS対応のホイールに 悪意ある3ファイル が混入、Pythonプロセス起動時に自動実行。 GitHub本家ソースは無害、PyPIは該当リリースを削除済み。 攻撃経路や動作内容、ファイルハッシュ、IOCを詳細解説。 安全なバージョン や感染確認方法も記載。

LiteLLM 1.107.0リリースにおける認証情報窃取およびバックドア混入の概要

  • LiteLLM 1.107.0 のPyPIリリースに、 認証情報窃取型マルウェア と リモートコード実行バックドア が混入
  • Linux・macOS・Windows 向け全ホイールが対象、 site-packages にcook.pth, cook.py, sitecustomize.pyの3ファイルを設置
  • Pythonプロセス起動時 に自動実行。モジュールをimportしなくても感染
  • GitHub本家リポジトリ のソースコードには悪意あるコードやcook/フォルダは存在せず
  • PyPI は該当バージョンを削除済み。 1.106.2、1.107.0rc1、1.107.0rc2 や関連パッケージは安全

攻撃内容の詳細

  • cook.pth が cook.py (認証情報窃取)をimportし、 SSH鍵・クラウド認証情報・CI/CDシークレット・AIツールAPIキー・ブラウザパスワード などを収集
  • 収集データは 暗号化 され、 www.litellm[.]dev へ送信
  • sitecustomize.py はバックグラウンドでデーモンを起動し、1時間ごとに攻撃者指定サーバからコードをダウンロード・実行
  • 攻撃者は GitHubリポジトリ 経由で送信先サーバを動的に変更可能

窃取対象の詳細(cook.py)

  • システム情報: ホスト名、ユーザ名、OS、IPアドレス
  • ブラウザ情報: Chromium・Firefoxの保存パスワードと履歴
  • SSH・シェル履歴: ~/.ssh/*、bash/zsh/PowerShell/cmd履歴
  • クラウド認証情報: AWS, Azure, GCP, Kubernetes, Docker, GitHub CLI, rclone, Netrc
  • 開発者シークレット: PEM, KEY, PFX, P12, PK8, PPK, Composer, FileZilla
  • コンテナ認証情報: Kubernetesサービスアカウントトークン
  • CI/CDシークレット: GitLab Runner, Jenkins, Terraform, Packer
  • AI開発ツールAPIキー: Claude, Copilot, Gemini CLI, VS Code, Hugging Face, 他
  • 環境変数: 自身および他プロセスの環境変数
  • LiteLLMプロキシDB: LLMプロバイダーAPIキー
  • クラウドメタデータ: AWS IMDS
  • GPG/TLS秘密鍵

データ送信方法

  • 収集データを AES-256-CBC で暗号化、鍵は RSA-OAEP で暗号化
  • tar.gz (hdr.json, data.bin, key.bin)形式でPOSTリクエスト送信
  • X-Token: XWiA8gZNa7NcX2XRoAEb ヘッダー付与
  • /tmp/.pc_once_ *ファイルで一度のみ収集・送信

バックドア(sitecustomize.py)の動作

  • /tmp/remote_code_loader.lock で排他制御、1ホスト1デーモン起動
  • fork()・setsid() で親プロセスから切り離し
  • 1時間ごとに GitHub上のdomain.txt を読み、指定サーバから codepy をダウンロード・実行
  • 攻撃者はdomain.txtの編集で 配信サーバを随時変更可能

攻撃経路とビルドプロセス

  • pyproject.toml のmaturin設定に data = "cook" の行が追加され、cook/フォルダがホイールに混入
  • ソース配布物(sdist) にはcook/フォルダが含まれず、改ざんの痕跡が隠蔽
  • 公式のGitHub Actions ではビルド・公開されていない
  • BerriAIのプライベートリリースパイプライン が攻撃者により改ざんされたソースからビルドした可能性が高い
  • PyPIトークン流出 の可能性は低いが、パイプラインのログが原因特定に必要

タイムライン(2026-10-21)

  • 06:59: v1.107.0タグ作成
  • 08:50: mainブランチでa8113b0コミット
  • 10:44: 正常な1.106.2がPyPIへ
  • 11:20-11:37: 各OS向け悪意あるホイールビルド
  • 11:39-11:40: 1.107.0がPyPIへアップロード
  • 11:50: GitHubでv1.107.0リリース公開
  • 13:40: PyPIから1.107.0削除、攻撃者GitHubアカウント消滅

インジケータ・オブ・コンプロマイズ(IOC)

  • ネットワーク:

    • www.litellm[.]dev/healthcheck:窃取データ送信先
    • HTTPヘッダー X-Token: XWiA8gZNa7NcX2XRoAEb
    • raw.githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt:バックドアのサーバアドレス取得先
    • http:///codepy:二次ステージコード配信
    • 169.254.169.254 へのリクエスト:AWSインスタンスメタデータ窃取
  • ホスト:

    • cook.pth, cook.py, sitecustomize.py がsite-packagesに存在
    • /tmp/.pc_once_ *:窃取済み判定ファイル
    • /tmp/remote_code_loader.lock :バックドアデーモン起動済み
    • PRIVCOLLECT_ACTIVE=1 環境変数
    • 親PID=1, セッション独立、作業ディレクトリ/のPythonデーモン
  • ファイルハッシュ(SHA-256):

    • litellm-1.107.0.tar.gz: 2befe2a7...
    • litellm-1.107.0-cp310-abi3-manylinux_2_28_x86_64.whl: 462d0c9f...
    • 他詳細は本文参照
  • OSごとの差異: Windows版はCRLF改行のためファイルハッシュが異なる

安全なバージョン・対応策

  • 1.106.2, 1.107.0rc1, 1.107.0rc2 および litellm-proxy-extras==0.4.110, litellm-enterprise==0.1.78 は安全
  • 該当バージョン利用者は即アンインストール・感染確認・認証情報変更 推奨

まとめ

  • サプライチェーン攻撃 によるPyPIパッケージの汚染事例
  • 全OS・全プロセス感染型 で被害範囲が広い
  • 公式ソースの整合性確認やCI/CDパイプラインの保護 が重要
  • IOCによる感染チェック と 認証情報の緊急ローテーション が必須

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

個人的には、uvやnpmなどのデフォルトには、24〜48時間のクールダウンが必要だと思う。新しいものをインストールするには、わざわざ手間をかけるべきだよね。

└

みんながそんな風に追加してるとは知らなかった。これ、去年の初めに自分たちのプロジェクトで変更したことなんだ。一般的になってるのを見ると嬉しいな。リスクは、十分なセキュリティ研究者がこれを見つけて、デフォルトのクールダウンが切れる前に隔離することだね。

└

内部のpypiプロキシではパッケージに7日間のクールダウンを設けてるけど、これだとセキュリティアップデートもブロックしちゃうんだ。今は手動でクールダウンから除外しなきゃいけなくて、どうやって自動化するか悩んでる。もしかしたらLLMが最初の一歩になるかも。

└

もしかしたら、みんなが更新しすぎるっていうより、デプロイメントパイプラインにビルドに固定されたバージョンがないのが問題なのかも。

└

最後に情報を探したとき、中央値のサプライチェーン攻撃が発見されるまで数ヶ月から数年続いているって見た記憶がある。そんな短いクールダウンは、詐欺みたいに思える。

└

それから、マルウェアについては24〜48時間後にわかるよ。

└

これにはsafechainを使ってる。だって、いつも別のパッケージマネージャーが間違って設定されるからね。 https://github.com/AikidoSec/safe-chain

またlitellmか。メンテナーの信頼性が気になるな。

またlitellmがニュースに出てるね。

└

ここで面白いのは、最初に攻撃された後にLiteLLMから移行しなかった人たちにだけ影響が出るってこと。脆弱性が出たからってみんなが移行すべきだとは言わないけど、やっぱりそう言いたい。プログラミング言語みたいな大きな基盤のものじゃない限り(PHPは二度目のチャンスがある)、数週間以内に移行した方がいいよ。俺は最初の時にはインストールすらしてなかったから、理想のプログラマー(つまり、あなたの競争相手)はこの依存関係から0の脆弱性を受けてる。もし1つでも被害を受けたなら、それはかなりまずい。二度もやられたら目を覚ますべきだよ。同じ依存関係で3回被害を受けたら、もう手遅れだね。

https://github.com/BerriAI/litellm/issues/47826#issuecomment... > OSSユーザーへ > とりあえず、バージョンを1.106.2か、それ以前に公開された明示的なバージョンに固定してください。 > 企業顧客へ > 現在、企業顧客向けのプライベートLiteLLMレジストリが存在していて、そこでは10月27日に公開予定の脆弱性を修正したリリースを配布しています。私たちのプライベートレジストリには影響はありません。プライベートレジストリから引き出している企業顧客は影響を受けません。

└

他人のLiteLLMインスタンスをハックするための情報に先行アクセスを売ってるってこと?ちょっと倫理的にどうかと思うな。

Hacker Newsで議論の続きを見る