ネザーポータルデシンク (HUUP)

「私は既存の道を旅するのではなく、虚空を自由に跳び越えます。間違って梱包すれば、秘密を間違った戸口に届けてしまうでしょう。」

説明

このチャレンジは、UDP上にHTTP/3（QUIC）アプリケーションを重ねたものです。UDPはステートレスであり、プロキシはTCPのような厳格なHTTPリクエスト境界を強制しないため、プロキシとバックエンドサーバーの同期をずらすことが可能です。攻撃者は別のリクエスト内に隠れたHTTPリクエストをスマグリングできます。

注意 - 最大メッセージ長は1024バイト、実際に機能するのはGETリクエストのみ、メッセージは10秒後に破棄されます

ターゲット: byuctf.xyz:40011

脆弱性分析

• 脆弱性: HTTPリクエストスマグリング (UDP/QUIC上)
• 根本原因: 信頼性の低いプロトコルにおいて、フロントエンドプロキシとバックエンドアプリケーション間でのHTTPペイロード境界の解析が一貫していないこと。

この具体的な実装では、Pythonミドルウェア（udp_server.py）がポート40000で受信テキストを待ち受けます。このサーバーは、\r\n\r\nが見つかると実際のウェブサーバーにリクエストを転送します。UDPであるため、部分的なパケット配信が発生する可能性が高く、複数のリクエストを高速に送信したり、パケット境界を操作したりすると同期ずれが発生します。

攻略法

このチャレンジを解くには、UDPの信頼性の低い性質と、ミドルウェアがリクエスト境界を処理する特定の方法を考慮する必要があります。

1. 偵察: ルート/エンドポイントにアクセスすると、ネザー接続の不安定性に関するヒントが得られます。
2. エンドポイントの発見: /endpoints.txtに移動すると、200個の可能性のある隠しエンドポイントのリストが見つかります。
3. ブルートフォース: これらのエンドポイントの1つにフラグが含まれており、他の3つは偽陽性を返します。
4. プロトコル習得: UDPミドルウェアのため、標準的なブラウザリクエストでは完全なレスポンスボディを受信できない場合があります（接続が閉じられるかタイムアウトする前にヘッダーのみが返される可能性があります）。
5. 自動化: ターゲットに対してUDP経由で生のHTTPリクエストを送信するスクリプト（solve.pyを参照）を作成します。スクリプトはエンドポイントを反復処理し、完全なレスポンス（ボディを含む）を受信するまで各エンドポイントに繰り返しリクエストを送信する必要があります。

緩和策

• フロントエンドとバックエンドの両方がリクエスト境界を解析するために全く同じロジックを使用することを確認してください。
• あいまいな長さヘッダーやヘッダーストリーム内の不正な文字を含むリクエストは拒否してください。
• カスタムのUDP-to-TCP転送ロジックではなく、確立されたHTTP/3ライブラリを使用してください。

ヒント

• フロントプロキシとバックプロキシがどのように通信しているか把握しましたか？
• 使用中のプロトコルを確認してください—UDPは配信を保証しません！

フラグ

CH4KR4X2{P0D5_bl0ckch41n_br34ch}

ホスティング

このチャレンジは、ポート1337でFlaskサーバーを、ポート40000でudp_server.pyを実行します。

ビルド:

sudo docker build -t huup .
sudo docker network create -d bridge huup

実行:

sudo docker run -p 40011:40000/udp --detach --name huup --network huup huup:latest