アップグレードヘッダーのスムーグリング

H2Cスムーグリング

HTTP2オーバークリアテキスト (H2C)

H2C、またはhttp2オーバークリアテキストは、標準のHTTP接続を持続的なものにアップグレードすることで、一時的なHTTP接続の規範から逸脱します。このアップグレードされた接続は、平文HTTPの単一リクエストの性質とは対照的に、継続的な通信のためにhttp2バイナリプロトコルを利用します。

スムーグリングの問題の核心は、リバースプロキシの使用にあります。通常、リバースプロキシはHTTPリクエストを処理し、バックエンドに転送し、その後バックエンドの応答を返します。しかし、HTTPリクエストにConnection: Upgradeヘッダーが存在する場合（一般的にウェブソケット接続で見られる）、リバースプロキシはクライアントとサーバーの間に持続的な接続を維持し、特定のプロトコルに必要な継続的な交換を促進します。H2C接続の場合、RFCに従うためには、3つの特定のヘッダーが必要です：

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

脆弱性は、接続をアップグレードした後、リバースプロキシが個々のリクエストの管理を停止し、接続確立後にルーティングの仕事が完了したと仮定する場合に発生します。H2Cスムギングを利用することで、H2C接続が正常に開始されると仮定して、リクエスト処理中に適用されるリバースプロキシルール（パスベースのルーティング、認証、WAF処理など）を回避できます。

脆弱なプロキシ

この脆弱性は、リバースプロキシがUpgradeおよび時にはConnectionヘッダーをどのように処理するかに依存します。以下のプロキシは、プロキシパス中にこれらのヘッダーを本質的に転送し、H2Cスムギングを本質的に可能にします：

HAProxy
Traefik
Nuster

逆に、これらのサービスはプロキシパス中に両方のヘッダーを本質的に転送しません。しかし、設定が不適切であれば、UpgradeおよびConnectionヘッダーのフィルタリングされていない転送を許可することがあります：

AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server

悪用

すべてのサーバーが、準拠したH2C接続アップグレードに必要なヘッダーを本質的に転送するわけではないことに注意することが重要です。そのため、AWS ALB/CLB、NGINX、Apache Traffic Serverなどのサーバーは、自然にH2C接続をブロックします。それでも、Connection: Upgradeの非準拠バリアントをテストする価値があります。これは、ConnectionヘッダーからHTTP2-Settings値を除外します。一部のバックエンドは標準に準拠していない可能性があります。

Caution

proxy_pass URLに指定された特定のパス（例：http://backend:9999/socket.io）に関係なく、確立された接続はhttp://backend:9999にデフォルト設定されます。これにより、この技術を利用して、その内部エンドポイント内の任意のパスと対話できます。したがって、proxy_pass URLにパスを指定してもアクセスは制限されません。

ツールh2csmuggler by BishopFoxおよびh2csmuggler by assetnoteは、H2C接続を確立することにより、プロキシによって課せられた保護を回避する試みを支援し、プロキシによって保護されたリソースへのアクセスを可能にします。

この脆弱性に関する追加情報、特にNGINXに関しては、この詳細なリソースを参照してください。

Websocketスムギング

Websocketスムギングは、プロキシを介してアクセス可能なエンドポイントへのHTTP2トンネルを作成するのとは異なり、潜在的なプロキシの制限を回避し、エンドポイントとの直接通信を促進するWebsocketトンネルを確立します。

シナリオ1

このシナリオでは、公開WebSocket APIとアクセスできない内部REST APIを提供するバックエンドが、内部REST APIへのアクセスを求める悪意のあるクライアントによって標的にされます。攻撃は以下のステップで展開されます：

クライアントは、ヘッダーに不正なSec-WebSocket-Versionプロトコルバージョンを含むUpgradeリクエストをリバースプロキシに送信します。プロキシはSec-WebSocket-Versionヘッダーを検証せず、Upgradeリクエストが有効であると信じてバックエンドに転送します。
バックエンドは、Sec-WebSocket-Versionヘッダーに不正なプロトコルバージョンを示すステータスコード426で応答します。リバースプロキシはバックエンドの応答ステータスを見落とし、WebSocket通信の準備が整ったと仮定し、応答をクライアントに中継します。
その結果、リバースプロキシはクライアントとバックエンドの間にWebSocket接続が確立されたと誤解しますが、実際にはバックエンドはUpgradeリクエストを拒否していました。それにもかかわらず、プロキシはクライアントとバックエンドの間にオープンなTCPまたはTLS接続を維持し、この接続を通じてクライアントがプライベートREST APIに無制限にアクセスできるようにします。

影響を受けるリバースプロキシには、問題に対処しなかったVarnishや、アップグレードメカニズムが変更されたEnvoyプロキシバージョン1.8.0以前が含まれます。他のプロキシも脆弱である可能性があります。

シナリオ2

このシナリオでは、公開WebSocket APIとヘルスチェック用の公開REST API、さらにアクセスできない内部REST APIを持つバックエンドが関与します。攻撃はより複雑で、以下のステップを含みます：

クライアントは、ヘルスチェックAPIをトリガーするためにPOSTリクエストを送信し、追加のHTTPヘッダーUpgrade: websocketを含めます。リバースプロキシとして機能するNGINXは、これをUpgradeヘッダーのみに基づく標準のUpgradeリクエストとして解釈し、リクエストの他の側面を無視してバックエンドに転送します。
バックエンドはヘルスチェックAPIを実行し、攻撃者が制御する外部リソースにアクセスし、ステータスコード101のHTTP応答を返します。この応答はバックエンドによって受信され、NGINXに転送されると、プロキシはステータスコードのみを検証するため、WebSocket接続が確立されたと誤解します。

警告: この技術の複雑さは、ステータスコード101を返すことができるエンドポイントと対話する能力を必要とするため、増加します。

最終的に、NGINXはクライアントとバックエンドの間にWebSocket接続が存在すると信じ込まされます。実際には、そのような接続は存在せず、ヘルスチェックREST APIがターゲットでした。それにもかかわらず、リバースプロキシは接続をオープンに保ち、クライアントがそれを通じてプライベートREST APIにアクセスできるようにします。

ほとんどのリバースプロキシはこのシナリオに脆弱ですが、悪用は外部SSRF脆弱性の存在に依存し、通常は低Severityの問題と見なされます。

ラボ

両方のシナリオをテストするためのラボを確認してください https://github.com/0ang3el/websocket-smuggle.git

9.3 KiB Raw Blame History Unescape Escape