Attaque HTTP/2 Rapid Reset affectant les produits F5 NGINX

Cet article de blog porte sur une vulnérabilité récemment découverte liée au protocole HTTP/2. Dans certaines conditions, cette vulnérabilité peut être exploitée pour mener une attaque par déni de service contre NGINX Open Source, NGINX Plus et les produits associés qui implémentent la partie serveur de la spécification HTTP/2. Pour protéger vos systèmes contre cette attaque, nous vous recommandons de mettre immédiatement à jour votre configuration NGINX.

Le problème lié à la réinitialisation des flux HTTP/2

Après l’établissement d’une connexion avec un serveur, le protocole HTTP/2 permet aux clients d’ouvrir des flux simultanés afin d’échanger des données. Contrairement aux versions précédentes du protocole, si un utilisateur final décide de quitter la page ou d’interrompre l’échange de données pour toute autre raison, HTTP/2 permet d’annuler le flux. Pour ce faire, il envoie une trame RST_STREAM au serveur, lui évitant ainsi d’effectuer inutilement des opérations.

La vulnérabilité est exploitée en lançant puis en annulant rapidement un grand nombre de flux HTTP/2 sur une connexion établie, contournant ainsi le nombre maximal de flux simultanés autorisé par le serveur. Cela est possible parce que les flux entrants sont réinitialisés plus rapidement que les flux suivants n’arrivent, ce qui permet au client de surcharger le serveur sans jamais atteindre le seuil configuré.

Impact sur NGINX

Pour des raisons de performances et de consommation des ressources, NGINX limite par défaut le nombre de flux simultanés à 128 (voir « http2_max_concurrent_streams »). En outre, afin d’équilibrer au mieux les performances du réseau et du serveur, NGINX permet par défaut au client de maintenir les connexions HTTP pendant un maximum de 1 000 requêtes grâce à une connexion HTTP persistante (voir « keepalive_requests »).

En s’appuyant sur la limite par défaut des connexions persistantes, NGINX empêche ce type d’attaque. La création de connexions supplémentaires pour contourner cette limite permet de détecter les acteurs malveillants à l’aide des outils standard de surveillance et d’alerte de couche 4.

Toutefois, si NGINX est configuré avec une limite de connexions persistantes nettement supérieure à la valeur par défaut recommandée, l’attaque peut épuiser les ressources du système. Lorsqu’un flux est réinitialisé, le protocole HTTP/2 exige qu’aucune donnée ultérieure ne soit renvoyée au client sur ce flux. En règle générale, la réinitialisation n’entraîne qu’une surcharge négligeable pour le serveur, sous la forme de tâches qui gèrent proprement l’annulation. Toutefois, en contournant le seuil de flux de NGINX, un client peut exploiter cette surcharge et l’amplifier en ouvrant rapidement des milliers de flux. Cela provoque une forte hausse de l’utilisation du processeur du serveur, empêchant ainsi les clients légitimes d’accéder au service.

Déni de service par l’établissement de flux HTTP/2, suivi de l’annulation de ces flux avec des limites de maintien de connexion anormalement élevées

Mesures visant à réduire l’exposition aux attaques

En tant que serveur et proxy complet, NGINX fournit aux administrateurs des outils puissants pour atténuer les attaques par déni de service. Pour tirer parti de ces fonctionnalités, il est essentiel d’apporter les modifications suivantes aux fichiers de configuration de NGINX afin de réduire la surface d’attaque du serveur :

• keepalive_requests doit être conservé à sa valeur par défaut de 1 000 requêtes.
• http2_max_concurrent_streams doit être conservé à sa valeur par défaut de 128 flux.

Nous recommandons également d’ajouter ces mesures de sécurité conformément aux bonnes pratiques :

• limit_conn impose une limite au nombre de connexions autorisées depuis un même client. Cette directive doit être ajoutée avec un paramétrage raisonnable assurant un équilibre entre les performances de l’application et la sécurité.
• limit_req impose une limite au nombre de requêtes provenant d’un même client qui seront traitées pendant une période donnée. Cette directive doit être ajoutée avec un paramétrage raisonnable assurant un équilibre entre les performances de l’application et la sécurité.

Notre réponse

Nous avons testé plusieurs stratégies d’atténuation qui nous ont permis de mieux comprendre l’impact potentiel de cette attaque sur notre large éventail de clients et d’utilisateurs. Bien que ces recherches aient confirmé que NGINX dispose déjà de tous les outils nécessaires pour éviter cette attaque, nous avons souhaité prendre des mesures supplémentaires afin que les utilisateurs qui doivent configurer NGINX au-delà des spécifications recommandées puissent le faire.

Notre enquête a permis de mettre au point une méthode visant à améliorer la résilience des serveurs face à diverses formes d’attaques par saturation théoriquement possibles via le protocole HTTP/2. Nous avons donc publié un correctif qui renforce la stabilité du système dans ces conditions. Pour se protéger contre de telles menaces, nous recommandons aux utilisateurs de NGINX Open Source de recompiler les fichiers binaires à partir de la dernière version du code source, et aux clients de NGINX Plus d’effectuer immédiatement la mise à jour vers les derniers paquets (R29p1 ou R30p1).

Fonctionnement du correctif

Afin de garantir la détection précoce des attaques par saturation sur NGINX, le correctif limite le nombre de nouveaux flux pouvant être introduits au cours d’une même boucle d’événements. Cette limite correspond au double de la valeur configurée à l’aide de la directive http2_max_concurrent_streams. Elle s’applique même si le seuil maximal n’est jamais atteint, par exemple lorsque les flux sont réinitialisés juste après l’envoi de la requête (comme dans le cas de cette attaque).

Produits concernés

Cette vulnérabilité affecte le module HTTP/2 de NGINX (ngx_http_v2_module). Pour savoir si votre produit NGINX ou F5 spécifique est susceptible d’être affecté, veuillez consulter la page suivante : https://my.f5.com/manage/s/article/K000137106

Pour plus d’informations sur la CVE-2023-44487 – attaque par réinitialisation rapide HTTP/2, consultez : https://www.cve.org/CVERecord?id=CVE-2023-44487

Remerciements

Nous tenons à remercier Cloudflare, Amazon et Google pour leur contribution à la découverte de cette vulnérabilité, ainsi que pour leur collaboration afin de l’identifier et d’en atténuer les effets.

Cet article de blog a été mis à jour après sa date de publication initiale afin d’apporter des précisions supplémentaires sur les mesures correctives et d’en améliorer la clarté.