Publié initialement le 29 septembre 2023 | mis à jour le 10 octobre 2023
Dave Andrews, Marcus Hildum, Sergio Ruiz
Mise à jour : attaque par réinitialisation rapide HTTP/2 – CVE-2023-44487
Suite au bref blog initial ci-dessous, Edgio a engagé un dialogue avec des pairs de tout le secteur sur la définition et la divulgation responsable de CVE-2023-44487 – HTTP/2 Rapid Reset Attack.
Le problème sous-jacent affecte de nombreuses implémentations de serveurs HTTP/2, ce qui rend les implications de l’attaque beaucoup plus larges qu’Edgio ne l’avait précédemment réalisé. Edgio conseille à tous les clients qui utilisent une infrastructure publique de mettre à niveau leurs serveurs vers des versions corrigées dès qu’elles sont disponibles, et/ou de désactiver temporairement HTTP/2.
Edgio est également disponible pour aider à atténuer les risques pour nos clients en effectuant la terminaison HTTP/2 et en renvoyant HTTP/1,1 par proxy à l’infrastructure des clients. Veuillez nous contacter pour lancer ce processus.
Le 28 août 2023 à 6:43 h, PST, les ingénieurs d’Edgio ont observé une augmentation de l’utilisation de la mémoire sur nos serveurs périphériques, des taux de requêtes vers plusieurs grandes propriétés Web et du volume de journaux générés à la périphérie.
Le trafic, rapidement identifié comme une attaque, était nouveau car il n’était observable que dans les journaux de notre équilibreur de charge de couche 7. Edgio exécute notre moteur de mise en cache et de proxy HTTP personnalisé, Sailfish, en tant que notre équilibreur de charge de couche 7 (que nous appelons un « frontal ») et notre couche de cache et de proxy (le « backend »). Cela permet une instrumentation et une journalisation communes aux deux couches, ce qui rend les comparaisons entre elles triviales.
Lorsque nous avons creusé dans les journaux frontend, nous avons observé quelques comportements intéressants indiquant une attaque:
- Le nombre de requêtes pour les clients individuels était beaucoup plus élevé que d’habitude : pendant l’attaque, nous avons vu des instances de plus de 20 000 requêtes sur un seul socket.
- Aucun octet n’a été envoyé aux clients.
- Le temps total de la requête, du début à la fin, était compris entre 1 et 2 millisecondes, le tout passé à initier une nouvelle connexion proxy aux backends.
- Toutes les connexions présentant ce comportement étaient des connexions HTTP/2.
Sur la base de ces premières observations, nous avons théorisé que l’attaquant abandonnait les requêtes en utilisant le cadre RST_STREAM de HTTP/2 et lançait de nouvelles requêtes sur le même socket, très rapidement.
Après cela, nous avons divisé nos efforts en trois flux de travail distincts:
- Étudier tout problème potentiel affectant la bibliothèque HTTP/2 que nous utilisons, nghttp2, qui pourrait en prouver la cause première.
- Construire des variables Sailfish pour exposer les principes fondamentaux de ce comportement afin d’activer les atténuations.
- Construire de nouvelles métriques, tableaux de bord et alertes pour identifier plus rapidement ce type d’attaque.
1. Envoyé… mais vraiment nghttp2
Après une petite recherche, nous avons trouvé dans ce numéro Envoy, un proxy de service qu’Edgio n’utilise pas en périphérie, et le CVE correspondant. Après un examen plus approfondi du diff, nous avons réalisé que ce problème ne concernait pas seulement Envoy, mais aussi nghttp2, que nous utilisons.
Une demande de tirage et une libération de balise ponctuelle pour nghttp2 ont été publiées peu après la divulgation, abordant le problème sous-jacent. L’absence d’un CVE spécifique alloué contre nghttp2 avait signifié que notre système automatisé d’analyse CVE, que nous utilisons pour suivre les vulnérabilités dans les logiciels clés que nous utilisons, a manqué le problème à l’origine.
Nous avons immédiatement commencé le processus de mise à niveau et de déploiement de cette dépendance, qui a été achevé il y a quelques semaines.
2. Pourcentage de remise à zéro de la demande
En parallèle, nous avons travaillé à identifier le comportement d’attaque par programmation, au sein même de Sailfish, afin de pouvoir agir immédiatement pour prévenir les problèmes de performance ou de fiabilité. Nous avons décidé d’implémenter une variable de configuration (h2_remote_reset_percent) dans Sailfish, qui suivrait le pourcentage de requêtes sur une connexion donnée qui a été réinitialisée par le client.
L’ajout, en conjonction avec une variable existante pour le nombre de requêtes sur une seule connexion, nous a permis de créer une règle qui fermait immédiatement une connexion à un client qui avait dépassé un seuil de requêtes et avait réinitialisé plus d’un pourcentage configuré de requêtes. Nous avons enveloppé cette configuration dans des coffres-forts opérationnels normaux, ce qui nous permet de la désactiver pour des emplacements ou des clients spécifiques.
En pseudocode, cela ressemble à:
if request_count > 1000 and
h2_remote_reset_percent > 99 and
pop ~ ".*" and
customer_id not in () then
connection.silent_close();
fi
Après une validation minutieuse pour éviter tout impact involontaire sur le trafic de nos clients, la nouvelle règle a été déployée et les ingénieurs d’Edgio ont continué à surveiller toute anomalie supplémentaire.
3. Nombres et ratios
Afin d’identifier plus rapidement quand des attaques de ce type se produisent, nous avons configuré un nouveau tableau de bord et une nouvelle alerte basés sur le nombre de trames HTTP/2 RST_STREAM reçues des clients, à travers un emplacement. Ceci, associé à une vue singulière de la disponibilité de la mémoire et des bilans de santé, nous a donné un signal clair de dégradation potentielle due à ce type d’attaque spécifique :
Cependant, nous sommes restés préoccupés par d’autres types d’attaques potentielles qui pourraient affecter uniquement les frontend spécifiquement. Pour fournir une visibilité sur cette préoccupation plus générale, nous avons commencé à suivre le ratio du taux de transaction entre frontend et backend dans un endroit donné. Les données sous-jacentes à cette comparaison sont au cœur de notre surveillance depuis très longtemps.
En regardant le comportement normal, vous pouvez voir la forte bande autour de 1, le ratio attendu, car chaque requête qui arrive à un front-end se traduit par une requête backend unique. Les bandes sont également plus proches de 0,5 et 0,25, qui se produisent principalement dans des emplacements de test dormants, où des systèmes tels que la purge et le contrôle de l’état entraînent le traitement d’un plus grand nombre de transactions internes par les systèmes dormants :
Lors de l’attaque initiale cependant, vous pouvez clairement voir l’effet sur ce ratio:
Notre alerte actuelle est configurée pour se déclencher lorsque le ratio dépasse une certaine valeur, créant un incident pour les ingénieurs de support Edgio afin de trier et de commencer les étapes d’atténuation.
Résumé
Il s’agissait d’un nouveau type d’attaque intéressant, exploitant une vulnérabilité révélée relativement récemment dans une bibliothèque largement utilisée. Heureusement, l’équipe d’Edgio a travaillé rapidement pour améliorer notre conscience opérationnelle, atténuer la cause profonde spécifique de l’attaque, ainsi que mettre en place des atténuations génériques et réglables à usage général pour cette classe d’attaque.
Bien sûr, nous travaillons toujours sur des améliorations comme celle-ci, telles que de nouvelles façons d’identifier les mauvais acteurs via les empreintes digitales, ainsi que l’intégration de ce travail dans notre suite de produits de sécurité pour permettre un blocage plus persistant et une limitation de débit.
Jamais un moment ennuyeux à Edgio.
Pour en savoir plus sur notre protection DDoS complète, qui fait partie de la solution primée WAAP (Web application and API protection) d’Edgio, contactez nos experts ici.
