今回は、JavaScriptエコシステムで大きなインシデントが発生したニュースを取り上げます。開発者が普段利用するパッケージに悪意あるコードが混入し、インストール時にファイルシステムを走査して認証情報を収集、ユーザーのアカウント下にリポジトリを作成して情報を送信するという重大な事象です。本編では、何が起きたのか、どのように検出・対応すべきか、再発を防ぐための実務的な対策をわかりやすく解説します。
8月27日、Nxおよび関連プラグインの悪意あるバージョン公開に関するセキュリティアドバイザリがnrwl/nxリポジトリで発表された。
こちらの記事を、簡単に解説お願いできますでしょうか?
今回のインシデントは、ある主要なJavaScriptパッケージの悪意あるバージョンがパッケージ公開レジストリに公開され、インストール時に実行されるスクリプトがユーザー環境を走査して認証情報を収集し、収集した情報をユーザーのソース管理アカウント下に自動で公開するというものです。原因はプロジェクトの継続的インテグレーションで導入されたワークフローにバッシュインジェクション脆弱性があり、プルリクエストのタイトルを介して任意コードが実行され得た点にあります。さらに問題を拡大したのは、そのワークフローが外部からのPRで「高い権限」で実行され、公開処理を担う別のパイプラインの機密トークンが流出した可能性が高いことです。初動では問題のバージョンがレジストリから削除され、公開トークンの無効化や脆弱ワークフローの撤回、被害の有無を確認するためのログ調査とトークン・パスワードのローテーションが指示されました。再発防止としては、ワークフローの権限見直し、外部PRでのワークフロー実行の事前承認、2要素認証の義務化、公開フローの安全化や静的解析の導入などが挙げられています。
質疑応答
postinstallスクリプトって具体的にどのように動くんでしょうか?
postinstallスクリプトはパッケージをインストールした直後に実行される任意のシェルコマンドやNodeスクリプトです。通常はビルドやセットアップに使われますが、悪意あるコードが仕込まれるとインストールした端末上で任意のファイルアクセスやネットワーク送信が可能になります。今回のように依存関係の解決やIDE拡張が自動的にインストールを起こす経路があると、利用者の意図しないタイミングで実行され得ます。
どうやってワークフローの脆弱性が悪用されたのですか、背景を教えてください?
問題のワークフローはプルリクエストのタイトルをそのままシェルで評価する処理をしており、タイトルに特殊文字やコマンドを入れられるとシェル注入が発生します。さらにそのワークフローは外部PRをトリガーした際に高い権限で実行され、リポジトリ用の短期トークンを持っていました。その結果、注入経由で公開用パイプラインを操作し、レジストリ公開に使うトークンを外部へ送信されてしまったと考えられます。
自分が被害にあっているかどうか、どう検出すればよいですか?
まずソース管理プラットフォームの監査ログで「s1ngularity-repository」を含むリポジトリ作成履歴を確認してください。もし該当するリポジトリが見当たらない場合でも、プラットフォーム側で削除・非表示にされている可能性があるためサポートに問い合わせて中身を取得してください。ローカルでは /tmp/inventory.txt の存在を確認し、存在すればそのファイルにマルウェアが読み取ったパス一覧が含まれている可能性が高いです。加えて .bashrc/.zshrc の不審な追記や知らないトークンの存在もチェックしてください。
被害があった場合の具体的な初動対応は何をすべきですか?
被害が疑われる場合は速やかに全ての関連する資格情報をローテーションしてください。ソース管理トークンやパッケージレジストリのトークン、CI/CDに設定されたシークレット、環境変数などを無効化して新しいものに差し替えるのが優先です。gh CLIなどの連携アプリのアクセス権を取り消し、端末上の不審なファイルや rc ファイルの改変を削除し、必要ならパスフレーズやパスワードも変更します。組織内レジストリを運用している場合は影響バージョンを即時削除してください。
運用側として再発を防ぐにはどんな施策が有効ですか、(情報公開はどう扱えばよいですか?
はい。再発防止ではワークフローの最小権限化と外部PRに対するワークフロー実行承認の導入が重要です。秘密はCI環境で直接参照しない設計、信頼できる発行者向けの公開プロセスや2要素認証の義務化、パッケージの署名やプロパティの検証を導入してください。公開時の情報は被害状況と検出方法、影響範囲、対応手順を明確に示し、被害者への個別通知とサポート窓口を用意することが信頼回復につながります。
まとめ
今回は、パッケージのpostinstallに悪意あるコードが混入し、CIワークフローの権限設定とシェル注入で公開用トークンが抜かれた事件だったんですね。被害確認は監査ログや /tmp/inventory.txt の確認、被害があればトークンとパスワードの即時ローテーション、ワークフローの権限最小化や外部PRの承認導入が重要ということがよくわかりました。また一つ、勉強になりました!


