
高速なHTTPダウングレード密輸スキャナー(Go製)
SmuggleFuzzは、設定可能で高速なHTTPダウングレードスマグリングスキャナです。ユーザーがカスタマイズ可能なガジェットリストを利用でき、スマグリング攻撃が失敗した理由についてより深い洞察を提供します。HTTPダウングレードに基づく多数のスマグリング脆弱性が未発見のままであると確信しています。残念ながら、多くの人が簡単なスキャンで探索を終えてしまいます。SmuggleFuzzを使用することで、他の人が見逃す可能性のあるスマグリング脆弱性を発見できます。
詳細については、https://moopinger.github.io/blog/smugglefuzz/fuzzing/smuggling/2024/01/31/SmuggleFuzz.html を参照してください。
リリースページからコピーをダウンロードしてください:https://github.com/Moopinger/smugglefuzz/releases
go install github.com/moopinger/smugglefuzz@latest
別の方法:
git clone https://github.com/moopinger/smugglefuzz.git
cd smugglefuzz
go build .
./smugglefuzz
SmuggleFuzzには3つのコマンドがあります:
Usage:
smugglefuzz scan [flags]
Examples:
smugglefuzz scan -u https://example.com/ --confirm
smugglefuzz scan -u https://example.com/ --filter TIMEOUT --confirm
smugglefuzz scan -u https://example.com/ -w wordlist.txt -t 10 --confirm --filter TIMEOUT
smugglefuzz scan --dc -u https://example.com/ -w wordlist.txt -x PUT --confirm
//複数のターゲット? -u の代わりに -f を使用し、ターゲットが記述されたファイルを指定するだけです:
smugglefuzz scan -f multiple_targets.txt --confirm -t 10
smugglefuzz scan -f multiple_targets.txt -w wordlist.txt --confirm -s ./save-success.txt --filter TIMEOUT
smugglefuzz scan -f multiple_targets.txt -w wordlist.txt -H "Cookie: date=...; session=...;" -s ./save-success.txt -x PUT --filter TIMEOUT
Flags:
-c, --confirm このフラグを有効にすると、タイムアウトが発生したときにターゲットに確認リクエストを送信します。ターゲットが脆弱かどうかを確認するのに役立ちます。
-d, --data string 送信するHTTP/2データフレーム。例:99\r\n (デフォルト "99\r\n")
--dc 出力の色を無効にします。出力をファイルに保存する場合に便利です。
-f, --file string 複数のターゲットをURL形式で含むファイル。1行に1ターゲット。
--filter string 文字列やフレームタイプなどでレスポンスをフィルタリングします。例:405, 200, 502, TIMEOUT, RST, GOAWAY など。
-H, --header string カスタムヘッダーを挿入します。通常のヘッダー形式で指定:"Cookie: date=...; session=...;"
-h, --help scanのヘルプ
-i, --interval int タイムアウト間隔(秒単位)(デフォルト 5)
-x, --method string 使用するHTTPリクエストメソッド (デフォルト "POST")
-s, --save-success string リクエストが確認成功した場合(--confirm フラグ経由)、ファイルに保存されます。多数のターゲットを扱う場合に便利です。
-t, --threads int 実行するスレッド数。Smugglefuzzは高速に動作できるため、希望する数を設定してください。ただし、多すぎるとWAFに悪影響を与える可能性があります。(デフォルト 4)
-u, --url string スキャン対象のターゲットURL
-w, --wordlist string 使用するカスタムガジェットリストを指定します。指定しない場合、デフォルトリストが使用されます。
Usage:
smugglefuzz request [flags]
Examples:
smugglefuzz request -u https://www.example.com/ -a "content-length\t; 13"
smugglefuzz request -u https://www.example.com/ -a "content-length\t; 13" -x PUT
smugglefuzz request -u https://www.example.com/ -a "content-length\t; 13" -H "Cookie: date=...; session=...;" --data "223\r\n"
Flags:
-a, --attack string 攻撃ヘッダー。'scan' モードのワードリストと同様に、(; ) で区切ります。
-d, --data string 送信するHTTP/2データフレームの内容 (デフォルト "99\r\n")
--dc 出力の色を無効にします。
-H, --header string カスタムヘッダーを挿入します。例:"Cookie: values"
-h, --help requestのヘルプ
-i, --interval int 検出のタイムアウト間隔(秒単位)(デフォルト 5)
-x, --method string 使用するメソッド (デフォルト "POST")
-u, --url string リクエストを送信するターゲットURL
これはデフォルトのスマグリングガジェットを出力します。現在のところ、組み込みの確認機能は H2.CL および H2.TE でのみ動作します。しかし、タイムアウト(--filter TIMEOUT)や、自分自身のドメイン上のOASTを使用して H2.0 攻撃を検出することも可能です(疑似ヘッダーセクションを参照)。
SmuggleFuzzは、カスタムワードリストを通じてリクエストを完全に制御できます。これらのリストは基本的な構造を持ち、最適なリクエスト処理のために従う必要があります。たとえば、ヘッダーとその値は、通常のコロンの代わりに セミコロンとスペース(; ) で分割されます。これにより、スマグリングリクエストにコロン値を含めやすくなります。また、さまざまな変異や創造的なアプローチの可能性も広がります。独自のペイロードを作成するための詳細なガイダンスは、James Kettle の HTTP/2 研究 を参照してください。
このツールには125個のスマグリングガジェットがあらかじめ含まれていますが、拡張の余地は常にあります。これらのガジェットは 'output' コマンドを使用して表示でき、クエリの構造を理解するのに役立ちます。ユーザーは 'w' フラグを使用してカスタムワードリストでスキャンを実行できます。リストは、改行や復帰(キャリッジリターンとラインフィードを '%0d%0a' または '\r\n' で表す)など、印刷不可能なバイト値に対してURLエンコーディング(%00)をサポートします。提供されるリストは包括的ですが、独自のガジェットを作成することで成功率を大幅に向上させることができます。
h2cサポートが必要ですか? SmuggleFuzzの「experimental-h2c」ブランチをチェックしてください。
疑似ヘッダーは完全にサポートされており、":name" 構文を使用してカスタマイズできます:
:authority:scheme:methodこれらのヘッダーは、H2.0攻撃ベクターをテストする際に特に便利です。たとえば、OASTベースの方法を使用してH2.0スマグリングをテストする場合、以下のようなワードリストエントリが効果的です:
v0.1.8以降、[HOSTNAME] はプレースホルダーとして使用できます。SmuggleFuzzは実行時にこれをホスト名に置き換えます。
:authority; [HOSTNAME]\r\n\r\nGET / HTTP/1.1\r\nHost: uniqid.oastify.com\r\nX-HEADER:%20または
:authority; [HOSTNAME]\r\n\r\nGET https://uniqid.oastify.com/ HTTP/1.1\r\nHost: [HOSTNAME]\r\nX-HEADER:%20SmuggleFuzzで使用される検出方法は、AlbinowaxがHTTP/1スマグリング研究で使用した方法や、defparamのSmugglerと類似していますが、HTTP/2に適合するよう調整されています。幸い、これらの攻撃はダウングレードを伴うため、H2.CLとH2.TEの両方の検出に同じリクエストボディ/DATAペイロードを使用できます。
ワードリストの重要なガイドラインとして、正常にスマグリングされたヘッダーには、確認攻撃のために以下の値を含める必要があります:
CL: 13
TE: chunked
各リクエストには、値 "99\r\n" を持つ「Body」/DATAフレームが含まれます。TEヘッダーがスマグリングされた場合、サーバーが正常にスマグリングした場合、チャンク化されたコンテンツ長153(0x99)として解釈され、タイムアウトが発生します。同様に、CLヘッダーがコンテンツ長13でスマグリングされた場合も、長さが満たされないためタイムアウトが発生します。
確認リクエストは、タイムアウトを引き起こした同じクエリを再送信しますが、Data: "3\r\nABC\r\n0\r\n\r\n" を使用します。これにより、チャンク化されたTEとCLの13の両方が満たされ、正常なレスポンスが得られ、スマグリング脆弱性の可能性を示します。