Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Attaque de type Company-In-The-Middle

Attaque de type Company-In-The-Middle
2009-03-252013-02-11actualités et événementsfr
Lorsque vous vous connectez depuis votre travail à un site WEB sécurisé en HTTPS, comme par exemple un Webmail personnel ou le site de consultation de vos comptes bancaires, pouvez-vous dire jusqu'à quel point vous êtes certains que vos échanges sont confidentiels...
Publié le 25 Mars 2009 par Hervé Troalic dans actualités et événements

Lorsque vous vous connectez depuis votre travail à un site WEB sécurisé en HTTPS, comme par exemple un Webmail personnel ou le site de consultation de vos comptes bancaires, pouvez-vous dire jusqu'à quel point vous êtes certains que vos échanges sont confidentiels ?


1. introduction

De nos jours, la plupart des communications entre un serveur WEB et un navigateur sont  sécurisées au moyen des protocoles SSL v3 ou TLS (connexion en HTTPS). Ces protocoles fonctionnent suivant un mode client/serveur et permettent l'établissement de tunnels sécurisés. Les services de sécurité fournis par SSL/TLS sont les suivants :


  • l'authentification du serveur,
  • l'authentification optionnelle du client,
  • la confidentialité des données échangées,
  • l'intégrité des données échangées.

L'authentification des parties repose sur l'utilisation de certificats numériques au format X.509. La confiance en ces certificats est garantie par une ou plusieurs autorités de certification, qui peuvent être de nature commerciale (GlobalSign, Thawte, VeriSign...) ou privée. L'authentification du client est par exemple utilisée lors de la déclaration d'impôt en ligne sur le site du gouvernement.

Si l'autorité ayant signé le certificat d'un serveur n'est pas reconnue comme autorité de confiance par le client, un avertissement de sécurité prévient normalement l'utilisateur que l'identité du serveur distant n'a pas pu être vérifiée. Si l'utilisateur passe outre cet avertissement, le tunnel SSL/TLS pourra tout de même être établi.

Enfin, rappelons que les protocoles SSL/TLS sont également utilisés pour établir des liaisons de type VPN, permettant la connexion d'une machine à un réseau privé distant.

2. le danger pour les entreprises

Une fois la connexion établie entre la machine d'un employé et un serveur distant, les données qui transitent dans un tunnel SSL/TLS ne peuvent être ni analysées, ni filtrées par l'entreprise.
 

schema_1.png

Il peut bien sûr s'agir d'une connexion à caractère professionnel, mais cette connexion peut également permettre :

  • la divulgation d'informations confidentielles vers l'extérieure de l'entreprise (voir chez des concurrents),
  • le téléchargement (involontaire ou non) de logiciels malveillants de type virus ou vers sur le réseau interne de l'entreprise,
  • une connexion VPN reliant, via la machine de l'employé, le réseau interne hautement sensible de l'entreprise avec un réseau externe potentiellement très dangereux.

Dans les trois cas, tous les moyens mis en place par l'entreprise pour filtrer les échanges externes (pare-feux, relais, anti-virus...) sont contournés par l'utilisation du tunnel sécurisé.

3. les solutions disponibles

Des appliances commerciales de type relai Internet (BlueCoat, IronPort...) proposent aujourd'hui aux entreprises des fonctionnalités «d'analyse intelligente du trafic SSL/TLS». Concrètement, cela se traduit par l'impersonification du client par rapport au serveur, et par l'impersonification du serveur par rapport au client. Deux tunnels sécurisés sont donc établis avec l'appliance, l'un à destination du serveur, l'autre à destination de la machine cliente. Tous les flux transitent ainsi en clair par l'appliance, qui peut alors analyser et filtrer les échanges.
 

schema_2.png

Pour pouvoir impersonifier le serveur auprès du client, un certificat SSL auto-signé est généré à la volée et renvoyé au client. L'utilisateur reçoit alors un avertissement de sécurité, puisque le certificat est auto-signé et non reconnu comme autorité de confiance. Cependant, rares sont les utilisateurs qui lisent (et comprennent) les avertissements de ce type, et le tunnel finit par être établi en toute confiance.

Si une infrastructure de gestion des clés (IGC, ou PKI en anglais) a été déployée en interne, les certificats générés à la volée peuvent alors être signés par l'autorité de certification de l'entreprise, par défaut approuvée sur toutes les machines, ce qui aura pour effet de supprimer les avertissements de sécurité précédents. L'interception des flux «sécurisés» sera alors totalement transparente pour les utilisateurs.

Attention, la solution fournie par ces appliances n'est possible que lorsqu'il n'y a pas d'authentification de la part du client. En effet, la clé privée associée au certificat du client n'étant présente que sur la machine de l'utilisateur, l'authentification de l'appliance en tant que client échouera forcément auprès du serveur WEB.
Ainsi, on ne pourra pas intercepter et analyser une connexion VPN SSL, mais on pourra cependant plus facilement identifier de telles connexions, et donc les interdire.

4. le danger pour les utilisateurs

