たった1文字のミスがマルウェアの拡散につながった
それはタイプミスから始まった。大量の機能追加やPRマージの慌ただしい中で、誰かがタイプミスをしたのだ。 @utils_core @utils-core に package.jsonそのたった一文字のミスはエラーを発生させなかった。代わりに、静かに 次の期間に悪意のある類似パッケージ CI/CD 固定バージョンへの信頼と自動化を活用して実行します。 オープンソースにおけるタイポスクワッティングの世界へようこそ。
タイポスクワッティング：人間のミスにつけ込む攻撃手法
タイポスクワッティングとは、まさにその名の通り、悪意のある者が正規のパッケージとほぼ同じ名前でパッケージを登録することです。開発環境が急速に変化している中で、開発者が正規のパッケージとほぼ同じ名前のパッケージを登録すると、この行為が成功します。 package.json (NAIST) と パッケージロック.json 彼らの期待を反映する。文字が1文字ずれている？PRの差分では、ほとんど気にならないだろう。
NPM タイポスクワッティングによって悪用されてきた歴史があります。 クロスエンベロープ クロスエンバイロメント or イベントストリーム バックドアは、こうした偽装プログラムがいかに効果的であるかを既に証明している。これらの偽パッケージは、見た目が本物そっくりで、実行時に即座にエラーが発生しないため、審査を通過してしまうことが多い。
よくある落とし穴は次のとおりです:
- ハイフンとアンダースコアの違い： lodash-core vs lodash_core
- 複数形： 要求 vs リクエスト
- 置換された文字: エクスプレス 表現します
package-lock.jsonが盲点となる場所
開発者はタイプミスを修正した。少なくとも彼らはそう思っている。しかし今や、 パッケージロック.json 既に攻撃者のパッケージが組み込まれてしまっている。そして、ここにこそ真の危険が潜んでいるのだ。
取消 package.json手動で編集され、より厳しく精査される パッケージロック.json 自動生成 NPMその結果、形式的なものとして扱われたり、省略されたり、ざっと目を通されるだけだったりすることが多い。 pull request レビュー。チームがそれを「ノイズが多すぎる」と評価したり、深く検討せずに無条件に信頼したりすることは珍しくない。
攻撃者はこれを知っている。彼らはそれを頼りにしている。 悪意のあるパッケージ タイプミスのおかげで参照されています package.json、package-lock.json 解決済みのバージョンが記録されます。たとえ後でタイプミスが修正されたとしても、ロックファイルが明示的に再生成されない限り、悪意のあるエントリは残存する可能性があります。
さらに悪いことに、一貫性を確保するはずのバージョン固定が裏目に出ることがあります。攻撃者は偽のパッケージを正規のパッケージと全く同じバージョンにすることができます。 CI/CD システムは固定されたバージョンを盲目的に信頼するため、既知の正常なバージョン番号を持つパッケージが、別の悪意のあるソースからインストールされていることを検出できません。
この静かな粘り強さこそが パッケージロック.json これは非常に危険です。確かに、決定論的なビルドを保証しますが、同時に、不正なパッケージが手動で発見され削除されない限り、そのまま残ってしまうことも保証してしまいます。
CI/CDマルウェアが攻撃する場所 – package.json
典型的な CI/CD pipeline悪意のあるパッケージは実行時まで待つ必要はありません。フローのかなり早い段階で解決され、トリガーされます。
依存関係の解決
その pipeline p から正確な依存関係バージョンを取得しますpackage-lock.json、現在では タイプミスによりパッケージがタイポスクワッティングされました package.json。
インストールフェーズ
npm ci の実行中に、悪意のあるものも含め、すべての依存関係がインストールされます。警告もプロンプトも表示されず、ただ静かにインストールが行われます。
インストール後のスクリプト実行
類似パッケージには、インストール完了後に自動的に実行されるインストール後スクリプトが含まれています。ここで問題が発生します。
擬似コードの例：
擬似コードの説明：
インストールフェーズにおいて、インストール後のライフサイクルフックが存在する場合、偽パッケージは隠されたロジックを実行します。これは、ビルドやテストが実行される前に発生することがよくあります。このロジックには、外部へのリクエストの送信、バックドアの挿入、その他の不正な操作が含まれる可能性があります。
⚠️ 警告: この擬似コードはデモンストレーションのみを目的としており、実際の環境で使用してはなりません。
アラートは発生しません。何も失敗しません。環境は既に侵害されています。 pipeline テスト段階にまで達する。
手遅れになる前に違いを見抜く
よくある間違い： package.json 物語の全てを語っている。そうではない。真の力は、 package.json + package-lock.json。
以下が検索対象です。
- しない パッケージロック.json 予期しないパッケージが含まれていますか？
- 未知のレジストリから取得された依存関係や、奇妙なスコープを持つ依存関係はありますか？
- バージョン番号は過度に具体的すぎたり、整合性が欠けていたりしますか？
次のようなCLIツールを使用します。
- npm監査 既知の問題を報告する
- npm ls 完全な依存関係ツリーを表示するには
- 差分 バージョンを比較する package.json (NAIST) と パッケージロック.json
ハード Pipeline効果的な防御策
タイポスクワッティングから身を守るために：
- スコープ制限を強制する package.json。
- 事前マージを追加 hooks 依存関係をリンティングおよび検証する。
- npmci 意図しないバージョンずれを避けるため。
- 定期的にスキャンする パッケージロック.json 異常に対して。
そして最も重要なことは、未検証のエントリを パッケージロック.json 潜在的なリスクとして。 commit サプライチェーンのチェックポイントとして扱うべきである。
自動検出：Xygeniのようなツールがどのように役立つか
万能薬ではないが、次のような自動化ツール ザイゲニ タイポスクワッティングが蔓延する原因となる人的ミスを減らす上で、Xygeniは重要な役割を果たします。XygeniはDevOpsワークフローに直接統合され、依存関係の乗っ取りが実行される前にリアルタイムで保護するレイヤーを追加します。
Xygeniがどのように役立つかをご紹介します。
- 不審なパッケージ名の検出：
スマートなヒューリスティックを使用して、タイポスクワッティングのパターンを検出します。 package.jsonよく知られているパッケージ名におけるわずかな違い（アンダースコアの追加、転置、文字の入れ替えなど）を探します。 - 不明なハッシュ検証:
すべての依存関係のハッシュを比較します パッケージロック.json 信頼できるレジストリから取得した、既知の正常なアーティファクトのデータベースと照合します。パッケージ名とバージョンが問題ないように見えても、ハッシュ値の不一致があれば危険信号となります。 - ビルド前のブロッキング:
インストールまたはインストール後のフェーズに到達する前に、未検証または疑わしいパッケージのインストールを阻止します。 CI/CD pipeline. - 依存関係グラフ分析：
間接的なタイポスクワッティングの試みや悪意のある推移的依存関係がないか、依存関係ツリー全体を継続的に検査します。 - アラートとレポート:
何がフラグ付けされたのか、その理由、そして依存関係チェーンのどこから発生したのかを示す、詳細で実用的なアラートを提供します。
パッケージエコシステムが複雑化するにつれて、Xygeniのようなツールが不可欠になります。手動レビューは、依存関係の拡大や迅速なイテレーションには対応できません。Xygeniは、現代のパッケージエコシステムで重要なチェックを自動化します。 pipeline信頼と検証の間のギャップを埋める必要性。
一人の登場人物。現実の結末。
これは異国情緒あふれるものではなかった ゼロデイタイプミスでした。 package.json静かに強化される パッケージロック.jsonマルウェアは、ルーチン処理中に自動的に配布された。 CI/CD 実行されます。
タイポスクワッティングの真の危険性はそこにある。複雑さは必要ない。スピード、信頼性、そして自動化を悪用するのだ。 適切な対策を講じていれば、このような事態は防げたはずだ。
- 自動スキャン インストール前に疑わしいパッケージ名やバージョンを検出する。
- ロックファイル監査 未審査または予期しないエントリを検出する パッケージロック.json.
- 名前検証ヒューリスティック 信頼できるパッケージとほぼ一致するものを識別する。
たった一文字で十分だった。適切なチェックを行っていれば、あなたの手に触れる前に阻止できたはずだ。 pipeline信頼だけでは不十分だ。現代のDevSecOpsでは、すべてを検証するか、すべてを危険にさらすかのどちらかだ。
