Aqua Nautilusのセキュリティ研究者は、脅威アクターがnpmのAPIに対してタイミング攻撃を実行し、非公開パッケージを発見できる可能性があることを明らかにした。
JavaScriptパッケージマネージャーに対するこのタイミング攻撃は、次のエンドポイント（一般的なパターン）へのリクエストを試みる権限のないユーザーや未認証ユーザーに対して、npmが404エラーを返す場合でも機能する。
https://registry.npmjs.org/@<scope_name>/<secret_package_name>
悪意ある攻撃者は、パッケージが存在するか削除されたかを判断するため、連続して複数のリクエストを送信できる。このようなタイミング攻撃は、「存在する非公開パッケージの検索にかかる時間と、存在しない非公開パッケージの検索にかかる時間」を比較するものだと、AquaのYakir Kadkoda氏は記している。
研究者らは、APIのレスポンスがパッケージの存在時または削除後に大幅に長くなることを確認するには、APIへの連続したリクエストが約5回必要だと突き止めた。所要時間は648ミリ秒対101ミリ秒だった。この差を利用すれば、テスト対象となるパッケージ名の候補リストを作成して、発見プロセスを自動化できる。
この問題は2022年3月にGitHubのバグ報奨金プログラムへ報告されたが、同プラットフォームの回答は安心できるものではない。「こうしたアーキテクチャ上の制約があるため、特定の非公開パッケージが存在するかどうかをタイミング攻撃によって判定されるのを防ぐことはできません」
以下も参照：コードのデバッグとセキュリティに役立つ主要ツール
ハッカーはAPI設計の欠陥をどう悪用できるか
Kadkoda氏の手法は非常に単純だ。同氏は「random-organization」という名前の下に非公開npmパッケージを作成し、いくつかのファイルをアップロードした。
次に、認証済みかつ認可されたユーザー（組織のメンバー）でパッケージが存在することを確認した。未認証ユーザーでも同じことを行ったが、連続したリクエストが1回だけの場合、目立った違いは見つからなかった。「さまざまなシステム」から5回連続でリクエストして初めて、結果に有意な差が現れた。
この情報を悪用すれば、非公開パッケージ名を暴露し、タイポスクワッティングや依存関係の混乱など、ソフトウェアサプライチェーンを攻撃するさまざまな手法を実行できる。
そのために攻撃者は、組織名を含む名前を使った汎用的な辞書や、よりカスタマイズした辞書を利用できる。開発チームが、整理された状態を保つために何らかの命名規則を適用することは珍しくない。
Aquaの研究者によると、攻撃者は公開データセットを利用して、削除された公開パッケージの一覧を入手し、それらを非公開パッケージに変更できる可能性もある。
このような脅威によって多くの組織が危険にさらされたのは、npm（やその他のプラットフォーム）にとって決して初めてのことではない（ソフトウェアサプライチェーン：依存関係にとって危険な時代）。
「ここ数年、サプライチェーン攻撃は数百ポイントも劇的に増加している」とKadkoda氏は記している。「脅威アクターの目的が、オープンソースのパッケージやプロジェクトにアクセスして汚染することのケースもある。また、正規の人気パッケージではなく悪意あるパッケージをダウンロードするよう被害者をだますため、名前を意図的に間違えて、非公開または公開のパッケージやプロジェクトになりすますケースもある」
npmへのタイミング攻撃から身を守る方法
Aqua Nautilusは、非公開・公開を問わずすべてのパッケージを記録することを推奨している。これは「自分たちのサプライチェーンを把握する」という実践に要約できる。
研究者らは、開発チームとセキュリティチームは、タイポスクワッティング、類似パッケージ、なりすましパッケージにも注意すべきだと述べている。
「社内の非公開パッケージと同じ名前を持つパッケージがほかに存在しないことを確認してほしい」と研究者らは述べている。「類似したパッケージが見つかった場合は、マルウェアが含まれていないことを確認し、関係するステークホルダーに通知する必要がある。
「社内パッケージに似た公開パッケージが見つからない場合は、公開パッケージをプレースホルダーとして作成し、このような攻撃を防ぐことを検討してほしい」
大規模なソフトウェアプラットフォームには大きな制約があるため、欠陥のあるAPI設計やその他のセキュリティホールの修正には長い時間がかかり、「修正しない」と判断されることさえある。しかし、それは企業がすべてのサードパーティーサービスをやめ、すべてを社内で処理すべきだという意味ではない。
- DIY方式が常に有効とは限らないのは、セキュリティの向上を保証しないまま、責任をサプライチェーンの末端に移すことになるためだ
- 総コストは大幅に増加し、インフラが保守とセキュリティの悪夢になる可能性さえある
もう1つの有効な方法は、非公開パッケージを増やしすぎないことだ。開発チームにとっては非常に魅力的だが、必ずしも最善の方法とは限らない。多くのユーティリティはまとめてリファクタリングできるからだ。非公開パッケージを作成すればするほど、定義上、攻撃対象領域は広がる。
多くのチームは、将来的に優れた公開オープンソースパッケージになり得る社内ツールから始めるが、すべてを同じ場所に置いておく必要はない。完全な履歴を残す必要もない。同じ名前の公開リポジトリを作成し、公開する時まで空のままにしておけばよい。
Gitのコミットを通じた望まない情報開示も避けられる。
最後に、開発環境のインストールと利用に関する手順を文書化し、開発者がパッケージをインストール（およびコミット）するのを防ぐことも重要だ。パッケージの追加、更新、削除にはチームによるレビューが必要になる。