La nouveauté fait peur, une chimère à ranger non pas dans la caste les vulgaires créatures réanimées parmi lesquelles on compte les momies et autres zombies, mais plutôt dans la catégorie des grands anciens que président Cthulhu et Nyarlathotep. Évitons les terreurs inutiles, restons bien à l’abri dans le giron d’une terre que l’on a déjà parcourue. Aujourd’hui je vous parlerai une nouvelle fois de stress testing et de déni de service, avec cette fois un petit programme original au potentiel sudatoire important… Pour les équipes de supervision en tout cas !
Dans ce billet j’apporte un peu de lumière sur un outil excessivement simple d’utilisation, inundator, qui est pourtant en mesure de retourner complètement une plateforme de supervision et de rendre plus que nervous-breakdown les administrateurs du réseau.
Le principe de fonctionnement d’inundator est relativement trivial, le programme pioche dans la liste de règles de Snort (qui doit être présente sur la machine depuis laquelle inundator est lancé, il est donc nécessaire d’installer Snort ou de récupérer l’archive de règles sur le site de l’IDS), afin de forger des paquets susceptibles de déclencher une alarme sur l’IDS/IPS supervisant le réseau. Les finalités sont nombreuses, on peut en citer quelques unes, comme la dissimulation d’une attaque réelle menée simultanément sur le même réseau, créer une diversion pour attaquer une partie du système ou du réseau qui serait alors momentanément délaissée ou encore déclencher illégitimement les triggers associés aux différentes alarmes… Mais plutôt que de nous perdre en supputations, voyons plutôt comment ça marche…
Comment ça marche… Pas ©
Petit aparté culturelle, saviez vous que le mot « ça » de l’expression « comment ça va ? » désignerait à l’origine les selles ? Cette banale question permettait de se renseigner sur l’état de santé de votre interlocuteur tout en s’épargnant des détails sous-jacents peu ragoûtants.
Inundator est capable de prendre pour cible, une machine spécifique, une fourchette d’adresses ou encore un sous réseau entier. Un IDS/IPS est classiquement placé sur un port en mode monitor sur lequel est répliqué l’intégralité du trafic qui traverse l’équipement réseau. C’est la raison pour laquelle ce serveur de détection d’intrusion sera capable de capter les paquets émis par inundator quelque soit l’adresse de destination. Entrons dans le vif du sujet avec cette commande quasiment imberbe ! (192.168.0.1 est monserveur Snort. Dessus on retrouve les serveurs HTTP, SSH, SNMP, SMTP, qui seront les cibles d’attaques simulées par inundator!)
root@kali:~# inundator 192.168.0.1 [+] queuing up attacks... [+] queuing up target(s)... [+] detecting open ports on 192.168.0.1... [+] child 1 now attacking. [!] connection error! [!] connection error! ... [!] connection error!
Et là Zobned !, pléthore de messages inquiétants ! Du coup, en grand naïf, je me suis dit que tout roulait sûrement, que l’appli était sans doute juste un peu trop verbeuse et que ces connection error! traduisaient un comportement normal de inundator… Mais non.
Après le scan de ports initial et une salve de paquets, plus rien n’était émis. J’ai donc passé la commande à l’invert match de grep pour filtrer un peu les messages (inundator 192.168.0.1 | grep -v error!), et je suis maintenant en mesure d’affirmer que même les programmes se bourrent la gueule !
... [!] connection errr! [!] cr! [!] connecr! [!] connection errr! [!] connecr! [!] connection errr! [!] connectioor! [!] or! [!] connectioror! [!]or! [!] connectioor! [!] connectior! ...
Fix-it
Ça m’apprendra, gros naze que je suis, à ne pas respecter l’adage vieux comme le monde Unix : « Read The Fucking Manual » ! Voilà ce que l’on peut lire dans le –help de inundator et qui explique ce petit FAIL bien mérité :
-p, --proxy Define the SOCKS proxy to use for attacks in host:port format. The use of a SOCKS proxy is mandatory for rather obvious reasons. Default: localhost:9050 (tor)
Du coup forcément, sans SOCKS Proxy en écoute sur le port 9050 ça n’risquait pas de marcher ! Pour les besoins de ce billet, je vais utiliser un proxy local, mais je vous suggère de suivre le judicieux conseil debindshell.nl en utilisant Tor ou assimilé…
On va un peu empiéter sur un prochain billet ou j’explique comment mettre en place le combo Tor + Proxy Local pour utiliser ni vu ni connu des applications telles que Havij ! Mais « est-ce un bien ou est-ce un mal ?«
Pour monter un proxy local, je vous propose deux solutions : Si vous utilisez Windows comme hôte de votre Linux virtuel, vous pouvez utiliser Privoxy sur votre Windows. Une fois lancé, il vous suffira d’utiliser inundator avec l’option -p @IP_Windows:8118 ! Deuxième solution, que vous soyez dans la première situation ou que vous utilisiez directement Linux comme système d’exploitation, vous pouvez taper la commande magique suivante que j’ai découvert ici :
ssh -N -D 0.0.0.0:1080 localhost
We are under attack !
0x0ff@kali:~# inundator -p localhost:1081 192.168.0.1
[+] queuing up attacks...
[+] queuing up target(s)...
[+] detecting open ports on 192.168.0.1...
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
[+] child 1 now attacking.
[+] child 2 now attacking.
...
[+] child 24 now attacking.
[+] parent now attacking.
[=] press ctrl+\ at any time to stop. Voilà qui est beaucoup mieux ! Pour vous montrer l’impact que ce script a sur un IDS/IPS (Snort en l’occurrence, mécaniquement le plus réceptif à cet outil), je vais réutiliser le petit script cmatrix légèrement modifié que j’ai présenté dans cet article. Chaque brin rouge qui apparaît dans le terminal ci-dessous correspond à une alerte émise par Snort.
cmatrix -L /var/log/snort/alert
Go Deep.
Je vous propose de vous attarder quelques minutes de plus sur ce billet pour découvrir le fonctionnement global de inundator, une nouvelle fois grâce à ce fabuleux outil qu’est Wireshark !
La première chose que va faire inundator, c’est chercher les ports ouverts sur les machines ciblées. Dans les premières secondes de vie du processus, on observe donc un gros scan de port. La capture ci-dessous montre la découverte fructueuse du port 22 et 80 correspondants respectivement au protocole SSH etHTTP.
Une fois cette phase préliminaire achevée, inundator va émettre vers ces ports ouverts, des paquets correspondant aux protocoles normalement associés à chacun d’entre eux, fabriqués de façon à les rendre suspects pour l’IDS/IPS qui écouterait le réseau.
Exemple SSH
La règle associée est aisément identifiable :
0x0ff@kali:~# cat /etc/snort/rules/* | grep GOBBLES
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT gobbles SSH exploit attempt"; flow:to_server,established; content:"GOBBLES"; reference:bugtraq,5093; reference:cve,2002-0390; reference:cve,2002-0639; classtype:misc-attack; sid:1812; rev:5;) Exemple HTTP
Alarme normalement remontée par cette règle :
0x0ff@kali:~# cat /etc/snort/rules/* | grep axs.cgi
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI axs.cgi access"; flow:to_server,established; uricontent:"/axs.cgi"; classtype:web-application-activity; sid:1205; rev:6;)
Vous l’aurez compris, inundator est sans doute l’un des outils les plus funs de la distribution Kali Linux. On peut également saluer le choix noob-friendly des auteurs d’avoir par défaut pipé inundator sur tor, un bon petit conseil éducatif en plus ! On arrive à la fin de ce nouveau billet, j’espère qu’il vous aura plu, ou tout du moins qu’il aura plu à Sans-pseudo-fix ! 
