Atacant el Directori Actiu: Usuaris

Un dels punts claus quan s’utilitza el Directori Actiu, és la gestió d’usuaris. Cada organització gestiona els seus usuaris de maneres diferents, ja sigui amb el format del nom, els permisos que assignen…

La forma més fàcil de fer aquesta gestió és emmagatzemar-los com a objectes a una base de dades central que es pugui consultar i editar des de qualsevol punt del domini, sempre i quant es tinguin suficients privilegis.

Propietats

Identificadors d’usuari

L’objecte d’un usuari conté informació diversa, però els atributs més importants són aquells que permeten identificar a l’usuari.

Normalment, s’utilitza el nom d’usuari com a identificador, que està guardat a l’atribut SamAccountName. Addicionalment, el SID (Security Identifier) també es pot utilitzar, tot i que és més complicat de recordar i gestionar.

El SID d’usuari és molt similar al de domini i de fet, és la combinació entre el SID del domini i el RID de l’usuari (Relative Identifier).

Hi ha moltes maneres d’aconseguir informació de l’usuari. Una d’elles és utilitzant el mòdul AD:

PS C:\Usuaris\Nadki> Get-ADUser Nadki

DistinguishedName : CN=Nadki,CN=Usuaris,DC=projectenadki,DC=local
Enabled           : True
GivenName         : Nadki
Name              : Nadki
ObjectClass       : user
ObjectGUID        : 58ab0512-9c96-4e97-bf53-019e86fd3ed7
SamAccountName    : nadki
SID               : S-1-5-21-1372086773-2238746523-2939299801-1103
Surname           :
UserPrincipalName : nadki@projectenadki.local

En aquest cas, el SID del domini és S-1-5-21-1372086773-2238746523-2939299801 i el RID d’usuari 1103. Algunes eines mostren el SID en lloc del nom d’usuari, per això has d’estar atent i conèixer el format per a identificar-lo correctament.

L’atribut DistinguishedName és utilitzat per la API de LDAP per identificar els objectes, per tant si has de llençar alguna consulta de base de dades utilitzant LDAP (que és una de les maneres més comunes), segurament veuràs les referències als objecte a través de DistinguishedName.

Secrets

La base de dades necessita emmagatzemar els secrets dels usuaris per permetre al Controlador de Domini realitzar el procés d’autenticació. La contrasenya de l’usuari no s’emmagatzema en text pla, sinó en un dels següents formats:

  • Hash NT (i hash LM pels comptes antics)
  • Clau Kerberos

No cal comentar que els secrets dels usuaris no poden ser consultats ni modificats per usuaris que no siguin administradors. Ni els ordinadors del domini poden accedir-hi, només el Controlador de Domini pot.

Des d’un punt de vista de l’atacant, necessites tenir privilegis d’administrador, o equivalent, per poder-te baixar la base de dades del domini. Aquesta base de dades està a C:\Windows\NTDS\ntds.dit al Controlador de Domini.

Pots consultar informació més detallada sobre que és el hash a aquesta entrada: Funció de hash

Hashes LM/NT

Els hashes LM i NT s’emmagatzemen en local a la base de dades SAM i al directori actiu a la NTDS per a poder autenticar usuaris locals i usuaris de domini, respectivament.

Aquests hashes son de 16 bytes de longitud. Per exemple, la contrasenya 123456 és:

Hash LM: 44EFCE164AB921CAAAD3B435B51404EE
Hash NT: 32ED87BDB5FDC5E9CBA88547376818D4

El hash LM és considera molt dèbil des d’un punt de vista de seguretat. De fet, no s’utilitza des de Windows Vista/Server 2008. El procediment per crear un hash LM és el següent:

  1. Converteix la contrasenya d’usuari a majúscules (aquest primer punt incrementa l’èxit d’un atac de força bruta, ja que passa de 60 possibles caràcters, majúscules, minúscules i números, a 35)
  2. Si la contrasenya de l’usuari és menys de 14 caràcters, s’afegeixen caràcters NULL fins arribar a la longitud de 14. Si la contrasenya en conté més de 14, es truca. Per tant, és inútil tenir contrasenyes de 14 caràcters.
  3. La contrasenya es parteix en dues cadenes de 7 bytes cada una.
  4. Cada una de les cadenes s’utilitza com a clau per xifrar la cadena KGS!+#$% que utilitza l’algorisme criptogràfic DES, algorisme considerat dèbil. El resultat d’això són dos hashes.
  5. Els dos hashes es concatenen per formar el hash LM. Un atacant podria utilitzar atacs de força bruta per separat per cada un dels hashes, cosa que facilita moltíssim la feina.

Amb pseudocodi, aquest seria l’algorisme:

contrasenya_majuscules = transforma_majuscula(contrasenya)
contrasenya_14 = truncar_14(contrasenya_majuscules)

cadena1, cadena2 = divideix_7(contrasenya_14)

hash1 = des(cadena1, "KGS!+#$%")
hash2 = des(cadena2, "KGS!+#$%")

hash_lm = hash1 + hash2

Per altra banda, el hash NT és més fort, però el salt no s’utilitza per calcular-lo, per tant és pot crackejar utilitzant valors precalculats, com rainbow tables.

