Attaque de réinitialisation rapide HTTP/2 affectant les produits F5 NGINX

Cet article de blog se concentre 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 exécuter une attaque par déni de service sur NGINX Open Source, NGINX Plus et les produits associés qui implémentent la partie côté serveur de la spécification HTTP/2. Pour protéger vos systèmes contre cette attaque, nous vous recommandons une mise à jour immédiate de votre configuration NGINX.

Le problème des réinitialisations de flux HTTP/2

Après avoir établi une connexion avec un serveur, le protocole HTTP/2 permet aux clients d'initier des flux simultanés pour l'échange de données. Contrairement aux itérations précédentes du protocole, si un utilisateur final décide de quitter la page ou d'arrêter l'échange de données pour toute autre raison, HTTP/2 fournit une méthode pour annuler le flux. Il le fait en envoyant une trame RST_STREAM au serveur, lui évitant ainsi d'exécuter des tâches inutilement.

La vulnérabilité est exploitée en initiant et en annulant rapidement un grand nombre de flux HTTP/2 sur une connexion établie, contournant ainsi le maximum de flux simultanés du serveur. Cela se produit parce que les flux entrants sont réinitialisés plus rapidement que l'arrivée des flux suivants, ce qui permet au client de surcharger le serveur sans jamais atteindre son seuil configuré.

Impact sur NGINX

Pour des raisons de performances et de consommation de ressources, NGINX limite le nombre de flux simultanés à une valeur par défaut de 128 (voir http2_max_concurrent_streams ). De plus, pour équilibrer de manière optimale les performances du réseau et du serveur, NGINX permet au client de conserver les connexions HTTP pour un maximum de 1 000 requêtes par défaut à l'aide d'un keepalive HTTP (voir keepalive_requests ).

En s’appuyant sur la limite keepalive par défaut, NGINX empêche ce type d’attaque. La création de connexions supplémentaires pour contourner cette limite expose les mauvais acteurs via les outils de surveillance et d’alerte de couche 4 standard.

Cependant, si NGINX est configuré avec un paramètre keepalive considérablement supérieur au paramètre par défaut et recommandé, l'attaque peut épuiser les ressources système. Lorsqu'une réinitialisation de flux se produit, 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 entraîne une surcharge négligeable du serveur sous la forme de tâches qui gèrent correctement l'annulation. Cependant, contourner le seuil de flux de NGINX permet à un client de profiter de cette surcharge et de l’amplifier en lançant rapidement des milliers de flux. Cela force le processeur du serveur à augmenter, refusant le service aux clients légitimes.

Déni de service par l'établissement de flux HTTP/2, suivi d'annulations de flux sous des limites de maintien en activité anormalement élevées.

Étapes à suivre pour atténuer 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 profiter de ces fonctionnalités, il est essentiel que les mises à jour suivantes soient apportées aux fichiers de configuration NGINX, minimisant ainsi la surface d’attaque du serveur :

• keepalive_requests doit être conservé au paramètre par défaut de 1000 requêtes
• http2_max_concurrent_streams doit être conservé au paramètre par défaut de 128 flux

Nous recommandons également que ces mesures de sécurité soient ajoutées en tant que bonne pratique :

• limit_conn applique une limite au nombre de connexions autorisées à partir d'un seul client. Cette directive devrait être ajoutée avec un paramètre raisonnable équilibrant les performances et la sécurité de l'application.
• limit_req impose une limite au nombre de requêtes qui seront traitées dans un laps de temps donné à partir d'un seul client. Cette directive devrait être ajoutée avec un paramètre raisonnable équilibrant les performances et la sécurité de l'application.

Comment nous réagissons

Nous avons expérimenté plusieurs stratégies d’atténuation qui nous ont aidés à comprendre comment cette attaque pourrait avoir un impact sur notre large éventail de clients et d’utilisateurs. Bien que cette recherche ait confirmé que NGINX est déjà équipé de tous les outils nécessaires pour éviter l’attaque, nous avons souhaité prendre des mesures supplémentaires pour garantir que les utilisateurs qui ont besoin de configurer NGINX au-delà des spécifications recommandées puissent le faire.

Notre étude a permis de mettre au point une méthode permettant d’améliorer la résilience du serveur sous diverses formes d’attaques par inondation théoriquement possibles via le protocole HTTP/2. En conséquence, nous avons publié un correctif qui augmente 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 reconstruire les binaires à partir de la dernière base de code et aux clients NGINX Plus de mettre à jour immédiatement les derniers packages (R29p1 ou R30p1).

Comment fonctionne le patch ?

Pour assurer la détection précoce des attaques par inondation sur NGINX, le patch impose une limite au nombre de nouveaux flux pouvant être introduits dans une boucle d'événements. Cette limite est définie à deux fois la valeur configurée à l'aide de la directive http2_max_concurrent_streams . La limite sera appliquée même si le seuil maximum n'est jamais atteint, comme 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 NGINX HTTP/2 ( ngx_http_v2_module ). Pour plus d'informations sur votre produit NGINX ou F5 spécifique qui pourrait être affecté, veuillez visiter : https://my.f5.com/manage/s/article/K000137106 .

Pour plus d'informations sur CVE-2023-44487 – HTTP/2 Rapid Reset Attack, veuillez consulter : https://www.cve.org/CVERecord?id=CVE-2023-44487

Remerciements

Nous tenons à remercier Cloudflare, Amazon et Google pour leur participation à la découverte et leur collaboration dans l’identification et l’atténuation de cette vulnérabilité.