Sécurité Active Directory : Filtrer les accès RPC dangereux avec RPCFirewall

I. Présentation

Cet article présente la solution open source RPCFirewall de la société ZeroNetworks. Il s’agit d’un pare-feu conçu pour filtrer les appels RPC sur les systèmes d’exploitation Windows.

Nous rappellerons d’abord ce qu’est le protocole RPC et les risques associés. Ensuite, nous explorerons le fonctionnement de RPCFirewall et pourquoi il constitue une solution efficace pour atténuer ces risques et améliorer la sécurité d’un domaine Windows et des systèmes qui le composent.

II. Le protocole RPC et ses risques

A. Rappel sur le protocole RPC

Bien que les administrateurs système ne l’utilisent pas directement, le protocole RPC (Remote Procedure Call) est omniprésent dans les environnements Windows, en particulier au sein des domaines Active Directory. Créé dans les années 1980, RPC permet à un client d’exécuter des fonctions sur un serveur distant comme s’il s’agissait d’appels locaux, facilitant ainsi les communications entre applications distribuées.

RPC ne doit pas être comparé directement à des protocoles comme HTTP ou FTP, car il opère au niveau 5 (Session) du modèle OSI et est conçu pour orchestrer des échanges complexes entre services plutôt que pour transférer des données ou gérer des connexions réseau. Sa fonction principale est de permettre à un processus de rendre accessibles ses fonctionnalités à d’autres processus, même s’ils sont distants. L’implémentation la plus répandue de RPC dans les systèmes Windows est DCE/RPC (Distributed Computing Environment/Remote Procedure Call), qui est au cœur de nombreuses fonctionnalités critiques du système, comme la gestion des services réseau, l’authentification et la gestion des permissions.

Vous pouvez voir le protocole RPC comme un protocole « valise », qui permet d’organiser les échanges client-serveur tout en restant ouvert sur la finalité exacte de ces échanges, il permet à chaque interface d’implémenter son propre protocole basé sur RPC et répondant à des tâches plus spécifiques. Cette flexibilité le rend extrêmement polyvalent, et c’est pourquoi il est utilisé dans de nombreux contextes. Parmi les cas d’usage courant du protocole RPC dans un domaine Windows, on trouve par exemple :

• Protocole MS-DRSR : Gestion de la réplication à distance des contrôleurs de domaine.
• Protocole MS-RPRN : Gestion des tâches d’impression client-serveur.
• Protocole MS-EFSR : Gestion des données chiffrées à distance.
• Protocole MS-DSSP : Récupération distante d’informations sur un système du domaine.
• Protocole MS-EVEN : Récupération de journaux d’évènements à distance
• Rendez-vous sur cette page pour avoir une liste plus complète des protocoles basés sur RPC utilisés en environnement Windows

Par exemple, si vous avez lu notre article sur l’attaque DCSync, vous savez que le protocole RPC est utilisé lors d’une synchronisation de données entre deux contrôleurs de domaine. On retrouve d’abord un appel DCE/RPC pour la connexion initiale, puis EPM pour mapper les services proposés par le serveur via RPC, et enfin DRSUAPI pour effectuer la synchronisation des données.

En contexte Windows, le Portmapper ou Endpoint Mapper (EPM) est le service qui écoute sur le port TCP/135. Il aide les clients à localiser l’adresse et le port d’un service RPC spécifique en fonction de son UUID (Universally Unique Identifier) d’interface.

Un point important à retenir concernant RPC est que même si un serveur n’expose qu’un seul service RPC (généralement en écoute sur le port TCP/135), il peut proposer de multiples fonctions et services accessibles via ce service RPC, ce sont les interfaces RPC.

Voici, à titre d’exemple, les interfaces proposées par un contrôleur de domaine classique :

Nous voyons ici, par exemple, le service RPC relatif à l’impression sur mon contrôleur de domaine (« (MS-RPRN) : Print System Remote Protocol« ), celui en charge de la réplication entre contrôleurs de domaine (« (MS-DRSR) : Directory Replication Service (DRS) Remote Protocol« ), etc.

Voici une vue plus complète d’une seule interface :

