Ou comment le plus merveilleux des pare-feu devient inutile.

C'est avec un peu de retard que je vous livre ma réflexion personnelle concernant la vidéo Tunneling Exploits through SSH.

La sécurité informatique ne consiste pas à mettre en place juste un outil afin se protéger. La preuve est faite par cette vidéo qui vous montre comment le plus beau ( et peut-être le plus coûteux ) de tout les pare-feu ne sert à rien, si la sécurité informatique n'est pas envisagée de façon globale.

En effet, dans notre cas, le pirate profite d'une faille existante pour prendre le contrôle d'un serveur WEB IIS 5.0. Bon d'accord, vous me direz que cette faille est corrigée depuis longtemps, et qu'on ne devrait plus trouver beaucoup de serveurs avec IIS 5.0. Là n'est pas le problème, car à travers cette vidéo, il faut noter deux points intéressants qui ont le mérite de bousculer quelques idées reçues :

                              - Un pare-feu peut devenir vulnérable.
                              - Le port 443 ( HTTPS ) est un port de communication qui peut aussi être exploité par un attaquant.

Je m'explique. Dans notre exemple, la société victime de piratage a installé un serveur Web pour permettre à ses collaborateurs ( et peut-être ses clients et fournisseurs ) d'accéder à des informations de nature confidentielles. Afin d'en assurer leur protection, tout transite par le port 443 ( HTTPS ), ce qui permet de crypter les données qui sont échangées. On peut même imaginer, que seuls les clients qui ont un certificat valide d'un référent de confiance, et qui se sont dûment authentifiés peuvent communiquer avec notre serveur. Oui, mais voila. Pour que notre serveur Web communique avec l'extérieur, le pare-feu doit accepter les connexions entrantes sur le port 443 et ce, quelque soit l'adresse IP de son expéditeur. En supposant que les autres ports ne soient pas ouverts, tout est en principe normal... Sauf que :

                              - Notre serveur n'est pas sur une DMZ ( ou Zone démilitarisée ) et donc fait partie intégrante du réseau local de l'entreprise.
                              - Il comporte une faille de sécurité critique non corrigée, qui permet à un attaquant de prendre le contrôle de la machine vulnérable.

C'est dans par l'exploitation de ses deux failles de sécurité que l'attaquant va prendre le contrôle du serveur IIS. Vous pourrez constater que toutes les commandes sont exécutées en local, sur le serveur vulnérable, alors que ce dernier n'a pas d'adresse IP routable. ( cf la commande Ipconfig lancée par l'attaquant ). Cela n'est pas sans incidence puisque désormais notre pirate peut activer ou désactiver des services sans réveiller les soupçons, puisque leur exécution se fait avec le compte d'administration de la machine. 

La suite du scénario est simple. L'attaquant va ouvrir le port 1035 (DCOM) pour lui permettre d'exploiter cette vulnérabilité et si cela s'avère nécessaire, de détourner l'attention de son but réel :

                             - Installer un serveur SSH et créer un tunnel de communication entre le serveur vulnérable et son ordinateur.

A partir du moment ou l'attaquant arrive à mettre en place le serveur SSH, il est quasiment impossible pour l'administrateur réseau de détecter sa présence, puisqu'il ne sera pas considéré comme intrusif par un IDS, un pare-feu personnel ou un antivirus.

En conclusion. L'importance des mises à jour de sécurité n'est plus à démontrer. Cependant, il existe toujours un laps de temps entre le moment ou une faille est découverte, et son correctif appliqué. Il est donc nécessaire d'apporter tout le soin possible à la configuration de ses outils de protections. Dans cette étude de cas, l'administrateur réseau aurait pu rendre très difficile l'exploitation de la faille du serveur IIS si :

                            - Le serveur est installé sur une DMZ. Dans ce cas, l'exploit aurait été réduit au serveur même.
                            - Un filtrage sortant des paquets est configuré sur le pare-feu. Seul les ports de communications nécessaires sortant sont ouverts. Dans ce cas, l'activation du port DCOM (1035) sur le serveur IIS aurait généré des alertes au niveau du firewall.
                            - Accessoirement, une sonde anti-intrusion est installée. L'exécution du script permettant la réalisation de l'exploit aurait été détecté et signalé à l'administrateur réseau.