【ITニュース解説】Anatomy of a Supply Chain Heist: The Day 'chalk' and 'debug' Became Crypto-Thieves

2025年9月8日、世界中のWeb開発者が利用するJavaScriptのパッケージ管理システム「npm」で、大規模なセキュリティインシデントが発生した。この事件は「サプライチェーン攻撃」と呼ばれるもので、開発者が信頼して利用するごく普通のツールが、仮想通貨を盗むための武器に変えられてしまったというものだ。攻撃の標的となったのは、ターミナルの文字に色を付けるchalkや、デバッグ作業で多用されるdebugといった、週に合計で数十億回もダウンロードされる極めて人気の高いパッケージ群だった。この事件は、ソフトウェア開発の根幹にある「信頼」がいかにして悪用されうるかを示す重要な事例となった。

この攻撃の巧妙さは、システムの脆弱性ではなく、人間の心理的な隙を突いた点にある。攻撃者は、標的となった多数のパッケージを管理していた一人の著名な開発者、Josh Junon氏のアカウントを乗っ取ることに成功した。その手口は、npmの公式サポートを装った非常に巧妙なフィッシングメールから始まった。メールには「あなたのアカウントの2要素認証（2FA）が古いため、48時間以内に更新しないとロックされる」といった内容が書かれており、受信者に危機感と焦りを抱かせた。

Junon氏がメール内のリンクをクリックすると、本物そっくりの偽のnpmログインページが表示された。しかし、このサイトは単なる偽物ではなかった。これは「中間者攻撃（Adversary-in-the-Middle, AitM）」と呼ばれる手法を自動で行うプロキシとして機能していた。被害者がIDとパスワードを入力すると、偽サイトは即座にその情報を本物のnpmサイトに転送する。本物のサイトが2要素認証のコードを要求すると、偽サイトも同じ画面を表示して被害者に入力を促す。被害者が認証アプリのワンタイムパスワードを入力すると、それも即座に本物のサイトへ転送され、ログインが成功してしまう。この過程で、攻撃者は正規のログインセッション情報を抜き取り、被害者のアカウントを完全に乗っ取った。この手法は、一般的なワンタイムパスワード方式の2要素認証では防ぐことが難しく、ドメインと認証情報を暗号技術で結びつけるFIDO2/WebAuthnのような、より強固なフィッシング耐性を持つ認証方式の重要性を示している。

アカウントを乗っ取った攻撃者は、パッケージに「クリプトクリッパー」と呼ばれるマルウェアを仕込んだ。これは、ユーザーのコンピュータ上で仮想通貨取引をハイジャックすることを目的としたプログラムだ。このマルウェアは、開発者のコンピュータではなく、汚染されたパッケージを使って作られたウェブサイトを訪れた一般ユーザーのブラウザ内で実行されるように設計されていた。その手口は非常に洗練されていた。まず、ブラウザの通信機能を乗っ取り、ウェブサイトがサーバーから受け取ったデータに仮想通貨のウォレットアドレスが含まれていないかを監視する。もしアドレスが見つかれば、それを攻撃者のアドレスにこっそり書き換えてから画面に表示させる。さらに、MetaMaskのような仮想通貨ウォレットの拡張機能が使われていることを検知すると、より積極的な攻撃に移行する。ユーザーが送金トランザクションを承認しようとするまさにその瞬間に、送金先のアドレスを攻撃者のものにすり替えるのだ。

このマルウェアの最も狡猾な点は、すり替える攻撃者のアドレスの選び方にあった。攻撃者は事前に多数のウォレットアドレスを用意しており、ユーザーがコピーした正規のアドレスと視覚的に最も似ている（文字列の差異が最も少ない）ものを自動で選んで差し替えた。これは「レーベンシュタイン距離」というアルゴリズムを利用したもので、人間がぱっと見で違いに気づくことを極めて困難にしていた。これらの悪意のあるコードは、発見を免れるために「難読化」という処理が施され、人間にも機械にも解読しにくい状態にされていた。

幸いにも、この攻撃はセキュリティコミュニティの迅速な対応により、悪意のあるパッケージが公開されてから約2時間で発見され、npmの公式レジストリから削除された。そのため、攻撃者が実際に盗み取った仮想通貨の額はごくわずかだった。しかし、本当の被害はそこではなかった。この事件により、世界中の何千もの開発チームが、自社のシステムが影響を受けていないかの調査やクリーンアップといった緊急対応に追われた。この世界規模での生産性の低下こそが、真の損害と言える。さらに、この攻撃は「Sonatype Nexus」のような社内向けプロキシリポジトリが抱えるリスクを浮き彫りにした。多くの企業では、外部のパッケージを社内のサーバーに一時保存（キャッシュ）している。悪意のあるパッケージが公開されていたわずかな時間内に社内サーバーがそれをダウンロードしてしまうと、公式レジストリから削除された後も、社内では汚染されたパッケージが配布され続けてしまう危険性がある。

この事件は、ソフトウェア開発に関わる全ての人々に重要な教訓を残した。まず開発者個人としては、package-lock.jsonのようなロックファイルを適切に管理し、常にロックファイルに基づいたクリーンなインストールを行うことが重要だ。また、自身のアカウントを守るために、フィッシング耐性のあるFIDO2/WebAuthnのような強固な多要素認証を積極的に採用すべきだ。組織としては、開発パイプラインに依存関係を自動でスキャンする仕組みを導入し、脆弱性が見つかった場合にはビルドを自動的に停止させるような対策が求められる。オープンソースソフトウェアのエコシステムは、開発者間の信頼の上に成り立っている。しかし、この事件は、その信頼が常に悪用される危険性と隣り合わせであることを示した。これからの開発では、ただ信頼するだけでなく、常に「検証する」という姿勢が不可欠となる。