npm IronWormマルウェアが36パッケージに感染、Trusted Publishing悪用で自己増殖

「うちのプロジェクトもnpm経由でビルドしているけど、どこまで巻き込まれているの？」
「Trusted Publishingを使っていればサプライチェーン攻撃は安全だと思っていたのに…」

チップス

ボス、npmにまた怪しいパッケージが混ざってたんでしゅよね。IronWormって何でしゅか？

ボス

Rust製のinfostealerだ。最大の特徴は、自分自身でnpmに新しい悪意あるパッケージを公開していく『自己増殖』だな。

本記事ではIronWormの実態と、なぜTrusted Publishingが回避策にならないのか、そして開発組織が今夜から取れる対策を整理します。
サプライチェーン攻撃は外部ライブラリだけの問題ではなく、自社のCI／CD設計にも踏み込んで考える必要があります。

読み終えた時には、自社CIへの侵入経路の見直しと、当面の検知ポイントが整理できます。

IronWormが起こした事件の概要

まずは攻撃の入口と、IronWormの中身を順に押さえます。

asteroiddaoアカウント乗っ取りから36パッケージ感染へ

BleepingComputerの報道によれば、攻撃の起点は『asteroiddao』というnpm公開者アカウントの乗っ取りでした。
攻撃者はこのアカウント経由で、Rust製のELFバイナリを同梱したパッケージを公開し、preinstallスクリプトでインストール時に自動実行させる仕組みを仕込みました。
結果として36パッケージにIronWormが混入し、研究者の検知で大規模拡散直前に押さえ込まれた格好です。

86環境変数と20認証ファイルを狙う設計

IronWormはRustで実装されたinfostealerで、開発者環境に存在しがちな鍵情報を網羅的に拾い上げる挙動を持ちます。
標的にしている主な情報は以下のとおりです。

チップス

ローカルの.envファイルもごっそり持っていかれるってことでしゅか？

ボス

そういうことだな。しかも単に盗むだけではなく、盗んだ認証情報で次のパッケージを侵害していく。これがIronWormの厄介な点だ。

Trusted Publishingを悪用する自己増殖と防御策

次に、IronWormが「自己増殖」と呼ばれる所以と、開発組織が取れる現実的な対策を整理します。

npm Trusted Publishingのシークレットが武器化される

注目すべきは、IronWormが窃取した認証情報のなかに『npm Trusted Publishingワークフロー関連のシークレット』が含まれている点です。
これにより、別の開発者アカウントや別パッケージのリリース経路を乗っ取り、自動的に追加パッケージへIronWormを横展開できる構造ができ上がります。
Trusted Publishing自体は本来、長期トークン削減のためのセキュリティ強化機能ですが、ワークフロー側のシークレットが平文で漏れれば攻撃者の足場として機能してしまいます。

開発組織が取るべき多層防御

preinstallスクリプトを契機にした即時感染を断つには、依存導入そのものを見直す多層防御が要ります。
優先度の高い順で、取り組みやすいアクションを整理します。

チップス

preinstallを切るだけで、かなり食い止められるんでしゅね！

ボス

そうだな。詳しい感染パッケージ一覧はBleepingComputerの報道を参照するといい。

まとめ

IronWormは、開発者アカウント乗っ取りからpreinstall実行、認証情報窃取、自己増殖までを一連の流れに組み込んだサプライチェーン攻撃の進化形です。
npm Trusted Publishingやクラウド資格情報のように『便利な仕組み』が、シークレット管理の運用次第で逆風になる構造を改めて思い出させます。
自社CIの依存導入とシークレット運用を今一度点検し、サプライチェーン防御を一段階引き上げていきましょう。