Le blog technique

Le rôle NPS (Network Policy Server) reste le seul moyen natif d’utiliser un serveur Windows pour réaliser des authentifications RADIUS, ce qui est très utile notamment pour gérer l’authentification à des appliances réseau, des bornes Wifi ou même des utilisations plus avancées comme de l’authentification par certificat avec AlwaysOn VPN.

Bien qu’il n’ait pas évolué depuis plusieurs versions de Windows et que sa partie NAP (Network Access Protection) soit dépréciée depuis Windows 2012 R2, il reste parfaitement fonctionnel pour son rôle de serveur RADIUS.

J’ai donc récemment déployé un serveur NPS sous Windows 2019 sur un serveur flambant neuf, configuré mon client Radius (une appliance NTP) ainsi qu’une stratégie d’authentification basique pour pouvoir utiliser des identifiants de l’AD pour me connecter à l’appliance.

Malheureusement, le premier essai de connexion fut un échec. Pas d’affolement, les stratégies NPS sont souvent assez obscures et il est vite arrivé de manquer un paramètre, me dis-je… mais pas cette fois.

J’active donc les logs d’audit de connexion, ils permettent souvent d’en apprendre plus sur les raisons de l’échec. Sauf que cette fois, ils sont intégralement vides : non seulement il n’y a pas d’erreur, mais il n’y a en réalité pas le moindre évènement, comme si la requête RADIUS n’arrivait jamais au serveur.

Les règles de firewall Windows créée automatiquement lors de l’installation du rôle NPS (groupe Network Policy Server) sont pourtant bien présentes et actives, et l’administrateur réseau me confirme que les paquets arrivent bien jusqu’au serveur.

Il est donc temps de sortir Wireshark : effectivement, les paquets RADIUS arrivent bien au serveur mais ensuite rien, aucune réaction; encore une fois comme si la requête n’arrivait jamais au rôle NPS…

Après bien des tentatives infructueuses, j’essaye en désespoir de cause de désactiver le firewall Windows; et miracle, tout tombe en marche.

Le problème se situe donc au niveau du firewall. Après quelques recherches, il apparaît que les règles natives sont configurées pour ne fonctionner que pour le service IAS, ce qui est normal. Par contre, dans Windows 2019, ce service utilise un identifiant de sécurité (service SID) qui l’empêche d’être la cible d’une règle de firewall… et donc la règle ne fonctionne pas et les flux sont bloqués.

Deux solutions s’offrent donc à nous :

• Reconfigurer le service pour retirer cette restriction à l’aide de la commande sc.exe sidtype IAS unrestricted
• Reconfigurer les règles de firewall pour qu’elles fonctionnent avec n’importe quel service :  Get-NetFirewallRule -DisplayGroup « Network Policy Server » | where DisplayName -like « *RADIUS* » | Set-NetFirewallRule -Service Any

Après avoir exécuté une de ces deux solutions, tout devrait rentrer dans l’ordre !

À quoi cela sert-il ?

En réalité, il y a peu de cas pratiques ou trouver le mot de passe d’un réseau wifi précédemment utilisé est utile, car bien souvent, celui-ci étant sauvegardé, il n’y a pas besoin de l’entrer à nouveau.

Alors à quoi cela sert-il ? C’est avant tout pour mettre en relief que certaines cmdlets Windows sont peu sécurisées et révèlent beaucoup d’informations avec peu de privilèges, ce qui est bien évidemment le combo préféré des hackers.

Les commandes

Les commandes ci-après sont exécutés avec un utilisateur qui n’est ni administrateur de la machine ni en mode administrateur

La première commande permet d’afficher les profiles auquel la machine s’est déjà connecté

C:\WINDOWS\System32>netsh wlan show profiles
 
Profiles on interface Wi-Fi:
 
Group policy profiles (read only) #Dans le cas d'un PC dans un domaine Active Directory les profiles déployés par GPO sont affichés ci-après
---------------------------------
    Profile_entreprise
    Profile_entreprise2
 
User profiles #Les profiles sont affichés ci-après
-------------
    All User Profile     : MonWifi
    All User Profile     : Faux_reseau
    All User Profile     : Toto

Cette commande va afficher le mot de passe du profile appelé en clair

C:\WINDOWS\System32>netsh wlan show profiles MonWifi key=clear

Profile MonWifi on interface Wi-Fi:
=======================================================================

Applied: All User Profile

Profile information
-------------------
    Version                : 1
    Type                   : Wireless LAN
    Name                   : MonWifi
    Control options        :
        Connection mode    : Connect automatically
        Network broadcast  : Connect only if this network is broadcasting
        AutoSwitch         : Do not switch to other networks
        MAC Randomization  : Disabled

Connectivity settings
---------------------
    Number of SSIDs        : 1
    SSID name              : "MonWifi"
    Network type           : Infrastructure
    Radio type             : [ Any Radio Type ]
    Vendor extension          : Not present

Security settings
-----------------
    Authentication         : WPA2-Personal
    Cipher                 : CCMP
    Authentication         : WPA2-Personal
    Cipher                 : GCMP
    Security key           : Present
    Key Content            : MonMotDePasseEnClair #Le mot de passe est affiché en clair

Cost settings
-------------
    Cost                   : Unrestricted
    Congested              : No
    Approaching Data Limit : No
    Over Data Limit        : No
    Roaming                : No
    Cost Source            : Default

Quels sont alors les moyens de se prémunir de cette vulnérabilité ? Les méthodes sont diverses, telles que l’utilisation du 802.1X ou un changement régulier du mot de passe.

Pour aller plus loin

Vidéo youtube qui propose un script python pour automatiser la récupération des mots de passe de tous les profils d’un ordinateur