On retrouve ici le protocole (toujours basé sur RPC), l’exécutable pipe ou DLL en charge de cette interface, c’est-à-dire celle qui expose ses fonctions via RPC et l’UUID de l’interface (très utile pour la suite). Les bindings spécifient les protocoles de transport et les points de terminaison utilisés pour établir une communication entre le client et le serveur RPC. Ici, cela peut être via un pipe, via TCP/IP, un appel RPC local (ncalrpc) etc.

B. RPC en environnement Windows : quels risques ?

En dépit de ses avantages, cette complexité et sa capacité à interagir avec des systèmes distants en font une cible privilégiée pour les cyberattaques. Les attaquants peuvent exploiter RPC pour effectuer des mouvements latéraux, exécuter du code à distance, ou accéder à des informations sensibles sans déclencher d’alertes immédiates.

La fonction « valise » de RPC au sein d’un domaine est aussi sa principale faiblesse. Contrairement à des protocoles « classiques », où il est possible d’utiliser un pare-feu local ou réseau pour bloquer l’accès (par exemple, au service RDP depuis le réseau utilisateur), RPC expose des services critiques sans possibilité de filtrage direct des accès. Certaines interfaces RPC sont vitales pour le bon fonctionnement du domaine, ce qui rend impossible leur blocage total. Ainsi, les administrateurs doivent exposer le port relatif au service RPC à tous les systèmes du domaine, laissant toutes les interfaces offertes par les serveurs, notamment les contrôleurs de domaine, vulnérables aux tentatives de compromission.

Pour faire une analogie simple : autant il est possible de mettre un vigile à l’entrée d’une boîte de nuit pour filtrer les entrées en fonction de critères simples, autant, cela est difficile à l’entrée d’un centre commercial, où les activités peuvent être très variées. Une fois à l’intérieur, chaque individu peut accéder à de nombreux services avec différents niveaux de contrôle d’accès.

Voici un schéma qui résume cette idée :

Profitant de cette faiblesse et de sa surutilisation en environnement Windows, les attaquants et les chercheurs en cybersécurité ont particulièrement ciblé ce protocole ces dernières années. Pour preuve, la plupart des vulnérabilités critiques récentes concernent des services exposés via RPC sur les contrôleurs de domaine :

• PrintNightmare (CVE-2021-34527) : Vulnérabilité dans le service Spooler d’impression, permettant l’exécution de code à distance.
• Zerologon (CVE-2020-1472) : Faiblesse dans le protocole MS-NRPC permettant à un attaquant de prendre le contrôle total d’un domaine.
• PetitPotam (CVE-2021-36942) : Exploitation du protocole MS-EFSRPC pour forcer l’authentification NTLM d’un contrôleur de domaine.
• DFSCoerce : Exploitation du protocole MS-DFSNM pour forcer un contrôleur de domaine à s’authentifier auprès d’une machine contrôlée par l’attaquant.

Une bonne partie de ces vulnérabilités concernent des attaques par « coercition » via des appels RPC. Les attaques par coercition (entendre, par contrainte) permettent d’obliger un hôte à communiquer et à s’authentifier auprès de la machine de l’attaquant en exploitant des appels RPC mal conçus et mal protégés. Le résultat est que l’attaquant reçoit une authentification d’une machine intégrée au domaine (parfois le contrôleur de domaine lui-même) et peut, si les durcissements nécessaires ne sont pas en place, relayer ces informations pour apparaître comme authentifié sur le domaine, facilitant ainsi des attaques comme SMBRelay.

Plutôt que de bloquer totalement l’accès au service RPC pour se protéger de ces attaques, la logique voudrait que l’on puisse bloquer l’accès un utilisateur, un système ou l’ensemble d’un sous-réseau à un ensemble d’appels du service RPC, tout en lui autorisant l’accès à d’autres appels considérés comme nécessaires. C’est ce que permet de faire RPCFirewall.

III. Reprendre le contrôle avec RPCFirewall

A. Qu’est-ce que RPCFirewall ?

