npmの依存関係混同攻撃を検出・防止してサプライチェーンのセキュリティを維持する

2021年2月9日、Alex Birsan氏は、 aptly named security researchとして知られる依存関係混同に関する調査結果を公開しました。公開内容では、開発者の設定ミスと、オープンソースの言語ベースのソフトウェアエコシステムで使われる複数のパッケージマネージャーの設計上の欠陥を悪用する、新たなサプライチェーン攻撃について説明しています。この攻撃により、Yelp、Tesla、Apple、Microsoftなどの企業にアクセスし、データを持ち出すことができました。

このセキュリティ調査は注目を集め、組織が依存関係混同攻撃の影響を受ける可能性があるかどうかを検出するための新たな幅広いツールが登場しました。

この記事では、npmエコシステムで開発するJavaScriptおよびNode.js開発者に依存関係混同攻撃がどのように影響するのか、手順を追って解説します。また、Snykの新しいオープンソースツールを紹介します。このツールを使えば、自身のソースコードリポジトリに潜む、依存関係混同につながる危険性を検出できます。ツール名はsnyncです。

クイズです！snyncが何を意味するか、わかりますか？答えは記事の最後にあります。

この記事では、このサプライチェーン攻撃が発生するそれぞれのパターンを確認し、各パターンの軽減方法を詳しく説明します。

• プライベートnpmレジストリの設定ミス

• プライベートnpmレジストリが最新バージョンを取得する

• 手動でのパッケージ更新によって悪意のあるバージョンが混入する可能性

依存関係混同攻撃の影響を受ける可能性はありますか？

依存関係混同攻撃が成立するのは、社内のソースコードライブラリに依存している組織に限られます。知的財産を守るためにプライベートパッケージを管理することは一般的です。そのため、多くの組織が社内プロキシ、キャッシュ、プライベートパッケージホスティングのレジストリサービスを利用しています。

組織が社内のプライベートパッケージを管理している場合、そのパッケージは（定義上）パブリックレジストリやそのミラーには存在しません。また、プライベートパッケージがパブリックレジストリに登録されていないため、誰でもそのパッケージ名を取得し、依存関係混同攻撃を仕掛ける可能性があります。プライベートパッケージとパブリックパッケージが同じ名前を持てることが、この攻撃の核心です。

JavaScriptおよびNode.jsのエコシステムでは、予約済みの名前空間としてスコープ付きパッケージを使うことで、依存関係混同攻撃の対象となる範囲を大幅に縮小できます。ただし、npmでもyarnでも、このサプライチェーン攻撃の影響を受ける可能性がある点にご注意ください。

依存関係混同攻撃を再現する

依存関係混同によるサプライチェーン攻撃を実際に試すため、脆弱性とその軽減方法を実演するハンズオンチュートリアルを行います。

以下は、社内で「デス・スター」と呼ばれるプロジェクトのパッケージマニフェストです。いい名前ですよね！

1{
2  "name": "the-death-star",
3  "version": "1.0.0",
4  "main": "index.js",
5  "scripts": {
6    "start": "node server.js",
7  },
8  "license": "ISC",
9  "dependencies": {
10    "debug": "^4.3.2",
11    "death-star-secret-hyper-matter-reactor": "^1.0.0",
12    “superlaser”: “^1.0.0”
13  }
14}
15

このコードはpackage.jsonにあり、このプロジェクトの依存関係も示しています。ご覧のとおり、superlaserは依存パッケージです。もちろん、これは帝国が保有する極秘兵器なので、社内でのみ公開されています。デス・スターは宇宙空間を移動する必要があるため、プライベートパッケージのdeath-star-secret-hyper-matter-reactorにも依存しています。

プライベートnpmレジストリの設定方法

一緒に試す場合は、プライベートnpmレジストリを設定するため、まず本題から少し寄り道します。プライベートレジストリがあれば、自分の環境で実験し、依存関係混同によるサプライチェーン攻撃を最初から最後まで再現できます。

そのために、こうした用途向けのオープンソースプロジェクトVerdaccioを使って、社内プライベートnpmレジストリとプロキシサーバーを設定します。Dockerがインストールされていれば、次のように簡単に起動できます。

1docker run -it --rm --name verdaccio -p 4873:4873 verdaccio/verdaccio\

問題なく起動すると、Verdaccioから次のように表示されます。

これで、ポート4873でローカルに動作する、専用のプライベートnpmパッケージホスティング環境ができました。

