私たちは本当に大きな脅威を回避した

• 最近、NPMパッケージエコシステムで発生したサプライチェーン攻撃は、実際にはさらに大きな被害を引き起こしかねなかった
• 攻撃者は人気のあるライブラリを悪用し、暗号資産ウォレットのアドレスを書き換える方向にのみマルウェアを使用した
• この攻撃は、巧妙なフィッシングメールを通じて開発者の二要素認証情報を盗み出す形で行われた
• もし、より致命的な形態（例: APIキーの窃取など）で使われていたなら、甚大な被害が発生した可能性がある
• すべての依存関係が潜在的に危険であるという認識と、依存関係ツリー全体を理解する重要性を強調している

---

攻撃の概要と懸念

• 最近、最大級のパッケージエコシステムのひとつであるNPMで人気パッケージが攻撃にさらされた
  • 例となる機能: ターミナルの色処理、色名-RGBマッピング、関数のデバッグデコレータ、配列風の値を判定するユーティリティなど
• こうした一般的な依存関係は広範に使われており、コードが入り込めばそのまま本番環境にデプロイされる可能性が高い
• もし悪意あるプロキシ、APIキーの窃取、その他の深刻な攻撃が含まれていたなら、結果ははるかに深刻になっていた危険があった
• 実際には、このマルウェアはオンラインウォレット（例: MetaMask）で暗号資産の支払い先アドレスだけを改ざんする方式だった

フィッシング攻撃の巧妙さ

• 攻撃の出発点は、非常によく作り込まれたフィッシングメールだった
  • NPMのユーザー名を使って個別化された印象を与える方式
  • 「セキュリティのためにパスワードと二要素認証の認証情報を変更してほしい」というメッセージで信頼を誘導
  • NPMの少し特殊な運用方式とも相まって、一般的な利用者なら簡単にだまされかねない内容だった
  • 特定の期限を明示して緊急性を与え、忙しい状況で油断した状態のままフィッシングリンクをクリックさせるよう誘導
  • 実際のNPM公式ドメインに似た.helpドメインを使用
• 目立つ点は、公式ドメインの代わりに「npmjs.help」を使っている程度だった
  • 近年はさまざまな新しいgTLD(Generic Top Level Domain)がブログやドキュメントなどで広く使われており、これも自然に見え得る

攻撃による潜在的な被害

• フィッシングメールは利用者の二要素認証情報を盗んだ後、攻撃コードを挿入して新しいパッケージを配布できた
• is-arrayish, color-string, color-name など、非常に広く使われている代表的なライブラリが標的だった
  • マルウェアが単なる暗号資産の横取りにとどまらず、APIキーの窃取などに拡大していたなら、致命的な結果を招いた可能性がある
  • たとえばOpenAIやAWSのAPIキーが大量に露出するなど、長期的かつ大規模な被害につながり得た
• 実際には、感染したライブラリの大半は主にコマンドラインツールで使われていたため、暗号資産窃取の目的はそれだけ限定的だった

Web3エコシステムを狙う攻撃者の戦略

• 今回の攻撃は、Web3ユーザー（ブラウザで支払いなどを行う利用者）を主な標的にしていたように見える
  • Web3と無関係な汎用ライブラリを攻撃対象にすることで、Web3エコシステム側の迅速な検知や遮断を回避
  • 例: MetaMaskと連携するライブラリを注意深く点検していても、テキストカラー関連のユーティリティで攻撃が起きるとは予測しにくい

開発エコシステムへの教訓

• 今回の事例は、あらゆる依存パッケージが実際に悪意あるものになり得ることを改めて示している
  • 依存関係ツリーを常に完全に制御または監視することには、現実的な限界がある
  • 迅速な本番デプロイの流れや時間的プレッシャーの中では、セキュリティ面の検討が後回しになりがちであることも示唆している
• 今後は、プロジェクト全体の依存関係の構成把握と慎重な管理の重要性がさらに高まる

締めくくりと案内

• 本内容は特定の人物を非難したり責任を問うものではなく、誰もがフィッシング攻撃にさらされ得ることを認識するのが重要だ
• この投稿の公開後に状況が変わっている可能性もあるため、内容の誤りや疑問があれば直接確認する必要がある

Tags:

[GN⁺]

Hacker News の意見