Au même titre que la messagerie ou les données personnelles, le principal danger pour les utilisateurs réside dans l'abus de pouvoir des administrateurs ou de la direction. Cependant, si un utilisateur peut avoir conscience que ses données personnelles stockées sur un serveur de l'entreprise peuvent être lues, en revanche des données distantes accessibles uniquement en HTTPS devraient être maintenues confidentielles par rapport à l'entreprise.

Dans le cas d'une appliance analysant le trafic SSL/TLS et intégré à l'IGC interne, l'utilisateur lambda n'aura aucun moyen de s'apercevoir que ses échanges ne sont plus confidentiels. Ainsi, si en théorie l'appliance n'est pas configurée pour journaliser les informations qui transitent par elle, rien ne peut empêcher leur écoute et leur enregistrement par des administrateurs peu scrupuleux...

Le seul moyen de contrôle par un utilisateur est de systématiquement vérifier les certificats des serveurs sur lesquels il se connecte. Cette tâche n'est bien entendu pas à la portée de l'utilisateur lambda.

5. Conclusion

Pour éviter le contournement des plates-formes de sécurité Internet et afin de réduire les risques liés à l'utilisation des tunnels SSL/TLS, il est préférable de contrôler les échanges en coupant les tunnels au moyen d'une appliance spécialisée.
Cependant, pour prévenir tout litige ultérieur avec les utilisateurs, la mise-en-place de ces équipements doit être contrôlés de la façon suivante :
 

  • Responsabilisation des administrateurs :
Il est toujours bon de rappeler aux administrateurs ce qu'ils peuvent faire, et ce qu'ils n'ont pas le droit de faire, au nom du bon sens et au nom des législations en vigueur (loi Informatique et liberté, loi Godfrain...).
  • Communication aux utilisateurs :
La charte signée par les utilisateurs concernant l'utilisation des ressources Internet doit être mise-à-jour et préciser la mise en place d'équipement de sécurité provoquant une rupture des tunnels SSL, ceci pour permettre l'analyse et le filtrage des flux échangés avec l'extérieur de l'entreprise.

Article écrit par Alexandre Lauga

 

3 Commentaires

  • 14 Avril 2009
    2009-04-14
    par
    Florent
    Bonjour,
    je suis actuellement chez un client qui utilise un proxy générant des certificats pour pouvoir analyser les échanges. Pour certains sites légitimes comme gmail, la connexion n'est pas interceptée.

    Par contre pour les sites moins connus les communications sont interceptées. Cela inclut le webmail de mon entreprise :x

    Pour rajouter un point particulier, c'est que justement ce webmail qui a un certificat erroné (oui oui le webmail de mon entreprise...) et qui m'affiche normalement un pop-up d'avertissement ne l'affiche plus car celui auto-généré par le proxy est valide (via ajout du certificat de la CA sur le poste client).

    Au final il est encore plus facile d'attaquer les utilisateurs de l'entreprise via du DNS poisoning ou autre car il n'est même pas nécessaire d'avoir un certificat valide...
  • 1 Avril 2009
    2009-04-14
    par
    Alexandre Lauga
    Bonjour,

    Pour les appliances que j'ai eu l'occasion de tester (BlueCoat), le proxy intercepte la requête du client et génère à la volée une paire de clés et un certificat autosigné. Ce certificat correspond à un certificat standard pour serveur WEB (rôle "Server Authentication" et CN=URL). L'avertissement de sécurité renvoyé au client porte sur le fait que le certificat est autosigné et ainsi non reconnu comme autorité de certification racine.
    Ainsi, si on utilise les clés et le certificat d'une CA d'entreprise - dont le certificat de l'autorité racine est par défaut approuvée sur toute les machines de l'entreprise - pour signer le certificat, le client n'aura aucun avertissement de sécurité.

    Le lien que vous mentionnez fait référence au problème de certificat unique utilisé par un serveur WEB gérant plusieurs VirtualHosts. Si le client se connecte sur https://perso.domain.com et que le certificat du serveur utilise comme CN www.domain.com, le client aura alors inévitablement un avertissement, qu'il passe ou non via le proxy.
    Ce problème - non adressé dans l'article - peut être résolu par des certificats WildCard (*.domain.com).

    Bien cordialement,
    Alexandre Lauga
  • 27 Mars 2009
    2009-04-14
    par
    Youssef
    Bonjour,

    Vous dites que quand le certificat racine de l'entreprise est approuve par tous les postes l'interception est totalement transparante. Alors que ce n'est pas le cas.
    Dans tous les cas, le CNAME a mettre sur le certificat auto-signe ne peut etre "devine" par le proxy au milieu (le CNAME doit correpondre a l'URL saisie par l'internaute et qui fait partie du protocole HTTP qui ne commence qu'apres etablissement de la couche SSL) et le navigateur va emettre un warning sur la non conformite de l'URL tape et celle decalare dans le CNAME du certificat auto-signe (et genere a la volee)

    Seul l'utilisation de SNI (http://en.wikipedia.org/wiki/Server_Name_Indication) peut rendre l'interception totalement transparente...

    Cordialement.

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage