WinSSLMiM

Le protocole HTTPS, basé sur SSL (voir la fiche SSL pour plus d'explication), apporte la confidentialité, l'intégrité et l'authentification des échanges de données entre un site Web et un navigateur. Contrairement à toutes les indications de ces mêmes sites dit sécurisés, l'utilisation de ce protocole n'est pas infaillible et ne doit pas empêcher d'être vigilant. En effet, il existe un attaque, le Man in the Middle, applicable au HTTPS. Succinctement, ce type d'attaque consiste pour un pirate à ce mettre entre le client qui utilise son navigateur et le site Web en question :

La conséquence immédiate est la perte des trois critères précédemment cités, à savoit que le pirate a la possibilité de lire en clair et/ou de modifier les données échangées. WinSSLMiM met en oeuvre cette attaque dite du Man in the Middle SSL (ou HTTPS plus précisément)

Ce type d'attaque est connue maintenant depuis plusieurs années et les outils adéquates sont déjà disponibles sur Linux (sslmim, sslsniff ou webmitm du package dsniff). Il existe biensûr un moyen de détecter une attaque de ce genre. Grâce au SSL, le serveur Web est authentifié via un certificat X509 (l'équivalent d'une identité numérique). Ce certificat est signé par une autorité de certification (Certification Authority ou CA) reconnue internationalement et surtout par les navigateurs. Ainsi lorsqu'un certificat n'est pas conforme ou signé par une CA connue, le navigateur émet une alerte de ce type :

Dans le cas de l'attaque, le pirate doit substituer son propre certificat (signé par lui même et non par une CA) à celui du vrai serveur. Le navigateur alerte donc l'utilisateur sur la non conformité de ce certificat. La sécurité du mécanisme repose alors uniquement sur le clique de souris de l'utilisateur sur le bouton "non". Pour le certificat de notre pirate, il est assez logique de répondre "non" après l'avoir affiché :

Lors d'une véritable attaque, il n'est pas aussi simple de voir la supercherie. Des techniques avancées ont été implémentées dans les outils sous Linux. En ce qui concerne WinSSLMiM, il a l'avantage de fonctionner sous Windows 9x/2000 et de réunir les principales fonctionnalités avancées liées à cette attaque.

Deux techniques avancées sont intégrées à cet outil. La première est inspirée de l'outil sslmim (voir l'article de Phrack 57) qui génère automatiquement un certificat X509 très proche de l'original. La deuxième technique apporte l'exploitation de la vulnérabilité dite de chaine de certficats (voir l'alerte Certficate Chain Vulnerability) que fait déjà très bien sslsniff.

Première attaque

Pour implémenter cette fonctionnalité WinSSLMiM est fourni avec FakeCert un outil ayant la faculté de se connecter à un serveur HTTPS et de générer un certificat le plus proche possible de l'original. Le principe est simple, tous les champs du certificat sont recopiés. La seule différence reste que ce certificat n'est pas signé par une CA connue. Cependant le nom de cette CA (champ émetteur du certificat) est aussi recopié en ajoutant simplement un espace à la fin du nom.

D:\>fc -s www.securiteinfo.com -f faux_certificat.crt

>> FakeCert by Valgasu (valgasu@securiteinfo.com) <<

+ Connection to https://www.securiteinfo.com
+ Get X509 certificate
+ Make fake certificate
+ Save fake certificate to faux_certificat.crt

En comparant les certificats, il n'est plus aussi simple de savoir si l'utilisateur est victime d'une attaque ou si seulement l'émetteur (CA) n'est pas connu par le navigateur. Celui-ci possède de base un certain nombre de certificats de CA mais surement pas tous.

Vrai certificat du serveur


Faux certificat généré par FakeCert

Il suffit ensuite d'utiliser WinSSLMiM avec ce faux certificat.

D:\>wsm -f faux_certificat.crt -l d:\log.txt

>> WinSSLMiM by Valgasu (valgasu@securiteinfo.com) <<

Waiting for connections...

Cette fois-ci l'utilisateur reçoit une alerte moins inquiétante en apparence, surtout s'il vérifie le certificat :

Si l'utilisateur accepte le certificat, WinSSLMiM enregistre en clair dans le fichier log.txt toutes les informations échangées entre le navigateur et le serveur.

Deuxième attaque

La deuxième technique exploite la vulnérabilité dite de chaine de certificats (Certificate Chain Vulnerability). Sans rentrer dans le détail de cette vulnérabilité (présente entre autres sur Internet Explorer), un certificat signé par la clé privée associée à un certificat authentifié (donc signé) par une CA connue est accepté sans alerte. En effet, IE ne vérifie pas si ce certificat intermédiaire de confiance à le droit de lui aussi certifier des certificats finaux. Cette propriété du certificat est appelée Basic Constraints et c'est elle qui n'est pas contrôlée. En conclusion, un pirate possédant un certificat de confiance signé par une CA connu est à même de certifier n'importe quel serveur Web sans que IE ne s'en inquiète. Là encore, l'utilisation de FakeCert est nécessaire pour la mise en oeuvre de cette exploitation.

D:\>fc -s www.securiteinfo.com -f trust_certificat.crt -t trust.crt

>> FakeCert by Valgasu (valgasu@securiteinfo.com) <<

+ Connection to https://www.securiteinfo.com
+ Get X509 certificate
+ Make fake certificate
+ Load trusted certificate from trust.crt
+ Save fake certificate to trust_certificat.crt

Pour générer ce faux certificat, il faut un certificat authentifié, celui fournit par FakeCert est celui inclus dans l'outil sslsniff. Il reste à utiliser ce certificat avec WinSSLMiM.

D:\>wsm -f trust_certificat.crt -l d:\log.txt -t trust.crt

>> WinSSLMiM by Valgasu (valgasu@securiteinfo.com) <<

Waiting for connections...

Cette fois-ci aucune alerte n'est émise par le navigateur (s'il s'agit de IE), l'attaque est considérée commme quasi parfaite car indétectable. Le certificat reçu est le suivant :