RPCFirewall est un outil qui permet d’avoir un contrôle fin et granulaire sur les interfaces exposées par un service RPC. Il permet notamment d’appliquer une décision d’autorisation ou de blocage en fonction de différents critères comme l’utilisateur ou l’adresse IP cliente effectuant l’appel RPC.

RPCFirewall ne doit pas être confondu avec RPCFilter, une fonction native qui permet de se protéger de l’accès anonyme (non authentifié) aux interfaces RPC, mais aucune gestion granulaire des accès en fonction de l’IP source par exemple.

Cet outil permet donc de mieux contrôler l’accès à des interfaces RPC sensibles qui ne doivent être utilisées que par certains hôtes (par exemple, la synchronisation des données entre contrôleurs de domaine) tout en gardant ces interfaces opérationnelles et accessibles pour les hôtes légitimes et en continuant d’exposer les interfaces RPC nécessaires à tout le reste du réseau.

Nous allons aussi voir que RPCFirewall peut être utilisé comme outil de surveillance des activités plutôt que de blocage actif. Cette fonctionnalité le rend encore plus intéressant pour de la recherche ou dans le cadre d’une surveillance active de la sécurité d’un système d’information (SIEM, SOC, XDR) et notamment pour surveiller les interfaces RPC concernées par des vulnérabilités récentes susceptibles d’être exploitées.

RPCFirewall se présente sous la forme d’une DLL (fichier Windows contenant des fonctions au même titre qu’un exécutable classique). Une fois installée, cette DLL va venir hooker (intercepter) les appels RPC réalisés pour y appliquer un filtre et journaliser ces appels.

L’ajout d’une DLL externe sur un contrôleur de domaine ou serveur en production est une opération sensible, prenez le temps de consulter le code source de RPCFirewall avant de l’utiliser en production : Github – ZeroNetworks/RPCFirewall.

Également, RPCFirewall est fourni avec un exécutable qui nous permettra d’installer et de désinstaller la solution puis de gérer l’état de son service sur un système en ligne de commande.

B. Installation de RPCFirewall

Nous allons voir comment installer RPCFirewall sur une machine Windows Server. Nous aurons pour cela besoin d’un accès administrateur et d’avoir à disposition les fichiers d’installation de RPCFirewall que vous trouverez sur ce lien :

Une fois l’archive ZIP de la dernière version à jour décompressée sur le serveur cible, ouvrez un terminal en tant qu’administrateur puis rendez-vous dans le répertoire RPCFW_. Voici ce que vous y trouverez :

C:\Users\Administrateur\Desktop\RPCFW_2.2.4>dir
Le volume dans le lecteur C n’a pas de nom.
Le numéro de série du volume est 9482-6291
Répertoire de C:\Users\Administrateur\Desktop\RPCFW_2.2.4

13/08/2024  21:57

. 13/08/2024 21:57.. 09/05/2024 14:35 370 728 rpcFireWall.dll 08/05/2024 11:04 6 057 984 rpcFireWall.pdb 11/01/2024 14:20 27 RpcFw.conf 09/05/2024 14:35 444 456 rpcFwManager.exe 09/05/2024 14:35 178 216 rpcMessages.dllComme présenté plus haut, nous retrouvons la DLL rpcFireWall.dll et l’exécutable rpcFwManager.exe. Le fichier rpcFireWall.pdb n’est présent qu’à des fins de débogage et peut être supprimé sans conséquence. Nous avons également la DLL rpcMessages.dll qui contient quelques fonctions partagées et gérera surtout la journalisation des appels RPC dans l’Observateur d’évènements.

Pour installer RPCFirewall, il faut utiliser les options suivantes de son exécutable :

# Installation de RPCFirewall
C:\Users\Administrateur\Desktop\RPCFW_2.2.4> .\rpcFWManager.exe /install

Voici le retour que vous aurez dans le cas d’un succès :

Vous pourrez ensuite démarrer le service avec l’option « /start » (ou « /stop » pour l’arrêter) :

# Démarrer le service RPCFirewall
.\rpcFwManager.exe /start

RPCFW Manager started manually...
Removing RPC Filters...
Creating RPC Filters...
Service configured to start automatically.
Service start pending...
Service started successfully.

