# オープニング #我が家の防災対策 どうもー。セキュリティジョッキーの松野です。 御社のセキュリティ企業を立ち上げて、300人以上のセキュリティ人材を排出した 屈指のセキュリティ企業家である私、松野が、東京都関連のセキュリティ組織で働きつつ、 サイバーセキュリティの最新ニュースについて解説しております。 ということでね、今日は我が家の防災対策に関する話なんですけども、 そうですね、いろいろ思い出してみたんですけども、大した防災対策はできてないなぁというふうに思いました。 見渡してみるとですね、いわゆる突っ張り棒というんですかね、 棚が目の前にあるんですけども、その突っ張り棒が若干緩んでるなぁというので、 この後直したいなというふうに思っています。 昨年末までですね、社長をやらさせていただいていた会社で、宮崎にオフィスがあったんですけども、 非常に大きな地震がありまして、 当時ですね、10階にオフィスがありましたので、本当にですね、いろんなものが倒れて、 天井もですね、落ちてきたところもありました。 何よりですね、サーバールームがありますので、そこでですね、 業務をやっている従業員の方のシステムがダウンしないようにというので、 瞬時にですね、そこに飛び込んだということを今思い出しました。 こういった非常時こそですね、突砂の判断というのはですね、 普段何を大切にしているかということが露呈しますので、 まずはですね、身の安全というか、命大事にというところはですね、 皆さんも気をつけていただければと思います。 はい、ということで今回はJavaScriptエコシステムで発生した 大規模インシデントについて取り上げております。 この放送を通じてリスナーの皆さんは、今回のインシデントで何が起きたのか、 どのように検出や対応をすべきかについて理解を深めていただければと思います。 それではどうぞ! # Nxおよび一部のサポートプラグインの悪意あるバージョンが公開 NXおよび一部のサポートプラグインの悪意あるバージョンが公開。 8月27日、NXおよび関連プラグインの悪意あるバージョン公開に関するセキュリティアドバイザリが、 NRWL NXリポジトリで発表された。 こちらの記事を簡単に解説お願いできますでしょうか。 はい。今回のインシデントは、ある主要なJavaScriptパッケージの悪意あるバージョンがパッケージ公開レジストリに公開され、 インストール時に実行されるスクリプトがユーザー環境を操作して認証情報を収集し、 収集した情報をユーザーのソース管理アカウント下に自動で公開するというものです。 原因はプロジェクトの継続的インテグレーションで導入されたワークフローにバッシュインジェクション脆弱性があり、 プルリクエストのタイトルを介して任意コードが実行された点にあります。 さらに問題を拡大したのは、そのワークフローが外部からのプルリクエストで高い権限で実行され、 公開処理を担う別のパイプラインの機密トークンが流出した可能性が高いことです。 初動では問題のバージョンがレジストリから削除され、公開トークンの無効化や脆弱ワークフローの撤回、 被害の有無を確認するためのログ調査とトークンパスワードのローテーションが指示されました。 再発防止としては、ワークフローの権限見直し、 外部プルリクでのワークフロー実行の事前承認、二要素認証の義務化、公開フローの安全化や静的解析の導入などが挙げられています。 ポストインストールスクリプトって具体的にどのように動くんでしょうか? はい。ポストインストールスクリプトはパッケージをインストールした直後に実行される任意のシェルコマンドやノードスクリプトです。 通常はビルドやセットアップに使われますが、悪意あるコードが仕込まれると、 インストールした端末上で任意のファイルアクセスやネットワーク送信が可能になります。 今回のように依存関係の解決やIDE拡張が自動的にインストールを起こす経路があると、利用者の意図しないタイミングで実行されます。 どうやってワークフローの脆弱性が悪用されたのですか?背景を教えてください。 はい。問題のワークフローはプルリクエストのタイトルをそのままシェルで評価する処理をしており、 タイトルに特殊文字やコマンドを入れられるとシェル注入が発生します。 さらにそのワークフローは外部プルリクをトリガーした際に高い権限で実行され、リポジトリ用の短期トークンを持っていました。 その結果、注入経由で公開用パイプラインを操作し、レジストリ公開に使うトークンを外部へ送信されてしまったと考えられます。 自分が被害に遭っているかどうか、どう検出すればよいですか? はい。まずソース管理プラットフォームの監査ログで、シンギュラリティリポジトリを含むリポジトリ作成履歴を確認してください。 もし該当するリポジトリが見当たらない場合でも、プラットフォーム側で削除・非表示にされている可能性があるため、サポートに問い合わせて中身を取得してください。 ローカルでは//inventory.txtの存在を確認し、存在すればそのファイルにマルウェアが読み取ったパス一覧が含まれている可能性が高いです。 加えて//.bashrc、//.gshellrcの不審な追記や知らないトークンの存在もチェックしてください。 被害があった場合の具体的な初動対応は何をすべきですか? はい。被害が疑われる場合は、速やかにすべての関連する資格情報をローテーションしてください。 ソース管理トークンやパッケージレジストリのトークン、CI、CDに設定されたシークレット、環境変数などを無効化して新しいものに差し替えるのが優先です。 GHCLIなどの連携アプリのアクセス権を取り消し、端末上の不審なファイルやRCファイルの改変を削除し、必要ならパスフレーズやパスワードも変更します。 組織内レジストリを運用している場合は、影響バージョンを即時削除してください。 運用側として再発を防ぐにはどんな施策が有効ですか? はい。再発防止ではワークフローの最小権限化と外部プルリクに対するワークフロー実行承認の導入が重要です。 秘密はCI環境で直接参照しない設計、信頼できる発行者向けの公開プロセスや二要素認証の義務化、パッケージの署名やプロパティの検証を導入してください。 なるほど。今回はパッケージのポストインストールに悪意あるコードが混入し、CIワークフローの権限設定とシェル注入で公開用トークンが抜かれた事件だったんですね。 被害確認は監査ログやスラッシュテンプスラッシュインベントリー.テキストの確認、被害があればトークンとパスワードの即時ローテーション、ワークフローの権限最小化や外部プルリクの承認導入が重要ということがよく分かりました。 また一つ勉強になりました。 # エンディングと今日のまとめ はい、ということでいかがでしたでしょうか。 今回のNXに関するインシデントなんですけれども、 僕もですね、現場で対応したことがありましたので、 その観点から補足をさせていただきますと、 このNPM関連のですね、レポジトリで改ざんがあったというインシデントはですね、 今回が初めてではなくてですね、 そういったことからですね、最新のパッケージをインストールしないような対策をしている方も多くいらっしゃるんじゃないかと思います。 それでもですね、今回被害が発生してしまっているのは、 このVS Codeの拡張機能ですね、NXコンソールというものがあるんですけれども、 こちらのアップデートでですね、被害に遭ってしまっているという方が多くいらっしゃるようです。 公式のドキュメントにも書かれているんですけれども、 やはりですね、このVS Codeに限らずですけれども、 Chromeだったりとか、いわゆる拡張機能、エクステンションプラグインと、 この類はですね、いわゆるインシデントにつながりやすいというのが、 今回も露呈してしまったということになります。 ですので、VS Codeをお使いでない方も含めてですね、 いわゆる本体とは別の拡張機能のセキュリティ対策、バージョン管理ですね、 こちら、しっかりと行ってくださいますようお願いいたします。 今日の10分セキュリティラジオは、月曜から金曜の朝7時15分に配信しております。 そして、わからないことは今すぐ聞こう、何でも聞ける、 セキュラチー製作室は、水曜夜8時から絶賛生放送中です。 さらに土曜日は、セキュラチーAIミーションのまとめチャンネルを放送しております。 ぜひこちらも聞いてみてください。 それではまた、次回のレギュラー配信でお会いしましょう。 セキュリティジョッキーの松野でした。See you!