L'attaque CPDoS, qui permet de rendre les pages inaccessibles, étant diffusées via le CDN

Des chercheurs des universités de Hambourg et de Cologne
ont développé une nouvelle technique d'attaque contre les réseaux de distribution de contenu et les proxies de mise en cache — CPDoS (Cache-Poisoned Denial-of-Service). Cette attaque permet de provoquer un refus d'accès à une page en empoisonnant le cache.

Le problème est que les CDN mettent en cache non seulement les requêtes réussies, mais aussi les situations où le serveur http renvoie une erreur. En règle générale, lorsque des problèmes surviennent lors de la formation des requêtes, le serveur renvoie une erreur 400 (Bad Request), à l'exception de l'IIS, qui renvoie une erreur 404 (Not Found) pour des en-têtes trop volumineux. La norme autorise la mise en cache uniquement 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), qui dépend de la requête envoyée.

Les attaquants peuvent provoquer un retour d'erreur « 400 Bad Request » sur la ressource d'origine en envoyant une requête avec des en-têtes HTTP correctement formatés. Ces en-têtes ne sont pas pris en compte par les CDN, donc les informations sur l'impossibilité d'accéder à la page seront mises en cache, et toutes les autres requêtes correctes des utilisateurs jusqu'à l'expiration du délai peuvent entraîner un affichage de l'erreur, bien que le site d'origine fournisse sans problème le contenu.

Pour forcer le serveur HTTP à renvoyer une erreur, trois variantes d'attaque ont été proposées :

• HMO (HTTP Method Override) — l'attaquant peut réécrire la méthode de demande d'origine via les en-têtes « X-HTTP-Method-Override », « X-HTTP-Method » ou « X-Method-Override », qui sont pris en charge par certains serveurs, mais pas par les CDN. Par exemple, il est possible de changer la méthode d'origine « GET » en une méthode « DELETE » interdite sur le serveur ou en une méthode « POST » non applicable pour des contenus statiques ;
  
• HHO (HTTP Header Oversize) — l'attaquant peut ajuster la taille de l'en-tête de manière à ce qu'il dépasse la limite du serveur d'origine, mais ne soit pas soumis aux restrictions du CDN. Par exemple, Apache httpd limite la taille de l'en-tête à 8 Ko, tandis que le CDN Amazon Cloudfront autorise des en-têtes allant jusqu'à 20 Ko ;
  
• HMC (HTTP Meta Character) — l'attaquant peut insérer des caractères spéciaux dans la demande (\n, \r, \a), qui sont considérés comme non valides sur le serveur d'origine, mais ignorés dans le CDN.
  

Le CDN CloudFront, utilisé par Amazon Web Services (AWS), a été particulièrement touché par l'attaque. Actuellement, Amazon a déjà résolu le problème en interdisant la mise en cache des erreurs, mais il a fallu plus de trois mois aux chercheurs pour obtenir la mise en place de protections. Le problème a également affecté Cloudflare, Varnish, Akamai, CDN77 et
Fastly, mais l'attaque à travers eux est limitée aux serveurs cibles utilisés avec IIS, ASP.NET, Flask et Play 1. Il est noté, que potentiellement 11 % des domaines du ministère américain de la Défense, 16 % des URL de la base HTTP Archive et environ 30 % des 500 plus grands sites selon le classement Alexa pourraient être exposés à cette attaque.

Comme méthode de contournement pour bloquer l'attaque du côté du site, il est possible d'utiliser l'en-tête « Cache-Control: no-store », interdisant la mise en cache des réponses. Dans certains CDN, comme
CloudFront et Akamai, il est possible de désactiver la mise en cache des erreurs au niveau des paramètres du profil. Des pare-feu pour applications web (WAF, Web Application Firewall) peuvent également être utilisés pour la protection, mais ils doivent être déployés du côté du CDN avant les hôtes qui effectuent la mise en cache.

Source : opennet.ru