Bijour à tous …
Bé voilà, actuellement en licence Pro CDED, nous sommes en train de voir les certificats auto-signés via openssl …(ça fait un bail que l’on sait que l’auto-signé c’est le mal mais bon … c’est gratuit, instantanée et ça permet d’avoir un niveau de chiffrement assez sympa qui permet de se protéger des petits rigolos qui ne savent pas utiliser ettercap … ça existe encore ???).
Dans cet article je montrerais la simplicité de la mise en place d’un tel certificat sur … ubuntu (quoique la doc d’ubuntu est plutôt bien fournit sur ce plan là), ainsi qu’une possibilité pour « déchiffrer le traffic ssl » via ettercap (qui n’est pas vraiment du déchiffrement, plutôt une attaque de type MITM automatisée).
Donc on monte notre « environnement sécurisé » :
-
sudo apt-get install apache2 && sudo a2enmode ssl && cd /etc/apache2/sites-available
On génère notre superbe certificat : (Vous pouvez mettre tout et n’importe quoi à tous les champs SAUF au champ « Common Name », où il faudra mettre votre nom de domaine, dans mon cas www.portable.lan)
-
sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -out /etc/apache2/server.crt -keyout /etc/apache2/server.key
On modifie le fichier default-ssl (nettoyage puis ajout des bonnes options de configuration pour utiliser le certificat et révision de sed 
)
-
sudo cat default-ssl | sed '5,168 d' | sed "3a\\\tSSLEngine On\n\tSSLCertificateFile /etc/apache2/server.crt\n\tSSLCertificateKeyFile /etc/apache2/server.key" > ssl-conf && sudo a2ensite ssl-conf
Le sed ’5,168 …’ risque de ne pas marcher si vous le faites sur une distrib différentes d’ubuntu 8.10, car il supprime les lignes 5 à 168 de la config fournit par défaut par le paquet apache2 (contenant pas mal de truc assez moche, à supprimer quoi )
Un zoli sudo /etc/init.d/apache2 restart permettra de prendre en compte tous ça, il suffit ensuite d’ouvrir le navigateur sur l’url https de votre serveur et l’on tombe sur cette superbe page :
Et ouai … comme je l’ai dit les certificats auto-signés c’est le mal, si l’on veut visiter ce superbe site il va falloir « confirmer une exception de sécurité » sur le site, ce qui n’est pas très sécurisant en sommes :s. Mais bon passons … ce qui nous donne ceci :
A partir de maintenant, on peut commencer par analyser le traffic lors de la connexion à notre site ultra-pas-du-tout-protégé-par-du-ssl-qui-rox-pas-sa-race, et comme on peut l’imaginer … le traffic est chiffré (ce qui signifie que le couple login/mot-de-passe qui a été rentré par le visiteur et ben on pourra pas le choper) :
Ce qui aurait été le cas si l’on c’était loggué à partir du site non-sécurisé, qui donne la capture suivante :
Dans cette capture l’on arrive à récupérer le mot de passe en clair …donc on se dit que c’est quand même classe avec le certificat on a évité une catastrophe nationale … mon super login/password ne s’est pas fait prendre … et là on se rappel le titre de mon article « du ssl en clair » … pour le moment ce n’est pas le cas.
C’est donc là qu’intervient ettercap … que j’ai déjà présenté ici et là.
Pour l’installer :
-
sudo apt-get install ettercap
Puis il faut modifier le fichier /etc/etter.conf (façon l33t h4x0r encore une fois … histoire de faire kikoo)
-
sudo cat /etc/etter.conf | sed '/^.*redir_command_on = \ »ipt/ s/#//'|sed '/^.*redir_command_off = \ »ipt/ s/#//' > /etc/etter.conf
La ligne précédente dé-commente les deux lignes qui permettent de rediriger les flux … il aurait peut-être été possible de mettre les deux sed en un … mais sudo cat /etc/etter.conf | sed ‘/^.*redir_command_o(n|ff) = \ »ipt/ s/#//’ > /etc/etter.conf ne semble pas fonctionner … dommage … j’aurais pu passer pour un boss de la ldc :s une autre fois peut-être ^^.
Ensuite, il faut permettre le forwarding : (quoique ça marche aussi sans)
-
sudo sysctl net.ipv4.ip_forward=1
et lancer ettercap :
-
ettercap -Tqi ath0 -M arp:remote /192.168.0.101/ /192.168.0.10/
qui aura pour effet de faire de l’arp poisonning pour les communications entre 192.168.0.101 (le client) et 192.168.0.10 (le serveur HTTPS) et le pirate en 192.168.0.100 (oui les ips ont changés depuis le début de l’article … ^^).
Le « -M:arp-remote » quand à lui permet l’attaque MITM qui va « renvoyer » un faux certificat (avec les mêmes informations que le certificats d’origine):
Et comme le pirate (192.168.0.100 qui est invisible dans cette trame) a généré le certificat, et que le traffic transite par son ordinateur, il peut ainsi récupérer le login et mot de passe chiffré :
Bien entendu … comme ce n’est pas le même certificat, il faut de nouveau « confirmer une exception de sécurité » (ce qui n’a pas été le cas pour moi … mais normalement ^^) et là avec son pauvre certif’ auto-signé ont se sent un peu nue, car le certificat générer est aussi auto-signé et contient toutes les caractéristiques fournient lors de la génération du premier certificat … donc le client ne peut pas savoir si c’est le bon certificat qu’il est en train d’autoriser (en vrai, il faudrait qu’il retienne la signature du certificat … mais IRL c’est assez rare de voir des parannos qui retiennent les signatures de leurs certificats).
Donc voilà … en espérant avoir découragé l’utilisation de certificat auto-signés (je viens de plomber le TP de mon prof :p).
A noter qu’avec ettercap, il est aussi possible de déchiffrer des certificats émis par Verisign et …, mais dans ce cas ettercap génère aussi un certificat auto-signé … révélant l’utilisation d’un MITM.
Mais pas mal de gens sont encore prêts à cliquer ok lors d’une « confirmations d’exception de sécurité » pour google, facebook ou … donc en sécurité, le problème restera toujours l’utilisateur :s
