Contournement des requêtes POST du pare-feu applicatif web (WAF) Imperva

Le pare-feu applicatif web (WAF) cloud Imperva était vulnérable à un contournement qui permet aux attaquants d'éviter les règles du WAF lors de l'envoi de charges utiles HTTP POST malveillantes, telles que des exploits log4j, des injections SQL, des exécutions de commandes, des traversées de répertoires, XXE, etc.

Correctif

L'équipe Imperva a pris cela très au sérieux dès le moment où cela leur a été signalé, et ils ont mis en place un correctif global en quelques jours seulement. Bravo. Tous les clients du Cloud WAF sont automatiquement mis à jour depuis le 22 décembre 2021. Imperva a été un partenaire formidable et possède clairement une équipe de sécurité mature, compétente et capable.

Pour l'exploiter

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 WAF ne sera appliquée aux requêtes POST.

Vous pouvez le faire dans Burp en utilisant la fonction Match & Replace du proxy :

Ajoutez un nouvel en-tête comme ceci :

C'est tout ; vous êtes prêt.

Exécution du script de test

Exécutez imperva_gzip.py contre une URL qui supporte les requêtes POST comme ceci :

Syntaxe : ./imperva_gzip.py [[-t] | [-r]] URL

Devinez 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

alors essayez de passer -r en ligne de commande pour activer le mode relaxé. Le mode relaxé 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 étend les réponses acceptables aux codes HTTP 2xx, 3xx.

Scripting

Les codes de sortie pour 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.

Processus de test manuel de la vulnérabilité

Envoyez trois requêtes POST :

Établissez une référence de requête/réponse POST avec une requête POST valide mais inoffensive.
Déclenchez le WAF Imperva en utilisant la même requête POST, mais avec des données « malveillantes » supplémentaires comme &test=../../../../../../../etc/shadow dans le corps pour vérifier qu'Imperva la bloque.
Ajoutez l'en-tête Content-Encoding: gzip à la même requête malveillante et vérifiez qu'Imperva ne la bloque pas.

Autres encodages

Selon https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, il existe quatre valeurs valides pour l'en-tête Content-Encoding :

compress
deflate
gzip
br

Lors des tests, seul gzip a fonctionné comme contournement.

Versions affectées

Imperva Cloud WAF

Le Cloud WAF est géré par Imperva. En conséquence, les mises à jour du Cloud WAF affectent presque tous les clients presque en même temps. Il est patché pour tous les clients depuis le 22 décembre 2021.

SecureSphere

Le bogue de contournement gzip a été corrigé dans un autre produit Imperva appelé SecureSphere. Les notes de version pour la v12.6 de SecureSphere contiennent ce paragraphe :

SPHR-58185: When SecureSphere failed to decompress POST body in requests with "Content-Encoding: gzip/deflate" header, it issued no alert and let the request through.

Je suis presque certain qu'il s'agit du même bogue, peut-être avec le même héritage de code que le Cloud WAF... c'est un bogue 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 !

Imperva_gzip_bypass

Populaires