L’idée de base
Après avoir analysé plusieurs types d’attaques que la littérature propose, nous avons choisi de chercher d’implémenter une attaque basée sur l’injection de code HTTP dans une session TLS, où le serveur demande un certificat au client. Le serveur en question met à disposition aussi des services qui ne demandent pas l’authentification du client.
L’idée est d’utiliser un proxy transparent par le client, qui reçoit les requêtes des clients et qui les rejoue à un serveur fiable pour le client qui héberge un service critique. Par exemple, un service qui peut être considéré critique est un système d’home-banking. Imposer un proxy transparent par le client est une opération suffisamment simple, qui peut être fait à travers un courriel de phishing ou une attaque au système DNS.
Pendant l’attaque, le proxy (P) s’agiterait comme un MITM, en rejouant les requetés du client (C) au serveur (S) et vice-versa. En plus, P injecterait une requête malveillante que verrait satisfaite sans problèmes par le serveur.
L’attaque commence avec un message de type « Server Hello » de C, qui est intercepté et mémorisé par P. P commencerait une normale authentification TLS avec S, en négociant les paramètres de la connexion. Peut faire cette opération parce que c’est S qui se doit authentifier chez C, mais pas le contraire.
Quand une première connexion TLS a été crée, le P injecte une requête HTTP qui contient un GET ou un POST d’une page qui appelle un service critique (le changement d’un mot de passe, l’exécution d’un payement, etc.). Si cette page a besoin d’un certificat de C (qui a été fournit au client précédemment par une autorité certificatrice connu par S) sur S, S va demander à C de lui envoyer ce certificat, avec une requête de renégociation de session, à travers un message de type « Hello Request ».
Pour répondre à ce message, P peut rejouer le premier message de type « Client Hello » reçu par C, crypté avec les paramètres de session négociâtes. En ce moment là, P doit forcer la négociation entre C et S, en décryptant les messages arrivant de S vers C et en les cryptant dans le cas contraire. Cette opération est nécessaire parce que C ne connaît pas les paramètres de la session TLS instauré avec S.
Quand C a envoyé son certificat et négocié les paramètres de session, S exécutera la requête malveillante qui P lui avait envoyé et après la requête envoyé par C. En plus, pour éviter que C puisse réaliser d’avoir subi une attaque, P peut cacher la première réponse et laisser passer la requête (et la réponse) originale du client.
La topologie
Pour réaliser cette attaque nous avons mis en place une architecture de test basée sur trois hôtes :
-un client « C », la machine utilisateur, qui génère les requêtes;
-un proxy « M » qui agit comme un MITM;
-un serveur « S » fiable, qui gère un service sécurisé;
Les trois hôtes ne sont pas forcement connecté directement : si l’attaquant est réussi à modifier un registre DNS (local ou distant) ou il a convaincu l’utilisateur à utiliser un lien malveillant cet attaque peut marcher sur le réseau Internet sans particulières empêchements.
Le client envoie sa requête au serveur fiable, mais elle est interceptée par le proxy, qui a un service qui accepte les connexions sur le port 443, exactement comme un serveur HTTPS. Après, le proxy s’agit comme un client TLS sans que le serveur puisse noter la différence.
L’attaque est donc complètement transparente pour l’utilisateur et peut être potentiellement utilisé sur grande échelle, avec la nécessité d’attaquer avec succès un serveur DNS. Une version plus simple, adapte à la démonstration de la vulnérabilité plus que à la mise en ouvre d’une vraie attaque, peut être réalisé avec la configuration sur la machine « cible » un proxy malveillant.
Certificats
Pour créer les certificats nécessaires à l’implémentation de notre attaque nous avons utilisé les librairies OpenSSL. La première phase était de créer une factice autorité de certification pour signer tous les certificats successifs que nous avons crée.
C’est importante rappeler que la clé de l’autorité de certification sera ajouté à la liste des « root CA » du browser (dans notre cas, Mozilla Firefox) pour éviter signalisations d’erreurs et pour rendre plus réaliste la procédure d’attaque.
En utilisant toujours les outils de OpenSSL nous avons crée la clé et le certificat du serveur en utilisant un chiffrement Triple DES avec un mot clé. Le passage successif est de signer le certificat juste crée avec la clé de l’autorité certificatrice pour utiliser la confiance que le browser a en elle.
Après avoir configuré Apache pour utiliser ces certificats, c’est le moment de générer le certificat pour le client. La procédure est plutôt proche à quelle du server : nous créons une clé de 1024 bit avec TDES, et nous l’utilisons pour générer le certificat. Aussi ce certificat doit être signé par la clé de l’autorité de certification pour le rendre digne de confiance.
La dernière partie est l’importation des certificats et de la clé privée dans le browser, procédure qui est différent pour chaque logiciel en commerce.
La première solution
Pour démontrer la possibilité d’exploiter la vulnérabilité et pour vérifier la bonté de la topologie pensée, nous avons choisi tout d’abord de limiter la complexité de l’implémentation pour nous concentrer sur les aspects les plus importants : un foie démontré la faiblesse du protocole, notre planning serait de créer une application plus complète.
Le principal problème que nous avons rencontré est lié aux librairies OpenSSL, qui sont les plus populaires et connues pour le développement d’applications basées sur TLS/SSL. Comme plusieurs librairies disponibles, OpenSSL fournit des méthodes de base pour crypter et décrypter les messages, et aussi des fonctions avancées pour gérer toutes les phases d’une session.
Si normalement les fonctions avancées sont parfaites pour construire un dialogue TLS, dans notre application le déroulement d’une session n’est pas du tout standard. Par contre, les méthodes de base se sont démontrées vraiment complexes à utiliser parce que en OpenSSL soit les fonctionnes de bas niveau, soit les fonctionnes de haut niveau modifient les mêmes structures données, en créant beaucoup de dépendances.
L’absence d’une documentation complète, surtout pour quel que concerne les fonctionnes internes, a rendu notre travail d’analyse du code vraiment lourde. Un autre bizarre comportement de ces librairies est de cacher en différentes façon la clé de session (la clé utilisé pour les processus de cryptographie), en manière de décourager les programmeurs à créer des paquets d’handshake ou alert TLS personnalisé. Nous ne sommes pas réussis à la récupérer et il est curieux que ni la documentation, ni les développeurs que nous avons contacté ne sont réussi à nous expliquer comme arriver à récupérer la clé de session.
Pour surmonter ces problèmes, dans la première version du notre simulation, nous avons choisi de fournir au proxy le certificat du client, pour faciliter la gestion de la connexion avec les librairies OpenSSL. En fait, la possibilité de faire gérer aux libraires OpenSSL toute la phase d’handshake, permit de voir facilement si l’attaque peut marcher.
En cette configuration, le client s’agit comme client HTTP qui envoie les requêtes en claire sur le port 80 du MITM. C’est le proxy qui commence la session TLS et qui injecte le message « GET » malveillante comme dans notre schéma original. Après, le serveur demande une renégociation et une nouvelle session est négociée avec le MITM. Comme on se peut voir dans le schéma, le serveur réponde à la requête malveillante, qui est lui envoyé par le proxy. Aussi dans le cas que le proxy envoie deux requêtes au proxy, le serveur n’aura pas de problèmes à satisfaire la première requête qui n’est pas authentifiée.
Avec cette version nous avons comprit le déroulement de la phase de renégociation sans et avec le patch pour sécuriser les échanges et nous avons choisi la plateforme de test que nous avons présenté.
Notre logiciel se base en partie sur l’application open source « SSLProxy.2000 », qui nous avons déjà décrit. Nous l’avons utilisé pour avoir une modèle de proxy de départ fonctionnant, documenté, fonctionnel et simple. Nous remercions l’équipe de développement de « SSLProxy.2000 » pour l’aide involontaire, mais très apprécié, qui ont nous fournit.
La deuxième solution
Une fois que nous avons démontré que la topologie choisie peut être utilisée pour simuler l’attaque, nous avons choisi de mettre en place l’attaque vraie e propre.
Pour réaliser cette attaque nous avons dû changer en manière significative les messages envoyés pendant la phase d’handshake. Afin de effectuer cette opération, nous avons analyse le code de la librairie OpenSSL et nous avons trouvé deux fonctions qui permettaient d’envoyer et de lire des messages qui appartiennent à cette phase. Comme nous avons déjà dit, les fonctionnes internes d’OpenSSL sont vraiment mal documenté et puis la recherche des fonctionnes qui permettent ces opérations a été lourde. Heureusement, nous avons aussi trouvé un programme open-source qui les utilise et qui nous a permit de comprendre leur fonctionnement.
Le fonctionnement du programme reproduit fidèlement le schéma d’attaque qui nous avons décrit dans la première partie de ce chapitre. Nous avons pensé de simuler l’attaque en injectant une requête HTTP vers une page différente par rapport à quelle que le client a requeté. Nous avons choisi, aussi, de filtrer la requête envoyée par le client pour permettre la visualisation du message de réponse malveillante sur le client et être sure que l’attaque a été effectuée correctement. C’est clair que si on veut mettre un place un vrai attaque il faut filtrer la première réponse du serveur et envoyer au client la deuxième, pour rendre l’attaque transparent pour le client.
Pour comprendre la trace Wireshark ci dessous, il faut imaginer que le client est sur la machine 10.0.1.5, le proxy sur la 10.0.1.247 et le serveur sur la 10.0.1.245.
Possibles améliorations
Pour terminer la description de l’implémentation d’attaque on va observer quels peuvent être des améliorations à notre deuxième solution :
-augmenter la robustesse de notre application, en implémentant plusieurs contrôles (notre application n’est pas compatible avec les messages « Alert » ou avec versions différentes du protocole TLS) ;
-effectuer un contrôle sur le serveur à attaquer, pour vérifier si il y a les conditions (versions, algorithmes de chiffrement) pour effectuer l’attaque ;
-effectuer les modifications décrites pour rendre l’attaque transparente pour le client ;
-améliorer le code et l’optimiser. En effet maintenant l’application est écrite de façon très simple pour garantir la correcte compréhension.
-implémenter les autres types d’attaque que nous avons décrit dans le chapitre « Vulnérabilités de la renégociation ».
| < Prec. | Succ. > |
|---|
