Archives par mot-clé : ace

mimikatz :: sekurlsa et le privilège « debug »

Publié le par
Répondre

Le module sekurlsa récupère les hashes et mots de passe en clair depuis le processus système : LSASS.

Si vous n’étiez pas SYSTEM, il convenait de demander le privilège SeDebugPrivilege.
Mais pourquoi ? de quoi avons-nous besoin ?

  • lire des données dans le processus LSASS
  • la liste des modules chargés dans LSASS (nom, adresse de base et taille)

La théorie

Nos besoins nécessitent les droits suivants :

  • PROCESS_VM_READ ; pour lire des données dans le processus LSASS
  • PROCESS_QUERY_INFORMATION ; pour obtenir le PEB du processus LSASS et ainsi par PEB->PPEB_LDR_DATA->LDR_DATA_TABLE_ENTRY : la liste des modules chargés

Voici la DACL du processus LSASS sous Windows 7 pour les membres du groupe Administrateurs :

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x18
->Dacl    : ->Ace[1]: ->Mask : 0x00121411
->Dacl    : ->Ace[1]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrateurs)

Correspondant ainsi à :

  • READ_CONTROL
  • SYNCHRONIZE
  • PROCESS_QUERY_LIMITED_INFORMATION
  • PROCESS_QUERY_INFORMATION
  • PROCESS_VM_READ
  • PROCESS_TERMINATE

Nous y retrouvons PROCESS_VM_READ et PROCESS_QUERY_INFORMATION, donc a priori pas de problème ?

La pratique

Hormis pour certaines personnes maitrisant les structures de type PEB, la fonction utilisée pour obtenir les modules d’un processus est : CreateToolhelp32Snapshot.

Cette fonction permet d’énumérer, via la structure…

typedef struct tagMODULEENTRY32 {
  DWORD   dwSize;
  DWORD   th32ModuleID;
  DWORD   th32ProcessID;
  DWORD   GlblcntUsage;
  DWORD   ProccntUsage;
  BYTE    *modBaseAddr;
  DWORD   modBaseSize;
  HMODULE hModule;
  TCHAR   szModule[MAX_MODULE_NAME32 + 1];
  TCHAR   szExePath[MAX_PATH];
} MODULEENTRY32, *PMODULEENTRY32;

…, l’ensemble des modules associés à un processus (via son PID)

Chouette, une fonction qui va simplifier les opérations d’ouverture et de lecture à travers le processus LSASS !

mimikatz # process::list
PID     PPID    #Ths    pri     image
    0       0       2       0   [System Process]
    4       0     100       8   System
...
  592     460       7       9   lsass.exe
...

mimikatz # process::modules 592
mod_process::getModulesListForProcessId ; (0x00000005) Accès refusé.

Résultat : Accès refusé ! Nous savons obtenir les droits nécessaires, alors pourquoi ?

CreateToolhelp32Snapshot(TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32, ...) #fail

Allons voir de plus près les appels effectués par cette fonction…

  • kernel32!CreateToolhelp32Snapshot
  • kernel32!_ThpCreateRawSnap
  • ntdll!RtlQueryProcessDebugInformation (#wtf?)
  • ntdll!ZwOpenProcess … avec PROCESS_ALL_ACCESS !
  • …

Pas étonnant que l’accès nous soit refusé !
Malgré des droits restreints clairement identifiés pour énumérer les modules, la fonction CreateToolhelp32Snapshot nécessitera un accès complet au processus cible LSASS.
Quel bel exemple de demande des droits minimums nécessaires !

Précédemment, mimikatz demandait systématiquement le privilège debug afin de passer cette étape… quel gâchis !

Finalement, mod_process::getVeryBasicModulesListForProcess a été écrite, énumérant les modules via le PEB du processus.

Résultat

Cette nouvelle fonction est maintenant utilisée dans sekurlsa.

Windows NT 5

mimikatz 1.0 x86 (RC)   /* Traitement du Kiwi (Aug  4 2012 03:10:51) */
// http://blog.gentilkiwi.com/mimikatz

mimikatz # sekurlsa::logonPasswords full

Authentification Id         : 0;73296818
Package d'authentification  : Kerberos
Utilisateur principal       : gentilkiwi
Domaine d'authentification  : NIRVANA
       ...

Une réussite !

Windows NT 6

mimikatz 1.0 x64 (RC)   /* Traitement du Kiwi (Aug  4 2012 03:12:34) */
// http://blog.gentilkiwi.com/mimikatz

mimikatz # sekurlsa::logonPasswords full
OpenProcess : (0x00000005) Accès refusé.

#fail, mais pourquoi ? cela fonctionne sous NT 5 et nous nous limitons ici à un accès réduit sur un processus sur lequel nos deux droits sont normalement autorisés ?

Réponse : Mandatory Integrity Control (http://msdn.microsoft.com/library/windows/desktop/bb648648.aspx
Cette fonctionnalité, disponible à partir de NT 6, rajoute des informations dans la SACL des objets.

Regardons la SACL du processus LSASS sous Windows 7 :

->Sacl    : ->Ace[0]: ->AceType: SYSTEM_MANDATORY_LABEL_ACE_TYPE
->Sacl    : ->Ace[0]: ->AceFlags: 0x0
->Sacl    : ->Ace[0]: ->AceSize: 0x14
->Sacl    : ->Ace[0]: ->Mask : 0x00000003
->Sacl    : ->Ace[0]: ->SID: S-1-16-16384 (Label: Étiquette obligatoire\Niveau obligatoire système)

Ouch, à moins de provenir d’un autre processus de niveau minimum ML_SYSTEM, le flag 0x00000003 nous interdira lecture et écriture, quoi qu’en dise la DACL…
En effet, ce 0x00000003 signifie :

  • SYSTEM_MANDATORY_LABEL_NO_WRITE_UP
  • SYSTEM_MANDATORY_LABEL_NO_READ_UP

Les noms sont équivoques…

Conclusion

  • Nous pouvons nous en sortir sous NT 5 sans utilisation de privilège !
  • Sous NT 6 point de salut sans privilège(s), que ce soit debug ou même security pour modifier les ACL…

Quoi qu’il en soit, sekurlsa fonctionne maintenant avec des droits réduits sur LSASS, cela évitera sans doute de déclencher quelques HIPS ;)
La version prenant en charge cette nouvelle fonction est disponible : http://blog.gentilkiwi.com/mimikatz