• nx の npm サプライチェーン攻撃は、多くの企業が避けきれなかった弾丸だった。VS Code の nx プラグインをインストールしているだけで、自動的に npm 上の最新 nx バージョンを確認し、GitHub セッション（例: GH CLI で会社アカウントにログイン済み）や .env ファイルに重要な認証情報があれば、すべて流出していた。依存関係の固定やセキュリティアップデートを適切に管理していても避けられない事案であり、このエコシステムには根本的により深い変化が必要だ。詳細は 公式セキュリティ告知 を参照

  • 私は NPM 関連のものをすべて避けている。唯一 TypeScript compiler だけは使っているが、Go で書き直されたらそれも外すつもりだ。Go は最小バージョン指定機能があり、ダウンロードしたものをコンパイル過程でも決して実行しない点が優れている。NPM の場合、ソースが GitHub と異なることが多く、信頼できないと考えている
  • エディタ拡張機能は、自動更新や自動インストールが行われる高リスクな開発環境に存在するため、非常に魅力的な攻撃対象だ。なぜまだブラウザ拡張機能のような悪意ある勢力による大規模買収が起きていないのか不思議だ。VS Code チームがマルウェア検出にかなり注力しているとは聞くが、Sublime などすべてのエディタがこうした検証プロセスを持っているのか気になる
  • 私はすべてのパッケージとデータベースをローカルに保持し、開発マシンでは機内モードで作業している。git push するときだけインターネット接続を有効にする

• 本当に危機一髪で助かった。こうしたパッケージにアクセスできた攻撃者が、単に暗号資産を盗むツールひとつだけを載せたというのが信じられない。絶好の機会なら、さらに1週間ほど投資してもっと巧妙なエクスプロイトを仕込んだほうが得に思える。API キー、SSH 公開鍵の追加、サーバー IP の流出、開発者端末のブラウザプロファイルやセッショントークン、さらには私のデスクトップ上の Amazon のカード情報まで、盗めるものが多すぎる。こうしたものは自分で使わなくてもダークウェブのフォーラムで簡単に売れる。もしかして腕の立つサイバー犯罪者は、すでに安定して高収入なテック企業で働いていて、こういう単純な攻撃だけが残っているのだろうかと思ってしまう

  • この攻撃手法はすぐに発覚するのが確実だったので、隠密型ではなくアカウント全体の掌握、つまり素早く「奪って逃げる」戦略を選んだように見える。数時間以内に自動化で最も多くの金を最速で抜き取る方法が必要で、暗号資産が明白な答えだった。世界の半分がコードを精査してもバックドアが見つからないレベルでない限り、長く準備する理由はなかった
  • 盗まれた暗号資産は取引の取り消し、返金、復旧ができないため、現実的に確実に手に入る資産だ。一方で開発者の API や SSH キーはほとんど価値がなく、運良く使えても、結局それを換金するには暗号資産に換えることになる
  • 素早く侵入して数十万ドルを盗み、撤収し、数か月後に同じことを繰り返す。こうして警察さえうまく避ければ一生困らずに暮らせる。AWS キーのようなものを盗んでもそれほど大きな利益にはならない。暗号資産以外ではパスワードやパスワードマネージャーのデータベースを狙う犯罪者もいるが、結局は暗号資産関連サイトを狙うことが多い。今この瞬間も、企業への侵入タイミングを綿密にうかがっている犯罪者がいるはずで、彼らは露見せず成功するまで潜み続けるだろう
  • これは一生に一度の機会などではない。今後は犯罪者たちが、たった数人の「開発者」を狙うだけで数百万ドルに簡単に手が届くと気づき、さらに大胆な手口が次々に出てくるはずだ。オープンソースコードのメンテナであれば、自分の物理的な身元をオンライン上でどれだけ隠せているかを真剣に考えるべき段階だ

• 私の先延ばし癖は生存スキルだ。みんながベータテストを終えるまで待つので、昔会社では 12 年間 Microsoft Office 2000 だけを使い、アップグレードによる問題や再教育なしで 10 年間平穏に過ごせた。そして、メール内のリンクは絶対にクリックしない習慣がある

  • 私の Honda も Kubernetes も同じだ。2006 年式の車を長く維持したおかげで、何世代にもわたる大小さまざまな車-スマホ連携の問題を飛ばせたし、最近になってようやく 2023 年式の車で iPhone 接続が非常にスムーズになった。Kubernetes も同様で、上司の勧めを長いあいだ先延ばしにしたおかげで、EKS や GKE などが十分成熟した今になって移行しており、苦労がかなり減った。もし 6〜7 年前にすぐ従っていたら、かなり無駄な苦労をしていたと思う
  • npm エコシステムでは、54 秒ごとに更新しないともう大きく遅れているようなものだ
  • 新規の悪意あるパッケージには有効だが、すでに感染したソフトウェアがワームまで食らっている場合には効かないこともある
  • 明日返信する
  • 「新しいバージョンは基本的に 2 週間使わない」は、サプライチェーン攻撃に非常に有効な防御策だ

