Détecter et corriger la vulnérabilité zero-day HTTP/2 Rapid Reset CVE-2023-44487

Des chercheurs et des fournisseurs ont enquêté sur des attaques DDoS volumétriques observées entre août et octobre 2023. Cette enquête a permis de découvrir une nouvelle technique de « réinitialisation rapide » qui exploite le multiplexage des flux, une fonctionnalité du protocole HTTP/2 largement adopté.

Divulguée aujourd’hui, la vulnérabilité HTTP/2 Rapid Reset est suivie sous le numéro CVE-2023-44487 et a été classée comme vulnérabilité de gravité élevée, avec un score CVSS de 7,5 sur 10.

Cette vulnérabilité est réputée affecter tous les serveurs web qui implémentent HTTP/2. Son exploitation pourrait entraîner des attaques DDoS volumétriques de très grande ampleur. Si cette CVE affecte un package de votre application ou de votre système d’exploitation ET que ce package est présent dans une application déployée et accessible depuis Internet, pensez à :

• Vérifier auprès de votre fournisseur d’infrastructure et/ou de CDN (par exemple Cloudflare, Google Cloud, AWS ou Akamai) que vous êtes protégé contre cette vulnérabilité.

• Mettre à niveau le package si un correctif est disponible. Des versions corrigées ont déjà été publiées pour certains packages.

Snyk n’est pas affecté par cette vulnérabilité

Tous les services Snyk accessibles depuis l’extérieur sont protégés. Ils sont hébergés derrière Akamai ou des équilibreurs de charge cloud qui ont déjà été protégés contre cette vulnérabilité.

Atténuation des risques par le fournisseur d’infrastructure

Il est recommandé aux entreprises de commencer par appliquer, si nécessaire, des changements de configuration et des mesures d’atténuation auprès de leurs fournisseurs d’infrastructure et de leurs CDN, afin de réduire l’exposition à cette nouvelle technique DDoS. 

• Cloudflare : HTTP/2 Rapid Reset: décryptage de l’attaque qui a battu tous les records

• Google : Comment fonctionne la nouvelle attaque DDoS « Rapid Reset » sur HTTP/2

• AWS : CVE-2023-44487 - Attaque HTTP/2 Rapid Reset

• NGINX : L’attaque HTTP/2 Rapid Reset affecte les produits NGINX

• Azure : Réponse de Microsoft aux attaques par déni de service distribué (DDoS) contre HTTP/2

Même si l’exposition à cette vulnérabilité peut être efficacement atténuée par des fournisseurs d’infrastructure ou des équilibreurs de charge cloud, ne vous arrêtez pas là : prenez des mesures correctives à la source en mettant à niveau tous les packages susceptibles d’être affectés par cette CVE.

Mettre à niveau les packages vers des versions corrigées

Les entreprises doivent ensuite vérifier si leurs images de conteneur ou leurs écosystèmes open source sont affectés et appliquer les mises à jour disponibles. Vous trouverez tous les avis relatifs à cette CVE dans la Snyk Vulnerability Database, en sélectionnant votre ou vos gestionnaires de packages, ou votre ou vos distributions de conteneurs.

Détecter les vulnérabilités HTTP/2 avec Snyk

Pour savoir si vos projets ou applications sont affectés, filtrez par « CVE-2023-44487 » dans le rapport Détails du problème afin de trouver les projets contenant un package vulnérable.

Tester vos projets avec l’interface de ligne de commande Snyk

Snyk vous propose différentes façons de détecter et de corriger gratuitement la vulnérabilité HTTP/2 — sans frais. Avec la Snyk CLI, vous pouvez tester vos projets en local.

Tester les projets qui utilisent des gestionnaires de packages

Pour les applications, exécutez snyk test avec la Snyk CLI afin de comparer les dépendances de votre dépôt et de détecter les packages vulnérables. Vous pouvez tester tous vos projets avec la Snyk CLI à l’aide de snyk test --all-projects et spécifier le gestionnaire de packages avec l’option --package-manager=. Vous pouvez également indiquer un fichier de configuration non standard avec l’option --file=.

Les valeurs prises en charge actuellement pour l’option --package-manager= comprennent cocoapods, composer, golangdep, maven, npm et pip, entre autres (consultez la CLI pour découvrir les autres options).

Tester des projets C++ avec la CLI

Pour les applications, exécutez snyk test --unmanaged avec la Snyk CLI afin de comparer les dépendances non gérées de votre dépôt et de détecter les packages vulnérables.

Tester des images de conteneur avec la CLI

