##新種のサプライチェーン攻撃のストーリー
Alex Birsanより
今年3月にAlex Birsan氏は テクノロジー35社以上 を対象とした依存関係かく乱（dependency confusion）についての調査の結果を発表しました。そこで、Apple、Microsoft、Shopify、その他大手テクノロジー会社も含む30社以上は依存関係かく乱というソフトウェアサプライチェーンのハッキングが含まれるコードベースを乱用しています。今回Markdown: DevSamurai株式会社はAlex Birsan氏の調査をアイデアから方法と結果をこ簡単にご紹介いたします。
Pythonなど一部のプログラミング言語ではプロジェクトをインストールするための、より簡単またはあまり公式ではない手法が用意されています。それらのインストーラーは通常、パブリックコードレポジトリーに関連付けさせており、誰もがコードパッケージを他社が使用できるように、自由にアップロードできます。
例えば、Nodeには npm とnpmレジストリ、PythonのpipはPyPI（Python Package Index）、それにRubyGemsはRubyの``gems` があります。
それらのソースどれからパッケージをダウンロードし、使用することはそのコードパッケージのパブリッシャーを信用するわけです。
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
でも、パッケージホスティングサービスは、ユーザがアップロードしたコードがすべてマルウェアが含まれていないこと、を保証しません。一例としては、この間の研究によりますと、タイポスクワッティング (typosquatting) は、URLハイジャッキングとも呼ばれる形態のサイバースクワッティングで、インターネットユーザーがWebブラウザにURLを入力する際に犯す打ち間違いを利用します。
よく知られている他の依存関係チェーンのパースには、様々な方法を利用して既存のパッケージを侵害したり、存在しなくなった依存関係の名前で悪意のあるコードをアップロードしたりすることが含まれます。
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
###アイデア
Alex BirsanのパートナーのJustin Gardner氏は、Paypalをハックしている間、GitHubに見つけたNode.jsソースコードを共有しました。このコードはPaypal内部の利用を目的としており、そのpackage.json フィルにはパブリック（npmからのパブリック）とプライベート（Paypalによる内部的にホストされている可能性が高い非パブリック名）の依存関係の組み合わせが含まれています。それらの名前は、当時、パブリックnpmレジストリに存在していませんでした。
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
それで、その悪質的なコードがその名前でnpmにアップロードされると、どうなるでしょう？Paypal内部のプロジェクトがプライベートのパッケージではなく、新しいパブリックパッケージデフォルト設定される可能性がありますか？それに、デベロッパー、自動化されたシステムはライブラリーにあるコードの実行を開始しますか？
ここで、Alex Birsanは自分で作成した「悪意のある」Nodeパッケージを見請求の名前でnpmレジストリにアップロードしてみました。いずれかのパッケージがPaypal所有サーバーまたはその他自社所有サーバーにインストールされる場合、パッケージ内のコードがすぐに通知してくれます。
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
データにもとづいて組織を特定し、それに機密情報を収集しすぎないように、Alex氏はユーザー名、ホスト名、及び各固有のインストールを記録することにしました。
DNSプロトコルを介して、自分のサーバーに情報を送信することにより、トラフィックが途中でブロックされたり、検出されたりする可能性が低くなります。
データはHEXエンコードされ、直接または中間リゾルバーを介して、カスタムの権威ネーム サーバーに到達したDNSクエリの一部DNSとして使用されます。サーバーは、受信した各クエリをログに記録できるように構成され、基本的にパッケージがダウンロードされたすべてのマシンの記録を保持していました。
Alex氏はまず、代替生態系を調査することを図り、同様のパッケージをPyPI（Python Package Index）とRubyGemsにそれぞれアップロードできるように、コードをPythonとRubyの両方に移植しました。
結局は、Alex氏はGitHub、主流なパッケージホスティングサービス（誤って公開させた内部パッケージ）、それにインターネットフォーラムにある投稿でも数多くの名前を見つけました。その中で、最もプライベートパッケージが見つけられたソースはJavaScriptファイルであると彼が気づきました。
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
2020年後半、彼らは標的となった企業の数百万のドメインを自動的にスキャンし、npmレジストリで見請求の追加JavaScriptパッケージ名を抽出しました。
###結果
（https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610）
内部サーバーまたはクラウド基盤ビルドを体系的に脆弱な開発パイプラインに設定が間違った、デベロッパーの一回限りの間違いから。有効な内部パッケージ名を不法占拠することは、大手テクノロジー企業のネットワークに侵入してリモートでコードを実行し、場合によっては攻撃者がビルド中にバックドアを追加できるようにするための、ほぼ確実な方法でした。とAlex氏が認識しました。
この脆弱性、いわばAlex氏に「依存関係かく乱」（dependency confusion）と呼ばれるの、はテストされた3つのプログラミング言語すべてにわたって、これまでに35組織以上の内で検出されました。大規模な組織は内部ライブラリーの使用率が高いことが反映されたそうです。
JavaScript の依存関係名が見つけやすいため、ログに記録されたすべてのコールバックのほぼ 75% が npm パッケージからのものです。しかし、RubyGems名を内部で特定した8社の中に、4社はRubyGemsによる依存関係かく乱の脆弱性が含まれたと判明しました。
悪意のあるコードベースを公開した数時間後、Shopify、Apple、それにMicrosoft、Nextflix、Yelp、Uberなどテクノロジー会社が内部に彼の使った脆弱性を乱入しました。
##それはなぜ起こったのか。
Alex氏によると、Pythonにおける依存関係かく乱の主な原因は--extra-index-url と呼ばれる「設計上安全でない」コマンドライン引数の誤った利用にあるそうです。この引数をpip install library ライブラリーで使用して独自のパッケージインデックスを指定すると、期待通りに動作するようですが、pip が実際に舞台裏で以下のことを行っていました。
・library が独自（内部）のパッケージインデックスに存在しているかどうか確認
・library がパブリックパッケージインデックス（PyPI）に存在しているかどうか確認
・見つかったバージョンをインストールする。パッケージが両方に存在する場合、デフォルトでより高いバージョン番号のソースからインストールする。
それでlibrary 9000.0.0 という名称のパッケージをPyPIにアップロードすると、依存関係が上記の例のようにハイジャックされます。
参考文献：Markdown: Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies - The Story of a Novel Supply Chain
###依存関係かく乱を用いたソフトウェアサプライチェーンのハッキングを回避する方法
世界中のテクノロジー企業はどうなるだろう。この度、Markdown: DevSamuraiは6月9日（水）Sonatype会社と共に**「依存関係かく乱」を用いたソフトウェアサプライチェーンのハッキングを回避する方法ウェビナー**を共催致します。
「依存関係かく乱攻撃」の仕組みと回避方法を徹底的に解説されますのでご興味のある方はぜひご参加ください。
開催時間：17時～17時45分（日本時間）
