Étiquette : Microsoft Page 7 of 8

PetitPotam n’est toujours pas résolu, et Microsoft recommande toujours de regarder la lune et non le doigt, c’est-à-dire de désactiver Web PKI sur un domaine alors qu’en fait le problème est double : continuer à utiliser le protocole d’authentification NTLM en général, et le fait que vous pouvez vous connecter via RPC aux appels MS-EFSR sans authentification. Mais quelqu’un s’est souvenu d’une solution alternative, puisqu’il n’est pas possible d’arrêter complètement le service de cryptage et bien sûr de bloquer l’accès RPC au système : bloquer les filtres RPC spécifiques avec netsh.
Lors de la communication avec les tuyaux efsrpc et lsarpc, le client et le serveur échangent un UUID spécifique pour savoir de quoi ils parlent, comme l’indique la documentation elle-même :

“Remote servers MAY respond to EFSRPC messages sent using the well-known endpoint \pipe\lsarpc. When connecting to \pipe\efsrpc, the server interface is identified by UUID [df1941c5-fe89-4e79-bf10-463657acf44d], version 1.0. When connecting to \pipe\lsarpc, the server interface is identified by UUID [c681d488-d850-11d0-8c52-00c04fd90f7e”

L’astuce consiste à bloquer ces UUID avec ces commandes (enregistrées dans un fichier txt) :

rpc
filter
add rule layer=um actiontype=block add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit

Et ensuite l’exécuter avec netsh -f file.txt

Plus d’information:
https://twitter.com/gentilkiwi/status/1421949715986403329

Après #printNightmare et #SeriousSAM vient PetitPotam. Il s’agit d’une demande du réseau interne pour des requêtes SMB au protocole MS-EFSRPC de la victime. Lors d’une tentative d’authentification, il partagera son hachage NTLM avec l’attaquant. A partir de là, avec des techniques connues de « pass the hash », il peut prendre le contrôle du contrôleur de domaine. Il s’agit en fait d’une nouvelle façon d’exploiter de vieux problèmes dont l’environnement des contrôleurs de domaine Windows souffre depuis des années. L’origine de la faille est que l’attaquant « provoque » la victime pour qu’elle s’authentifie, de sorte qu’il lui envoie tout ce dont il a besoin pour voler les informations nécessaires pour se faire passer pour elle.

Dans ce cas, après avoir « provoqué » la victime, l’attaque profite du fait que les services de certification Active Directory utilisent NTLM sur HTTP pour s’authentifier. L’idée est d’essayer d’obtenir un certificat valide via IIS une fois que le hachage « volé » a été obtenu. Mais cela n’a en fait rien à voir avec PetitPotam.

Il existe une preuve de concept. Microsoft a publié un avis, mais curieusement, les détails de l’attaque sont très rares. En gros, les mesures habituelles contre les attaques par relais NTLM : activer Extended Protection for Authentication (EPA) ou signer les paquets SMB. Microsoft ne mentionne même pas le vecteur d’attaque MS-EFSRPC, mais sera obligé de le corriger à l’avenir, car c’est là que réside la faille, dans la possibilité de « demander » à ce protocole de tenter « involontairement » de s’authentifier auprès d’une autre victime. Le fait que ce hash soit ensuite « exploité » par « Active Directory Certificate Services » n’est qu’une formule pour prendre le contrôle de l’Active Directory, puisqu’avec ce certificat, l’attaquant tentera probablement d’obtenir un ticket Kerberos signé.

Plus d’information:
https://msrc.microsoft.com/update-guide/vulnerability/ADV210003