Le service musical Spotify a supprimé la limite de 10 000 chansons pour les bibliothèques personnelles.

Un groupe de chercheurs de l'Université de Pékin, de l'Université Tsinghua et de l'Université du Texas à Dallas a détecté une nouvelle classe d'attaques DoS — RangeAmp, basée sur l'utilisation de l'en-tête HTTP Range pour organiser le renforcement du trafic via les réseaux de livraison de contenu (CDN). Le principe de la méthode repose sur le fait qu'en raison de la particularité du traitement des en-têtes Range par de nombreux CDN, un attaquant peut demander via le CDN un seul octet d'un grand fichier, mais le CDN chargera depuis le serveur cible l'intégralité du fichier ou un bloc de données beaucoup plus important pour le mettre en cache. Le degré de renforcement du trafic dans une telle attaque, en fonction du CDN, varie de 724 à 43330 fois, ce qui peut être utilisé pour surcharger le trafic entrant du CDN ou réduire la bande passante du canal de communication final vers le site de la victime.

L'en-tête Range permet au client de spécifier une plage de positions dans le fichier à charger au lieu de transmettre le fichier complet. Par exemple, le client peut indiquer « Range: bytes=0-1023 » et le serveur ne transmettra que les 1024 premiers octets de données. Cette fonctionnalité est recherchée lors du téléchargement de grands fichiers — l'utilisateur peut suspendre le téléchargement et le reprendre à partir de la position interrompue. En indiquant « bytes=0-0 », la norme prescrit de donner le premier octet du fichier, « bytes=-1 » — le dernier, « bytes=1- » — à partir de 1 octet jusqu'à la fin du fichier. Il est permis de transmettre plusieurs plages dans un même en-tête, par exemple « Range: bytes=0-1023,8192-10240 ».

Une seconde variante d'attaque a également été proposée, visant à augmenter la charge réseau en passant le trafic à travers un autre CDN, qui est utilisé comme proxy (par exemple, lorsque Cloudflare agit en tant que front-end (FCDN) et Akamai comme back-end (BCDN)). Cette méthode est similaire à la première attaque, mais se localise à l'intérieur des réseaux CDN et permet de renforcer le trafic lors des requêtes via d'autres CDN, augmentant ainsi la charge sur l'infrastructure et diminuant la qualité du service.

L'idée est que l'attaquant envoie des requêtes de plage CDN multi-plages, telles que «bytes=0-,0-,0-…», «bytes=1-,0-,0-…» ou «bytes=-1024,0-,0-…». Ces requêtes contiennent un grand nombre de plages «0-», ce qui implique la livraison du fichier depuis la position zéro jusqu'à la fin. En raison d'une implémentation incorrecte de l'analyse des plages lors de la première requête CDN vers le second, chaque plage «0-» entraîne la livraison du fichier complet (les plages ne sont pas agrégées, mais parcourues séquentiellement), si l'attaque initialement envoyée par l'attaquant contient des duplications et des intersections de plages. Le degré d'amplification du trafic dans cette attaque varie de 53 à 7432 fois.

Au cours de l'étude, le comportement de 13 CDN a été examiné —
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath et Tencent Cloud. Tous les CDN examinés autorisaient le premier type d'attaque sur le serveur final. Le second type d'attaque sur le CDN a affecté 6 services, dont quatre peuvent agir en tant que frontend (CDN77, CDNsun, Cloudflare et StackPath) et trois en tant que backend (Akamai, Azure et StackPath). L'amplification la plus importante se produit chez Akamai et StackPath, qui autorisent l'indication de plus de 10 000 plages dans l'en-tête Range. Les propriétaires de CDN ont été informés des vulnérabilités il y a environ 7 mois et, au moment de la divulgation publique, 12 des 13 CDN avaient corrigé les problèmes identifiés ou exprimé leur volonté de les corriger (seul le service StackPath n'a pas réagi).

Source : opennet.ru