• 小さなスタートアップには厳しいだろうが、npm のような大手プレイヤーなら npm.io、npm.sh、npm.help など、npm ドメインのあらゆる TLD 版を押さえるべきだと思う。攻撃者が npm.help ドメインを確保したことが、この攻撃をより効果的にした

  • AWS のように顧客へフィッシングに気をつけろと言っておきながら、公式請求メールアドレスを [e-mail] から [e-mail] に変えてしまうことがよくある。初見ではほぼフィッシングメールにしか見えないのに公式だというので混乱する。しかも事前案内メールまでフィッシングっぽく見え、本当に請求書を受け取るまで怪しくて添付の PDF を開けなかった。企業は顧客にフィッシング注意を呼びかけながら、不必要な混乱を生む行動をしている
  • TLD は 1,500 を超えており、一部は制限付きや国別コード型だとしても、こうした TLD をすべて登録する実際の年間コストがどれくらいなのか気になる。SaaS として代行してくれるところもありそうだ
  • TLD リスト を見るとドメインが多すぎる。大規模企業でも、類似 TLD をすべて押さえてフィッシング対策を試みる必要はあるにせよ、完全に防ぎきることはできないと思う
  • まず第一に、すべての公式ドメインかどうかを確認することだ。最近登録された格安ドメイン（registrar）だったり、有効期限があまり残っていないドメインは無条件で疑う。特に締切日などを強調しつつ「時間がない」と人を追い込むようなリンクであれば、より深く調べる。公式なコミュニケーションは、有名な代表ドメイン（あるいはそのサブドメイン）だけを使うべきだと思う
  • npm および類似ドメインの命名は変種が無限にあるため、すべて先回りして取得する方法では実質的に防げない。ドメイン名を見ただけでもフィッシングだと疑うべきだが、npmjs.help のようなドメインでも現実には誤ってクリックされる

• もし誰かが非常に周到さ（Jia Tan 方式）と、こちらのセキュリティの甘さ（エディタプラグイン、シェルのユーザーランドなど）を組み合わせたらどうなるのか。開発者向けツールはスーパーユーザー権限で動くのに、最も検証が少ない。私も elisp、neovim、vscode、そして簡単なユーザーランドツールまで一つひとつ検証してはいられない。よくて nixpkgs から取ってくる程度だ。いつかもっと良い VSCode プラグインをひとつ登場させて 1〜2 年待てば終わりだ。GG だ

  • いつか誰かが xkcd 1200 番の問題を解決してくれることを願う

• MetaMask などのウォレットが標的になったが、MetaMask は LavaMoat という分離モジュールのおかげで、こうした攻撃からかなりよく守られていると聞く。実際の防御レベルを詳しく分析した記事があればぜひ読みたい。個人的には MetaMask とは無関係だが、こうしたセキュリティ対策（実際の攻撃に比べて適用が遅い）の有効性が気になる。参考までに 関連記事 を追加しておく

• 「こういうフィッシング攻撃には結局いつか引っかかるしかないのが現実だ」という話に対して、私は自分はたぶん違うと思っている。自分で依頼していないメールのリンクには絶対に認証情報を入力しない習慣があるからだ（例: パスワード初期化など）。2025 年なら誰もが必ず身につけるべきセキュリティスキルだと思う

  • 「『こういう』フィッシング攻撃」と言うと何か巧妙な攻撃のように聞こえるが、実際には開発者がまたしてもごく普通のフィッシングメールに引っかかった事例にすぎない。非常に基本的なミスであり、場合によっては管理部門の社員ですら引っかからないレベルだ。もちろん誰でも失敗はするが、明らかな不注意とアマチュア的なミスがこれを繰り返させていると思う

• 「すべてのマルウェアは暗号資産ウォレットのアドレスだけを書き換えていた」という記事の説明とは異なり、MetaMask が影響を受けなかった理由は、

1. 攻撃時点でパッケージがすぐ更新されなかったこと
2. MetaMask がインストール時と実行時の両方で LavaMoat による保護を受けていたこと による。一方、この悪意あるペイロードは、MetaMask と相互作用する他のウォレット利用 Web ページを狙おうとしていた。なお、私は LavaMoat の開発に参加していた。詳細は LavaMoat GitHub を参照

• 主要なオープンパッケージリポジトリには、はるかに強力なセキュリティソリューションが必要だ。さもなければ、信頼性の高い審査済み中核パッケージ群だけでも必要になる。Python や Rust のエコシステムなども同様に、信頼だけで回っている

  • npm の根本的な問題は、名前空間の強制がないことだ。Java の Maven について初心者は「なぜ npm ほど簡単じゃないのか」と不満を言うが、Maven の名前空間体系などの品質管理への執着は、時がたつほど高く評価するようになる。POM xml は不便ではあるが、保守的な変更管理が信頼につながっている。関連記事: なぜパブリックなオープンソースリポジトリで名前空間が重要なのか
  • この事例のようにパッケージメンテナのアカウント自体が奪われた場合、名前空間などの構造的対策も無意味だ。唯一の解決策は、新規リリースが即時適用されないように遅延させることだけだ
  • Linux ディストリビューションも同じく信頼ベースだが、パッケージを上げる権限を得るには信頼を「証明」しなければならず、そのための信頼確認システム全体が存在する。NPM はまるで誰でも上げられる自由放任のシステムのようだ

• 「これは防ぎようがない」という主張は、最も頻繁に侵害が起きているエコシステムでしか出てこない

  • まさにそこが問題だ。あまりにも怠惰な結論だ