HTTP接続の汚染

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
公式のPEASS＆HackTricksのグッズを手に入れましょう。
💬 Discordグループまたはtelegramグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。
ハッキングのトリックを共有するには、PRを hacktricks repo と hacktricks-cloud repo に提出してください。

この投稿の内容は https://portswigger.net/research/http-3-connection-contamination から取得されました****

Webブラウザは、異なるウェブサイトに向けたリクエストに対して、同じIPアドレスに解決し、両方のホスト名に対して有効なTLS証明書を使用する場合、HTTP接続の結合を使用します。

最初のリクエストのルーティングは、リバースプロキシの危険な動作であり、プロキシが接続の最初のリクエストを分析して、それをどのバックエンドにルーティングするかを判断し、その後のすべてのリクエストを同じバックエンドに送信します。

接続の結合と最初のリクエストのルーティングはうまく動作しません。例えば、secure.example.comとwordpress.example.comが両方ともリバースプロキシの背後にあり、*.example.comに対して有効な証明書を使用している場合を想像してください。

$ nslookup wordpress.example.com
52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing

$ nslookup secure.example.com
52.16.179.7 // same reverse proxy

$ openssl s_client -connect x.portswigger-labs.net:443
subject=/CN=*.example.com // wildcard TLS certificate

もしブラウザがwordpress.example.comにリクエストを送信した後にsecure.example.comにリクエストを送信しようとする場合、ブラウザの接続統合により、両方のリクエストが1つの接続に強制的に統合されます。最初のリクエストのルーティングにより、secure.example.comへのリクエストが誤ってWordPressのバックエンドにルーティングされます。つまり、wordpress.example.comでXSSを見つけた場合、それを使用してsecure.example.comを侵害することができます！

// create HTTP/2+ connection
fetch('https://wordpress.example.com/', {credentials: 'include'})

// connection coalescing will force this down the same connection...
// ...leading to the front-end misrouting it to WordPress
// the browser thinks our injected JS is coming from secure.example.com
// exposing saved passwords, cookies, etc.
location='https://secure.example.com/plugin/x?q=<script>stealPasswords()'

自分で接続の結合を探索することができます。Chromeの開発者ツールのネットワークタブのタイミンググラフを使用して（または masochist なら WireShark を使用して）、fetch()を使用してリクエストペアを発行し、グラフが2番目のリクエストの「初期接続」に費やされた時間を表示し、接続IDの列が一致するかどうかを確認してください：

{% code overflow="wrap" %}

fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

{% endcode %}

この脅威を詳しく調査したり、実際に発生しているかどうかをスキャンする時間を割いていませんが、現在はまれな状況であると考えています。まず、最初のリクエストのルーティングは比較的一般的ではなく、HTTP/2の実装の複雑さから、HTTP/1.1に比べてユニークなHTTP/2サーバーの数は非常に少ないです。また、接続の統合により、最初のリクエストのルーティングを行うHTTP/2サーバーは、正規の訪問者に対して一時的に破損する可能性があるため、所有者は攻撃者の助言なしで脆弱性を修正する可能性があります。

しかし、攻撃者にとってはすべてが悪いわけではありません。HTTP/3では、IPアドレスの一致が必要な要件を削除することが提案されています。これにより、最初のリクエストのルーティングを使用し、複数のホストに対して有効な証明書を持つフロントエンドを使用しているすべての人が公開されることになります。

これにより、最初のリクエストのルーティングとは関係のない第二のリスクも生じます。つまり、ワイルドカード証明書を持つ侵害されたサーバーは、MITMを必要とせずに悪用することができるようになります。実際には、これにより、悪意のある行為者のプールが大幅に増加します。

これらのリスクが現実のものになる前に、リバースプロキシが最初のリクエストのルーティングを行わないように注意してください。Repeaterでこれを手動でテストするには、HTTP/1とHTTP/2の接続の再利用を有効にし、HTTP Request Smugglerで「Connection-State」攻撃を使用してスキャンすることもできます。また、ワイルドカードTLS証明書は常に理想的ではありませんが、HTTP/3により、ワイルドカード証明書を持つ侵害されたサーバーはアクティブなMITMなしで姉妹ドメインを攻撃するために使用される可能性があります。

これらの新たな脅威は、ウェブインフラストラクチャが複雑に絡み合った混乱の中に陥っていくという継続的なトレンドを示しています。個々のサイトの弱点が全体システムのセキュリティに多くの非明示的な影響を与えるということです。これらのリスクが実際にどのように影響するか、興味深いです。

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

サイバーセキュリティ企業で働いていますか？ HackTricksであなたの会社を宣伝したいですか？または、最新バージョンのPEASSを入手したり、HackTricksをPDFでダウンロードしたりしたいですか？ SUBSCRIPTION PLANS をチェックしてください！
The PEASS Familyを発見しましょう。独占的なNFTのコレクションです。
公式のPEASS＆HackTricksのグッズを手に入れましょう。
💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦@carlospolopmをフォローしてください。
ハッキングのトリックを共有するには、 hacktricks repo と hacktricks-cloud repo にPRを提出してください。

9.5 KiB Raw Blame History Unescape Escape

HTTP接続の汚染

9.5 KiB

Raw Blame History