PrivExchange : L’escalade de privilège AD

Bon nombre d’organisations utilisent aujourd’hui la solution de messagerie Microsoft Exchange au sein d’un environnement Active Directory. Dans un article de blog publié en janvier 2019, le chercheur en sécurité Dirk-jan Mollema détaille une technique d’escalade de privilège pouvant conduire à la compromission d’un domaine Active Directory via un simple appel à Exchange Web Services [1]. Par la combinaison de plusieurs vulnérabilités connues, le chercheur propose comme preuve de concept un outillage permettant à tout utilisateur non-privilégié possédant une boîte mail Exchange d’obtenir les privilèges d’administrateur de domaine.

Par défaut, les serveurs Exchange possèdent des privilèges élevés au niveau du domaine Active Directory (AD). Etant membre du groupe “Exchange Trusted Subsystem” et par héritage du groupe “Exchange Windows Permission”, le compte machine utilisé par un serveur Exchange dispose en effet de la permission “WriteDacl” sur l’objet “Domain” qui autorise la modification des privilèges des objets du domaine AD.
Exchange offre par ailleurs une fonctionnalité permettant à un utilisateur de spécifier une URL arbitraire vers laquelle la solution de messagerie vient s’authentifier pour y accéder. En effet, le service “PushSubscription” de Exchange Web Services (EWS) fournit aux utilisateurs une méthode “PushSubscriptionRequest” pour souscrire à des événements « push ». Un utilisateur peut ainsi spécifier l’URL d’un web service client et le serveur Exchange vient s’y connecter lorsqu’un événement survient. Via un simple appel à l’API “PushSubscription”, un utilisateur malveillant est donc en mesure de capturer les données d’authentification NTLM d’un serveur Exchange en demandant à celui-ci de se connecter à un web service client illégitime sous son contrôle.

A partir de ces données, l’attaquant procède alors à une attaque de type NTLM Relay à l’encontre d’un contrôleur de domaine AD pour y effectuer une action avec les privilèges du serveur Exchange. NTLM Relay est une attaque bien connue, communément utilisée pour usurper les droits d’accès d’un utilisateur afin d’exécuter du code à distance sur une machine via le protocole SMB [2]. Dans le cas présent, le code d’exploitation proposé par Dirk-jan relaye l’authentification NTLM du serveur Exchange pour réaliser une opération LDAP sur l’annuaire AD. Cette opération consiste à octroyer le privilège “DS-Replication-Get-Changes-All” à un compte utilisateur non-privilégié contrôlé par l’attaquant. Normalement réservé au groupe des contrôleurs de domaine, ce privilège fournit l’accès aux fonctionnalités de réplication d’Active Directory. L’attaque DCSync, notamment implémentée au sein de l’outil Mimikatz, consiste à exploiter ce privilège pour récupérer l’ensemble des secrets d’authentification stockés dans l’annuaire [3]. Cette attaque peut par exemple être menée dans l’objectif d’obtenir le condensat NTLM du compte “krbtgt”, qui peut être utilisé par l’attaquant pour générer des tickets d’or Kerberos (Kerberos Golden Tickets) afin d’usurper l’identité d’utilisateurs d’intérêt [4].

En résumé, la technique d’escalade de privilège est illustrée par le schéma ci-dessous :

Cinématique de l’attaque PrivExchange (source : dirkjanm.io)

Remédiation

A l’heure actuelle, toutes les versions récentes d’Exchange on-premise (2013, 2016 et 2019) sont vulnérables à cette technique d’escalade de privilège. Aucun correctif corrigeant ce problème n’a été mis à disposition par Microsoft.

Sept préconisations sont énoncées par Dirk-jan pour prévenir l’escalade de privilège. Les contre-mesures les plus efficaces sont listées ci-dessous :

Désactiver la fonctionnalité de souscription au niveau de EWS si celle-ci n’est pas utilisée [5]
Forcer la signature du trafic LDAP et SMB, pour se prémunir des attaques de type NTLM Relay
Appliquer un filtrage des flux pour interdire la communication des serveurs Exchange vers le segment réseau où sont localisés les postes de travail (notifications « push »)
Supprimer la permission “WriteDacl” sur l’objet Domain dont bénéficie les serveurs Exchange

Détection

Quelques approches pour détecter cette attaque sont recensées dans un article publié récemment sur le blog du SANS ISC [6].

Une première approche consiste à détecter l’événement d’authentification réseau provoquée par une attaque de type NTLM Relay à l’encontre d’un compte machine des serveurs Exchange. Cet événement est représenté par l’entrée suivante dans les journaux des contrôleurs de domaine :

EventCode=4624
LogonType=3
Authentication Package=NTLM
Account Name = YOUREXCHANGESERVER$

Une deuxième approche consiste à détecter l’événement 5136 dans les journaux, qui apparaît lorsqu’un privilège est modifié. Les GUID suivants sont ici à surveiller en priorité :

1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes)
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)
89e95b76-444d-4c62-991a-0facbeda640c (DS-Replication-Get-Changes-In-Filtered-Set)