THC-SSL-DOS : jouer avec une faille SSL !

C’est avec intérêt que j’ai appris, en lisant le post de mon collègue Vincent Maurin «quel avenir pour le protocole HTTPS », que l’équipe THC avait sorti un nouvel outil : THC-SSL-DOS. Cette équipe existe depuis de nombreuses années et a produit des scripts de qualité. Une nouvelle production est donc une belle surprise et impose un passage en lab pour s’approprier tout cela.

THC-SSL-DOS

THC-SSL-DOS est un outil permettant de tester les montées en charge des serveurs supportant un service web sécurisé, en utilisant de façon intensive les fonctions de renégociation du protocole SSL.

Ce résultat est obtenu suite à une dissymétrie en termes de consommation de ressources entre le client et le serveur. En effet, la charge générée est environ quinze fois plus importante pour le serveur que pour le client. Cette propriété particulière permet d’aller éventuellement jusqu’au déni de service avec un simple PC.

vidéo phase 1 : l’installation

Aucun problème de compilation ou d’installation. Tout tourne parfaitement rond et le script est installé en 30 secondes. Une surprise agréable pour tous ceux qui ont, comme moi, passés de nombreuses heures à lutter avec les problèmes de dépendance des différentes librairies… Il ne reste donc plus qu’à essayer ce nouveau jouet.

Voir cette vidéo sur YouTube

vidéo phase 2 : mise en situation avec un CUCM

Et maintenant, comme Saint George terrassant le dragon (clin d’œil à la photographie liée à l’article, tout s’explique finalement), je vais endosser mon habit de preux chevalier de l’ordre de la sécurité pour évaluer l’impact de ce script.

Echec, le serveur à survécu à ma tentative et il est toujours possible d’accéder à l’interface de configuration du CUCM. Il est intéressant de constater qu’une configuration adapté du serveur web et du linux sous jacent a permis de protéger le serveur et de limiter l’impact d’une telle attaque. En effet, le message « tcp_connect() : Too many open files » montre que le serveur web a atteint l’une des limites paramétrés et qui permet de gérer les cas de connexions simultanées trop nombreuses.

Les déclarations des auteurs (il n’est pas possible de bloquer le processus initié par le script) semblent donc pouvoir être modulées avec de la compétence et de la rigueur lors du hardening system.

vidéo phase 3 : mise en situation avec un HP Proliant

L’interface web du serveur n’est plus accessible une fois l’attaque lancée. Aucun mécanisme de sécurisation du serveur web ne semble implémenté contrairement au cas précédent. Il y a clairement un DoS. Il pourrait être intéressant de laisser tourner l’attaque pour examiner l’occupation mémoire et CPU. Un crash machine pourrait-il survenir ?

quelles conclusions ?

S’il n’existe pas réellement de contre mesure claire pour lutter contre ce type d’attaque, un paramétrage fin des services web limitant le nombre de session ou désactivant les fonctions de renégociation (qui ne sont pas toujours utiles dans ces environnements) permet malgré tout de lutter efficacement contre les effets directs. Encore faut-il le faire…

Cette petite balade dans le monde THC m’a permis de constater que l’outil HYDRA (réalisation de brute force supportant un grand nombre de protocoles et avec une interface graphique – et oui tout le monde n’est pas un dieu du clavier ne travaillant qu’à la ligne de commande !) était désormais en version 7.1. Les évolutions continuent donc à un rythme intéressant et mériteraient sans aucun doute que l’on se penche sur les nouveautés.

Cedric.