Slowloris exploite, en Déni de Service, une faille de conception dans Apache 1.x et 2.x, Squid, dhttpd et GoAhead WebServer

Par Xavier Poli, secuobs.com
Le 18/06/2009

---

Résumé : Slowloris permet de réaliser des attaques par Déni de Service via des requêtes HTTP partielles permettant d'exploiter une faille de conception dans l'implémentation du protocole HTTP de nombreux serveurs Web donc les branches 1.x et 2.x d'Apache - Lire l'article



Rsnake ( lien ) vient de publier un nouvel outil, Slowloris, permettant d'exploiter une faille de conception au sein de plusieurs serveurs Web, dont Apache ( lien ) dans ses branches 1.x et 2.x. L'exploitation de la vulnérabilité en question permet à un attaquant de réaliser un Déni de Service pour empêcher les utilisateurs légitimes d'avoir accès aux sites Web hébergés et cela sans pour autant que les autres services (SMTP, POP, ...) du serveur en soient impactés.

Contrairement à Letdown ( lien ) et Sockstress ( lien ), le Déni de Service n'est pas opéré via des connexions TCP incomplètes, il est ici imputable à l'implémentation HTTP. Une bande passante minimale est requise et le contexte offre une furtivité accrue. Slowloris s'appuie en fait sur de multiples connexions ouvertes via des requêtes HTTP partielles (SYN-Flood over HTTP), le différenciant ainsi de l'Apache benchmark tool ( lien ).

Des entêtes ultérieures sont envoyées à intervalle régulier pour la persistance, Apache peut ainsi être rapidement submergé, et plus généralement les serveurs avec une limitation du nombre de processus et de threads autorisés. A noter que la fluctuation de ce nombre (HARD_SERVER_LIMIT, MaxClients) ne fera que retarder l'échéance, il en va de même pour d'autres paramètres (TimeOut, MaxKeepAliveRequests, KeepAliveTimeout, MaxRequestsPerChild - lien ).

Slowloris doit cependant attendre que les requêtes légitimement en cours soient finalisées pour s'attribuer leurs ressources. Les sites Web à fort trafic, et Load Balancing ( lien ), nécessiteront un délai supplémentaire, mais l'issue restera la même. Dans ce laps de temps, les nouvelles connexions légitimes ne seront, pour la plupart ( race condition - lien ), déjà plus possibles. De plus, Slowloris intègre des fonctions permettant d'accroître sa furtivité, comme la modification dynamique des entêtes host pour exploiter les serveurs à virtual hosts.

Les fichiers de logs ne seront pas ici d'une grande utilité pour détecter les attaques Slowloris, puisqu'ils ne sont impactés que lorsqu'une connexion HTTP est complétée, ce qui ne sera que rarement le cas. Seul des solutions limitant le nombre de connexions par adresse IP source pourraient être temporairement envisagées, cependant l'utilisation conjointe de listes de proxy avec Slowloris rendrait par exemple le module mod_evasive ( lien ) inefficace dans un tel contexte.

Compléter périodiquement les requêtes, messages 200 contre erreurs 400 dans les logs, pour contourner les détections à posteriori et privilégier les requêtes POST aux GET/HEAD pour échapper à HTTPReady ( lien ) sont envisagées. Les serveurs Web concernés par cette attaque, et ses variantes (envois rapides d'entêtes de petites tailles, keep-alive et requêtes incomplètes, content-length sans données, ...), sont donc les branches 1.x et 2.x d'Apache, mais aussi dhttpd ( lien ) et GoAhead WebServer ( lien ).

A noter que les utilisateurs de Squid ( lien ) sont également dans la liste des victimes potentielles, alors que ceux des versions 6.0 et 7.0 de Microsoft IIS ( lien ) ne le sont pas, pas plus que ceux utilisant Lighthttpd ( lien ). Slowloris est compatible avec les systèmes d'exploitation de type GNU/Linux, alors que les utilisateurs des systèmes Microsoft Windows ne pourront pas le tester, même sous un environnement CygWin ( lien ).

Source : Ha.Ckers.org ( lien )