gentilkiwi @ AfterWork OSSIR Février 2013

OSSIR-Logo

news0ft m’a offert une tribune sympathique pour présenter mimikatz.
Je serais donc présent à l’AfterWork de l’OSSIR ce Mardi 26 Février à partir de 19h30.

En dehors du plaisir d’y rencontrer une riche communauté, j’y évoquerai le fonctionnement de la récupération de données sensibles dans Windows via mimikatz, tout cela en une petite demi-heure.

Se passant au Café Six, les questions supplémentaires se feront autour d’un verre !

Informations :

mimikatz @ sekurlsa : Credman et le planificateur de tâches

Vendredi soir, mgrzeg (http://zine.net.pl/blogs/mgrzeg/) m’a posé une petite colle sur les mots de passe associés à des tâches planifiées :

22:27 – Michal: Have you ever tried to recover passwords for scheduler tasks?

Et bien non ! Je pensais naïvement que beaucoup d’outils permettaient déjà de récupérer les mots de passe de tâches planifiées… mais, à part une version historique pour NT5 d’Ivan (http://www.ivanlef0u.tuxfamily.org/?p=173), rien de bien précis dans le paysage des outils pour les versions actuelles de Windows…

penguins_ho

Recherches

Créons une petite « Tâche de test » associée au compte de « Gentille Tâche »
gentilletache

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Tâche de test"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Tâche de test
    Id    REG_SZ    {B0261D58-1302-40C8-A547-3AFD8F76BB4C}
    Index    REG_DWORD    0x3

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{B0261D58-1302-40C8-A547-3AFD8F76BB4C}"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{B0261D58-1302-40C8-A547-3AFD8F76BB4C}
    Path    REG_SZ    \Tâche de test
    Hash    REG_BINARY    913E7022936A887F6CA5DD1C5BCAF21BCB7B8A120FA1551CCB19DBC7EC10D93D
    Triggers    REG_BINARY    150000000000000000F3A401A4F76772FFFFFFFFFFFFFFFF00F3A401A4F7677200000000000000002821440048484848EA0DE31E484848480048484848484848004848484848484801000000484848481C000000484848480105000000000005150000003C07DD79702A63251C051BB6E903000048484848360000004848484876006D002D00770037002D0075006C0074005C00470065006E00740069006C006C00650020005400E2006300680065000000000000004848380000004848484800000000FFFFFFFF80F40300FFFFFFFF0700000000000000000000000000000000000000000000000000000018A20F010000000000000000

Vous l’aurez sans aucun doute reconnue :

vm-w7-ult      | 76 00 6D 00 2D 00 77 00 37 00 2D 00 75 00 6C 00 74 00
\              | 5C 00
Gentille Tâche | 47 00 65 00 6E 00 74 00 69 00 6C 00 6C 00 65 00 20 00 54 00 E2 00 63 00 68 00 65 00
<NULL>         | 00 00 
<NULL><NULL>   | 00 00 00 00

Cela tombe bien, il y a une référence à son SID (S-1-5-21-2044528444-627255920-3055224092-1001) pas très loin :

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\CredWom\S-1-5-21-2044528444-627255920-3055224092-1001"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\CredWom\S-1-5-21-2044528444-627255920-3055224092-1001
    Count    REG_DWORD    0x1
    Index    REG_SZ    {55DEDD5A-70DE-49AC-98C2-9D86B9A437FA}

Point de mot de passe… mais un GUID très utile…, le planificateur de tâche va appeler :
CredMarshalCredential avec :

  • CredType : UsernameTargetCredential
  • Credential : TaskScheduler:Task:{55DEDD5A-70DE-49AC-98C2-9D86B9A437FA}

… et se servir du résultat pour appeler LogonUser puis CreateProcessAsUser.

Explications

UsernameTargetCredential

Specifies that the credential is a reference to a CRED_FLAGS_USERNAME_TARGET credential described by a USERNAME_TARGET_CREDENTIAL_INFO structure.

Il s’avère donc que les comptes associés aux tâches planifiées sont enregistrés dans le « Gestionnaire d’identification » de SYSTEM.
Cohérent, puisque le planificateur de tâches fonctionne en tant que service local, même si la session de l’utilisateur ayant créé la tâche, ou ciblée par la tâche, est fermée.

Test

Qu’à cela ne tienne, mimikatz permet de dumper les différents éléments du gestionnaire d’identification de NT6 via : divers::secrets full

En ayant obtenu un mimikatz « SYSTEM » :

mimikatz # divers::secrets full
Nombre de secrets : 1
TargetName         : Domain:batch=TaskScheduler:Task:{55DEDD5A-70DE-49AC-98C2-9D86B9A437FA} / <NULL>
Type               : DOMAIN_PASSWORD (2)
Comment            : <NULL>
UserName           : vm-w7-ult\Gentille Tâche
Credential         : <NULL>

Damn, pas de mot de passe ici :(

mario_princess-in-another-castle

If the Type member is CRED_TYPE_DOMAIN_PASSWORD, this member contains the plaintext Unicode password for UserName. The CredentialBlob and CredentialBlobSize members do not include a trailing zero character. Also, for CRED_TYPE_DOMAIN_PASSWORD, this member can only be read by the authentication packages.

La solution sera donc plus générale que pour les mots de passe de tâches planifiées…, en effet la catégorie CRED_TYPE_DOMAIN_PASSWORD englobe aussi les credentials pré-enregistrés de lecteurs , de partages ou RDP…

A voir dans un prochain post ;)

Bonus

Dans le contexte de l’utilisateur ayant créé la tâche planifiée (et donc inacessible à SYSTEM si session fermée…) :

mimikatz # divers::secrets full
Nombre de secrets : 1
TargetName         : LegacyGeneric:target=VM-W7-ULT\Gentille Tâche / <NULL>
Type               : GENERIC (1)
Comment            : <NULL>
UserName           : VM-W7-ULT\Gentille Tâche
Credential         : wazawaza12341234//

Mais là, je ne vois pas la raison de sa présence… c’est le moteur du planificateur de tâche qui a besoin des credentials, pas l’utilisateur d’origine… (?)

gentilkiwi @ Application Security Forum 2012

asfws
Je me suis laissé pousser à proposer une présentation à l’Application Security Forum – Western Switzerland 2012.
J’ai la chance d’avoir été invité à présenter mes travaux sur mimikatz !

J’y exposerai bien sûr mimikatz mais plus particulièrement les modules sekurlsa et crypto
slide
Les participants comprendront rapidement comment récupérer des mots de passe Windows et des certificats/clés privées !

Attention : les participants du premier rang pourraient apercevoir des mots de passe et des clés…

En dehors de ma présentation (le 07 Novembre à 11h40), j’assisterai à un maximum de conférences d’experts : http://2012.appsec-forum.ch/programme/.
N’hésitez pas à faire de même et à venir me faire un petit coucou :)

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

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