L'histoire commence lorsque l'un de ses amis PFE contacte Tomek sur l'attribut userPassword dont le comportement était particulier sur l'environnement de l'un de ses clients.

Le comportement observé était qu'après certaines opérations sur l'environnement, les objets impactés par celles-ci disposaient de cet attribut contenant le mot de passe utilisateur en clear text... et oui, la connotation password + clear text est plutôt négative pour certains :)

Bien entendu, le fait que le mot de passe était présent ne signifiait pas qu'il était disponible pour tous ceux qui souhaiteraient le lire, il y a toujours des ACLS pour ça, mais le fait qu'il était BIEN PRÉSENT.

Matched DNs:
Getting 1 entries:
>> Dn: CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan
    4> objectClass: top; person; organizationalPerson; user;
    1> cn: jonathan Bismuth;
    1> sn: Bismuth;
    1> userPassword: P@ssw0rd!;

Quoi que vous en pensiez, il n'est pas nécessaire de hurler à la faille et de publier un hack 0day... cette fonctionnalité est attendue comme tel et est le résultat d'un dualisme du comportement de l'attribut userPassword dans l'AD.

L'attribut userPassword

Cet attribut agit différemment suivant qu'il soit écrit ou lut et dépends de plus de la configuration de l'annuaire lui même. En effet, suivant le paramétrage de celui-ci, il peut être traité de deux manières distinctes :
  • un attribut unicode classique, qui peut être lu et écrit comme tout autre attribut unicode.
  • un raccourcis vers le mot de passe utilisateur dans l'annuaire, ce qui autorise les opérations de changement de mot de passe par LDAP.
D'une part, lorsque le domaine est en dessous du niveau fonctionnel Windows 2003 ou à ce niveau dans dsHeuristics, l'atribut n'est qu'un unicode. Il est donc possible d'y lire et écrire. Essayons :

admod -b "CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan" userPassword::P@ssword!!1

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: dc1.pm.lan:389
Directory: Windows Server 2003

Modifying specified objects...
   DN: CN=jonathan Bismuth,OU=test,DC=pm,DC=lan...

The command completed successfully


Donc il est possible de modifier cet attribut... arrive t'on à le lire :

adfind -b "CN=jonathan BISMUTH,OU=Test,DC=pm,DC=lan" -s base userPassword

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: dc1.pm.lan:389
Directory: Windows Server 2003

dn:CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan
>userPassword: 5040 7373 776F 7264 2121 31

1 Objects returned

C'est un succès! Apparemment, nous pouvons donc lire et écrire dans cet attribut. En revanche, ceci n'influe en rien sur le mot de passe de l'utilisateur qui peut être tout autre. Au final, nous avons juste modifié une chaine de caractère.

Les règles du jeu changent en revanche si nous passons le 9eme caractère de dsheuristics à 1 (en théorie, n'importe quel caractère autre que 0 et 2 devrait marcher). L'écriture dans cet attribut se comporte différemment. Après cette modification, userPassword devient "write-only" et n'est plus lisible. Nous pouvons en revanche modifier le mot de passe. essayons :

1- modification de dsHeuristics :

admod -b "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuratio
n,DC=pm,DC=lan" dsHeuristics::000000001

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: dc1.pm.lan:389
Directory: Windows Server 2003

Modifying specified objects...
   DN: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=pm,DC =lan

The command completed successfully


C'est fait, maintenant on retente la même modification qu'auparavant :

admod -b "CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan" userPassword::P@ssword!!1

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: dc1.pm.lan:389
Directory: Windows Server 2003

Modifying specified objects...
   DN: CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan...: [dc1.pm.lan] Error 0x35
(53) - Unwilling To Perform

Ah tiens, une erreur... et pourquoi donc?
En fait, nous venons d'essayer de modifier le mot de passe depuis LDAP et dans AD, ça n'est possible que depuis une connexion SSL. Recommençons donc en LDAPS :

admod -b "CN=jonathan Bismuth,OU=test,DC=pm,DC=lan" userPassword::P@ssword!!1 -ssl -h dc1.pm.lan:636

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: dc1.pm.lan:636
Directory: Windows Server 2003

Modifying specified objects...
   DN: CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan...

The command completed successfully

Marche mieux non? Reste à arriver à lire ce fameux attribut :

adfind -b "CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan" -s base userPassword

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: dc1.pm.lan:389
Directory: Windows Server 2003

dn:CN=jonathan Bismuth,OU=Test,DC=pm,DC=lan

1 Objects returned

Rien n'apparait, étonnant non? OK... non. On peut ne conclure qu'avec les droits adéquats sur un compte user, on peut modifier le mot de passe, mais bien évidemment pas le lire à la suite.

Le problème

Le soucis apparait du fait du comportement de l'outil KTPASS (globalement, un outil qui permet la création de keytab, des fichiers utilisés depuis des machines UNIX/LINUX afin de s'authentifier en Kerberos avec un AD).

Donc, dans le cas ou KTPASS a été utilisé pour un compte pour lequel aucune modification de dsHeuristics n'a été faite sur l'annuaire, le mot de passe appliqué avec KTPASS est disponible a la lecture avec LDAP. Si l'on essaye de générer un nouveau keytab pour un compte et que l'on spécifie un mot  de passe :

ktpass -princ HOST/ubuntu.pm.lan@pm.lan -mapuser ubuntu$@pm.lan -ptype KRB5_NT_SRV_HST -mapop set -pass P@ssw0rd1 -out ubuntu.keytab

(…)

Reset UBUNTU$'s password [y/n]?  y
Key created.
Output keytab to ubuntu.keytab:
Keytab version: 0x502
keysize 60 HOST/ubuntu.pm.lan@pm.lan ptype 3 (KRB5_NT_SRV_HST) vno 2 etype 0x17
(RC4-HMAC) keylength 16 (0xae974876d974abd805a989ebead86846)

Ensuite, avec ADFIND :

adfind -b "CN=ubuntu,OU=Test,DC=pm,DC=lan" -s base userPassword

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server:dc1.pm.lan:389
Directory: Windows Server 2003

dn:CN=ubuntu,OU=Test,DC=pm,DC=lan
>userPassword: 5040 7373 7730 7264 31

Nous voyons que userPassword est peuplé, et si vous vérifiez sa valeur, il s'agira de la valeur stipulée avec KTPASS. Le phénomène se reproduira de la même manière avec n'importe quel outil qui utilise LDAP pour changer ou remettre à zéro le mot de passe utilisateur.

Si nous modifions le comportement du dsHeuristics, userPassword ne contiendra bien entendu aucune trace du mot de passe sous forme lisible.

Solution

Que dire de plus?  Il n'y a pas de recette miracle, dans la mesure où il ne s'agit pas d'un problème mais d'un comportement standard.
Le meilleur moyen de savoir si vous êtes concernés est de vérifier le comportement attendu et de corriger celui-ci, que ce soit par la modification de dsHeuristics, ou en instaurant des règles et bonnes pratiques quant à l'utilisation des outils qui utilisent LDAP pour modifier les mots de passe, histoire de ne pas provoquer... d'"accidents".
Bien entendu et pour rappel, les ACLs sont là pour protéger à minima ce type d'attributs, mais les explications seront assez compliquées à donner quant au POURQUOI CE MOT DE PASSE EST LA. Maintenant vous avez quelques arguments :)

Source : Tomek's DS World