Dependency Confusion
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
要約すると、依存関係の混乱脆弱性は、プロジェクトがスペルミスのある名前、存在しない、またはバージョンが指定されていないライブラリを使用しているときに発生し、使用される依存関係リポジトリが公開リポジトリから更新されたバージョンを取得することを許可します。
スペルミス:requests
の代わりに**reqests
**をインポート
存在しない:もはや存在しない内部ライブラリcompany-logging
をインポート
バージョンが指定されていない:内部の存在するcompany-requests
ライブラリをインポートするが、リポジトリはより新しいバージョンがあるかどうかを公開リポジトリで確認する。
すべての場合において、攻撃者は被害者企業が使用しているライブラリの名前を持つ悪意のあるパッケージを公開するだけで済みます。
あなたの会社が内部でないライブラリをインポートしようとしている場合、ライブラリのリポジトリは公開リポジトリでそれを探す可能性が非常に高いです。攻撃者がそれを作成している場合、あなたのコードと実行中のマシンは非常に高い確率で侵害されるでしょう。
開発者が使用するライブラリのバージョンを指定しない、またはメジャーバージョンだけを指定することは非常に一般的です。その後、インタープリターはその要件に合った最新バージョンをダウンロードしようとします。
ライブラリが既知の外部ライブラリ(例えば、Pythonのrequests
)である場合、攻撃者はあまりできることがありません。なぜなら、彼はrequests
という名前のライブラリを作成できないからです(彼が元の著者でない限り)。
しかし、ライブラリが内部である場合、例えばこの例のrequests-company
のように、ライブラリリポジトリが外部からの新しいバージョンの確認を許可する場合、公開されている新しいバージョンを探します。
したがって、攻撃者が会社がrequests-company
ライブラリのバージョン1.0.1(マイナーアップデートを許可)を使用していることを知っている場合、彼はバージョン1.0.2のライブラリrequests-company
を公開し、会社は内部のものの代わりにそのライブラリを使用することになります。
この脆弱性はAWSのCodeArtifactで発見されました(このブログ投稿の詳細を読む)。 AWSは、ライブラリが内部か外部かを指定できるようにすることで、外部リポジトリから内部依存関係をダウンロードするのを避けるように修正しました。
依存関係の混乱に関する元の投稿で、著者はJavaScriptプロジェクトの依存関係を含む数千の公開されたpackage.jsonファイルを検索しました。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)