Pour les conteneurs, exécutez snyk container test afin de détecter les packages du système d’exploitation qui dépendent de versions vulnérables de HTTP/2. Pour obtenir les meilleurs résultats, indiquez le nom de l’image et le chemin vers le Dockerfile qui l’a créée. Par exemple :

snyk container test debian:10 --file=Dockerfile

Tester vos projets avec une intégration Git/SCM

L’importation de votre projet dans Snyk via nos intégrations SCM prises en charge (GitHub, Bitbucket, GitLab, Azure Repos) déclenche automatiquement un test. Vous pourrez ensuite utiliser l’interface Snyk pour identifier, prioriser et corriger les vulnérabilités http/2 dans vos projets dès qu’un correctif sera disponible. 

Corriger les vulnérabilités HTTP/2

Une fois les packages et conteneurs vulnérables identifiés dans votre environnement, vous pouvez les corriger avec Snyk. Les méthodes sont similaires, mais plusieurs options s’offrent à vous.

Pour les composants open source

• Correction automatique : connectez Snyk à vos dépôts Git pour qu’il puisse créer des pull requests afin de mettre à jour votre graphe de dépendances lorsque cela est possible, puis reconstruisez votre application.

• Correction manuelle (option 1) : si votre application dépend directement d’un composant affecté par la vulnérabilité HTTP/2, mettez à jour votre fichier de dépendances pour indiquer la version corrigée correspondante, puis reconstruisez votre application.

• Correction manuelle (option 2) : si votre application utilise un composant affecté par la vulnérabilité HTTP/2 comme dépendance indirecte ou transitive, identifiez une version de votre dépendance directe qui inclut une version mise à jour de la dépendance affectée, puis reconstruisez votre application. Si votre gestionnaire de packages prend en charge les substitutions, vous pouvez aussi traiter cette dépendance comme une dépendance directe et inclure une version corrigée dans votre fichier de configuration.

Pour les images de conteneur

• Correction automatique : connectez Snyk à vos dépôts Git afin qu’il puisse créer des pull requests pour mettre à jour l’image de base de votre Dockerfile lorsque cela est possible. Vérifiez si la mise à niveau de l’image de base suggérée est toujours vulnérable en utilisant https://snyk.io/test/docker/<image_name> , puis reconstruisez votre conteneur une fois que vous avez trouvé une option de mise à niveau adaptée.

• Correction manuelle : si votre image contient une version vulnérable des packages concernés et qu’aucune mise à niveau de l’image de base n’est disponible ou souhaitée, vous pouvez effectuer la mise à niveau vous-même en suivant les conseils de correction de Snyk Container. 

Si aucun correctif n’est encore disponible

Si la mise à niveau d’un package ou d’un conteneur spécifique n’est pas possible, cette vulnérabilité peut être atténuée en amont du chemin d’appel, comme indiqué précédemment. Par exemple, si un service est affecté par cette vulnérabilité et exposé à Internet via un équilibreur de charge cloud, il ne sera pas touché, car tous les principaux fournisseurs de cloud ont déjà atténué ce risque à leur niveau.

Comment reprioriser cette vulnérabilité à l’aide de règles personnalisées ?

Pour augmenter la priorité de la vulnérabilité HTTP/2 et la rendre plus visible, vous pouvez utiliser les règles personnalisées de Snyk afin de reprioriser ces vulnérabilités. La CVE est actuellement classée comme présentant une gravité élevée. Toutefois, si vous souhaitez modifier cette priorité, vous pouvez créer une règle qui cible CVE-2023-44487 et faire passer sa gravité à Critical.

À l’inverse, si vous avez atténué le risque par d’autres moyens, vous pouvez abaisser la gravité à Faible afin que vos rapports reflètent précisément la situation. 

Prochaines étapes pour répondre aux vulnérabilités HTTP/2

1. Appliquez des changements de configuration et des mesures d’atténuation auprès de vos fournisseurs d’infrastructure et de vos CDN afin de réduire l’exposition à cette nouvelle technique DDoS. 

2. Testez vos projets avec Snyk en suivant les méthodes décrites dans cet article. Pour commencer, créez un compte Snyk gratuit, puis importez et analysez tous les projets potentiellement affectés à l’aide de l’assistant d’importation.

3. Dès qu’ils sont disponibles, appliquez les correctifs en mettant à jour les bibliothèques affectées vers des versions corrigées et en créant de nouvelles images de conteneur à partir d’images de base corrigées.

4. Continuez à suivre l’évolution de la situation, suivez-nous sur Twitter/X (@snyksec) et consultez le blog Snyk pour rester au courant des dernières informations. Les équipes de sécurité de Snyk mettront régulièrement à jour nos ressources.