00:00:00これは深刻な事態です。冗談ではありません。ここ数時間、非常に厳しい状況が続いています。
00:00:06というのも、Axiosに対して大規模なサプライチェーン攻撃が発生したからです。そうです、あのAxiosです。
00:00:14週間のダウンロード数が8,000万回を超える、あのライブラリです。
00:00:15さて、まず最初にすべきことがあります。
00:00:18皆さんが影響を受けているかどうかを確認するために、記事へのリンクを添付しました。
00:00:23詳細はすぐにお話ししますが、これは重要です。自分が影響を受けたかどうかを確認するために、
00:00:27下のリンク先にアクセスして、お使いのオペレーティングシステムに応じたコマンドを
00:00:32実行してください。macOS、Linux、Windows、すべてが対象です。
00:00:37もし影響を受けている可能性があるなら、これらのコマンドを実行してください。
00:00:40特に、これらの手順でシステムが侵害されていることが判明した場合は、
00:00:49シークレットのローテーション、パスワードの変更が必要です。認証情報やシステム上のAPIキーは、
00:00:55すべて盗まれたものと考えてください。
00:01:00パスワードも盗まれたと考え、すべて変更し、APIキーを無効化してください。これは本当に重要です。
00:01:07さて、一体何が起きたのでしょうか？
00:01:09Axiosは、ご存知の通り非常に人気のあるJavaScriptライブラリです。例えばReactアプリから
00:01:17バックエンドAPIにHTTPリクエストを送信するために使用されます。
00:01:22ご覧の通り、非常に広く使われていますが、このライブラリに
00:01:28悪意のあるコードが注入されました。
00:01:29これは、そのライブラリを使用している「ウェブサイト」が影響を受けたという意味ではありません。
00:01:36そうではなく、そのライブラリをインストールした「システム」、つまり皆さんのMacBookや
00:01:41PC、あるいはウェブサイトをビルドしたVPSなどが侵害されたことを意味します。
00:01:50もしここ数時間の間に、npm installやbun install、npm update、bun updateなどを実行したなら、
00:01:57影響を受けている危険性が非常に高いです。
00:02:00繰り返しますが、影響の有無を確認するためのチェック手順を共有しました。
00:02:05では、具体的にどのようにしてこれが起き、サプライチェーン攻撃とは何なのでしょうか？
00:02:10将来、このような攻撃から身を守る方法についても後ほど共有します。
00:02:15ですがまずは、何が起きたのか、そしてサプライチェーン攻撃とは何かを理解しましょう。
00:02:20サプライチェーン攻撃とは、簡単に言えば、アプリケーションのコードを直接狙わない攻撃のことです。
00:02:24攻撃者は、皆さんのシステムやコードベースに直接侵入しようとするのではありません。
00:02:31その代わりに、アプリケーションコードが依存関係（デペンデンシー）を持ち、その依存関係自体も
00:02:37さらに別の依存関係を持っているという事実を利用します。
00:02:38つまり、この「依存関係の鎖」が存在し、攻撃はこの鎖をターゲットにします。
00:02:45つまり、皆さんのコードよりも「上流」で発生するのです。
00:02:48これらの依存関係のいずれかに、コード注入攻撃によって悪意のあるコードが入り込みます。
00:02:54これは、メンテナが皆さんを攻撃しようとしているからではありません。
00:02:58そうではなく、今回のように、メンテナのアカウントが乗っ取られ、
00:03:03攻撃者がそれを利用して、あるライブラリやパッケージに悪意のあるコードを注入するのです。
00:03:10すると、別のパッケージがそのライブラリを使用し、皆さんのコードがそのパッケージを使用したり、
00:03:16あるいは皆さんのアプリが直接その悪意のある依存関係を取り込んだりする可能性があります。
00:03:23いずれにせよ、依存関係の1つが突然、悪意のあるコードを含んだ状態で提供されることになります。
00:03:28そして、npm installなどを実行したり、アップデートを行ったりした瞬間に、
00:03:36その感染した悪意のあるパッケージがシステムにダウンロードされ、システム上で
00:03:41悪意のあるコードが実行されます。通常は「postinstall」スクリプトが悪用されます。
00:03:47ご存知ない方のために説明すると、npmにはスクリプトという仕組みがあります。
00:03:56私たちは皆、プロジェクトでこれを使っています。例えば開発サーバーを起動したり、プロジェクトをビルドしたり、
00:04:01テストを実行したりするためです。
00:04:04その中に、特に「postinstall」スクリプトというものがあります。Reactアプリを作る際には
00:04:11あまり使わないかもしれませんが、ライブラリでは頻繁に、あるいは時折、
00:04:17インストール後にシステム上で何らかのコードを実行するために使われます。通常は
00:04:23悪意のある目的ではなく、例えばコードをコンパイルしたり、そのライブラリに
00:04:31必要なバイナリを作成したり、ダウンロードしたライブラリを実際に使えるように
00:04:36システムを準備したりするために使われます。
00:04:40それがpostinstallスクリプトの本来の意図です。
00:04:42npm installなどでインストールされた後に実行されるべきコードを、パッケージ側で定義できるのです。
00:04:49そして、これこそがサプライチェーン攻撃において典型的に
00:04:55悪用されるポイントなのです。
00:04:57攻撃者はパッケージに悪意のあるコードを注入しますが、それは実質的に、感染したパッケージが
00:05:04インストールされると自動的に実行されるpostinstallスクリプトなのです。
00:05:10通常、そのコードは簡単には読めないように難読化されています。
00:05:14悪意のあるコードをスキャンするツールから逃れるために、Base64でエンコードされていたり、
00:05:20あるいは悪意のあるコード自体を後からダウンロードするようになっています。
00:05:24今回のAxiosへの攻撃のように、postinstallスクリプト自体には
00:05:30直接悪意のあるコードが含まれていない場合もあります。
00:05:32代わりに、サーバーに接続してそこからコードをダウンロードするのです。
00:05:36今回起きたのは、まさにそれでした。
00:05:37この攻撃で具体的に何が起きたのかについて、詳細なレポートがあります。
00:05:41詳細をすべて知りたい方は添付資料をご覧ください。そこから判明したのは、
00:05:45Axiosパッケージの2つのバージョン、1.14.1と0.30.4が侵害されたということです。
00:05:57攻撃者はAxiosパッケージのメンテナの1人のアカウントにアクセスし、
00:06:02そのアカウントを使ってAxiosの新しいバージョンを公開しました。
00:06:08そのバージョンには、ある依存関係が含まれており、そこに例のpostinstallスクリプトが入っていました。
00:06:14つまり、Axiosパッケージ自体にpostinstallスクリプトが含まれていたわけではなく、
00:06:19攻撃者によって作成された別のパッケージ「plaincryptojs」に含まれていたのです。
00:06:25このパッケージの唯一の目的は、悪意のあるコードをダウンロードして実行する
00:06:31postinstallスクリプトを持たせることでした。
00:06:32こうして、Axiosの依存関係に「plaincryptojs」を追加することで、Axiosは侵害されました。
00:06:39これは悪意のあるパッケージです。
00:06:40悪意のあるコードをダウンロードする以外の目的はなく、単にこの依存関係を
00:06:46Axiosに追加するだけで、攻撃はほぼ完了してしまいました。
00:06:52このパッケージはAxiosのソースコードのどこにもインポートされていません。
00:06:56ただpostinstallスクリプトがある、それだけです。
00:06:59先ほど言ったように、WindowsやLinux用のコードをダウンロードして実行できるようになりますが、
00:07:05その目的は何でしょうか？
00:07:06ええ、大量の情報を盗むことです。
00:07:08冒頭で述べたように、システムが影響を受けた場合、認証情報、APIキー、暗号化トークンなど、
00:07:14あらゆる重要なデータが、postinstallスクリプトによってダウンロードされたトロイの木馬によって
00:07:21収集され、外部に送信されてしまいます。
00:07:22これが今回の攻撃の手口です。
00:07:24過去の同様の攻撃も、このように行われてきました。
00:07:29さて、興味深い点があります。あ、その前に、この攻撃は今日の午前0時過ぎ、
00:07:36数時間前のUTC午前0時ちょうどに始まりました。
00:07:40数時間続き、Axiosのバージョン1.14.1と0.30.4の両方が、わずか40分以内、
00:07:50正確には39分以内に侵害されました。
00:07:53つまり、これは非常によく計画され、組織化された攻撃だったのです。
00:07:56明らかに、この追加パッケージの作成は攻撃開始の18時間前に行われていたと
00:08:03記憶しています。
00:08:04非常に緻密に計画されていました。
00:08:06ここで少し奇妙なのは、npmには「Trusted Publishing」という仕組みがあり、
00:08:14パッケージのメンテナが利用できる点です。
00:08:17この考え方は、新しいバージョンの公開プロセスを、明確に定義されたプロセスのみに
00:08:26制限するというものです。具体的には、特定のセットアップを行った
00:08:32サポート対象のCI/CDプロバイダー経由でのみ、ビルドと公開ができるようになります。
00:08:38これの目的は、たとえnpmアカウントの認証情報が盗まれたとしても、
00:08:46理論上、攻撃者は自分のマシンから新しいバージョンを公開することはできないはずです。
00:08:51そのプロセスを経る必要があるからです。
00:08:52もしメンテナのGitHubアカウントが侵害されれば、悪意のあるバージョンがGitHubに
00:08:59プッシュされ、デプロイワークフローがトリガーされて、Trusted Publishing経由で
00:09:06悪意のあるコードが公開される可能性はあります。
00:09:11しかし、今回のセキュリティレポートによれば、それは起きていないとのことです。
00:09:16というのも、Axiosチームは1.xブランチではこのTrusted Publishingを使用していますが、
00:09:210.30ブランチでは使用していません。
00:09:26しかしレポートによると、AxiosのGitHubリポジトリには、攻撃によるコミットは
00:09:33一切存在しなかったそうです。
00:09:40つまり、侵害されたバージョンのAxiosがGitHubにプッシュされたわけではありません。
00:09:44したがって、Trusted Publishingのプロセスはトリガーされるべきではありませんでした。
00:09:50レポートでは、攻撃者がAxiosの侵害バージョンを公開するために、有効期限の長い
00:09:56従来のnpmアクセストークンを入手したに違いないと述べています。なぜなら、
00:10:01リリースはnpm上にのみ存在し、GitHubには存在しなかったからです。
00:10:02もしかしたら、この推測が間違っているのかもしれません。GitHub経由だった可能性もあります。
00:10:05しかしもしレポートが正しいなら、どうやってそれが可能だったのか私には分かりません。
00:10:11理論上、Trusted Publishingが有効な場合、その方法での公開は
00:10:15できないはずだからです。npm側のセキュリティ脆弱性か、何らかの問題が
00:10:20あったのかもしれません。Trusted Publishingを有効にしていても、既存の
00:10:26長期有効トークンが使えてしまった、というようなことです。
00:10:27具体的にどうやって実行されたのかについては、私も突き止めることができませんでした。
00:10:32AxiosライブラリのGitHubイシューで、この攻撃が報告されている
00:10:39スレッドがあります。
00:10:40余談ですが、他にも多くのイシューが作成されましたが、それらは侵害されたメンテナの
00:10:45アカウントによって削除されてしまいました。
00:10:48このスレッドだけが残り、最終的に攻撃は阻止されました。影響を受けたメンテナは
00:10:52アカウントへのアクセス権を取り戻しました。
00:10:56そのスレッドの中で、メンテナは自分たちはTrusted Publishingを
00:11:03使っていると投稿しており、どうやって攻撃が成功したのか不明だとしています。
00:11:07ある説が共有されていますが、
00:11:09私の理解では、その説でもやはり悪意のあるバージョンをGitHubにプッシュする
00:11:16必要があります。しかし、結局のところ詳細は不明です。
00:11:20はっきりしているのは、侵害されたバージョンが公開され、npmに登録され、
00:11:25その結果、多くのシステムにダウンロードされ、情報を盗んだということです。
00:11:29週に8,000万回以上のダウンロードがあるとなれば、わずか数時間でも
00:11:35甚大な被害が出ます。
00:11:37もちろん、ダウンロード数は一日中均等に分散しているわけではありませんが、
00:11:44それでも膨大な数であり、この数時間の間に、数千、数万ものシステムが
00:11:51影響を受けたと推測されます。
00:11:55さて、これが最初のサプライチェーン攻撃というわけではありません。
00:11:59ここ数ヶ月、複数の攻撃が発生しています。
00:12:01昨年末には「Shy Hulu」攻撃という大きな攻撃があり、複数のパッケージが
00:12:08npm上で実行されました。それも同様のパターンで、悪意のあるコードが注入され、
00:12:16侵害されたパッケージをダウンロードしたシステムで実行され、認証情報などが
00:12:21盗まれました。
00:12:22それが1つの大きな事例です。
00:12:25さらに数日前には、Pythonのエコシステムでも同様の事件がありました。
00:12:31つまりJavaScriptに限った話ではありません。そこでは「lightllm」パッケージが影響を受けました。
00:12:37これは、1つの便利なインターフェースを通じてAIプロバイダーを簡単に利用できるようにする
00:12:43非常に人気のあるパッケージですが、これも同様の攻撃を受け、被害に遭いました。
00:12:49ですから、当然JavaScriptだけの問題ではありません。
00:12:52このような攻撃が増えている理由はいくつかあると思います。
00:12:57理論上、この種の攻撃は過去にも起こり得ましたし、おそらく起きていたでしょうが、
00:13:03明らかに最近、頻度が増しています。それにはいくつかの
00:13:08理由があると考えています。
00:13:11大きな理由の1つは、かつてないほど多くのコードが書かれ、生成されている時代に
00:13:17私たちがいるということです。
00:13:19様々な指標を見れば明らかです。
00:13:22例えば最近見たチャートでは、新しく作成されるGitHubリポジトリの数が
00:13:27過去最高を記録しています。これはもちろんAIの影響です。
00:13:31人々がプロジェクトに取り組み、コードを生成しています。
00:13:35以前よりもはるかに多くのコードが出力されており、それはつまり、非常に多くの
00:13:42プログラムが書かれ、生成されることで、攻撃対象領域（アタックサーフェス）が格段に広がったことを意味します。
00:13:47ターゲットが増えたのです。
00:13:48コードを書き、パッケージをインストールする人が増えました。
00:13:52そのため、攻撃者にとってこれまで以上に魅力的になっています。
00:13:54昔が魅力的でなかったわけではありませんが、今は攻撃できる対象が
00:13:59これまでになく多いのです。これが1つの大きな理由です。
00:14:00単にこれらの攻撃を実行するメリットが増えたということですが、理由はそれだけではありません。
00:14:03もう1つの理由は、これもやはりAIに関連していますが、
00:14:07AIの助けを借りることで、このような攻撃の実行自体が容易になった可能性があります。
00:14:15悪意のあるコードも当然、AIを使って生成し、書くことができるため、
00:14:21このような攻撃に必要な技術的スキルが、以前よりも手に入りやすくなったと
00:14:28言えるでしょう。もっとも、以前からダークネットでこうしたスクリプトや
00:14:33トロイの木馬を買うことはできましたが、より身近になったと言えます。
00:14:40AIの「良い面」だけではありません。より多くの人がソフトウェアを構築し、
00:14:46アイデアをビジネスに変えることができるようになりましたが、それは「悪いこと」についても同じです。
00:14:50AIのおかげで、より多くの人がコードに関連した悪事を行えるようになっています。これが理由の1つです。
00:14:55また、パッケージやライブラリのメンテナがプルリクエストの山に
00:15:01埋もれているという点も指摘できます。
00:15:02これは現代の大きな問題です。オープンソースのメンテナであれば、
00:15:07かつてないほどのプルリクエストが届きます。そのため、マージするものに対して
00:15:13十分な注意を払えなくなる可能性があります。
00:15:14はっきりさせておきますが、今回の件はそれが原因ではありません。
00:15:16今回のAxiosへの攻撃は明らかにアカウントの侵害によるものでした。しかし理論的には、
00:15:22メンテナが見落としたり、あるいは完全に自動化されたコードレビュープロセスが
00:15:29それを見逃したりして、悪意のあるコードや依存関係をマージしてしまう
00:15:34可能性は十分に考えられます。
00:15:38AIだけに頼っているような場合です。
00:15:40繰り返しますが、今回は違います。しかし、将来的に攻撃者が「人々が中身を細かく見ない」
00:15:45ことを突いて、コードベースに悪意のあるコードを注入することはあり得るでしょう。
00:15:51さらに、Claude CodeやOpenClaudeなどのツールをシステムで使って、
00:15:56ソフトウェア開発だけでなくシステム全体の管理など、あらゆる作業を
00:16:01行わせている場合、当然、特定のタスクをこなすために、
00:16:09それらのツールがスクリプトを書き、コードを実行することを選択するかもしれません。
00:16:15そして、生成されたコードがAxiosのような依存関係に頼ることもあるでしょう。
00:16:20ここでも攻撃対象領域が広がっています。これが私の最初の主張に繋がりますが、
00:16:24従来のソフトウェア開発の枠を超えたところでも同様です。こうしたあらゆる理由、
00:16:30そして私が思いつかなかった他の多くの理由によって、これらの攻撃はより儲かり、
00:16:37実行しやすく、魅力的なものになっています。ですから、将来的にこうした攻撃が増えるのは確実です。
00:16:43では、このような攻撃を防ぎ、自分を守るために何ができるでしょうか？
00:16:47大きなセキュリティ対策の1つとしてできることは、アプリケーションを開発している
00:16:55すべてのプロジェクトにおいて、依存関係の管理にnpmではなく
00:17:02pnpmのようなツールを使い、pnpm-workspace.yamlファイルに「minimum release age」の設定を追加することです。
00:17:09Bunにも同様の機能があります。パッケージマネージャーとしてBunを使っているなら、
00:17:15bunfig.tomlファイルを作成して「minimum release age」の設定を追加できます。これは何をするものでしょうか？
00:17:21これは単純に、パッケージをどのようにインストールする場合でも、
00:17:27少なくとも設定した期間を経過したパッケージ（またはそのバージョン）のみをインストールするようにするものです。
00:17:34例えば、あるパッケージが5時間前に侵害されたとしても、「少なくとも3日経過した
00:17:39バージョンのみをインストールする」というルールがあれば、安全でいられます。そういう考え方です。
00:17:46残念ながら、本家のnpmには現在この機能はありません。はっきりさせておきたいのは、
00:17:51対象は依然としてnpmにホストされているパッケージだということです。問題はnpmのリポジトリではなく、ツールの話です。
00:17:56もちろん、Bunやpnpmを使ってnpmからパッケージをダウンロードすることができます。
00:18:03npmコマンドそのものの代わりにこれらのツールを使えば、こうした設定を活用して
00:18:08余分なセキュリティ層を追加できます。通常、これまでこうした攻撃は
00:18:14数時間以内に発見されてきました。ですから、例えば3日間の猶予期間を設ければ、
00:18:20ほとんどの攻撃はその時までに発見され、収束しているはずです。もちろん100%安全では
00:18:25ありません。攻撃がもっと長く続くこともあり得ますが、明らかなアドバンテージになり、
00:18:32やっておく価値は十分にあります。さらに安全性を高めるために、
00:18:39Dopplerのようなソリューションの利用を検討すべきです。これは広告ではありません。あくまで一例です。
00:18:44実際、私は自分用に自作の代替ツールを使っていますが、これらはシークレットを
00:18:49管理するためのサービスやツールです。例えばOpenAIのAPIキーなどは、.envファイルに
00:18:55置くこともできますが、Dopplerのようなサービスを使って暗号化して保存する方が
00:19:02賢明です。彼らのサーバー、あるいは自分で所有するVPSでホストし、
00:19:08アプリケーションが必要な時にその環境に注入します。そうすれば、もしシステムに
00:19:13すべての.envファイルを取得して情報を抜き出すようなトロイの木馬が入り込んだとしても、
00:19:20そこには何のシークレットも見つかりません。それが狙いです。つまり、シークレットを
00:19:25システム上のテキストファイルとして保存しない（.envファイルも結局は単なるテキストファイルですから）
00:19:32代わりに、別の場所で暗号化して管理することを検討すべきです。
00:19:36これにも様々な解決策がありますが、一考の価値があります。
00:19:40さらに安全を期すなら、開発環境自体を切り離すことも考えられます。
00:19:45自分のMacBookやPC上に環境を置くのではなく、VPSやMac miniなどに環境を構築し、
00:19:50SSHなどで接続して作業する、あるいはDockerコンテナ内で作業する方法です。そうすれば、
00:19:56たとえそこで悪意のあるコードが実行されたとしても、影響を受けるのはそのコンテナや
00:20:02VPSだけで、システム全体には及びません。システム全体のパスワードなどを
00:20:07盗まれるのを防ぎ、被害範囲（ブラストライディアス）を小さく抑えることができます。
00:20:13こうした攻撃は今後も繰り返されるでしょう。もちろん、パッケージの公開プロセスを
00:20:21安全にするための仕組みは、ますます改善されていくはずですが、
00:20:27このような攻撃が二度と起きないという保証はどこにもありません。ですから、パッケージの利用者として、
00:20:33自分のシステムを保護し、多層的な防御策を講じる必要があります。そうすることで、
00:20:39侵害されたパッケージをダウンロードしてしまう確率を下げ、もしそうなっても被害を最小限に食い止めることができます。
00:20:45これについては、今後もメインチャンネルやAcademyチャンネルの動画で詳しくお話しします。
00:20:50とにかく、皆さんも気をつけてください。今回の攻撃の影響を受けていないか確認しましょう。
00:20:55先ほど言ったように、ここ数時間は本当に大変な状況でした。