Et, enfin consulter son état dans le gestionnaire de tâches ou à l’aide de l’option /status :

# Récupérer l’état du service RPCFirewall
.\rpcFwManager.exe /status

Voici le retour attendu si le service est bien démarré :

Le retour terminal nous donne plusieurs informations intéressantes concernant la présence à l’endroit attendu des DLL de RPCFirewall, la configuration actuelle (sur laquelle nous allons revenir), les processus surveillés par RPCFirewall, etc. Voyons à présent comment maîtriser et configurer cette solution.

C. Auditer et journaliser les appels RPC avec RPCFirewall

Pour l’instant, notre service tourne à merveille, mais nous ne l’avons pas configuré pour bloquer quoi que ce soit. Nous allons à présent nous attarder sur le fichier de configuration de RPCFirewall : RpcFw.conf

Par défaut, ce fichier contient la configuration suivante :

fw:action:allow audit:true

Cette ligne est simple à comprendre : RPCFirewall accepte tous les appels RPC (« fw:action:allow« ) et est en mode audit (« audit:true« ). Cela signifie qu’il laisse tout passer, mais journalise chaque appel. Voilà qui peut être utile dans les cas suivants :

• Configurer RPCFirewall : nous allons voir dans la section suivante que pour configurer efficacement RPCFirewall, il faut récupérer des informations très précises sur les appels que nous souhaitons bloquer. Les informations dans les journaux nous aideront à obtenir ces informations.
• Archiver : Les journaux vous permettront d’avoir un historique des appels RPC qui ont été réalisés vers votre serveur ou contrôleur de domaine. Cela pourra être utile pour du débogage ou dans le cadre d’une investigation numérique suite à une attaque.
• Surveiller et alerter : grâce à cette journalisation et l’utilisation de l’Event Viewer (logs standards Windows), il est possible de facilement centraliser ces journaux vers une solution de surveillance des évènements de sécurité (un SIEM, comme Splunk ou ElasticSearch) afin d’y appliquer des règles de détection. Certaines attaques pourront ainsi être détectées de cette manière, car elles laisseront dans les journaux des indicateurs forts d’exploitation.

Sans plus attendre, allons voir à quoi ressemble ces journaux, il faut pour cela ouvrir l’Observateur d’évènement, puis se rendre dans Journaux des applications et de services puis RPCFW :

Vous aurez ici tous les évènements journalisés par RPCFW, un pour chaque appel RPC réalisé (local ou distant). Dans ce premier exemple, l’appel est local, mais on peut voir que le client qui a effectué l’appel RPC est bien journalisé (Client Network Address : AD01).

Notez également le champ RPC Information, qui contient l’interface RPC cible de la requête (son UUID, identifiant unique) et l’OpNum. Dans le contexte d’un appel RPC, l’OpNum permet de spécifier la méthode que l’on souhaite appeler sur l’interface désignée. Voici, par exemple, la description des OpNums de l’interface RPC MS-LREC (Live Remote Event Capture, source) :

Chaque OpNum correspond à une méthode (une fonction) d’un programme qu’il est donc possible d’appeler de manière très précise. À titre d’exemple, voyons ce qu’il se passe lors de la réalisation à partir du réseau d’une attaque DCSync vers mon contrôleur de domaine muni de RPCFirewall en mode audit :

Nous voyons l’UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2 qui est lié à l’interface DRSR (Directory Replication Service Remote Protocol) ainsi que l’opnum 3 (méthode DRSGetNCChange, l’appel qui permet d’obtenir la liste des changements depuis la dernière synchronisation). De plus, la journalisation du client qui a effectué l’appel RPC nous permet de confirmer qu’il ne s’agit pas du tout d’un contrôleur de domaine légitime.

Pour rappel, une attaque DCSync est une opération de post-exploitation lors de laquelle un attaquant qui a obtenu des droits privilégiés sur le domaine va chercher à se faire passer pour un contrôleur de domaine et demander une synchronisation de toutes les données de l’Active Directory auprès du contrôleur de domaine principal. L’objectif est de récupérer tous les hashs des mots de passe des utilisateurs, et donc des autres administrateurs.

