Pourquoi il ne faut pas ouvrir le port TSE sur Internet

Par Valentin Wallyn

Si votre entreprise possède une infrastructure Windows, vous avez peut-être configuré le port 3389 (RDP/TSE) comme étant ouvert, afin d’accéder à vos machines à distance. Cela est en réalité une mauvaise pratique en termes de sécurité car cela permet à un attaquant de récupérer certaines informations sensibles, comme nous allons le démontrer.

PoC :

  • Ouvrir une fenêtre RDP et tenter de se connecter au serveur cible
  • Enregistrer le fichier de configuration RDP (« Enregistrer sous »)
  • Ouvrir ce fichier avec un éditeur de textes (type bloc-notes)
  • Ajouter la ligne suivante : « enablecredsspsupport:i:0 »
  • Ouvrir le fichier pour se reconnecter au serveur cible

On arrive directement sur la page de connexion Windows, du type :

Figure 1 : PoC de la manipulation [1]

On voit bien que des informations intéressantes sont directement délivrées à l’attaquant :

  • Version du serveur (Windows Server 2008)
  • Logins d’utilisateur valides (plus que le mot de passe à trouver !)
  • Nom du domaine

Explications :

Le paramètre « enablecredsspsupport » permet d’activer ou de désactiver l’utilisation de CredSSP pour l’authentification RDP. CredSSP est en réalité une interface utilitaire de Windows permettant de déléguer l’authentification d’une application à un serveur externe (ici l’authentification RDP) [2]. En désactivant l’utilisation de CredSSP (passage de « enablecredsspsupport » à la valeur « 0 »), on se connecte alors directement au serveur Windows sur la fenêtre d’authentification distante, et non plus sur la fenêtre de connexion classique RDP (qui aurait redirigé vers le serveur seulement une fois l’authentification réussie). On accède ainsi à la page de connexion du serveur Windows qui, si mal configurée, peut délivrer des informations intéressantes à n’importe quel attaquant du serveur cible.

Contre-mesures et préventions :

  • On peut dans un premier temps désactiver l’affichage des derniers utilisateurs connectés par la configuration des Local Security Policies du serveur. Cela s’effectue par exemple en activant la policy « Do not display last user name » (Local Security Policy > Local Policies > Security Options)
  • Forcer la sécurité NLA par GPO, en activant la règle « Require user authentication for remote connections by using Network Level Authentication » (dans Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security), ce qui « bloque » l’attaque.
  • Configurer la redirection de port conditionnelle (via un pare-feu StormShield), le port n’est alors ouvert que si l’utilisateur s’est authentifié sur le firewall depuis l’IP Source. Cela ne chiffre pas la communication, mais réduit grandement la surface d’attaque.
  • On peut aussi configurer un portail VPN SSL basé sur une applet Java, ou utiliser un client VPN SSL « lourd » type OpenVPN, qui permettra à l’utilisateur d’avoir accès à tout ou partie du réseau selon les règles de filtrages définis sur le pare-feu Stormshield.

Lien vers la documentation en ligne

[1] http://www.vsysad.com/2015/01/login-screen-displaying-multiple-accounts-on-windows-server-2008-r2/

[2] https://msdn.microsoft.com/fr-fr/library/windows/desktop/bb931352(v=vs.85).aspx