Publié initialement le 29 septembre 2023 | mis à jour le 10 octobre 2023
Par : Dave Andrews, Marcus Hildum, Sergio Ruiz
Mise à jour : attaque HTTP/2 Rapid Reset – CVE-2023-44487
Suite au bref blog initial ci-dessous, Edgio a discuté avec des pairs de toute l’industrie sur la définition et la divulgation responsable de CVE-2023-44487 – attaque de réinitialisation rapide HTTP/2.
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 le pensait auparavant. Edgio conseille à tous les clients qui exécutent une infrastructure publique de mettre à niveau leurs serveurs vers des versions corrigées dès qu’elles sont disponibles et/ou de désactiver HTTP/2 temporairement.
Edgio est également disponible pour aider à atténuer les risques pour nos clients en effectuant la terminaison HTTP/2 et en proxy HTTP/1,1 vers l’infrastructure des clients. Contactez-nous pour lancer ce processus.
Le 28 août 2023 à 18h43, 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 le volume de logs 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, à la fois notre équilibreur de charge de couche 7 (que nous appelons un « frontend ») et notre couche de mise en 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 uniques était beaucoup plus élevé que d’habitude : lors de l’attaque, nous avons vu des instances de plus de 20 000 requêtes sur un seul socket.
- Aucun octet n’était envoyé aux clients.
- Le temps total de 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 observations initiales, nous avons théorisé que l’attaquant abandonnait les requêtes à l’aide de la trame 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 impactant la bibliothèque HTTP/2 que nous utilisons, nghttp2, qui pourrait en prouver la cause première.
- Construction de variables Sailfish pour exposer les principes fondamentaux de ce comportement et permettre des atténuations.
- Création de nouveaux indicateurs, 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 la CVE correspondante. Après un examen plus approfondi de la différence, nous avons réalisé que ce problème ne se trouvait pas seulement dans Envoy, mais en fait dans nghttp2, que nous utilisons.
Une demande de tirage et une libération de balise ponctuelle pour nghttp2 ont été publiées peu de temps après la divulgation, résolvant le problème sous-jacent. L’absence d’une CVE spécifique allouée à nghttp2 signifiait que notre système d’analyse CVE automatisé, que nous utilisons pour suivre les vulnérabilités dans les logiciels clés que nous utilisons, n’avait pas le problème à l’origine.
Nous avons immédiatement commencé le processus de mise à niveau de cette dépendance et de son déploiement, qui a été achevé il y a quelques semaines.
2. Pourcentage de réinitialisation de la demande
En parallèle, nous avons travaillé pour identifier le comportement d’attaque par programmation, au sein de Sailfish lui-même, afin de pouvoir agir immédiatement pour éviter 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 d’élaborer une règle qui fermerait 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, qui nous permettent de la désactiver pour des emplacements ou des clients spécifiques.
Dans 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 autre anomalie.
3. Comptages et ratios
Afin d’identifier plus rapidement les attaques de ce type, nous avons configuré un nouveau tableau de bord et une 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 fronts en particulier. Pour donner une visibilité sur cette préoccupation plus générale, nous avons commencé à suivre le ratio du taux de transaction entre les frontaux et les backends dans un emplacement donné. Les données sous-jacentes à cette comparaison constituent un élément central 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 en une seule requête back-end. Il est également visible que les bandes se rapprochent de 0,5 et 0,25, qui se produisent principalement dans des emplacements de test inactifs, où les systèmes tels que la purge et la vérification de l’état entraînent le traitement par les backends d’un plus grand nombre de transactions internes :
Lors de l’attaque initiale cependant, vous pouvez clairement voir l’effet sur ce ratio:
Nos alertes actuelles sont configurées pour se déclencher lorsque le ratio dépasse une certaine valeur, créant un incident pour les ingénieurs support Edgio afin qu’ils trient et commencent les étapes d’atténuation.
Résumé
Il s’agissait d’un nouveau type d’attaque intéressant, exploitant une vulnérabilité relativement récemment révélée 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 fondamentale spécifique de l’attaque, ainsi que pour mettre en place des mesures d’atténuation 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 et une limitation de débit plus persistants.
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.