それでは、秘密の社内npmパッケージsuperlaserとdeath-star-secret-hyper-matter-reactorを公開しましょう。まず、新しいVerdaccioプライベートレジストリにユーザーを追加します。

1npm adduser --registry https://localhost:4873

次に、superlaserパッケージのマニフェストファイルpackage.jsonを用意します。

1{
2  "name": "superlaser",
3  "version": "1.0.0",
4  "description": "Our secrets weapon",
5  "main": "index.js",
6  "scripts": {
7    "start": "node index.js",
8  },
9  "license": "ISC"
10}

death-star-secret-hyper-matter-reactorのパッケージマニフェストも、パッケージ名が異なるだけで同様です。それでは、プライベートnpmレジストリに公開しましょう。

1npm publish  --registry https://localhost:4873

依存関係混同が起きるのはなぜ？

この種のソフトウェアサプライチェーン攻撃につながる主な要因は、次の3つです。

• 開発者環境またはテストサーバーの設定ミス

• パブリックnpmレジストリに公開された、より新しいパッケージバージョン

• パッケージマネージャーの設計上の欠陥とも言える問題

それぞれのケースを改めて見ていきましょう。

プライベートnpmレジストリの設定ミス

開発者または継続的インテグレーション（CI）システムが、社内でsuperlaser依存関係を持つthe-death-star projectのソースコードをクローンすると、この依存関係はどのように取得されるのでしょうか？

npm installコマンドを実行する際、少なくとも次の条件を満たす必要があります。

1. この社内パッケージが存在するプライベートnpmレジストリのURLが必要です。

2. そのプライベートレジストリにアクセスするためのトークンなどの認証情報が必要です。

最初の手順で問題が起きる可能性があります。特定のプライベートnpmレジストリを指定するには、npmパッケージマネージャーの設定情報を明示的に指定する必要があります。

いくつかのケースを改めて考えてみましょう。

1. 継続的インテグレーションシステムにプライベートレジストリが設定されていないと、どうなるでしょうか？

2. 既存プロジェクトに新たに参加した開発者が、npm config set registryコマンドを実行するなどの事前手順を踏んでいない場合、どうなるでしょうか？

3. 誤って.npmrc設定を削除または変更し、社内プライベートnpmレジストリを指定しなくなった場合、どうなるでしょうか？

このように、社内レジストリのカスタム設定が省略されると、npmパッケージマネージャーはパブリックレジストリ（registry.npmjs.org）を既定で使用し、そこからパッケージをダウンロードします。

パブリックnpmレジストリには誰でもパッケージを公開できます。そのため、悪意のあるユーザーがsuperlaserという名前のパッケージを公開すると、社内パッケージではなく、そのパッケージがダウンロードされてインストールされてしまいます。

npmの依存関係混同を防ぐ方法

根本的な問題は、プライベートnpmプロキシが適切に設定されていないことです。開発者やCIシステムにこの設定がなければ、攻撃を受ける可能性があります。

まず、必ず.npmrcファイルを利用可能にするか、別の方法でプライベートnpmプロキシを設定してください。

次に、名前空間がパブリックnpmjsレジストリで予約されていないプライベートパッケージを使用していないか、事前に検出する方法があります。そのためにsnyncを開発しました。依存関係をインストールする前に、CIサーバーの実行手順の一部として実行できます。これにより、誤って悪意のあるパッケージをインストールするのを防げます。

次のスクリーンショットでは、snyncをnpx経由で実行し、依存関係をスキャンする対象として現在のディレクトリを指定しています。また、superlaserという名前のパッケージがプライベートパッケージであることも指定しています。

結果を見ると、snyncは依存関係混同につながる可能性のある、次の2つの問題を検出しました。

1. death-star-secret-hyper-matter-reactorパッケージはvulnerableです。現時点で、パブリックnpmjsレジストリに同名のパッケージが登録されていないためです。つまり、誰でもその名前で登録でき、依存関係混同攻撃が発生する可能性があります。

2. superlaserパッケージはsuspicious状態です。つまり、このツールは次のいずれかのケースを検出しました。

   1. このパッケージ名はGitのソースコードに先に登場し、その後、同名のパッケージがパブリックnpmjsレジストリに公開されました。パブリックnpmjsレジストリのパッケージが悪意のあるものだという意味ではありませんが、確認が必要です。

   2. 同名のプライベートパッケージを作成するより前から、そのパッケージ名がパブリックnpmjsレジストリに存在しています。

snyncはNode.jsベースのオープンソースコマンドラインプロジェクトです。DevSecOpsのセキュリティパイプラインでぜひご活用ください。