Per si t’interessa, el hash NT es calcula aplicant l’algorisme MD4, que ja està obsolet, directament sobre la versió Unicode (codificat UTF-16LE) de la contrasenya de l’usuari. Els pseudocodi seria el següent:

hash_nt = md4(codifica_utf_16le(contrasenya))

Moltes vegades el hash NT s’anomena NTLM. Tot i que aquest nom pot produir confusions, ja que el protocol NTLM també utilitza hashes anomenats hash NTLM. A aquesta entrada, el hash NTLM serà el hash del protocol NTLM.

Existeixen moltes eines que permeten extreure hashes LM i NT. Normalment s’emmagatzemen en un línia per usuari amb el següent format: USUARI:RID:HASH_LM:HASH_NT:::. Si es dona el cas on el hash LM no s’utilitza, tindrà el següent valor, que és una cadena buida:

aad3b435b51404eeaad3b435b51404ee

Un exemple de fitxer de sortida després d’haver extret l’informació de la base de dades:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16a7t61b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16a7t61b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16a7t61b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:6535b87abdb134ghfc3bf92528ac01f6:::
user:1001:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aahjk87aea09c70:::

Per un pentester és important reconèixer els hashes NT, ja que encara que no siguin contrasenyes en text clar, es poden utilitzar igualment per autenticar-te de manera local a ordinadors Windows. Amb tècniques com Pass-The-Hash o Overpass-The-Hash podries utilitzar el hash per suplantar a usuaris.

Per acabar, comentar que per trencar hashes pots utilitzar moltes eines. Les més famoses són hashcat i John the Ripper. Amb temps i una mica de sort, segur que aconseguiràs alguna contrasenya.

Claus Kerberos

A part dels hashes LM/NT, les claus Kerberos s’utilitzen durant el procès d’autenticació al protocol Kerberos.

Les claus Kerberos poden ser utilitzades per demanar un tiquet Kerberos, que representa l’autenticació d’un usuari al protocol Kerberos. Hi ha molts tipus de claus diferents que es poden utilitzar:

  • Clau AES 256: és utilitzada per l’algorisme AES256-CTS-HMAC-SHA1-96. És la clau més comú, la mes forta i la que com a pentester hauries d’utilitzar per evitar aixecar sospites.
  • Clau AES 128: és utilitzada per l’algorisme AES128-CTS-HMAC-SHA1-96.
  • Clau DES: és utilitzada per l’algorisme DES-CBC-MD5, que es considera dèbil.
  • Clau RC4: és el hash NT utilitzat per l’algorisme RC4-HMAC, que es considera dèbil.

Les claus de Kerberos es poden extreure de diverses maneres, una d’elles és utilitzar l’eina secretsdump del paquet Impacket:

$ secretsdump.py projectenadki.local/Administrator@192.168.1.30
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
Password: ************

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
projectenadki.local\Nadki:1103:aad3b435b51gfr4eaad3b435b51404ee:cdeae556dc2858l45b7b14e9df5b6e21:::
[*] Kerberos keys grabbed
projectenadki.local\Nadki:aes256-cts-hmac-sha1-96:ecce3d24b29c7f044163ab4d94245kju5698337318e98bf2903bbb7f6d76197e
projectenadki.local\Nadki:aes128-cts-hmac-sha1-96:18fe293e673578214c57e9f9fe753198
projectenadki.local\Nadki:des-cbc-md5:fbba85nnh43d04cb
[*] Cleaning up...

Aquestes claus les pots utilitzar amb tècniques de Pass-The-Key que aconseguir un tiquet per suplantar l’identitat d’un usuari. Amb el tiquet Kerberos que aconsegueixes el pots utilitzar per iniciar sessió a diversos serveis del domini.

UserAccountControl

Una propietat interessant de la classe usuari és el UserAccountControl (UAC). No confondre amb User Account Control, mecanisme que evita l’execució programes amb privilegis elevats a ordinadors Windows.

La propietat UserAccountControl conté una sèrie d’atributs que són molt rellevants per la seguretat i pel domini que s’utilitzen en diverses tècniques d’atac. Aquests són els més importants:

  • ACCOUNTDISABLE: el compte d’usuari està desactivat, no es pot utilitzar.
  • DONT_REQUIRE_PREAUTH: el compte d’usuari no requereix la pre-auntenticació de Kerberos.
  • NOT_DELEGATED: aquest compte d’usuari no pot ser delegat mitjançant la delegació de Kerberos.
  • TRUSTED_FOR_DELEGATION: la Kerberos Unconstrained Delegation està activada per aquest compte d’usuari i els seus serveis. L’atribut SeEnableDelegationPrivilege és necessari si es vol modificar.
  • TRUSTED_TO_AUTH_FOR_DELEGATION: l’extensió de Kerberos S4U2Self està habilitada per aquest compte d’usuari i els seus serveis. L’atribut SeEnableDelegationPrivilege és necessari si es vol modificar.

Altres propietats

Hi ha altres propietats que poden ser molt útils durant un pentest. Pots utilitzar eines com BloodHound per obtenir ràpidament les relacions i propietats dels objectes del domini.

