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

htARTE（HackTricks AWS Red Team Expert） でゼロからヒーローまでAWSハッキングを学ぶ！

HackTricks をサポートする他の方法:

HackTricks で企業を宣伝したい または HackTricks をPDFでダウンロードしたい 場合は SUBSCRIPTION PLANS をチェックしてください！
公式PEASS＆HackTricksのグッズを入手する
The PEASS Familyを発見し、独占的な NFTs のコレクションを見つける
💬 Discordグループ に参加するか、telegramグループ に参加するか、Twitter 🐦 @carlospolopm をフォローする
ハッキングトリックを共有するために、PRを HackTricks と HackTricks Cloud のGitHubリポジトリに提出してください。

H2Cスマグリング

クリアテキスト上のHTTP2（H2C）

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

スマグリングの問題の核心は、リバースプロキシ の使用に起因します。通常、リバースプロキシはHTTPリクエストを処理し、バックエンドに転送してからバックエンドの応答を返します。ただし、HTTPリクエストに Connection: Upgrade ヘッダーが存在する場合（websocket接続で一般的に見られる）、リバース プロキシはクライアントとサーバーの間に永続的な接続を維持 し、特定のプロトコルで必要な連続した交換を容易にします。H2C接続の場合、RFCへの遵守には、3つの特定のヘッダーが存在する必要があります。

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

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

脆弱なプロキシ

この脆弱性は、リバースプロキシが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値を除外したもの）でテストする価値があります。なぜなら、一部のバックエンドが標準に準拠していない可能性があるからです。

{% hint style="danger" %} proxy_pass URL内で指定された特定のパス（例：http://backend:9999/socket.io）に関係なく、確立された接続は常にhttp://backend:9999にデフォルトします。これにより、このテクニックを利用して、その内部エンドポイント内の任意のパスとやり取りすることが可能となります。したがって、proxy_pass URL内でパスを指定してもアクセスが制限されるわけではありません。 {% endhint %}

BishopFoxのh2csmugglerおよびassetnoteのh2csmugglerというツールは、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や、バージョン1.8.0以前のEnvoyプロキシなどが含まれます。他のプロキシも影響を受ける可能性があります。

シナリオ2

このシナリオでは、公開WebSocket APIと公開REST API（ヘルスチェック用）を持つバックエンドが、アクセスできない内部REST APIを持っています。より複雑な攻撃は、以下の手順を含みます：

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

警告: このテクニックの複雑さは、ステータスコード101を返すエンドポイントとやり取りできる能力が必要となるため、増加します。

最終的に、NGINXはクライアントとバックエンドの間にWebSocket接続が存在すると誤解します。実際にはそのような接続は存在せず、ヘルスチェックREST APIが標的となります。それでも、リバースプロキシは接続を維持し、クライアントがこの接続を介してプライベートREST APIにアクセスできるようにします。

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

ラボ

両方のシナリオをテストするためのラボは、https://github.com/0ang3el/websocket-smuggle.gitで確認できます。

11 KiB Raw Blame History Unescape Escape