プライベートnpmレジストリが最新バージョンを取得する

同じ名前のパッケージ（superlaser）がパブリックnpmレジストリで公開されていて、より高いsemverバージョンが利用可能な場合、どうなるでしょうか？

状況を例にすると、次のとおりです。

• プライベートnpmレジストリhttps://localhost:4783にsuperlaser@1.0.0が存在する

• 匿名ユーザーがsuperlaser@1.99.999をパブリックnpmレジストリ（https://www.npmjs.com/package/superlaser）に公開している

ここで、新しいプロジェクトを作成し、superlaserパッケージのインストールを要求するとどうなるでしょうか？まだpackage.jsonもロックファイル（package-lock.json）もありません。開発者が単に次のように実行したとします。

1npm install superlaser

このインストールでは、リモートの攻撃者が管理する悪意のあるバージョンのsuperlaserがインストールされる可能性があります。しかし、なぜでしょうか？開発者はローカルのnpmレジストリを設定しているはずです。

テストで確認されたように、社内のプライベートnpmプロキシが設定されていても、多くのプロキシはまずパブリックnpmレジストリで最新バージョンを確認することがわかっています。より新しいバージョンがある場合、これらのプロキシはパブリックレジストリから最新のsemverバージョンを取得してインストールします。

Verdaccioでこの状況を再現してみましょう。以下のように、害のないsuperlaser npmパッケージをVerdaccioにプッシュしました。Verdaccioは、社内プライベートnpmパッケージのホスティングとして機能します。

次に、ローカルのVerdaccioレジストリを指定した.npmrcファイルしかない新しいプロジェクトディレクトリで、npm installコマンドを実行するとどうなるか見てみましょう。社内で公開したsuperlaser@1.0.0がインストールされると思っていたにもかかわらず、superlaserパッケージの最新バージョンがパブリックnpmレジストリから取得されます。

予期しない結果となり、エンドユーザーを危険にさらす可能性があります。

この動作については、オープンソースのVerdaccioプロジェクトでGitHub上の公開ディスカッションが行われています。参加してこのトピックの議論を追いたい方はご覧ください。

技術的には、Verdaccioなどのプライベートnpmプロキシが行うこの処理では、次のような複数の変数が考慮されます。

1. 最新のsemverリリース

2. パッケージの公開日時

たとえば、パブリックnpmjsレジストリに高いsemverバージョンが存在していても、同じ名前で、その公開バージョンと同じ範囲内の低いsemverバージョンのパッケージが、高いバージョンの公開日より後に作成された場合、Verdaccioはパブリックレジストリのパッケージを取得しません。

誤ったパッケージの取得を防ぐ方法

プライベートnpmプロキシを設定し、パブリックレジストリへの上流プロキシリクエストを常に無効にするようにします。パッケージまたはバージョンがローカルで利用できない場合は、信頼性や検証が不十分なソースから無条件にパッケージを取得しない方法で解決してください。

ここでの例のようにVerdaccioを使用している場合は、/verdaccio/conf/config.yamlにある次の設定で対応できます。

1#
2# This is the config file used for the docker images.
3# It allows all users to do anything, so don't use it on production systems.
4#
5# Do not configure host and port under `listen` in this file
6# as it will be ignored when using docker.
7# see https://verdaccio.org/docs/en/docker#docker-and-custom-port-configuration
8#
9# Look here for more config file examples:
10# https://github.com/verdaccio/verdaccio/tree/master/conf
11#
12
13# path to a directory with all packages
14storage: /verdaccio/storage/data
15# path to a directory with plugins to include
16plugins: /verdaccio/plugins
17
18web:
19  # WebUI is enabled as default, if you want disable it, just uncomment this line
20  #enable: false
21  title: Verdaccio
22  # comment out to disable gravatar support
23  # gravatar: false
24  # by default packages are ordercer ascendant (asc|desc)
25  # sort_packages: asc
26  # darkMode: true
27
28# translate your registry, api i18n not available yet
29# i18n:
30# list of the available translations https://github.com/verdaccio/ui/tree/master/i18n/translations
31#   web: en-US
32
33auth:
34  htpasswd:
35    file: /verdaccio/storage/htpasswd
36    # Maximum amount of users allowed to register, defaults to "+infinity".
37    # You can set this to -1 to disable registration.
38    # max_users: 1000
39
40# a list of other known repositories we can talk to
41uplinks:
42  npmjs:
43    url: https://registry.npmjs.org/
44
45packages:
46  '@*/*':
47    # scoped packages
48    access: $all
49    publish: $authenticated
50    unpublish: $authenticated
51    # DO NOT FETCH PACKAGES FROM NPMJS
52    #proxy: npmjs
53
54  '**':
55    # allow all users (including non-authenticated users) to read and
56    # publish all packages
57    #
58    # you can specify usernames/groupnames (depending on your auth plugin)
59    # and three keywords: "$all", "$anonymous", "$authenticated"
60    access: $all
61
62    # allow all known users to publish/publish packages
63    # (anyone can register by default, remember?)
64    publish: $authenticated
65    unpublish: $authenticated
66
67    # if package is not available locally, proxy requests to 'npmjs' registry
68    # DO NOT FETCH PACKAGES FROM NPMJS
69    #proxy: npmjs
70
71middlewares:
72  audit:
73    enabled: true
74
75# log settings
76logs:
77  - { type: stdout, format: pretty, level: http }
78  #- {type: file, path: verdaccio.log, level: info}
79#experiments:
80#  # support for npm token command
81#  token: false
82#  # support for the new v1 search endpoint, functional by incomplete read more on ticket 1732
83#  search: false
84
85# This affect the web and api (not developed yet)
86#i18n:
87#web: en-US

