Sartomiki.net

Man in the middle (MITM)
En cryptographie, une attaque de type man in the middle  (MITM) est une attaque dans laquelle il y a un attaquant qui transfert les messages entre deux entité, en faisant croire aux victimes qui elles sont en train de parler directement. Pour mettre en place une attaque de ce type, l’attaquant doit avoir la possibilité d’intercepter touts les messages entre les victimes et de les manipuler ou de créer des autres messages.

Les attaques MITM sont beaucoup utilisées pour chercher d’affecter le bon fonctionnement du protocole TLS et, en général, de tous les protocoles de sécurité.

Par exemple, on suppose que Alice et Bob veulent communiquer entre eux et que Mallory (l’attaquant) veut écouter et envoyer des messages pendant la communication. Alice et Bob cherchent de sécuriser la communication, en utilisent un mécanisme basé sur des clés publiques :
1. Alice envoie un message à Bob, qui est intercepté par Mallory. Ce message contienne la requête de la clé publique de Bob.
2. Mallory retransmet le message à Bob sans changement.
3. Bob envoie une réponse à Alice, qui est intercepté par Mallory. Ce message contienne la clé publique de chiffrement de Bob.
4. Mallory retransmet le message mais change la clé publique avec sa propre clé.
5. Alice pense que seulement Bob peut lire ses messages, mais en vérité ils sont compréhensibles aussi par Bob.
6. Mallory peut décider quels messages d’Alice envoyer à Bob, il peut modifier les messages et aussi il peut créer des nouveaux messages en place d’Alice.

Vulnérabilités de la renégociation
Plusieurs études ont signalé la présence de vulnérabilités dans les différentes implémentations de TLS. Marsh Ray et Steve Dispensa ont documenté trois cas principaux :
-Client Certificate Authentication ;
-Differing Server Cryptographic Requirements ;
-Client Initiated Renegotiation.

Client Certificate Authentication
Les serveurs HTTPS peuvent être configurés pour demander l’authentification du client sur la base du dossier ou du ficher requête. Ça signifie que le serveur ne peut pas demander un certificat au client avant d’avoir reçu et filtré sa requête. Le serveur doit donc utiliser la renégociation improprement, pour avoir la sécurité d’être en train de communiquer avec quelqu'un qui peut accéder aux informations.
HTTP n’a pas un message d’erreur qui informe le client de renvoyer la requête dans un nouveau canal TLS, donc l’authentification est donnée rétroactivement à la requête originale. Aussi s’il n’y a pas des problèmes dans l’algorithme de chiffrement, il y a une discontinuité dans l’authentification, qui peut être utilisé par un attaquant.

En plus, dans le cas de Session Resumption, cette vulnérabilité est encore plus grave, parce que la réutilisation des paramètres d’une session précédent donne à l’attaquant la possibilité de prendre le contrôle d’une entière session TLS. Selon l’étude de Ray et Dispensa, cet option n’est pas normalement utilisée pour gérer la renégociation due aux certificats, mais il reste la possibilité théorique d’avoir aussi cette complication.

Differing Server Cryptographic Requirements
Les serveurs HTTPS qui utilisent suites de chiffrement différentes, en basant sur les ressources qui doivent fournir, sont vulnérables à une attaque pendant la phase de renégociation. A cause de la force différents des algorithmes, le serveur est obligé à utiliser le niveau plus bas entre les suites supportés et, après avoir lit et filtré la requête, il peut déterminer la suite correcte.

Si la suite choisie initialement n’est pas la suite qui doit être utilisée par servir la requête, le serveur doit demander une renégociation. La sollicitation d’une renégociation porte les mêmes vulnérabilités du cas précèdent, parce que le serveur est forcé à utiliser une requête tamponnée, que peut contenir du plaintext  inséré par un attaquant.

Une méthode d’exploitation de la vulnérabilité différente est d’insérer deux requêtes HTTP en une seule, en utilisent les fonctions offertes par HTTP de pipeling et de keep-alive. En pratique, le MITM doit générer une requête, qui peut être indépendante avec les suivantes, qui force la renégociation et une autre requête qui contient l’injection. La deuxième requête a dans l’en-tête l’option « X-ignore » habilité, qui est lit par le serveur comme une requête d’ignorer la ligne originale du client (la commande « GET »). Cette requête incomplète est épissée avec les messages suivants, qui contiennent toutes les informations d’authentification, d’autorisation et éventuels cookies. Un exemple est le suivant :

GET /highsecurity/index.html HTTP/1.1
Host: example.com
Connection: keep-alive

GET /evil/do.php?evilStuff=here HTTP/1.1
Host: example.com
Connection: close
X-ignore-what-comes-next: GET /index.html HTTP/1.1
Cookie: AuthMe=Now
...

Dans ce cas l’attaquant a aussi la possibilité d’exploiter une autre vulnérabilité de TLS. En effet, la possibilité donnée au client de négocier la version du protocole TLS/SSL à utiliser peut consentir à l’attaquant de choisir une ancienne version qui contient quelque vulnérabilité note, cas qui n’est pas impossible.

