Slowloris, une nouvelle attaque de type "HTTP flooding"
Date : 06 Juillet 2009
L'outil permet d’effectuer des attaques par déni de service sur les serveurs vulnérables en très peu de temps d’une part, mais aussi sans nécessiter de grande connaissance sécurité ou réseau. C’est pour cela que nous avons jugé utile d'informer notre communauté de l’existence de cet outil, via le message VulnCoord-2009-008 Outil de DOS web SlowLoris), et ce malgré l’absence de rapport massif d’exploitation de cette vulnérabilité.
Slowloris en quelques mots ?
Slowloris est un outil d’attaque "DOS". Il a pour objectif de rendre inaccessible un serveur web ou WAF vulnérable. Pour ce faire, il tente de provoquer une surconsommation anormale des connexions disponibles (sockets) sur le serveur cible. Cependant, Slowloris n’est pas une attaque de type "TCP DOS" traditionnelle, qui consisterait à saturer un serveur en consommant toutes les sockets TCP qu’il est en mesure d’ouvrir.
L’idée n’est pas nouvelle, si l’on se souvient des attaques de type "Syn-Flooding" qui conserve les demandes de connexions TCP ouvertes afin de provoquer une saturation réseau de la cible.
La technique employée ici est la même, sauf qu’elle porte sur l’établissement des connexions HTTP et non TCP. Elle consiste à maintenir les connexions HTTP vers le serveur cible dans un état connecté le plus longtemps possible, et à réitérer les demandes de connexions afin de saturer le serveur, empêchant ainsi toute nouvelle connexion.
D’un point de vue technique
Contrairement à une attaque "TCP DOS", les connexions TCP de Slowloris vont jusqu’à leur terme (le fameux "3-way-handshake"). Celles-ci ne sont donc pas laissées à l’état semi-ouvert (half-open) et sont donc bien établies (SYN -> SYN-ACK -> ACK). Par contre les sessions HTTP sont bien maintenues à l’état ouvert, afin de conduire à une saturation du serveur vulnérable. Ceci témoigne donc d’une certaine similarité entre les deux attaques.
Pour maintenir les connexions ouvertes, plutôt que d’envoyer des données aléatoires vers le serveur cible (comme le font de nombreux outils), Slowloris transmet au serveur des requêtes dont les en-têtes HTTP sont incomplètes (commande GET…). Ceci provoque l’attente de la réception de la fin de l’en-tête par le serveur cible. Ensuite, Slowloris maintient les connexions ouvertes sur le serveur par envois réguliers d’en-têtes erronées vers ce dernier.
En répétant ces demandes de connexion et en les maintenant actives le plus longtemps possible, Slowloris pousse le serveur à atteindre ses limites de connexions autorisées, ce qui provoque le déni de service.
Pourquoi Slowloris est-il différent des autres ?
Comme nous l’avons dit précédemment, il n’y a rien de novateur dans la vulnérabilité exploitée, puisqu’en 2007 un article de SecurityFocus ("a cheesy Apache / IIS DoS vuln") décrivait déjà la faisabilité de cette attaque, sans toutefois fournir d’outil de démonstration (PoC).
Toutefois, bien qu'il existe de nombreux outils permettant de provoquer des DOS, Slowloris présente la particularité de ne nécessiter qu’une très faible bande passante réseau. Ce n’était pas le cas des outils connus à ce jour, qui dans les attaques de type "flooding" nécessitent en général l’envoi d’un très grand nombre de paquets IP (souvent plusieurs milliers) pour provoquer le déni du service visé.
Slowloris lui, ne nécessite que l’envoi de quelques centaines de requêtes HTTP vers le serveur, préservant ainsi la bande passante réseau. C’est ce qui rend possible des attaques depuis des connexions bas débit.
De plus, il permet un déni de service ciblé, c’est-à-dire du service web uniquement. En effet, contrairement à ce que permet une attaque "TCP DOS" classique, qui provoque le déni de service du système vulnérable (plus de connectivité réseau), Slowloris ne permet la saturation que du serveur web. Les autres services hébergés sur la machine continue de fonctionner. C’est d’ailleurs souvent ce qui est souhaité par les pirates, afin de poursuivre leurs méfaits.
Slowloris peut également changer les données dans les en-têtes qu’il transmet au serveur. Cette technique peut être vue comme une manière de camoufler ou rendre plus difficile le filtrage ou l’analyse a posteriori des traces.
Il peut également être plus furtif que les autres, du fait du fonctionnement du système de journalisation des serveurs Apache. En effet, la journalisation des évènements par le serveur Apache, n’a lieu que lors de la clôture des sessions HTTP ouvertes. Du fait du maintien de celles-ci par Slowloris, les journaux ne seront remplis que lors de l’arrêt de l’outil d’attaque. Par conséquent, tant que l’outil fonctionne, les évènements et les erreurs de connexions (Erreur 404) ne seront pas immédiatement transmis aux systèmes de journalisation. Cela permet une sorte de camouflage du déni de service en cours.
Comment s’en protéger ?
Il est souvent difficile de formuler des conseils ou recommandations face à des vulnérabilités d’implémentation. En effet, au-delà du fait que ces failles touchent souvent de multiples éditeurs, les correctifs ou palliatifs ne peuvent s’appliquer de façon uniforme.
Bien que la vulnérabilité exploitée par Slowloris ne semble affecter que les serveurs web utilisant des processus à base de "Thread" comme Apache, Squid et d’autres (IIS semble actuellement épargné), il est évident que cette nouvelle attaque pose de nombreux problèmes.
De nombreuses questions se posent ; "Est-ce qu’une solution de load balancing amont protège un serveur vulnérable ?", "Est-ce que mes routeurs filtrants ou firewalls peuvent bloquer l’attaque Slowloris ?", "Est-ce que ma solution WAF me protège ?". Et il est en effet légitime de se poser toutes ces questions.
Malheureusement, il n’y a pas de réponse toute faite. La difficulté est inhérente à la forme de l’attaque. D’un point de vue TCP, l’attaque est légitimement "orchestrée". En effet les établissements de connexion sont légitimes. Les en-têtes HTTP le sont aussi (initialement en tout cas). Ceci rend donc tout filtrage difficile (puisque tout semble légitime). Le seul paramètre "anormal" ici c’est le temps de connexion HTTP. Dans la plupart des cas, les sessions HTTP initiées vers un serveur sont de courte durée. Réduire le temps d’ouverture des sessions pourrait donc réduire les effets de l’attaque mais cela pourrait aussi avoir des effets de bord sur les serveurs vulnérables utilisés pour le transfert de grosses quantités de données (ex. transferts de fichiers).
L’une des parades consiste à influer sur la variable de "Timeout" des sessions HTTP, comme le fait remarquer cet article du SANS. Pour Apache, il s’agirait de modifier la variable "Timeout" (par défaut à 300s) comme le conseille la page de sécurité d’Apache. Cependant, il faut être conscient que ceci peut avoir des effets de bords pour les personnes dotées de connexions bas débit, pour les sessions de transferts par exemple ou les sessions applicatives qui peuvent nécessiter des valeurs de "Timeout" élevées. Ce paramètre doit donc être choisi en connaissance de cause.
Une autre solution est d’agir sur le nombre de connexions autorisées par adresse IP sur le serveur vulnérable. L’avantage de cette solution est également son défaut principal, puisqu’elle limitera implicitement le trafic passant par les serveurs mandataires (proxy) ou rendra incompatible toute utilisation d’un "reverse proxy".
Une autre solution peu coûteuse consiste à augmenter le nombre de connexions autorisées sur le serveur. Cependant cette technique risque de rester vaine face à un Slowloris qui tournerait en permanence et arriverait à consommer toutes les connexions autorisées.
Une autre solution est d’utiliser un "reverse proxy" non vulnérable en amont d’un serveur vulnérable. Dans l’état actuel des systèmes vulnérables, cela reviendrait probablement à mettre en place un serveur Microsoft (ex. ISA) pour protéger un serveur Apache ou autre. Ce qui peut prêter à sourire. Il existe également une solution de relayage et de "load balancing" gratuite du nom de "Haproxy", dont une configuration particulière permet de se protéger contre Slowloris.
Une dernière solution pourrait venir des IPS, si l’on peut identifier des signatures permettant l’inspection des flux HTTP (afin de détecter les en-têtes échangées pour maintenir la session HTTP ouverte). Pour le moment, malheureusement, ces signatures n’existent pas. D’autres alternatives plus ou moins artisanales consisteraient à vérifier périodiquement l’état des sessions HTTP établies depuis un temps trop grand. Il est toutefois nécessaire de développer de telles solutions et d’être conscient du contenu habituel de son trafic, notamment celui des applications web, afin de ne pas couper des sessions légitimes.
En attendant, la vulnérabilité n’a
toujours pas été corrigée. Nous la suivons dans la faille en cours
d’investigation FA-2009.0112.
