SSTIC 2012 - Sécurité de RDP
Bon, Windows, c’est pas administrable en ligne de commande. Il faut donc une solution d’administration à distance avec une interface graphique.
VNC, RDP, RPC et diverses solutions propriétaires comme PC Anywhere fraichement passé open-source sont à la disposition des administrateurs.
RDP est un protocole de déport d’affichage qui a été étendu avec un certain nombre de fonctionnalités, et il est maintenant au coeur d’une architecture de service avec 2008 R2. Les orateurs nous montrent une superbe map de RDP par Microsoft qui ressemble à un plan de paris.
RDP à fait l’objet de tellement d’ajouts de foncitonnalités que RDP se retrouve connecté à quasiment tous les composants du système. Coté tuyauterie, il y a toute une série de protocoles de communication avec en plus divers composant le tout résumé dans 2000 pages de Doc.
Quand on dissèque un paquet RDP dans network monitor, on obtient de quoi faire crasher NetZob 😉 (NDLR: ça taunt :p ). 4 pages d’attributs pour un pauvre paquet, c’est juste overkill. RDP fournit des virtual channel pour toutes les interractions entre l’utilisateur et le serveur administré en RDP. L’établissement de session est tout sauf simple, se fait en 8 étapes, une vingtaines de paquets et à peu près une centaine de propriétés sur lequelles on a aucun contrôle.
Le coté protocolaire est pas glorieux, maintenant les auteurs s’intéresse à la sécurité de RDP. On à le droit à une vidéo d’établissement de session RDP, et une capture réseau réalisé par l’attaquant. au démarrage de RDP on voit passer une clef RSA de 512 bits… ce qui fait pas beaucoup, et donc il est possible de factoriser la clef et d’obtenir les secrets de la session. Et ainsi de rejouer la session graphique de l’admin, ce qui permet de tout voir ;D c’est beau, c’est visuel, c’est pas sur… c’est un gros FAIL
Sur RDP il n’y a pas à l’origine d’authentification du serveur… il y a eu un patch ou une clef privée était hardcodé dans la dll et documentée dans la doc (Fail again). Suite à ces sévères échecs sur RDP Security, les gars de Microsoft ont refondu la sécurité de RDP a l’aide de TLS mais il n’y a toujours pas d’authentification mutuelle :x. NLA est là pour éviter que le client soumette directement sont mot de passe au serveur. L’utilisateur confie donc sont mot de passe au client RDP, qui va effectuer une authentification Kerberos ou NTLMSSP. Après validation et établissement d’une clef de session on est content.
Coté configuration client, seule une boite de dialogue est disponible pour configurer les options de sécurité. En cas de problème, soit on établit la connexion quand même sans avertir l’utilisateur, soit on avertit et on demande à l’utilisateur s’il veut s’authentifier, soit on fait rien. Par défaut sous XP on établit la connexion quand même et on avertit pas l’utilisateur. Le problème, c’est que les popup énervent les utilisateurs, et la solution proposée par Microsoft c’est de passer en mode « ne pas m’avertir et me connecter quand même » (fail again).
Petite vidéo à nouveau d’un fail sur la configuration du client RDP.
Demonstration d’un MITM RDP… et ça sans avertissement pour le client qu’il y a usurpation du serveur.
Coté client, la seule recommandation c’est de forcer l’authentification du serveur (ne pas établir la connexion) pour éviter toute acceptation de connexion à un serveur non authentifié pour éviter de se faire piéger.
Coté serveur, il n’y a pas de mise à jour. En domaine pas de salut pour Windows XP. Sur 2003 il faut activer et forcer TLS. Sur vista, seven 2008 il faut forcer NLA. Hors domaine sous XP, pas de salut. Pour les autres il faut forcer TLS. Tout ceci améliore la sécurité de RDP, mais c’est pas très très solide pour autant.
Il reste plein de failles exploitables :s analyse statistique des frappes au clavier qui sont chiffrés unitairement avant envoie, le presse papier qui se promène en clair, etc… Il faut donc que seul les administrateurs réseaux l’utilisent au sein d’un LAN d’administration sécurisé et cloisonné.
