Chercheurs des universités de Hambourg et de Cologne
une nouvelle technique d'attaque sur les réseaux de diffusion de contenu et les proxys de mise en cache - (Déni de service empoisonné par le cache). L’attaque permet de refuser l’accès à une page via un empoisonnement du cache.
Le problème est dû au fait que les CDN mettent en cache non seulement les requêtes terminées avec succès, mais également les situations dans lesquelles le serveur http renvoie une erreur. En règle générale, s'il y a des problèmes avec la formation des requêtes, le serveur génère une erreur 400 (Bad Request), la seule exception est IIS, qui génère une erreur 404 (Not Found) pour les en-têtes trop volumineux. La norme autorise uniquement la mise en cache des erreurs avec les codes 404 (Not Found), 405 (Method Not Allowed), 410 (Gone) et 501 (Not Implemented), mais certains CDN mettent également en cache les réponses avec le code 400 (Bad Request), ce qui dépend sur la demande envoyée.
Les attaquants peuvent provoquer le renvoi par la ressource d'origine d'une erreur « 400 Bad Request » en envoyant une requête avec des en-têtes HTTP formatés d'une certaine manière. Ces en-têtes ne sont pas pris en compte par le CDN, donc les informations sur l'impossibilité d'accéder à la page seront mises en cache, et toutes les autres demandes valides des utilisateurs avant l'expiration du délai d'attente peuvent entraîner une erreur, malgré le fait que le site d'origine diffuse le contenu. sans aucun problème.
Trois options d'attaque ont été proposées pour forcer le serveur HTTP à renvoyer une erreur :
- HMO (HTTP Method Override) - un attaquant peut remplacer la méthode de requête d'origine via les en-têtes "X-HTTP-Method-Override", "X-HTTP-Method" ou "X-Method-Override", pris en charge par certains serveurs, mais non pris en compte dans le CDN . Par exemple, vous pouvez remplacer la méthode « GET » d'origine par la méthode « DELETE », qui est interdite sur le serveur, ou la méthode « POST », qui n'est pas applicable pour la statique ;
- HHO (HTTP Header Oversize) - un attaquant peut sélectionner la taille de l'en-tête de manière à ce qu'elle dépasse la limite du serveur source, mais ne tombe pas dans les restrictions CDN. Par exemple, Apache httpd limite la taille de l'en-tête à 8 Ko et Amazon Cloudfront CDN autorise des en-têtes jusqu'à 20 Ko ;
- HMC (HTTP Meta Character) - un attaquant peut insérer des caractères spéciaux dans la requête (\n, \r, \a), qui sont considérés comme invalides sur le serveur source, mais sont ignorés dans le CDN.
Le plus vulnérable aux attaques était le CDN CloudFront utilisé par Amazon Web Services (AWS). Amazon a désormais résolu le problème en désactivant la mise en cache des erreurs, mais il a fallu plus de trois mois aux chercheurs pour ajouter une protection. Le problème a également affecté Cloudflare, Varnish, Akamai, CDN77 et
Rapidement, mais l'attaque via eux est limitée aux serveurs cibles qui utilisent IIS, ASP.NET, и . , que 11 % des domaines du ministère américain de la Défense, 16 % des URL de la base de données HTTP Archive et environ 30 % des 500 meilleurs sites Web classés par Alexa pourraient potentiellement faire l'objet d'attaques.
Comme solution de contournement pour bloquer une attaque côté site, vous pouvez utiliser l'en-tête « Cache-Control : no-store », qui interdit la mise en cache des réponses. Dans certains CDN, par ex.
CloudFront et Akamai, vous pouvez désactiver la mise en cache des erreurs au niveau des paramètres de profil. Pour la protection, vous pouvez également utiliser des pare-feu d'applications Web (WAF, Web Application Firewall), mais ils doivent être implémentés côté CDN devant les hôtes de mise en cache.
Source: opennet.ru