Ce matin mise à jour Apache, tiens donc, comme à l’accoutumée je cherche à savoir ce que corrige/apporte cette mise à jour, ce que je vous encourage à faire vous aussi.

http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser

Whaoo, une vulnérabilité à une attaque Dos de type « fire and run away » c’est à dire réalisable avec une seule machine et pas la moindre bande passante. Autant dire que c’est du pain béni pour les hackers du monde entier puisque qu’Apache délivre pas loin – si ce n’est plus -  de 50% du trafic HTTP mondial. Plus impressionnant encore toutes les versions d’Apache depuis la 1.3 sont vulnérables et ce dès leur installation par défaut.

La faute à qui ? Une mauvaise implémentation du protocole HTTP/1.1 au niveau des headers ‘Range’ et ‘Range-Request’. Le problème avait pourtant déjà été reporté en 2007 par Michal Zalewski à cette adresse : http://seclists.org/bugtraq/2007/Jan/83

Le header Range est détaillé dans la RFC2616 qui définit le protocole HTTP/1.1 :

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35

Le header Range permet de spécifier dans une requête HTTP que l’on souhaite seulement récupérer une partie de la réponse (la page).  On peut par exemple chercher à récupérer les n premiers octets. Le problème est que rien – d’après la RFC – n’empêche de récupérer plusieurs fois la même partie de la page, ce qui permet de générer une réponse énorme à partir d’une page de seulement quelques kilooctets. L’implémentation de cette fonctionnalité dans Apache et visiblement dans IIS — du moins à l’époque — ne protège pas le serveur contre une telle requête. Il faut dire que la RFC reste assez vague quant au besoin même d’implémenter cette fonctionnalité.

Exploitation de la vulnérabilité :

1 – Ouvrir parallèlement autant de connexion TPC qu’il est possible (ou nécessaire).

2 – Négocier une fenêtre TCP de grande taille (>= 1Go).

3 – Envoyer une requête HTTP partielle par connexion TCP contenant un header Range forgé pour récupérer plusieurs fois la totalité de la page — de l’octet zéro à la fin de la page. La limite est la taille maximum d’un champ header  — 8Ko pour Apache — soit plus de 1000 fois alors imaginez un peu le carnage sur un fichier avi ou un iso.

GET /foo.html HTTP/1.1
Host: example.com
Range: bytes=0-,0-,0-,0-,0-,...

4 – Clore les connections TCP pour lancer l’attaque.

5 – Se déconnecter ou rejeter simplement les réponses du serveur de manière silencieuse — il ne se rendra compte qu’on n’écoute plus seulement une fois la taille de la fenêtre TCP épuisée.

Que va-t-il se passer ?

Le serveur va recevoir les requêtes et commencer à mouliner et donc à consommer du temps processeur pour générer les réponses. Pour ce faire il va créer de nouveaux processus qui vont petit à petit – quelques minutes suffisent — remplir  complètement la mémoire du serveur et ce jusqu’à la SWAP. Il en résulte une instabilité certaine du système et un mal-fonctionnement voir un arrêt des services hébergés par la machine, you win.

Vous l’aurez compris, l’intérêt de l’attaque est de pouvoir déstabiliser un serveur en envoyant une très faible quantité de données en un temps très court, vous n’avez maintenant plus qu’à regarder tranquillement le serveur s’écrouler — d’où le nom « fire and run away », vous placez un explosif à mèche lente dans un bâtiment, vous vous reculez tranquillement de quelques kilomètres et attendez le spectacle.

Visiblement oubliée du grand public — des hackers et experts en sécurité — cette faille refait surface suite au post de ce petit script Perl permettant d’exploiter la faille sur Full Disclosure. Apache a bien évidement réagi et proposé un correctif dans les jours qui ont suivis, il n’est donc plus nécessaire que je vous explique comment contrer cette attaque, il suffit de mettre à jour.

Encore plus rapidement l’équipe SpiderLabs a créer des règles permettant de mitiger le risque à l’aide du mod_security. Ce module que je ne peux que vous recommander permet de détecter et de lutter contre de nombreux patterns d’attaque web allant de l’énumération en passant par les injections, les attaques de type  XSS ou CSRF et bien d’autres.  L’article suivant explique comment ils ont procédé pour contrer cette attaque :

http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html