Shai-HuludテーマのマルウェアがPyTorch LightningのAI学習ライブラリで発見
(semgrep.dev)- ディープラーニングフレームワーク
lightningの 2.6.2 と 2.6.3 バージョンがサプライチェーン攻撃に悪用された —pip install lightningを実行するだけで、隠された_runtimeディレクトリ内の 難読化されたJavaScriptペイロードが自動実行 - 画像分類器の構築、LLMのファインチューニング、拡散モデル、時系列予測などに広く使われるフレームワークであるため、多くのAI/MLチームの 依存関係ツリーにすでに含まれている 可能性が高い
- マルウェアが実行されると、ローカルファイルシステム上の80以上のパスをスキャンして GitHubトークン(
ghp_,gho_)、npmトークン(npm_)、環境変数、クラウドシークレットを窃取 し、ファイルごとに最大5MBまで処理 - AWS（認証情報ファイル・IMDSv2・ECS・Secrets Manager・SSM）、Azure（Key Vault）、GCP（Secret Manager）など 主要3大クラウドプロバイダー全体を対象にシークレットを列挙して取得 する
- GitHub Actions環境では組み込みPythonを使って
Runner.Workerプロセスメモリをダンプ し、"isSecret":trueと表示されたすべてのシークレットとリポジトリ・ワークフロー情報を抽出 - 侵入口はPyPI（Python）だが、ワーム拡散はnpm（JavaScript）経由で広がる — 窃取したnpmトークンで公開可能なすべてのパッケージにドロッパー（
setup.mjs）とマルウェア（router_runtime.js）を注入し、パッチバージョンを上げて再公開、そのパッケージをインストールした下流開発者のマシンまで連鎖感染 - データ流出は単一経路の遮断では防げないよう 4つの並列チャネル を同時に使用する: ① HTTPS POSTでC2サーバーへ送信、② GitHubコミット検索APIを使ったデッドドロップ（コミットメッセージに二重Base64エンコードしたトークンを挿入）、③ Dune世界観の名前を持つ公開GitHubリポジトリへ
results-<timestamp>.jsonとしてコミット、④ 被害者リポジトリへ直接プッシュ - リポジトリ侵入後は 開発ツールに永続化フックを仕込んで再感染を保証 — Claude Codeの
.claude/settings.jsonにSessionStartフックを書き込み、セッション開始時に自動実行し、VS Codeの.vscode/tasks.jsonにrunOn: folderOpenタスクを仕込んでフォルダを開くたびに実行- どちらのフックも自己完結型ドロッパー
setup.mjsを呼び出し、BunランタイムがなければGitHubから静かにダウンロードして14.8MBのペイロードrouter_runtime.jsを実行
- どちらのフックも自己完結型ドロッパー
- 書き込み権限のあるGitHubトークンを確保すると、被害者リポジトリに
Formatterという偽装ワークフローをプッシュ — すべてのpushで${{ toJSON(secrets) }}によりリポジトリシークレットをダンプし、Actionsアーティファクトとしてアップロード - 影響期間中に該当バージョンをインストールしたすべてのマシンは 完全に侵害されたものと見なす 必要があり、GitHubトークン・クラウド認証情報・APIキーを直ちにローテーションし、
.claude/と.vscode/ディレクトリに想定外のファイルがないか監査が必要 - 攻撃指標: コミットメッセージに
EveryBoiWeBuildIsAWormyBoiプレフィックス、リポジトリ説明に"A Mini Shai-Hulud has Appeared"、リポジトリ内の_runtime/ディレクトリの存在有無などで GitHub検索を通じて直接確認可能
2件のコメント
これで、もうアップデートしないほうがよさそうだ……
Hacker Newsの反応
単なる頻度の錯覚かもしれないが、最近は主要パッケージで有名なサプライチェーン攻撃がかなり多く見られる
今のHNの最初の数ページを見ても、別々の事例を扱った投稿がいくつもある
10年前の
left-padを振り返ると、今は成功した攻撃が当時より増えているのではと思うし、おそらくその通りだろう成功した攻撃の価値も確実に大きくなっているはずだが、パッケージのリリース前に検知する能力が、コミュニティ全体として実際に向上しているのか気になる
商用ソフトウェア企業はもっとうまくやるべきだが、趣味・アマチュアのコードとして始まり、その後多くのプロジェクトの依存先になるようなケース向けの、汎用的で簡単なツールはまだ不足しているように見える
今のSAPサプライチェーン攻撃スレッドにも同じコメントを投稿した: https://news.ycombinator.com/item?id=47964003
以前は
npm installを手動で実行することがもっと多く、ビルドが壊れたときか、せいぜいたまに実行する程度だったはずだサプライチェーン攻撃は、人間が、より正確にはパイプラインが、新しいリリースが出るやいなや何も考えずにパッケージを自動更新することに依存している
これが良いビジネスモデルかは分からないし、たぶんそうではないだろう
left-padは攻撃ではなく、NPMのバグだったすでに公開されていて、別のパッケージが依存しているパッケージバージョンを削除できてはいけなかったし、逆に新しいバージョンで、まだ誰も依存していない特定のパッケージバージョンは削除できるべきだった
left-padの作者がサービスを離れる意図ですべてのデータを消そうとしたとき、NPMはエラーコードを返すべきだったWikipediaによると、Koçuluがnpm, Inc.の決定に失望し、プラットフォームの一部として残りたくないと述べた際、NPM作者のSchlueterが、彼が登録した273個のモジュールを削除するコマンドを提供したという
奇妙なのは、4件のセキュリティ問題が上がったのに、どれも
pl-ghostというボットが自動コメントを付けて閉じていたことだ [1][2][3][4]結局、このうち[4]だけがきちんと処理され、ボットのコメントはすべて削除された
別のレポート[5]ではそのボットコメントを見ることができ、元記事より多くの情報を与えている
[1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
[2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
[3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
[4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
[5] https://socket.dev/blog/lightning-pypi-package-compromised
攻撃者はこのアカウントで新しいActionsワークフローを作成し、実行されたワークフローからPyPIシークレットをパースして抜き取りました
パッケージをリリースした後は、そのアカウントでコメントを投稿し、こちらを少しあざ笑っていました
依存関係がまったくない日が早く来てほしい
極端な例として、最近は娘のためのインタラクティブな教育アプリを作るとき、Opusに純粋なJavaScriptとHTMLだけを使わせている
二重振り子から流体シミュレーションまで一発でうまく動き、昔なら依存関係が数百個あったはずだ
MITライセンスのコードなら、Opusに必要な部分だけを正確に抽出し、自分の用途向けに修正して組み込ませることもできる
趣味プロジェクトでは今のところうまくいっていて、今後は本番ソフトウェアでも依存関係がなくなってほしい
ChromeがあるAPIの形を変えたら自分で見つけて直す必要があるし、モロッコが夏時間の開始時期を変えたら日時処理コードも自分で更新しなければならない
こうしたことは、ライブラリが代わりに処理してくれるから当たり前だと思っていた部分だ
娘が来週には興味を失うような二重振り子シミュレータなら大したことではないが、今後無期限に動き続けるものを作る会社にとっては問題になる
MITライセンスのリモートアクセスコードを1つ公開して、Opusの学習データに入るようにしてみるべきだな
Fast.AIのディープラーニング講座を受けたとき、機械学習プロジェクトが引き込むPython依存関係の数に驚いた
Webフロントエンドのプロジェクトは常にサードパーティ依存が多いと思っていたが、自分には機械学習エコシステムの方がはるかに絡み合って見える
しかもWeb開発はセキュリティに敏感だと見なされ、長年にわたりセキュリティの知見や慣行が蓄積されてきたが、機械学習開発はずっと場当たり的で、一般的なソフトウェア工学の慣行もあまり適用されていないように思える
たとえば当時、機械学習モデルの配布方法の1つがPython pickleだったが、これは基本的に制限のない実行可能オブジェクトだ
この形式のモデルは、取り込むコンピュータ上で何でもできてしまい、この初期の無法地帯のようなエコシステムがセキュリティ侵害やサプライチェーン攻撃をより容易にしている可能性がある
やっているうちに少しコーディングを覚えた人もいれば、数学者もいるし、AIに酔った開発者のような人もいる
「コードはもう重要ではなく、動けばいい」という考え方もある
多くの人にとって、まともな依存関係管理は気にしたくない雑務にすぎない
いくつもの機械学習プロジェクトでこうした要素が重なっているが、実際には機械学習プロジェクトこそ再現性に最も注力すべき分野の1つだ
リポジトリ検索を見たところ、過去24時間に作成されたリポジトリのうち、
"A Mini Shai-Hulud has Appeared"というテキストを含むものが2.2千件もある: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...これはアカウント、たぶんGitHub認証/Actionsトークンが侵害された後、それを使ってリポジトリが作成されたことを示すサインに見える
前回もこういうことがあったのだから、教訓を得ていたはずだと思っていた
このマルウェアはあまり努力しておらず、Microsoftもあまり努力していないように見える
免責すると、pytorchを使ったことはないし、ソフトウェアセキュリティの慣行にも詳しくない
だが、pytorchでネットワークアクセスが必要になるシナリオがあまり思い浮かばない
コードベースのどこででも任意のモジュールをimportしてそのAPIを使えるのは、まずいように思える
追加のimport制限や静的解析が必要そうだ
言語がこういう問題を扱うための適切な抽象化を持っていないように思う
比較すると、Rustでは関数シグネチャを見るだけで内部コードを理解しなくても可変性やライフタイムが分かるのが良い
依存関係にも似たものが必要だと感じる
開発者は下位コードをのぞかなくても、すべての依存関係を簡単に監査して、「ああ、この依存関係は
eval()を使っているな」とか「ネットワークアクセスしているな」と分かるべきだモバイルアプリは権限を強制するのだから、開発者も特定の機能だけを許可リストに入れ、あらゆる機能を丸ごと受け入れずに済むべきではないか
一般化はしたくないが、とくにAI開発コミュニティは、他のあらゆる考慮よりも利便性を優先しているように見える
たとえば、プロジェクトが初回実行時に大きなモデルを自動ダウンロードするのが標準のようになっている
たいてい無効化はできるが、複数ライブラリにまたがるコードクラスの深い階層のせいで、正しいパラメータを見つけるのが本当につらい
複雑なものを、たいていはおもちゃに近いものを、あまりに簡単に始められるのは良いことだが、この許容的な空気はかなり居心地が悪い
最初の問題解決ステップがいつも「
pip install …」であるように思えるし、一部の環境、たとえばMacOSではGPUアクセスの仮想化もうまくいかない今週、Pythonのバージョン管理にuvを使うのが良い考えなのか気になっていた
Webサイト[1]には「Pythonは公式な配布用バイナリを提供していないため、uvはAstralのpython-build-standaloneプロジェクトのディストリビューションを使う」とある
それはこのGitHubリポジトリ https://github.com/astral-sh/python-build-standalone を指していて、そこではさらに https://gregoryszorc.com/docs/python-build-standalone/main/r... に言及している
自分の理解が正しければ、Pythonビルド用のソースコードをpython.orgから直接取ってきていないようにも見え、これがどれほど安全なのか確信が持てない
asdf[2]にも同じ懸念はあるが、asdfはpyenv[3]を使っていて、そちらの方がより公式に近い感じがする
Pythonのインストールには、uvとasdfのどちらがより良く、より安全なのか、説明できる人はいるだろうか？
[1] https://docs.astral.sh/uv/guides/install-python/
[2] https://github.com/asdf-community/asdf-python
[3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...
そもそも他のどこから取るんだという話だ
[1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
uvとcpythonについてはあまり心配していない。プロセスは堅牢で、対応も速く、今では資金もかなりある心配なのは、たとえば
mdformatのように広く使われているが、主に1人が余暇で保守しているフォーマッタや、何年も更新されておらず、依存ツリーの3段階下にあるような非常に特定の依存関係だ活発に開発中のアプリで、すべての更新を固定して手動承認したくはないが、真面目なアプリなら今やそれが必須に見え始めている
その間に、暗号化されていない
.envファイルからAPIキーを取り出しておこう大規模なコンシューマー向けWebアプリで被害に遭うのは恥ずかしいが理解はできるとしても、同じホストやシステム上にたまたまある、おもちゃのデモ用リポジトリの間接依存のせいで数百〜数千ドル失うのは痛すぎる
こういう形でキーを盗まれた場合、OAIやAnthropicは返金してくれるのか知っている人はいる？ それともユーザーのミス扱いなのだろうか？
Pythonバイナリを彼らがビルドするか、別の誰かがビルドするかで、危険性がどれほど変わるのか分からない
最近の自分の
pip installの大半はClaude Codeが提案し、自分はそのままEnterを押しているだけだモデルは数か月前のデータで学習されているのだから、今週何が侵害されたか知るはずがない
「このパッケージは今安全か」を判断するうえで最悪のフィルタを作ってしまった
Claude Codeにインターネット上のインストール用ソフトウェアを推薦させ、それをそのままインストールしているという話だろう
Claude CodeやどのLLMであれ、「このパッケージは今安全か」を判断するフィルタだと提案しているのは聞いたことがないし、述べられた理由も含めて、非常に悪いヒューリスティックに見える
setup.pyが自分のマシンで何を実行するかは分からない実行前にパッケージを実際に検査しているわけではないからだ
必要なのは、実行前にメタデータを取得して、どんなフックがあるか確認するツールだ
Claude Codeはほぼ毎日、ときには1日に何度も更新される
いつかAnthropicが侵害されたら、私たちは皆ひどい目に遭うだろう
とはいえ、最近は何もかもYOLOだ
GitHubで4月20日に投稿されたこのメッセージを見かけたのだが、少し混乱している
"deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."もしその時点から問題を把握していたのに今まで警告していなかったのだとしたら、本当に嫌だ
もっと知っている人が明確に説明してくれるとありがたい
https://github.com/Lightning-AI/pytorch-lightning/issues/216...
それ以前に影響を受けた配布物はなく、流出についても把握していませんでした
GitHub上の元のリリースには問題はありませんでしたが、混乱を防ぐために取り下げています