En plus, pendant la phase d’handshake, le client peut spécifier une liste de suites de chiffrement acceptables. Si le client, ou l’attaquant, décide de fournir au serveur seulement un ensable de paramètres de sécurité faibles, la session TLS serait faible. Plusieurs chercheurs  ont noté qu’une grande partie des serveurs web existants, pour des raisons de compatibilité, donne au client la possibilité d’instaurer des sessions avec des algorithmes ou des paramètres de chiffrement faibles ou, en général, déconseillés.

Client Initiated Renegotiation
TLS permit aux clients de forcer une renégociation avec l’envoie d’un message du type « Hello Client ». Cette opération peut être effectuée à n’importe quel moment et donne à un potentiel attaquant la possibilité d’attaquer le protocole TLS sans attendre un message de type « Hello Request » envoyé par le serveur ou la nécessité de configurations particulières avec zones de sécurité différente.

Le MITM, comme dans le cas précédent, doit ajouter une requête qui contienne un HTTP « X-ignore » dans l’en-tête au message original. Cette attaque est possible aussi sans nécessiter que le pipeling ou le keep-alive soient activés sur le serveur et permit le vol d’informations d’authentification ou d’autorisation.

En effet, la réalisation pratique de l’attaque est la même du cas précédent, mais le manque de la nécessité de configurations spécifiques rende le numéro de potentielles cibles énorme. Si cette attaque serait mise en place, les conséquences pourraient être très graves.

Solutions
En 2009, quand les vulnérabilités ont été publiées, deux approches sont émergées dans la communauté des développeurs et des utilisateurs : le premier était de supprimer la renégociation de session pour implémenter une communication directe entre HTTP  et TLS et la deuxième était de sécuriser la renégociation sans trop modifier le protocole.

La première réaction de plusieurs producteurs était de délivrer des patchs pour déshabiliter la renégociation de session jusqu’à une solution définitive aurait été publiée, mais l’orientation de l’IETF était de suivre la deuxième route.

Dans la partie suivant nous allons distinguer clairement entre SSL et TLS, protocoles qui souvent sont cités ensable. TLS 1.0+ support les extensions , des méthodes d’ajouter fonctionnalités sans modifier le noyau du protocole. Elles sont définies comme des données « extra » qui sont appendues aux messages. Si un hôte ne comprend pas ces données, il est censé des les ignorer.

En effet, la solution aux vulnérabilités qui nous avons étudié est mise en ouvre avec des extensions TLS. SSH v.2 et précédents ne supportent pas les extensions, donc la seule possibilité de les rendre secoures est de effectuer la mise à jour à TLS.

Le RFC 5746 propose d’ajouter un champ « Renegotiated_Connection » à la fin de chaque message « Hello ». Pendant la première négociation, la valeur de cette extension doit être zéro. Les hôtes doivent sauver le contenu du camp « Verify_data » des messages « Finished » de la session active et l’ajouter au camp « Renegotiated_Connection » dans le cas d’une renégociation.

Avec cette extension, si un attaquant essaye de rejouer un message du client pour authentifier sa requête, le serveur comprend que le client n’est pas au courent qui une renégociation est en cours et peut donc couper la connexion.

Si cette modification empêche la réussie des attaques décrites dans la dernière partie, elle ne résolve pas possibles problèmes qu’une application peut rencontrer si elle ne sait pas d’être dans une phase de renégociation. Pour exemple, un des deux entités peuvent fournir, pendant la renégociation, un certificat différent du premier. Si l’exception n’est pas correctement gérée par l’application, c’est possible l’apparition des erreurs ou des problèmes de sécurité.

Un grand nombre  de producteurs et développeurs de logiciels et libraires ont intégré la nouvelle norme IETF avec un petit délai,  mais plusieurs serveurs, par différentes motivations,  ne sont mis au jour .

La même nature de la solution porte à être protégée seulement si tous le deux hôtes utilise la nouvelle version du protocole. En théorie, un hôte devrait terminer une connexion si l’interlocuteur n’est pas mis au jour, mais pour évidents problèmes de compatibilité il n’est pas possible. Un hôte, donc, ne peut pas savoir si l’autre a un vieux logiciel ou s’il est au dessus d’une attaque.

Cette solution est évidement fonctionnant avec les attaques illustrées, mais la présence d’un comportement au dehors du normal déroulement de la pile ISO/OSI est toujours présente. La renégociation de session continue à être utilisée pour des motivations différentes que celles qu’il a été conçu. Il faut aussi considérer que  l’extension du protocole a porté à des modifications  seulement en raison de la compatibilité.

L’introduction d’une faux « Cipher Suite » qui indique que le client support la renégociation sécurisé en lieu de l’utilisation standard des extensions, par exemple, semble être un point faible du protocole, parce qu’une modification de ce camp n’est pas impossible.

Jusqu’à HTTP ne sera pas capable de gérer individuellement les requêtes et leurs exigences de sécurité, il y aura toujours la possibilité d’exploiter des vulnérabilités.

Maintenant, la meilleure façon de protéger les serveurs est d’avoir différent instances (aussi virtuelles) qui gèrent les différentes parties du site web, ainsi que mettre à jour toutes les applications qui utilisent la suite TLS/SSL.