Pour en savoir plus sur cette attaque, rendez-vous sur nos deux articles à ce sujet :

Toutes ces informations permettent de confirmer qu’il s’agit bien d’un évènement anormal qui mérite une investigation plus poussée. C’est un exemple de ce qu’il est possible de faire grâce à la fonction de journalisation de RPCFirewall, voyons à présent comment bloquer des appels RPC en fonction de l’adresse IP source ou d’autres critères.

D. Configurer un filtrage des appels RPC avec RPCFirewall

Nous allons à présent apprendre à configurer RPCFirewall pour effectuer un blocage sélectif des appels RPC en fonction de différents critères tels que l’IP source du client.

Soyez sûr de bien comprendre le fonctionnement de RPCFirewall et de maîtriser sa configuration avant de mettre en production une configuration de ce type. Il est préférable de passer par une validation dans un environnement de test au préalable, car cela peut lourdement impacter le fonctionnement du domaine dans son ensemble.

Supposons à présent que nous souhaitions limiter l’utilisation de l’interface RPC MS-DRSR, celle qui permet de synchroniser les contrôleurs de domaine entre eux. Seul le contrôleur de domaine secondaire de notre réseau doit être autorisé, aucun autre système ou adresse IP ne doit pouvoir communiquer avec cette interface RPC.

La première chose à faire ici est de récupérer l’UUID de l’appel RPC correspondant et les OpNums utilisés lors de cette attaque.

Petite difficulté ! Les UUID des interfaces RPC Microsoft sont très mal documentés, leurs OpNums eux le sont un peu mieux, mais il faut tout de même passer du temps dans la documentation Microsoft. C’est pour cela que la fonction de journalisation de RPCFirewall est si précieuse : elle nous permet de voir précisément les UUID des appels effectués. Dans le contexte où l’on maîtrise l’attaque réalisée (test, recherche, validation), cela simplifie beaucoup les choses.

L’opération de consultation des journaux d’évènement suite à la réalisation d’une attaque DCSync que nous avons effectuée dans la section précédente nous permet d’identifier l’UUID « e3514235-4b06-11d1-ab04-00c04fc2dcd2 » et l’OpNum « 3« . Je sais également que dans mon lab, le seul système légitime pour la demande d’une opération de synchronisation vers mon DC principal est mon DC secondaire, qui possède l’adresse IP « 192.168.56.150« . Avec toutes ces informations, je peux ajouter la règle suivante dans le fichier « RpcFw.conf » :

fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:192.168.56.150 opnum:3 action:allow
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:block
fw:audit:true

Détaillons à présent ces directives :

• « fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2« : spécifie une règle de pare-feu basée sur l’UUID de l’interface RPC.
• « Addr:192.168.56.150« : restreint l’application de la règle à une adresse IP spécifique.
• « Opnum:3« : spécifie le numéro d’opération particulier au sein de l’interface RPC.
• « Action : allow » : indique qu’il faut autoriser les appels qui correspondent aux filtres spécifiés

La seconde ligne utilise les mêmes directives, mais sans spécifier d’adresse IP et avec l’action « block« . En d’autres termes : on bloque toutes les autres adresses IP qui cherchent à joindre cette interface RPC avec cet OpNum. La troisième ligne permet d’activer la journalisation.

Pour appliquer cette nouvelle configuration, il est nécessaire de redémarrer le service RPCFirewall à l’aide de son exécutable :

# Appliquer la mise à jour de configuration
.\rpcFwManager.exe /update

Vous pourrez ensuite vérifier que vos directives ont bien été appliquées grâce à l’option « /status » vue précédemment. Sa sortie affichera la configuration actuellement en place :

Voici une démonstration de l’impact de ces directives sur la réalisation d’une attaque DCSync :

Dans un premier temps, l’attaque est réalisée lorsque RPCFirewall est en mode audit uniquement. Sa configuration est ensuite durcie avec les directives que nous venons de voir pour n’autoriser la synchronisation que depuis un hôte bien précis. La seconde attaque est donc bloquée, car mon adresse IP d’attaquant n’est plus autorisée à réaliser cet appel RPC.

