Une équipe de chercheurs de l'Université de Pékin, de l'Université Tsinghua et de l'Université du Texas à Dallas a publié des informations sur votre travail effectué pour pouvoir identifier une nouvelle classe d'attaques DoS qu'ils ont nommée "RangeAmp" et qui reposent sur l'utilisation de l'en-tête HTTP Range pour organiser l'amplification du trafic à travers le réseau de distribution de contenu (CDN).
L'essence de la méthode c'est que, en raison de la bizarrerie du traitement des en-têtes Range sur de nombreux CDN, un attaquant peut demander un octet à partir d'un fichier volumineux via CDN, mais le CDN téléchargera le fichier entier ou un bloc de données beaucoup plus volumineux à partir du serveur de destination pour la mise en cache.
El grado de amplificación del tráfico durante un ataque de este tipo, según la CDN, es de 724 a 43330 veces, lo que se puede utilizar para sobrecargar el tráfico de CDN entrante o reducir el ancho de banda del canal de comunicación final al sitio de la victime.
L'en-tête Range permet au client de déterminer la plage de positions dans le fichier qui devrait être chargé au lieu de renvoyer le fichier entier.
Par exemple, le client peut spécifier "Plage: octets = 0-1023" et le serveur ne transmettra que les 1024 premiers octets de données. Cette fonctionnalité est très demandée lors du téléchargement de fichiers volumineux: l'utilisateur peut suspendre le téléchargement, puis le poursuivre à partir de la position interrompue. En spécifiant "bytes = 0-0", la norme prescrit de donner le premier octet du fichier, "bytes = -1" - le dernier, "bytes = 1-" - de 1 octet à la fin du fichier. Vous pouvez transférer plusieurs plages dans un en-tête, par exemple "Plage: octets = 0-1023.8192-10240".
En outre, une deuxième option d'attaque a été proposée (cela s'appelle l'attaque OBR (RangeAmp Overlapping Byte Ranges), conçu pour augmenter la charge du réseau lorsque le trafic est transféré via un autre CDN, qui est utilisé comme proxy (par exemple, lorsque Cloudflare agit en tant que frontend (FCDN) et Akamai agit en tant que backend (BCDN)). La méthode ressemble à la première attaque, mais est localisée dans les CDN et vous permet d'augmenter le trafic lors de l'accès via d'autres CDN, ce qui augmente la charge sur l'infrastructure et réduit la qualité de service.
L'idée est que l'attaquant envoie plusieurs plages à la requête de plage CDN, telles que "bytes = 0-, 0-, 0 - ...", "bytes = 1-, 0-, 0 - ..." ou "octets = - 1024,0-, 0 -…«.
Les requêtes contiennent un grand nombre de plages "0-", ce qui implique le retour du fichier de zéro à la fin. En raison d'une analyse de plage incorrecte lorsque le premier CDN fait référence au second, un fichier complet est renvoyé à chaque bande "0-" (les plages ne sont pas agrégées, mais ordonnées séquentiellement) si la duplication de plage et l'intersection sont présentes dans la demande d'attaque soumise à l'origine. Le degré d'amplification du trafic dans une telle attaque varie de 53 à 7432 XNUMX fois.
L'étude a examiné le comportement de 13 CDN: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath et Tencent Cloud.
"Malheureusement, bien que nous leur ayons envoyé plusieurs e-mails et essayé de contacter leur service client, StackPath n'a fourni aucun commentaire", a déclaré l'équipe de recherche.
«Dans l'ensemble, nous avons fait de notre mieux pour signaler de manière responsable les vulnérabilités et fournir des solutions d'atténuation. Les fournisseurs de CDN associés ont eu près de sept mois pour mettre en œuvre des techniques d'atténuation avant la publication de ce document. "
Tous les CDN examinés ont permis le premier type d'attaque sur le serveur cible. La deuxième version de l'attaque CDN s'est avérée être exposée à 6 services, dont quatre peuvent servir d'interface dans l'attaque (CDN77, CDNsun, Cloudflare et StackPath) et trois dans le rôle d'un back-end (Akamai, Azure et StackPath).
Le gain le plus élevé est obtenu dans Akamai et StackPath, qui vous permettent d'indiquer plus de 10 XNUMX rangs dans l'en-tête Rang.
Les propriétaires de CDN ont été informés de des vulnérabilités il y a environ 7 mois et au moment de la divulgation publique des informations, 12 CDN sur 13 ont résolu les problèmes identifiés ou ont exprimé leur volonté de les résoudre.
source: https://www.liubaojun.org