Archives par mot-clé : debug

Symboles Microsoft

Publié le par
1

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

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