- 9月8日、人気の npm パッケージに対する マルウェア挿入 が検知された
- 影響を受けたパッケージは合計 18件 で、世界全体で 週20億回以上のダウンロード を記録している
- 攻撃者は Webサイト訪問者のブラウザ 上で、暗号資産および Web3 の処理を 密かに乗っ取り、ウォレット内の承認や資金の流れ を攻撃者アカウントへ 切り替える コードを含めていた
- 主要パッケージのファイル (
index.js) に 難読化された JavaScript コード が追加されていたことが確認された
- 一連の事案は 対象パッケージの更新と同時に始まり、現在コミュニティが対応を進めている
事件の概要
- 9月8日 13:16 UTC 時点で、Aikido のセキュリティ監視フィードにより、マルウェアを含む複数のパッケージが npm にアップロードされる 現象が確認された
- これらのパッケージは npm で非常に人気が高く、1週間で20億回以上のダウンロード数 を記録している
攻撃手法と内容
- 悪意ある更新の後、該当パッケージを利用する Web サイトの 訪問者ブラウザ上で JavaScript マルウェアが秘密裏に実行される仕組み が確認された
- このコードの目的は、暗号資産および Web3 活動の監視、ウォレット操作の改ざん、送金先アドレスの無断変更 である
- ユーザーは画面上で特別な変化がないまま、資金や承認権限が 攻撃者の指定した暗号資産アドレスへ送られる 可能性がある
マルウェアの詳細分析
- 代表例として、
is-arrayish などでは index.js ファイルが改ざんされ、難読化された複雑な JavaScript が挿入されていた
- コード内では
window.ethereum インターフェースを利用して ウォレットのアカウント情報を確認 し、攻撃コードの発動条件を確認する手順を踏んでいた
- 内部には複数の暗号資産アドレス（ビットコイン、イーサリアムなど）と関数ロジックが含まれており、ウォレットアドレスやトランザクション詳細を攻撃者アドレスへ置き換える 機能が実装されていた
- これにより、実際のユーザーの暗号資産が 気付かないうちに流出・不正送金 されるリスクが生じている
現在の状況とコミュニティの対応
- 問題の 悪意あるパッケージのバージョンは主要な npm リポジトリから迅速に削除 されている
- IT／オープンソースコミュニティでは、関連パッケージの利用停止とアップグレード案内、追加感染の検知および対処が活発に進められている
- 今回のハッキング事故により、パッケージサプライチェーンのセキュリティ、コード難読化の検知、Web3 ブラウザ拡張の保護 に対する警戒感が大きく高まるきっかけとなっている
2件のコメント
> 2023年9月8日、
幻覚によって日付が誤って出ていました。2023年の話ではなく、今の話ですね。
npmはかなり頻繁にハッキングのニュースを耳にする気がします。問題がありそうです。
Hacker Newsの意見
はい、やられました。本当に恥ずかしいし、皆さんに申し訳ないです。詳細はこちらとこちらを見てほしいです。影響を受けたパッケージの一覧も載せてあります。今回の攻撃は標的型攻撃のようです。コメント編集可能時間が終わるまで継続的に更新する予定です。Chalkパッケージは復旧しましたが、他はまだ乗っ取られたままです（8日 17:50 CEST）。NPMからはまだ何の連絡もありません。私のNPMアカウントにはアクセスできず、パスワード復旧機能も動きません。今の私にできるのは待つことだけです。サポートチームのメールは npmjs dot help から来ていて、とてももっともらしく見えました。言い訳ではありませんが、疲れた朝で、ひとつでも用事を片付けようとして、いつものように公式サイトへ直接行かずリンクを押してしまったのがミスでした（モバイルだったのもあると思います）。今回の攻撃で影響を受けたのはNPMだけで、
/debug-jsリンクに今後も更新を載せる予定です。改めて本当に申し訳ありませんこんなストレスの大きい状況で、迅速かつ透明性の高い対応をしていて本当に模範的です。自分はもうフィッシングには引っかからないと思っていても、いくつか付け加えるなら: 1) メールのリンクからは絶対にログインしないこと。フィッシングと正規メールの見分けは本当に難しく、引っかからない唯一の方法は最初から試さないことです。2) U2F/Webauthnのセキュリティキーを二要素認証に使えば、フィッシング対策としてはほぼ完璧です。TOTPはそうではありません。結局、人は疲れていたり忙しかったりするといつでもミスをします。今回はたまたまその標的になっただけです。改めて、見事な対応だったと言いたいです
sindresorhus の案内によると、自分の依存ツリーにマルウェアがあるかどうかは次のコマンドで確認できます:
rg -u --max-columns=80 _0x112fa8（ripgrep が必要、インストールはbrew install rg）。元コメントも参照してください昔、大学時代に酔った状態でフィッシング被害に遭ったことがあります（かなり前の話ですが）。誰でも被害者になり得ます。ただ、NPMの対応があまりにも遅いのは意外です。こういう遅れは攻撃者にさらに有利に働くと思います
Socket は今回の件をすぐに検知していました。関連ブログでも扱っています。今回の件は残念ですが、オープンソースのエコシステムが非常に速く対応した点は評価できます。こうした事件を見ると、パッケージスキャンがなぜ重要なのかを改めて実感します
早く警告してくれてありがとう。porkbun にドメイン遮断の依頼メールを送りました
このマルウェアのペイロードには、十分に注目されていない巧妙な点があります。それはウォレットアドレスをランダムに置き換えるのではなく、正しいアドレスと自分の一覧にある各アドレスとの Levenshtein 距離を計算し、最も似ている攻撃者のウォレットを選ぶことです。つまり、アドレスの先頭と末尾だけをざっと確認するという一般的な安全習慣を突破するよう設計されています。この特異な機能を含め、ペイロード全体を難読化解除して分析し、詳しくまとめた記事があります。皆さん気をつけてください
記事のある部分が分かりにくいのですが、package-lock.json は特定バージョンを「厳密に」固定するものだと思っていました。package.json では「x バージョン以上」のような指定ができますが、lockfile には各依存関係の指定バージョンと tarball URL が直接入っています。lockfile があるなら、CI 環境でパッケージが自動更新されることはないはずで、npm/yarn/pnpm の lockfile の挙動を私が誤解しているのか気になります。npm公式ドキュメントの引用も参照してください
ハッシュ値を各文字ごとの色（前景/背景色）で、そのハッシュとインデックスから決めた配色で表示すれば、見た目を似せて作られたハッシュの区別がずっと簡単になると思います
この手法が特定のハッカーグループと関連していると分かる情報はあるのでしょうか
この攻撃コードは巧妙ではありますが、実際にはWebでは類似アドレス攻撃と何十年も戦ってきたわけで、これはそのより動的な版にすぎません。そこを過剰に持ち上げるのには賛成できません。正直、この分析記事全体がむしろAIが書いたような印象で、慎重な分析には見えません
12日前に Nx 側でもまったく同じことが起きたとき、似たコメントを残しました。これは一人の失敗ではなく、業界全体の失敗です。サプライチェーン攻撃は影響が非常に大きく、しかも実際にはすでに解決済みの問題だと思っています。私たちはソフトウェア開発者なのだから、標準的なセキュリティ対策（コード署名、アーティファクト署名、アカウント異常行動の検知、2FA など）を全面的に適用すれば防げます。いまだにすべてのパッケージングプラットフォームがこれをやっていないのは技術的限界ではなく、誰も強制していないからです。AIの発展と実地攻撃の成功の積み重ねで、今後さらに深刻になるでしょう。今こそ強力なセキュリティ基準を「義務化」すべきだと思います
こうしたセキュリティ対策にはトレードオフがあります。たとえばヒューリスティックや証明ベースの仕組みを適用すると、かなり多くの自動化システムや一般ユーザーが締め出される可能性があります。SMS ベースの 2FA は安全性が弱く、メールもフィッシングの危険があります。TOTP はオープンスタンダードとして使う場合に意味がありますが、それでもフィッシングを完全には防げません。ハードウェアベースの認証だけが唯一有効ですが、大規模プラットフォームでは現実的に適用が難しいという限界があります
「セキュリティ標準をちゃんと守れば全部防げる」というほど単純ではありません。どれだけ完璧な対策を入れても、人間がミスをすればシステム全体が脆弱になります。完全に安全なシステムは存在しません。AIの進歩でフィッシングメールが本物と見分けられなくなりつつありますが、その一方でAIを使ってこうした攻撃自体をよりよく検知することもできます。結局はAIで防御するしかないのでしょう
昔は Windows を狙うハッキングが多かったですが、今では JavaScript と Python の開発者人口のほうがはるかに多いです。今後こうした攻撃はますます悪化するでしょう
NPM にもある程度の責任があると思います。さまざまな外部セキュリティベンダーやスタートアップはこうした悪質な活動を素早く見つけているのに、すべてのパッケージとセキュリティイベントをリアルタイムで見られるはずの NPM が、なぜこれほど繰り返し無力なのか理解しがたいです。ほとんど見て見ぬふりをしているレベルに近いです
NPM は今や GitHub、つまり Microsoft の所有です。彼らは Copilot のような生成AIをあらゆるアプリに入れるのに忙しいのでしょう
複数人で管理しているパッケージなら、少なくとも別の管理者が publish を承認しないと配布できないようなオプションを提供すべきだと思います
同じ攻撃者が、長期間非アクティブだった 22 個以上のパッケージに、難読化された（しかも非常に怪しく見える）ペイロードを一斉に投入して同時配布しました。NPM にそれを検出しろというのは、ほとんど不可能だと思います。私は他のソフトウェアプラットフォームにアプリや拡張機能を配布してきた立場ですが、時には数日から数週間待たされることも珍しくありません。それなのに NPM は、MS と GitHub があらゆるセキュリティソリューションを売っているにもかかわらず、サービス自体にきちんと投資された形跡がなく驚くばかりです
NPM がわざわざ何かを変える理由もないと思います。すでに10年以上マルウェア配布の発生源でしたが、誰も使うのをやめないので、ビジネスへの打撃もありません
原因の一つはパッケージマネージャの過剰な拡散です。もともとこういう些細なパッケージにまで依存するのが嫌いでした。最新版を無作為に引っ張ってきて環境が壊れる経験も本当に嫌です。npm だけが嫌いなのではなく、パッケージマネージャ一般がどれも同じようにうんざりします
今やパスワードマネージャなしで、公式ドメインと一致しないサイトに自分でパスワードを入力するような人は、インターネットで重要なことをする資格がないと思います
パスワードマネージャやブラウザの自動入力なら、こうした偽装ドメインを警告してくれたでしょうし、今回の NPM フィッシングのような npmjs.help と公式ドメインの不一致も防げたはずです
それは事実ですが、実際には公式アプリとWebサイトがまったく別のドメインを使っている例にも何度も遭遇しました。モバイルアプリとWebでドメインがまったく違うケースが最悪です。誰がそんな設計をしたのか分かりません
こういう事件が繰り返されるたびに、なぜパッケージレジストリがすべてのパッケージに暗号学的署名を義務づけないのか理解できません。もちろん CI/CD で自動署名していてそこまで侵害されたら破られますが、大半の問題は防げます。開発者にとっては、アーティファクトのダウンロード、署名、アップロードといった追加手順を手動で踏む必要が出てきます
本物のレジストリなら Debianのように すでにやっています。npm はアマチュア的で、大企業環境では使用禁止にされることも多いです
私が好きなのは事後確認方式です。CI/CD で自動アップロードした後、Web上で人間がもう一度クリックしないと実際の配布が行われないようにすれば、リリース工程の摩擦を減らしつつ、それでも人間が最終承認する手順を入れられます
ただし「どの署名鍵を信頼すべきか」という難しい問題は残ります。2FA を奪われた誰でも新しい鍵を登録して署名できてしまうので、不審なアカウント活動が検知されたときは、新規署名鍵の登録を遅延させる仕組みなどが必要に思えます
npm registry を避けたほうがずっと得だという結論になりました。代わりに (git) リポジトリから直接パッケージを取ってくるほうがいいと思います。npm registry はサプライチェーン攻撃の主な経路でもありますし、ソースと配布コードが完全に分離されているという問題もあります。
npm publishはローカルのどんなコードでもそのまま上げられるので、悪意あるユーザーが簡単に悪性コードを差し込めますGitHub builds から npm に配布するときは真正性検証の機能があるようですが、それでも別の環境から publish できるようで、いまひとつ理解できていません
C 開発者として、依存関係を最小化すること、単一ヘッダライブラリを使うこと、ベンダリングすることなどが一時期は古いやり方だと批判されていたのに、最近になって皆がそれらが再び必要だったと気づいている現実はとても奇妙に感じます
npm の最近の provenance 機能がこの問題を解決してくれます。設定もかなり簡単で、こうした攻撃の予防に役立つはずです。大きなパッケージが次々に導入しているのを見るのはうれしいです
CI 環境でもこの方式を使っているのか気になります。普段サーバーで npm install していたものを git clone に置き換えるということなのでしょうか
「git リポジトリから直接パッケージを取る」というのは理論上は良さそうですが、実際には npm にバグが多く、git dependency のインストールに影響する問題もあります。issue にも書いたとおり、ビルドステップの問題で 2020 年までまともに動かず、グローバルに npm install する場合はいまだに問題があります。しかも prepack スクリプトは npm ドキュメントに明記されていても、実際には git ベースの依存関係では動きません。TypeScript コンパイラチームもこのバグのせいで奇妙な回避策を使わざるを得ず、回避用コード と バグ も残っています。prepack が失敗しても exit code が伝播せず、npm install が壊れた状態のまま完了してしまうのも問題です。こういう点を見ると、npm はきちんとした運営監督が切実に必要か、いっそ新しいパッケージマネージャに置き換えられるべきだと思います
npm エコシステムの外部の人間から見ると、これほど多くのパッケージを、いったいなぜ些細なことのためにまで大量に持ち込んで使うのか驚きます
理由は標準ライブラリがあまりにも貧弱で、基本的な機能でさえ外部パッケージに頼らなければならないからです。自作しようとすると、些細な実装でも膨大になります
15年の開発経験から言うと、職業としての JavaScript 開発者の多くは、実のところほとんどコーディングができないことが少なくありません。知的能力の問題ではなく、教育と文化の問題です。独自コードを書くことへの強い恐れがあり、その結果、些細な部分でも無条件に外部依存に頼るようになります。趣味プロジェクトの開発者のほうが、むしろそうした恐れがなく、コードが堅牢な場合も多いです。興味があれば、会社のチームメンバーに大きなフレームワークなしで直接ビルドさせてみればすぐ分かるはずです
小さなトリビアルモジュール単位で取り込むのは、不要なコードまでクライアントに含めないようにするためです。総合ライブラリのほうが DX はきれいになりますが、不要なコードまで載ってしまいます（tree-shaking があっても万能ではありません）
leftpad 事件以降、こうした議論はずっと続いています。JS の標準ライブラリが小さすぎるのかもしれません
コード変更の PR で「trusted」に見えるモジュールを1行 import するほうが、大規模なコード変更よりもレビューアにはずっと楽に見えます。実際により安全というわけではありませんが、疲れているとそのほうがもっともらしく感じられます
前回の nx 事件のときにも同じ意見を書きましたが、パッケージマネージャには新しいパッケージを一定時間（たとえば 24 時間）必ずスキップする「グレースピリオド」が必要だと思います。こうした攻撃の大半は公開直後にすばやく検知・遮断されるので、その期間ユーザーが最新版を自動インストールしないようにすれば、実害を減らせるはずです
作者が味わったであろう苦痛とストレスは想像に難くありません。たった一度のミスのせいで、説明し続けなければならないのは本当につらいはずです。オープンソースのエコシステムが、実質的に一人の所有するパッケージに大きく依存していることを示す事例でもあります。誰でもミスでハッキング被害に遭い得ることを認めるべきです。技術的に見れば、AI がこれほど使われている時代なのだから、deno/node/bun などで不審なコードに警告を出したり、debian の認証ベースの @verified のような配布で信頼性を高めたり、最新版ではなく検証済みバージョンを使うといった文化への転換が必要に思えます。作者も人間ですし、私たちは皆もっと親切であるべきです。事態が収束したら、もう少し技術的に詳しい分析やポストモーテムも見てみたいです