Algunes de les més importants i comuns són:

  • Description: descripció de l’usuari. Et pot donar una idea dels permisos del compte i, a vegades hi ha la contrasenya escrita (molt poques de fet, però pot passar).
  • AdminCount: indica que l’usuari o grup està protegit per l’objecte AdminSDHolder. Degut que a vegades no està actualitzat, només s’utilitza com a referència.
  • MemberOf: indica que un usuari és membre d’un grup.
  • PrimaryGroupID: indica el grup primari d’un usuari. Aquest grup no apareix a la propietat MemberOf.
  • ServicePrincipalName: indica els serveis d’un usuari. Pot ser útil de cara a un atac de Kerberoast.
  • msDS-AllowedToDelegateTo: llistat dels serveis els quals un usuari pot suplantar l’identitat dels clients utilitzant la propietat Kerberos Constrained Delegation. L’atribut SeEnableDelegationPrivilege és necessari.

Usuaris importants

Per consultar els usuaris que hi ha al domini, hi ha diverses opcions com net user /domain o amb Powershell. No has de tenir cap privilegi especial per obtenir el llistat, qualsevol usuari pot fer-ho:

PS C:\Usuaris\Nadki> Get-ADUser -Filter * | select SamAccountName

SamAccountName
--------------
Administrator
Guest
krbtgt
Nadki
test
NADKI$
BCN$

En aquest exemple, el domini és molt petit, però normalment si executes la comanda a una empresa és possible que obtinguis centenars o milers d’usuaris. Per aquest motiu és molt important saber distingir quins són realment importants. Depèn molt de l’empresa, però normalment els membres de l’equip d’IT acostumen a tenir permisos d’administrador per fer la seva feina.

A més a més, usuaris generats pel sistema com Administrator és el compte amb més privilegis del domini. Pot realitzar accions a gaire bé qualsevol ordinador. Per tant, si aconsegueixes comprometre aquest usuari obtindràs control del domini.

Addicionalment, el compte krbtgt és molt important també. Els seus secrets (hash NT i clau Kerberos) s’utilitzen per xifrar els tiquets, específicament els TGTs, utilitzats per Kerberos que permeten autenticar els usuaris. Si aconsegueixes comprometre el comte krbtgt seràs capaç de crear Golded Tickets, que et permetrà accedir a qualsevol recurs del domini sense fer sonar cap alarma.

Comptes d’ordinadors

Un altre punt que has de tenir en compte és que a les empreses, cada persona té el seu usuari i inclús certs treballadors, com els de IT, poden arribar a tenir-ne més d’un per realitzar les seves tasques. A més a més, cada ordinador connectat al domini té el seu propi usuari, ja que també han de poder realitzar certes accions al domini.

La diferència entre els comptes d’usuaris i els dels ordinadors és que els primers s’emmagatzemen com a instancies de la classe User a la base de dades, mentre que els segons s’emmagatzemen com a instàncies de la classe Computer, que és una subclasse de User. A més a més, els comptes dels ordinadors són el hostname de l’ordinador però acabat amb el símbol del dòlar.

Per exemple:

PS C:\> Get-ADObject -LDAPFilter "objectClass=User" -Properties SamAccountName | select SamAccountName

SamAccountName
--------------
Administrator
Guest
DC01$
krbtgt
Nadki
DC02$
WS01$
WS02$
test
nadkipc$
NADKI$
BCN$

També seràs capaç de trobar patrons. De la mateixa manera que els usuaris normalment tenen algun format com nomcognom o nom.cognom, els ordinadors també, com DC01$ i DC02$ pels controladors del domini o WS01$ i WS02$ per les estacions de treball.

L’objecte dels ordinadors guarden altra informació com la versió del sistema operatiu que estan utilitzant. Pots obtenir-la dels atributs OperatingSystem o OperatingSystemVersion.

Per tant, si ets capaç d’entendre i ordenar els diferents formats de noms i ordinadors que utilitza l’empresa, podràs distingir amb facilitat quins comptes són els que tenen més privilegis o poden tenir informació sensible. També pots comprovar altres atributs dels objectes com Description per obtenir més informació. Una eina que et pot ser útil per extreure tota aquesta informació és Powerview.

Relacions de confiança

Et deus haver adonat que hi ha comptes com NADKI$ o BCN$ que apareixen tant amb GetADObject com Get-ADUser, però que acaben amb el símbol del dòlar. Podrien ser un usuari normal, ja que no hi ha cap impediment en crear usuaris amb el símbol $, però normalment serveixen per gestionar les relacions de confiança entre dominis.

Quan una relació de confiança s’estableix, un objecte d’usuari es crea a cada domini per guardar-hi les claus de confiança. El nom de l’usuari és el NetBIOS del nom dels altres dominis, però acabats en $. Per exemple, si hi ha una relació de confiança entre NADKI i BCN, el domini NADKI emmagatzemarà la clau de confiança de BCN a l’usuari BCN$ i BCN guardarà la de NADKI a NADKI$.

Referències

Etiquetes: , , , , , ,

Deixa un comentari