Re – re – re – pass the pass (word)


homer
Certains tendent le bâton… :(

Fournir aisément à autrui, par ses dires ou son comportement, l’occasion, la raison ou le simple prétexte de se faire blâmer, condamner ou punir.


Après le dernier billet sur « re – re – pass the pass » et…

  • l’absence de réaction (oui, cela a été rapide :)
  • une bonne question

… voici la suite !

Le provider

Cette fois ci nous avons le provider Kerberos ! Son fonctionnement par ticket n’impose normalement pas la réutilisation des mot de passe en clair.
Cf. une explication rapide de Microsoft : http://technet.microsoft.com/en-us/library/bb742516.aspx
kerberos par MS

Ce qui est dommage, c’est qu’une fois de plus des mots de passe sont encore conservés dans la mémoire du processus LSASS (en particulier à partir de NT 6).
mimikatz_vs_kerberos

Téléchargement et fonctionnement

Une mise à jour de mimikatz existe, mais elle n’est toujours pas disponible en téléchargement… (merci à nos amis éditeurs antivirus et Microsoft qui choisis de blacklister plutôt que d’améliorer ses processus)
Plus de release avant fin mai

A exécuter après avoir obtenu des droits administrateurs (ou system) :

privilege::debug
inject::service samss sekurlsa.dll
@getLogonPasswords full

La commande privilege::debug n’est pas obligatoire si vous êtes déjà system.
(plus d’information : http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa#getLogonPasswords et http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa/kerberos)

Nouvelles commandes (si besoin de séparation) :

@getMSV
@getTsPkg
@getWDigest
@getLiveSSP
@getKerberos

@getLogonPasswords utilise les providers disponibles et connus par mimikatz.

Améliorations

  • ne garder que kerberos, msv1_0 et schannel dans la liste des providers autorisés (se référer au billet d’origine sur « pass the pass »)
    Utiliser Kerberos uniquement avec des Tokens et Cartes à puce (sans délégation)
    ils sont essentiels au fonctionnement des services Windows
  • demander à Microsoft la validité de ce mode de fonctionnement avec un minimum de provider (je n’y crois vraiment plus…)

Re – re – pass the pass (word)


maggie_incas
Toute ressemblance avec un billet précédent est malheureusement normale :(
Je ne pense pas que Microsoft change sa philosophie de gestion du SSO dans un avenir très proche…


Après le dernier billet sur « re – pass the pass » et…

  • les réactions positives de certains (Espagnols, Américains, Russes et Chinois)
  • les réactions étranges d’autres : Microsoft & Amplia Security (ça faisait juste quasi un an que je l’avais présenté…)
  • Windows 8 en approche

… voici la suite !

Le provider

Cette fois ci nous avons le provider LiveSSP qui, dans Windows 8, permet de se connecter avec son compte Microsoft Live (avec tout de même un petit cache dans la SAM locale en cas d’indisponibilité d’Internet ou des services Live).

mimikatz_vs_livessp

Remarques :

  • un compte Live est utilisé avec les providers :
    • msv1_0
    • tspkg
    • livessp
  • un compte non Live est utilisé avec les providers :
    • msv1_0
    • wdigest
    • tspkg

Téléchargement et fonctionnement

Une mise à jour de mimikatz existe, mais elle n’est pas encore disponible en téléchargement… (merci à nos amis éditeurs antivirus et Microsoft qui choisis de blacklister plutôt que d’améliorer ses processus)
Plus de release avant fin mai

A exécuter après avoir obtenu des droits administrateurs (ou system) :

privilege::debug
inject::service samss sekurlsa.dll
@getLogonPasswords full

La commande privilege::debug n’est pas obligatoire si vous êtes déjà system.
(plus d’information : http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa#getLogonPasswords et http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa/livessp)

Nouvelles commandes (si besoin de séparation) :

@getMSV
@getTsPkg
@getWDigest
@getLiveSSP

@getLogonPasswords utilise les providers disponibles et connus par mimikatz.

Améliorations

  • ne garder que kerberos, msv1_0 et schannel dans la liste des providers autorisés (se référer au billet d’origine sur « pass the pass »)
    ils sont essentiels au fonctionnement des services Windows
  • demander à Microsoft la validité de ce mode de fonctionnement avec un minimum de provider (je n’y crois vraiment plus…)

Re – pass the pass (word)

Après le dernier billet sur « pass the pass » et…

  • les réactions positives de certains
  • les réactions étranges d’autres
  • une incitation très forte de newsoft à fouiller ma mémoire vive ;)

… voici la suite !

Le provider

Il n’y a pas que le provider TsPkg qui « doit » conserver une copie du mot de passe de session en clair ; le provider WDigest avait le même comportement bien avant l’apparition de TsPkg (et il l’a toujours…)

Problème

Bien que je n’ai jamais rencontré de véritable architecture reposant sur une authentification Digest et n’ayant toujours pas autorisé Windows à conserver mon mot de passe en clair, celui-ci se retrouve encore une fois en mémoire :
mimikatz_vs_wdigest

Téléchargement et fonctionnement

Une mise à jour de mimikatz, toujours en version « alpha », pour l’occasion :

Attention, cette version de mimikatz reste toujours en « alpha »…

A exécuter après avoir obtenu des droits administrateurs (ou system) :

privilege::debug
inject::process lsass.exe sekurlsa.dll
@getLogonPasswords

La commande privilege::debug n’est pas obligatoire si vous êtes déjà system.
(plus d’information : http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa#getLogonPasswords et http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa/wdigest)

Nouvelles commandes (si besoin de séparation) :

@getMSV
@getTsPkg
@getWDigest

@getLogonPasswords utilise les providers disponibles et connus par mimikatz.

Améliorations

  • ne garder que kerberos, msv1_0 et schannel dans la liste des providers autorisés (se référer au billet d’origine sur « pass the pass »)
    ils sont essentiels au fonctionnement des services Windows
  • demander à Microsoft la validité de ce mode de fonctionnement avec un minimum de provider

Pass the pass (word)

Il arrive que j’ai le temps de lire les technet de Microsoft…, j’aurais du le faire beaucoup plus tôt !

Si vous utilisez beaucoup le bureau à distance, vous aurez déjà découvert RDCMan :

Si vous êtes un aficionados, vous n’aurez pas manqué le SSO pour bureau à distance, qui permet d’éviter de rentrer ses identifiants lors d’une connexion :

(dans les commentaires du blog MSDN, on trouve aussi les options particulières pour activer ce mode sous Windows XP SP3 et envers les serveurs non NLA et sans TLS)
Ceci fonctionne très bien vers toutes les machines basées sur NT 6 depuis des machines NT 6 ! (ou XP SP3 avec le nouveau fournisseur de sécurité RDP installé) (c’est déjà ça ;))

Sans trop chercher à comprendre le fonctionnement, j’ai tout de suite voulu tester les fonctionnalités « pass-the-hash » de mimikatz sur une connexion bureau à distance….
Sans succès :(, la connexion continue à s’effectuer avec les identifiants virtuels de mimikatz… c’est donc que ce SSO fonctionne avec un « système » autre que nos hashs préférés, a priori directement notre mot de passe courant !
Ces fonctionnalités de SSO utilisent, entre autres, un SSP (security support provider) dans LSA (Local Security Authority) : tspkg

Le provider

Ce provider n’est pas sans nous rappeler msv1_0 qui, au fil des versions, continue de nous faire profiter de quelques fonctions amusantes :

NlpGetPrimaryCredential    ; GetPrimaryCredential
NlpAddPrimaryCredential    ; AddPrimaryCredential
NlpDeletePrimaryCredential ; DeletePrimaryCredential

Pour rappel, ces fonctions permettent de récupérer les hashs LM et NTLM d’une connexion existante en fonction de l’identifiant, puis de le manipuler (réinjecter par exemple)….
rien de nouveau, c’est déjà dans mimikatz 0.x, et c’est fort amusant

Notre nouvelle librairie préférée dispose d’une fonction très sympathique elle aussi :

TSCredTableLocateDefaultCreds
*TSObtainClearCreds

* dans certains cas

  • TSCredTableLocateDefaultCreds ; retourne une structure permettant de pointer vers les identifiants et le mot de passe « obfusqué » en fonction de l’identifiant de connexion
  • TSObtainClearCreds ; a été une bonne piste de départ, cette fonction retourne la structure finale avec le mot de passe en clair (!), en réalité cela repose sur : LsaUnprotectMemory

Problème

Ce provider est actif par défaut sous les NT 6 ! Et le stockage des mots de passe est effectué même si le SSO n’est pas activé !

pass-the-pass

Téléchargement et fonctionnement

Une livraison de mimikatz en version « pre-alpha » pour l’occasion :

(plus d’information : http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa#getLogonPasswords et http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa/tspkg)

Petite parenthèse pour les Windowsiens prudents (Aurélien C), il faut faire attention à débloquer le fichier téléchargé, sinon les fichiers décompressés auront du mal à fonctionner :

Les fonctions évoqués plus hauts, ne sont bien sûr disponibles que sur les systèmes NT 6 ! (ou XP SP3 sur lequel le provider tspkg aurait été activé)

A exécuter après avoir obtenu des droits administrateurs (ou system) :

privilege::debug
inject::process lsass.exe sekurlsa.dll
@getLogonPasswords

La commande privilege::debug n’est pas obligatoire si vous êtes déjà system.

Améliorations

par ordre d’importance

  1. étudier une authentification SSO RDP sans mot de passe en clair (avec un challenge/response par exemple)
  2. ne pas stocker directement un mot de passe avec comme seule protection réversible LsaProtectMemory (ça fait stagiaire étudiant)
  3. rendre le stockage de données de connexion dépendant de la stratégie SSO
  4. stratégie devant être au niveau utilisateur, pas au niveau machine… les identifiants appartiennent à un utilisateur, pas à une machine…

En attendant, il est URGENT de retirer le provider tspkg… surtout si vous n’utilisez pas le SSO du RDP !

Pour cela, il faut passer par le registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, valeur Security Packages et enlever seulement la ligne tspkg

ssp_tspkg
et redémarrer…