
Imperva Cloud WAFは、log4jエクスプロイト、SQLインジェクション、コマンド実行、ディレクトリトラバーサル、XXEなどの悪意のあるHTTP POSTペイロードを送信する際に、攻撃者がWAFルールを回避できるようにするバイパスに対して脆弱でした。
Impervaのチームは、報告を受けた瞬間からこの問題を非常に真剣に受け止め、わずか数日でグローバルな修正を完了させました。素晴らしい対応です。Cloud WAFの全顧客は、2021年12月22日時点で自動的にパッチが適用されています。Impervaは協力的で、明らかに成熟した、熟練した、有能なセキュリティチームを擁しています。
HTTP POSTリクエストにヘッダー Content-Encoding: gzip を追加します。POSTデータはそのままにします。エンコードしないでください。Content-Encoding ヘッダーの最初の4バイトが gzip である限り、POSTリクエストにはWAFルールが適用されません。
これは、BurpのプロキシのMatch & Replace機能を使用して行うこともできます:

次のように新しいヘッダーを追加します:

これで完了です。準備は整いました。
次のように、POSTリクエストをサポートするURLに対して imperva_gzip.py を実行します:
構文:
./imperva_gzip.py [[-t] | [-r]] URL
指定されたURLのWAFタイプを推測します:
$ ./imperva_gzip.py -t https://www.vulnerable.com/search
Imperva Incapsula
$ ./imperva_gzip.py -t https://www.wordpress-user.com/login
WordFence
$ ./imperva_gzip.py -t https://www.cloudflare-customer.com
Cloudflare
WAFがgzipバイパスに対して脆弱かどうかを確認します:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[+] Checking for Imperva WAF...
[+] Attempting gzip bypass for UNIX trigger...
[+] Vulnerable! HTTP response code: 200
[+] Attempting gzip bypass for Windows trigger...
[+] Vulnerable! HTTP response code: 200
次のエラーが発生した場合:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[!] Can't POST to https://www.vulnerable.com/search. Try -r if 30x redirects are allowed. HTTP response code: 302
その場合は、コマンドラインで -r を渡してリラックスモードを有効にしてみてください。リラックスモードはデフォルトでオフになっており、POSTリクエストに対してサーバーがHTTP 200応答を返すことが期待されます。-r を指定すると、許容される応答がHTTP 2xx、3xxに拡張されます。
imperva_gzip.py の終了コードは次のとおりです:
0: Returned after getting WAF type.
1: Command-line was invalid.
2: There was an error connecting. Could be DNS error, timeout, etc.
3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked.
4: A WAF was detected, but it wasn't Imperva.
5: The server responded to a test POST request with something other than HTTP 200.
128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass.
129: The bypass was effective for the UNIX payload, but not the Windows one.
130: The bypass was effective for the Windows payload, but not the UNIX one.
131: The bypass was effective against both Windows and UNIX payloads.
次の3つのPOSTリクエストを送信します:
&test=../../../../../../../etc/shadow などの追加の「悪意のある」データを含めて、Impervaがそれをブロックすることを確認するContent-Encoding: gzip を追加し、Impervaがそれをブロックしないことを確認するhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding によると、Content-Encoding ヘッダーには4つの有効な値があります:
compressdeflategzipbrテストでは、gzip のみがバイパスとして機能しました。
Cloud WAFはImpervaによって管理されています。その結果、Cloud WAFの更新はほぼすべての顧客にほぼ同時に影響します。2021年12月22日時点で、すべての顧客にパッチが適用されています。
gzip バイパスのバグは、SecureSphere という別のImperva製品で修正されています。SecureSphere v12.6のリリースノート には、次の段落が含まれています:
SPHR-58185: SecureSphereが「Content-Encoding: gzip/deflate」ヘッダーを含むリクエストのPOST本文の解凍に失敗した場合、アラートを発行せずにリクエストを通過させていました。
これが同じバグであることはほぼ間違いないと思います。おそらくCloud WAFと同じコードの系統を持つものでしょう。これほど特殊なバグが2つの製品に存在するのは考えにくいからです。この問題は2021年2月にSecureSphereで解決されましたが、いつ導入されたかは不明です。この脆弱性は何年も存在していた可能性があります!
Impervaカスタマーサポート: https://www.imperva.com/support/technical-support/