Empoisonnement queue poisoning avec H2.TE

Response queue poisoning via H2.TE request smuggling

Lab: Response queue poisoning via H2.TE request smuggling | Web Security AcademyWebSecAcademy

• Profiter d’une vulnérabilité de request smuggling pour empoisonner la file de réponses.

• Utiliser cet empoisonnement pour accéder au panneau d’administration /admin.

• Récupérer la requête de l’administrateur (et donc sa cookie de session) au moment où il se connecte, puis supprimer l’utilisateur carlos.

Contexte technique

• L’application accepte des requêtes HTTP/2 côté front-end.

• Le front-end downgrade ces requêtes HTTP/2 vers HTTP/1, même lorsque la longueur est ambiguë.

• L’attaque repose sur une désynchronisation de type H2.TE :

  • On envoie une requête HTTP/2 contenant à la fois :

    • un en-tête Transfer-Encoding: chunked

    • un en-tête Content-Length

• La connexion vers le back-end est réinitialisée toutes les 10 requêtes :

  • si la connexion est « cassée », il suffit d’envoyer quelques requêtes normales pour repartir sur une connexion propre.

• En HTTP/2, on n’a pas besoin de définir Content-Length normalement, ce qui rend la présence simultanée de Transfer-Encoding et Content-Length ambiguë et exploitable.

Requête d’attaque

POST / HTTP/2

Host: 0afc007a0423d9b980403f2c00dd00d7.web-security-academy.net

Transfer-Encoding: chunked

Content-Length: 120



0



GET / HTTP/1.1

Host: 0afc007a0423d9b980403f2c00dd00d7.web-security-academy.net

Content-Length: 12



testing=test

• La partie HTTP/2 est vue par le front-end, qui la convertit en HTTP/1 pour le back-end.

• À cause de l’ambiguïté H2.TE, le back-end interprète différemment la fin de la requête.

• La ligne GET / HTTP/1.1 et ce qui suit sont furtivement injectés comme début de la prochaine requête dans la file côté back-end.

Nous récupérons la requête de l’admin empoisonnée, ce qui nous permet d’obtenir : sa cookie de session.