CICD-SEC-3

定義

依存チェーンの悪用のリスクとはエンジニアリングワークステーションやビルド環境がコードの依存関係をフェッチする方法に関する欠陥を悪用する攻撃者の能力を指します。依存チェーンの悪用によりプルされた際に不注意に悪意のあるパッケージがフェッチされ、ローカルで実行されてしまいます。

解説

組織内のすべての開発コンテキストでプロセスに関与するシステムの総数を考えると、自己記述コードで使用される依存関係と外部パッケージの管理はますます複雑になっています。多くの場合、パッケージはクライアントごとに専用のクライアントを使用し、一般的には自己管理パッケージリポジトリ (例: Jfrog Artifactory) と言語固有の SaaS リポジトリ (例: Node.js は npm と npm レジストリ、Python の pip は PyPI、Ruby の gems は RubyGems を使用) の組み合わせからフェッチされます。

既知の脆弱性を持つパッケージの使用を検出し、自己記述コードとサードパーティコードの両方の静的解析を実施するために、多くの組織は多大な労力を払っています。しかし、依存関係を使用するというコンテキストでは、依存関係エコシステムを保護するために必要となる同様に重要な一連のコントロールがあります。これには依存関係をプルする方法を定義するプロセスの保護を含みます。構成が不適切な場合には、疑うことを知らないエンジニアや、最悪の場合ビルドシステムが、プルされることを意図したパッケージではなく悪意のあるパッケージをダウンロードする可能性があります。多くの場合、パッケージがダウンロードされるだけでなく、ダウンロード後すぐに実行されます。これはパッケージがプルされた直後にパッケージのコードを実行するように設計されたプリインストールスクリプトや同様のプロセスによるものです。

このコンテキストでの主な攻撃ベクトルは以下のとおりです。

  • 依存関係攪乱 (Dependency confusion) - 内部パッケージ名と同じ名前で悪意のあるパッケージをパブリックリポジトリに公開し、クライアントをだましてプライベートパッケージではなく悪意のあるパッケージをダウンロードさせます。

  • 依存関係ハイジャック (Dependency hijacking) - パブリックリポジトリ上のパッケージメンテナのアカウントのコントロールを取得し、広く使用されているパッケージの新しい悪意のあるバージョンをアップロードして、そのパッケージの最新バージョンをプルする無防備なクライアントを侵害します。

  • タイポスクワッティング (Typosquatting) - 人気のあるパッケージと似た名前の悪意のあるパッケージを公開し、開発者がパッケージ名のスペルを間違えて、意図せずタイポスクワットされたパッケージをフェッチすることを見込みます。

  • ブランドジャッキング (Brandjacking) - 特定のブランドのパッケージの命名規則やその他の特徴と一致するような悪意のあるパッケージを公開し、信頼できるブランドと誤って関連付けて、疑うことを知らない開発者がこれらのパッケージをフェッチするよう企てます。

影響

前述の技法を使用してパブリックパッケージリポジトリにパッケージをアップロードする攻撃者の目的は、パッケージをプルするホスト上で悪意のあるコードを実行することです。これは開発者のワークステーション、もしくはパッケージをプルするビルドサーバーのいずれかになります。

悪意のあるコードが実行されると、実行された環境内での認証情報の窃取やラテラルムーブメントに利用される可能性があります。

もう一つ可能性のあるシナリオとして、攻撃者の悪意のあるコードがビルドサーバーから本番環境へ送られることが考えられます。多くの場合、悪意のあるパッケージはユーザーが期待していた元の安全な機能も維持し続けるため、発見される可能性は低くなります。

推奨事項

さまざまな言語固有のクライアントの構成、内部プロキシや外部パッケージの使用方法に応じて、さまざまな緩和手法があります。

とはいえ、推奨されるすべてのコントロールは同じ基本原則を共有しています。

  • コードパッケージをプルするクライアントはインターネットや信頼できないソースから直接パッケージをフェッチすることを許可されるべきではありません。代わりに、以下のようなコントロールを実装すべきです。

    • サードパーティパッケージ外部リポジトリからプルされる際には常に、すべてのパッケージがインターネットから直接ではなく内部プロキシを介してプルされるようにします。これによりプロキシレイヤで追加のセキュリティコントロールをデプロイできます。もちろん、セキュリティインシデントの場合にはプルされたパッケージに関する調査機能も提供します。

    • 該当する場合、外部パッケージから直接パッケージをプルすることを禁止します。すべてのクライアントが内部リポジトリからパッケージをプルするように構成し、このクライアント構成を検証して適用するメカニズムを確立します。

  • プルされたパッケージに対するチェックサム検証と署名検証を有効にします。

  • パッケージの最新バージョンをプルするようにクライアントを構成するのは避けます。精査済みのバージョンまたはバージョン範囲を構成することをお勧めします。フレーム固有の技法を使用して、組織で必要なパッケージバージョンを安定かつ安全なバージョンに継続的に「ロック」します。

  • スコープ:

    • すべてのプライベートパッケージが組織のスコープで登録されているようにします。

    • プライベートパッケージを参照するすべてのコードがパッケージのスコープを使用するようにします。

    • クライアントが組織のスコープにあるパッケージを内部レジストリからのみフェッチするようにします。

  • インストールスクリプトがパッケージインストールの一部として実行されている場合には、それらのスクリプト用に別のコンテキストが存在することで、ビルドプロセスの他のステージで利用可能なシークレットやその他の機密リソースにアクセスできないようにします。

  • 内部プロジェクトはプロジェクトのコードリポジトリ内にパッケージマネージャの構成ファイル (NPM 内の .npmrc など) が常に含まれるようにし、パッケージをフェッチするクライアントに存在する可能性のある安全でない構成をオーバーライドします。

  • 内部プロジェクトの名前をパブリックリポジトリに公開することは避けます。

  • 概して、同時に使用されるパッケージマネージャと構成の量を考えると、サードパーティチェーンの悪用を完全に防止することは容易ではありません。したがって、検出、監視、緩和について適切なレベルに注力し、インシデントが発生した場合には可能な限り迅速に発見して潜在的な損害を最小限に抑えることをお勧めします。このコンテキストでは、「CICD-SEC-7: 安全でないシステム構成 (Insecure System Configuration)」リスクのガイドラインに従って、関連するすべてのシステムを適切に堅牢化されるべきです。

参考情報

  1. Alex Birsan による依存関係攪乱。パッケージマネージャとプロキシをだまして、内部リポジトリからの意図したパッケージではなく、パブリックリポジトリから同名の悪意のあるパッケージをフェッチするように仕向ける攻撃ベクトルです。

    https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

  2. Amazon, Zillow, Lyft, Slack の NodeJS アプリは脅威アクターによって依存関係攪乱の脆弱性を使用した標的とされていました。

    https://www.bleepingcomputer.com/news/security/malicious-npm-packages-target-amazon-slack-with-new-dependency-attacks/

  3. 週に 900 万回ダウンロードされる ua-parser-js NPM ライブラリがハイジャックされ、クリプトマイナーを実行し、認証情報を窃取していました。

    https://github.com/advisories/GHSA-pjwm-rvh2-c87w

  4. 週に 900 万回ダウンロードされる coa NPM ライブラリがハイジャックされ、認証情報を窃取していました。

    https://github.com/advisories/GHSA-73qr-pfmq-6rp8

  5. 週に 1400 万回ダウンロードされる rc NPM ライブラリがハイジャックされ、認証情報を窃取していました。

    https://github.com/advisories/GHSA-g2q5-5433-rhrf

Last updated