Attaque de type "Man-in-the-Middle" contre les sessions "Windows Terminal Services"

Date : 03 Août 2005

Cet article analyse une attaque qui exploite une vulnérabilité dans le protocole " Remote Desktop Protocol" (RDP) des systèmes Microsoft.

"Windows Terminal Services" et "Remote Desktop Protocol"

 "Windows Terminal Services" est une architecture dans la quelle les applications clientes sont exécutées sur des serveurs ("Terminal Server") et leur affichage est déporté sur des postes de travail  ("Terminal Client") qui sont des terminaux spécialisés, ou des PC dotés d'un logiciel client.

 La communication entre ces clients légers et le serveur centralisé s'effectue via le protocole RDP ("Remote Desktop Protocol").
Ce protocole développé par Microsoft permet l’affichage vidéo chez un client et l’envoi des saisies clavier et souris du client vers le serveur. Il gère des connexions point à point reposant sur TCP/IP, et chiffre les données qu'il transporte (algorithme RC4).

Analyse de la vulnérabilité

 Principe :

Cette vulnérabilité déjà publiée au mois d'avril 2003 est due au fait que le protocole RDP ne contrôle pas l'identité du serveur lors de l'échange des clés entre le client et le serveur, à l'établissement de la session. Ceci permet à un attaquant capable d'intercepter un trafic entre un client et un serveur (DNS spoofing, arp poisionning, …), de déchiffrer ce trafic.

Microsoft à confirmé la vulnérabilité, et l'a corrigée dans les versions récentes d'implémentions de ce protocole.

Mais ce mois-ci Massimiliano Montor a souligné les limites de la correction de Microsoft, et a présenté un moyen de la contourner.

 Détail :

  1. Lorsque le client demande à se connecter au serveur l'attaquant intercepte la demande et l'envoi au serveur à la place du client.
  2. Le serveur envoi en réponse, à l'attaquant, sa clé publique avec un "chalenge" en clair. L'attaquant mémorise cette clé publique et ce "chalenge", puis il transmet le message au client en ayant remplacé la clé publique du serveur par une autre dont il connaît la partie privée.
  3. Le client répond au serveur en lui envoyant un "chalenge" chiffré avec la clé publique qu'il croit être celle du serveur mais qui est celle de l'attaquant.
  4. L'attaquant déchiffre le "chalenge" avec sa clé privée, le mémorise, puis le chiffre avec la clé publique du serveur, et transmet le résultat au serveur.
  5. La communication est alors établie entre le serveur et le client, via l'attaquant qui possède tous les éléments pour la déchiffrer

Discussion :

La vulnérabilité est due au fait que le client n'a aucun moyen de vérifier la validité de la clé publique qu'il reçoit (2).

Certains protocoles, comme "Secure shell" (SSH) par ex., contournent ce problème par une interaction avec l'utilisateur qui doit confirmer que l'empreinte de la clé publique est bien celle du serveur.

Réponse de Microsoft et ses limites

Microsoft a contourné le problème en modifiant le serveur qui signe désormais la clé publique qu'il envoie avec une seconde clé privée RSA.
L'échange de la clé publique du serveur qui va servir à chiffrer la communication, est ainsi sécurisé car le client peut désormais s'assurer de la provenance de celle-ci en contrôlant la signature qui lui est associée.

Cependant la clé RSA privée qui sert à signer la clé publique est codée en dur dans la librairie "mstlsapi.dll" que tout utilisateur Windows possède.
De plus, le client ne prévient pas l'utilisateur dans le cas où la clé publique du serveur est différente que celle utilisée d'habitude.

Un attaquant peut donc très facilement récupérer la clé privée servant à signer la clé publique du serveur, puis mener à bien une attaque telle que celle décrite précédemment, et ceci de façon complètement invisible pour l'utilisateur.

Remarque : lorsqu'un serveur est en mode "administratif" (seul un utilisateur avec un compte administrateur peut accéder au serveur) un attaquant qui exploite cette vulnérabilité peut en prendre le contrôle.

Nota : Depuis la version Windows Server 2003 SP1, Microsoft a ajouté une couche sécurisée au niveau "transport" (utilisation de TLS - "Transport Layer Security") vis-à-vis de l'implémentation du protocole RDP. Cet état permet d'éliminer le problème historique d'absence d'authentification des parties dans le protocole RDP.

Pour plus d'information :

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST