Proxy / WAF Protections Bypass
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
この研究からの技術 from this research。
Nginxルールの例:
Nginxはバイパスを防ぐために、チェックする前にパスの正規化を行います。しかし、バックエンドサーバーが異なる正規化(nginxが削除しない文字を削除する)を行う場合、この防御をバイパスすることが可能かもしれません。
Nginx Version
Node.js Bypass Characters
1.22.0
\xA0
1.21.6
\xA0
1.20.2
\xA0
, \x09
, \x0C
1.18.0
\xA0
, \x09
, \x0C
1.16.1
\xA0
, \x09
, \x0C
Nginx Version
Flask Bypass Characters
1.22.0
\x85
, \xA0
1.21.6
\x85
, \xA0
1.20.2
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
1.18.0
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
1.16.1
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
Nginx Version
Spring Boot Bypass Characters
1.22.0
;
1.21.6
;
1.20.2
\x09
, ;
1.18.0
\x09
, ;
1.16.1
\x09
, ;
Nginx FPM構成:
Nginxは/admin.php
へのアクセスをブロックするように設定されていますが、/admin.php/index.php
にアクセスすることでこれをバイパスすることが可能です。
この投稿では、ModSecurity v3(3.0.12まで)が、アクセスされたパスを含むはずのREQUEST_FILENAME
変数を不適切に実装していたことが説明されています(パラメータの開始まで)。これは、パスを取得するためにURLデコードを行ったためです。
したがって、http://example.com/foo%3f';alert(1);foo=
のようなリクエストは、mod securityではパスが単に/foo
であると見なされます。なぜなら、%3f
が?
に変換されてURLパスが終了するからですが、実際にサーバーが受け取るパスは/foo%3f';alert(1);foo=
になります。
REQUEST_BASENAME
およびPATH_INFO
変数もこのバグの影響を受けました。
Mod Securityのバージョン2でも同様のことが発生し、特定の拡張子(例えば.bak
)に関連するファイルへのユーザーアクセスを防ぐ保護をバイパスすることが可能でした。これは、ドットを%2e
でURLエンコードして送信することで実現されました。例えば:https://example.com/backup%2ebak
。
この研究では、AWSが適用したHTTPヘッダーに対するWAFルールをバイパスするために、AWSによって適切に解析されなかった「不正な」ヘッダーを送信することが可能であったことが言及されていますが、バックエンドサーバーによっては解析されました。
例えば、ヘッダーX-QueryにSQLインジェクションを含む次のリクエストを送信することです:
AWS WAFをバイパスすることができたのは、次の行がヘッダーの値の一部であることを理解しなかったためであり、NODEJSサーバーは理解していた(これは修正された)。
一般的にWAFは、チェックするリクエストの長さ制限があり、POST/PUT/PATCHリクエストがそれを超えると、WAFはリクエストをチェックしません。
AWS WAFについては、ドキュメントを確認できます:
Application Load BalancerおよびAWS AppSync保護のために検査できるWebリクエストボディの最大サイズ
8 KB
CloudFront、API Gateway、Amazon Cognito、App Runner、およびVerified Access保護のために検査できるWebリクエストボディの最大サイズ**
64 KB
Core Rule Set 3.1(またはそれ以下)の古いWebアプリケーションファイアウォールは、リクエストボディの検査をオフにすることで128 KBを超えるメッセージを許可しますが、これらのメッセージは脆弱性のチェックを受けません。新しいバージョン(Core Rule Set 3.2以降)では、最大リクエストボディ制限を無効にすることで同様のことができます。リクエストがサイズ制限を超えると:
防止モードの場合:リクエストをログに記録し、ブロックします。
検出モードの場合:制限まで検査し、残りを無視し、Content-Length
が制限を超えた場合はログに記録します。
デフォルトでは、WAFはリクエストの最初の8KBのみを検査します。高度なメタデータを追加することで、制限を128KBまで引き上げることができます。
最大128KB。
Unicode 正規化の実装によって(詳細は こちら)、Unicode 互換性を共有する文字は WAF をバイパスし、意図したペイロードとして実行できる場合があります。互換性のある文字は こちら で見つけることができます。
https://github.com/ustayready/fireprox: ffufと一緒に使用するためのAPIゲートウェイURLを生成します
https://github.com/rootcathacking/catspin: fireproxに似ています
https://github.com/PortSwigger/ip-rotate: APIゲートウェイIPを使用するBurp Suiteプラグイン
https://github.com/fyoorer/ShadowClone: 入力ファイルサイズと分割係数に基づいて動的に決定された数のコンテナインスタンスがアクティブ化され、入力は並列実行のためにチャンクに分割されます。例えば、10,000行の入力ファイルから100行の分割係数で100インスタンスが100チャンクを処理します。
ファイアウォールのregexフィルターをバイパスするために異なる技術が使用できます。例としては、大文字小文字の交互、改行の追加、ペイロードのエンコードなどがあります。さまざまなバイパスのリソースはPayloadsAllTheThingsやOWASPで見つけることができます。以下の例はこの記事から引用されました。
nowafpls: WAFを長さでバイパスするためにリクエストにジャンクデータを追加するBurpプラグイン
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)