La nouvelle version de Cain est sortie depuis peu de temps. Pour ceux qui ne connaissent pas cet outil, je vous conseille d'aller regarde de plus prêt le site. Pour faire simple, c'est l'outil idéal pour mettre en place de manière simple et efficace une attaque de type man in the middle.
Une fois le trafic intercepté, l'outil offre tout un panel de plugins pour en retirer les principales informations. Pour vous donner une idée de sa puissance, il va jusqu'à reconnaitre les codecs VoIP et vous permet de convertir une trace en fichier WAV.
Devant un tel outil et sa facilité d'utilisation, je me permets de reposter un article que j'avais posté pour insister une nouvelle fois sur un sujet qui ne semble pas encore faire parti des préoccupations des DSI:
<< Tout au long des politiques de sécurité et déploiements effectués pour les clients d’Orange Business, je suis toujours surpris de voir à quel point les clients sont rétissants à aborder les problématiques liées à la gestion des sessions SSL/TLS vers internet au travers de leur gateway internet. Pourtant, tout DSI qui se respecte n’envisage pas une seule seconde d’offrir un accès Internet à ces utilisateurs sans que celui-ci fasse l’objet d’une politique de sécurité. En fonction du degré de sensibilisation de l’entreprise, la politique de sécurité définira un certains nombre de contraintes telles que l’authentification des utilisateurs, le filtrage des sites distants en fonction de catégories, un contrôle antivirus, … Cette politique, aussi bien faite soit t’elle, ne défini jamais d’exception à ces contraintes pour les flux chiffrés et c’est cependant bel et bien ce qui se passe dans les faits. Combien d’entreprises ont mis en place une politique de sécurité définissant ce qu’il était acceptable de faire ou non au sein d’une session chiffré vers un serveur distant sur internet ? Par exemple, est’ il normal que depuis un poste de l’entreprise, un utilisateur puisse décider d’établir une session HTTPS vers un site distant dont le certificat a été fourni par une autorité de certification non reconnue (et donc potentiellement par n’importe qui) uniquement en cliquant sur « oui » dans une boite de dialogue qu’il ne prend que rarement le temps de lire ?
En allant plus loin dans ce constat, on pourrait même dire que pour de très nombreuses entreprises, ce point n’a jamais été abordé. Soit le DSI part du principe que si un flux vers internet est chiffré, c’est qu’il a une bonne raison de l’être ou alors, il considère tout simplement que sur un flux HTTPS au travers d’un des proxys de l’entreprise, il n’a aucune action réellement possible.
C’est d’autant plus dommage que le marché propose depuis une ou deux années déjà des solutions matures et qui méritent de gagner en audience.
Prenons l’exemple le plus classique dans lequel la gateway internet que je fourni a mes utilisateurs est composée d’un firewall avec en DMZ un proxy et un anti-virus. Le proxy est chargé d’authentifier les utilisateurs en utilisant l’Active Directory de l’entreprise. Il se chargera aussi d’un filtrage d’URL (en utilisant une base de données d’un vendeur quelconque) et de faire suivre les objets téléchargés sur les serveurs distants à l’antivirus avant de les fournir aux utilisateurs. Le firewall n’est la que pour assurer une sécurité accrue pour l’ensemble de la solution (mais c’est un autre débat).
Comme vous le savez surement, lorsque l’utilisateur cherche à se connecter à un site HTTPS, le navigateur envoie au proxy une directive spécifique du protocole HTTP qui est la directive « CONNECT » en spécifiant vers quel serveur distant et sur quel port il veut se connecter. Cette directive indique au proxy de ne pas se poser de question et de faire suivre les paquets entre le serveur et le navigateur de manière « stupide » sans réellement les observer, ce qui est tout à fait normal puisque la session est censée être chiffrée entre le serveur distant et le poste client. Cette directive « CONNECT », s’il elle très utile dans ce contexte précis, présente aussi le gros défaut de permettre à n’importe quel logiciel d’envoyer des paquets à un serveur distant sans que le proxy ne vérifie quoi que soit, et pas même le fait que ces paquets correspondent bien à une session HTTPS. C’est une des techniques d’évasion principales utilisées par les logiciels tels que Skype, MSN et autre pour sortir du réseau de l’entreprise et se connecter sur internet. C’est aussi pour cette raison que lorsque un de vos utilisateurs a la bonne idée de se connecter sur https://mail.google.com à la place de http://mail.google.com, le flux n’est plus redirigé par le proxy vers l’antivirus en DMZ du firewall ce qui lui permet, s’il n’a pas d’antivirus sur son poste, de télécharger tous les virus que ces nombreux amis lui auront envoyés en pièce jointe sur sa boite aux lettres personnelle.
Pour remédier à cette situation, les éditeurs de proxy (Bluecoat par exemple ou encore Squid avec un patch dédié pour ne pas les citer) se sont penchés sur cette fameuse commande « CONNECT » afin d’améliorer le niveau de contrôle du proxy sur ce type de flux. Il est maintenant possible de mettre en place trois niveaux de contrôle plus ou moins poussés sur ce type de connexion:
1. Vérifier le type de flux
2. Imposer des contraintes à l'établissement de la session
3. Inspecter le contenu de la session
1/ Vérifier le type de flux
Le premier niveau de contrôle consiste tout simplement pour le proxy à ne pas autoriser n’importe quel paquet à transiter par la directive « CONNECT » mais de vérifier que le protocole utilisé est bien du SSL/TLS. Ainsi, tout programme ne faisant pas réellement une session SSL/TLS mais utilisant cette directive comme technique d’évasion ne fonctionnera plus.
2/ Imposer des contraintes à l’établissement de la session
Maintenant que nous sommes sûrs que le flux est bien un flux de type SSL/TLS, nous pouvons imposer un certain nombre de contraintes à l’établissement de la session. Par exemple, il est intéressant que ce soit la politique de sécurité de l’entreprise (en s’appuyant sur le proxy comme moyen technique) et non l’utilisateur final qui décide qu’il n’est pas possible d’établir une session vers un serveur distant chiffrant la communication avec des clefs de session de taille insuffisante. Ce type de contraintes imposées à la connexion est aussi un moyen élégant (en tout cas de mon point de vue) de répondre aux problématiques de certificats expirés que l’utilisateur doit refuser mais qu’il accepte la plupart du temps ou pire, comme je le disais précédemment, aux certificats auto-signés créés par des utilisateurs malveillants et utilisés sur des sites de phishing. En effet, le seul moyen de vérifier que je suis bien connecté sur Amazon par exemple avant d’envoyer mon numéro de carte crédit est de vérifier que le certificat présenté par le site distant a bien été signé par une autorité de certification connue (en espérant que cette autorité ne donne pas des certificats n’importe comment).
Ces contraintes imposées par le proxy permettent enfin de répondre à une autre problématique à laquelle la norme SSL/TLS n’a pas su répondre de manière efficace : la gestion des certificats révoqués. Combien d’utilisateurs vérifient que les certificats d’un site distant ne font pas parti de la liste des certificats révoqués (et donc potentiellement compromis) de l’autorité de certification qui l’a émis ? Avec notre proxy « intelligent », il est possible de demander au proxy d’assurer cette tache.
3/ inspecter le contenu de la session
Grace aux deux points précédents, nous savons maintenant que la session qui passe à travers le proxy est bien une session HTTPS, que les certificats utilisés pour l’établir sont valides, non expirés et que la taille de clef est suffisante mais tout ceci n’empêche pas notre utilisateur final de télécharger un virus sur un site HTTPS.
Afin de permettre au proxy d’inspecter (donc déchiffrer) le contenu de la session HTTPS établie par l’utilisateur, il n’existe qu’un seul moyen, mettre en place la technique du « man in the middle » ou littéralement « homme au milieu ». Cette technique consiste pour le proxy à présenter un certificat auto-signé généré dynamiquement lorsque l’utilisateur se connecte à un site HTTPS en lieu et place du certificat du site distant. L’utilisateur établi donc la session chiffrée non pas avec le site distant mais avec le proxy qui à son tour va établir une nouvelle session chiffrée avec le site distant pour relayer les requêtes de l’utilisateur. Bien évidemment, le certificat fourni par le proxy étant un certificat auto-signé, il ne provient pas d’une autorité de certification connue à laquelle les navigateurs accordent leur confiance par défaut et le navigateur va donc émettre un message d’alerte à l’utilisateur lui indiquant que le site distant n’est pas digne de confiance. Pour éviter ce message, il suffit de fournir au département IT qui gère votre parc informatique le certificat racine de l’autorité de certification que le proxy utilise pour générer ces propres certificats. Il est alors possible d’intégrer ce certificat sur les postes clients dans la liste des certificats de confiance et l’utilisateur ne recevra alors plus aucun message.
Dans ce type de configuration, le proxy peut alors déchiffrer à la volée toutes les sessions HTTPS générées par l’utilisateur et leur appliquer les mêmes vérifications que celles effectuées pour les sessions non chiffrées comme par exemple d’envoyer les objets téléchargés à l’antivirus en DMZ du firewall.
La seule difficulté technique pour ce type d’utilisation correspond aux sites distants (relativement rares) qui vont demander la présentation d’un certificat client pour authentifier l’utilisateur. Comme celui-ci est placé sur le poste client et par définition, connu uniquement du client, il n’est alors plus possible pour le proxy d’établir la session intermédiaire puisqu’il faudrait pour cela se faire passer pour le client. Le proxy peut alors décider, en fonction de sa configuration, d’autoriser ou non la session.
Bien sur, il est tout à fait possible de configurer le proxy pour que l’action d’effectuer du « man in the middle » soit déclenchée par la catégorie du site distant. Ainsi, il peut être conseillé de casser les sessions SSL/TLS pour les sites de la catégorie « Webmail » afin d’éviter d’offrir un point d’entrée supplémentaire pour les virus mais de ne surtout pas le faire pour les sites de la catégorie « Banking » qui demandent un niveau de confidentialité maximum.
Fort de ces nouveaux éléments, il ne vous reste plus maintenant qu’à remettre à jour votre politique de sécurité. >>
nsp