上記はDockerコンテナ版Verdaccioの標準設定ファイルです。ただし、# DO NOT FETCH PACKAGES FROM NPMJSというコメントがあり、その次の行でproxy: npmjsオプションがコメントアウトされている点が異なります。これにより、一致するパターンに設定されたパッケージについて、Verdaccioがnpmjsから何も取得しないようにできます。

手動でのパッケージ更新により、悪意のあるバージョンが導入される可能性があります

npm update またはnpm install <packages>@latestを実行してnpmパッケージを手動で更新し、依存関係を最新のバージョンにするケースを考えてみましょう。

こうした更新手順を実行すると、先ほどと同じことが起こります。npm updateコマンドはプライベートnpmプロキシに最新バージョンの取得を要求し、プロキシは公開npmレジストリで最新バージョンを確認します。

yarnを使用している場合、yarn upgradeを実行すると、公開npmjsレジストリから悪意のある可能性があるパッケージが取り込まれ、同じ結果になります。

次の例で説明します。まず、内部のsuperlaser@1.0.0バージョンから始めます。

1{
2  "name": "new-project",
3  "version": "1.0.0",
4  "description": "",
5  "main": "index.js",
6  "scripts": {
7    "test": "echo \"Error: no test specified\" && exit 1"
8  },
9  "keywords": [],
10  "author": "",
11  "license": "ISC",
12  "dependencies": {
13    "superlaser": "^1.0.0"
14  }
15}

ローカルレジストリを定義し、稼働中のVerdaccioサーバーを指定する.npmrcファイルを用意しています。それでも、依存関係をすべて最新にするためにnpm updateを実行すると、公開npmjsレジストリから、semverの条件に一致する最新バージョンが取り込まれることがわかります。

どうすれば防げるでしょうか？

npmパッケージを手動で無条件に更新するのではなく、オープンソースプロジェクトのリポジトリにプルリクエストを作成する自動パッケージ更新を利用しましょう。これにより、package-lock.jsonやyarn.lockなどのパッケージマニフェストも同期されます。

Snykを使えば、npmパッケージの更新を自動化できます。以下は、マージされたプルリクエストのスクリーンショットです。

Snykが作成するプルリクエストの数を制限したり、特定のパッケージの更新を完全に無視したりするなど、自動更新の設定をさらに細かく調整できます。詳しくは、Snykのドキュメント自動PRによる依存関係のアップグレードをご覧ください。

アプリケーションセキュリティに関するリソースのまとめ

ここまで読んでくださった方には、記事の冒頭で出題したクイズの答えをお伝えします。オープンソースツールの名前「snync」は、So Now You’re Not Confused（もう混乱していない、という意味）の略です。正解できましたか？

サプライチェーンのセキュリティインシデントが発生している昨今、コードを書くときも、日々の開発者セキュリティの習慣においても、安全な手法を実践することの重要性はいくら強調してもしすぎることはありません。JavaScriptやNode.jsを日常的に使用している方やチームには、次の参考資料がおすすめです。

1. GitHubセキュリティのベストプラクティス10選

2. npmセキュリティのベストプラクティス10選

3. Dockerを使ってNode.jsウェブアプリケーションをコンテナ化するためのベストプラクティス10選