Enfin, sachez que d’autres types de directives peuvent être utilisées dans la configuration RpcFirewall :

Il est, par exemple, possible d’utiliser un protocole ou le SID (Security Identifier) d’un utilisateur ou d’un groupe, il s’agit d’éléments journalisés, donc RPCFirewall peut les utiliser pour autoriser ou non un appel RPC authentifié. Voici un autre exemple rapide pour illustrer cela : lorsque j’utilise la commande RPC « enumdomusers » via « impacket-rpcdump » pour lister à distance les utilisateurs du domaine, je vois passer dans les journaux de RPCFirewall les informations suivantes :

UUID : 1cd138b9-cc1b-4706-b115-49e53189e32e, opcode 13

La commande « enumdomgroups » (lister les groupes du domaine) fait apparaître les informations suivantes :

UUID : 1cd138b9-cc1b-4706-b115-49e53189e32e, opcode 11

Après quelques recherches, je retrouve rapidement la documentation Microsoft liée à ces informations :

Je souhaite à présent empêcher l’utilisateur du domaine « JASPER_CLARK » d’avoir accès à la fonction de liste des groupes du domaine. Il faut commencer par récupérer le SID de cet utilisateur (ou du groupe si nous souhaitons agir au niveau groupe) :

PS C:\Users\Administrateur> Get-LocalUser -Name "JASPER_CLARK" | Select-Object Name, SID
Name         SID                  
----         ---                                                                                                        JASPER_CLARK S-1-5-21-1774753266-2208968439-3773012859-1695

Voici un article qui vous propose plusieurs commandes pour récupérer le SID d’un utilisateur du domaine :

Ensuite, nous pouvons utiliser les différentes informations récupérées dans la règle RPCFirewall suivante :

fw:uuid:12345778-1234-abcd-ef00-0123456789ac sid:S-1-5-21-1774753266-2208968439-3773012859-1695 opnum:11 action:block

Je bloque donc l’accès à l’OpNum « 11 » (SamrEnumerateGroupsInDomain) de l’interface « 12345778-1234-abcd-ef00-0123456789ac » (MS-SAMR, Security Account Manager Remote Protocol) pour l’utilisateur au SID « S-1-5-21-1774753266-2208968439-3773012859-1695 » (JASPER_CLARK).

Après application, l’utilisateur JASPER_CLARK peut toujours utiliser l’interface RPC MS-SAMR pour lister les utilisateurs du domaine, mais plus pour lister les groupes :

Ce dernier exemple est plus à titre démonstratif, car il ne présente pas d’intérêt particulier en termes de sécurité, voire peut causer des dysfonctionnements pour cet utilisateur.

IV. Conclusion

Nous avons dans cet article commencé par faire un rappel de ce qu’est RPC au sein d’un environnement Windows et quels sont les risques associés à ce protocole. Nous avons vu comment RPCFirewall pouvait être installé et utilisé pour se protéger de ces risques.

Il s’agit d’une solution intéressante qui permet de pallier certains manques des fonctions natives des systèmes Windows. La construction d’une configuration complète et efficace nécessite beaucoup de travail, car elle doit forcément être construite en fonction de vos contraintes et vos besoins de sécurité, mais aussi en fonction des éventuelles attaques en cours : interface/méthode RPC vulnérable suite à l’apparition d’une 0-day, mais pas encore patché par exemple. Le tout nécessite une bonne compréhension de RPCFirewall, mais surtout du fonctionnement des systèmes Windows, du domaine et de RPC en général.

Également, un impact que je n’ai pas étudié ici concerne les performances, l’ajout d’une phase de contrôle à chaque appel RPC (protocole surutilisé dans un domaine) va potentiellement impacter l’utilisation des ressources du serveur, et donc les performances. N’ayant pas d’Active Directory dans un environnement réaliste avec plusieurs milliers d’utilisateurs et de systèmes actifs, je ne suis pas en mesure de valider l’existence cet impact. N’hésitez pas à nous faire un retour dans les commentaires ou sur notre Discord à ce sujet !