Réflexions post-SSTIC

Mise à jour du 7 août : Damien Aumaitre m'a contacté pour me dire que sa technique n'a rien de secrète. Du coup je publie la réponse complète :)

Et oui le SSTIC 2008, à l'échelle numérique, ça semble déjà appartenir au paléolithique ...

Mais voici deux questions issues de cette conférence auxquelles j'ai réfléchi par la suite:

1. Concernant l'extension Firefox malicieuse présentée en Rump Session, et dont le code n'a pas été diffusé (à ma connaissance), je suis tombé là dessus par hasard en lisant le dernier Hackers News Magazine (fear).

2. Concernant la modification de la base de registre permettant de contourner l'authentification Windows, présentée pendant la conférence de Damien Aumaitre, voici quelques explications.

Tout d'abord il faut savoir sous Windows que les comptes locaux sont gérés dans la base SAM. Cette base est visible dans la base de registre, les clés qui nous intéressent étant:
HKLM\SECURITY\SAM\Domains\Account\Users\

(Ces clés ne sont visibles que pour le compte SYSTEM par défaut, il vous faudra changer les permissions pour y avoir accès).

Ces clés contiennent deux valeurs binaires mystérieuses: F et V. En regardant SAMSRV.DLL (avec les symboles de débogage), on se rend compte que ces clés sont nommées en interne _SampFixedAttributeName et _SampVariableAttributeName, ce qui est un peu plus explicite.

Parmi les quelques fonctions qui référencent ces chaines, on trouve la fonction CreateUser() qui permet de reconstituer l'essentiel de la structure de ces clés.

La structure F est de la forme:
ULONG version;
ULONG unk1;
time_t LastLogon;
time_t LastLogoff;
time_t LastPasswordSet;
time_t ExpirationDate;
time_t LastPasswordFailed;
ULONG uid;
ULONG gid;
ULONG options;
// différents compteurs (ex. login attempts) ?
USHORT unk2;
USHORT unk3;
[...]

Rien d'intéressant a priori. La structure V est un peu plus complexe, puisque de taille variable. Elle commence par une liste de structures de type:
ULONG offset;
ULONG length;
ULONG additional_data; // souvent zéro

Puisque viennent les données proprement dites, comme le nom d'utilisateur, la description du compte, les hashes (chiffrés), etc.

La manipulation de la SAM est effectuée par des API telles que RtlAddAttributeActionToRXact(), RtlAddActionToRXact(), RtlApplyRXact(). Ces API garantissent que la modification de la base de registre, et donc la création du compte, s'effectuera de manière unitaire.

Inutile d'aller plus loin dans l'analyse, puisque tout est documenté sur ce site (attention, la mise en page pique un peu les yeux* :). Voici les liens directs vers la clé F et la clé V.

[*] Pas autant qu'un post d'Ivanlef0u, mais presque.

Dans mon souvenir, la manipulation consistait à remplacer un octet 0x14 par un octet 0x04 dans la clé V. Echec.

En fait, l'auteur me signale qu'il faut remplacer les deux valeurs aux offsets 0xA0 et 0xAC, ce qui a pour effet de dire au système que les hashs LM et NTLM sont de longueur nulle. Et là, "ça marche chez moi" (Windows XP SP2 FR / Workgroup / Fast User Switching).

PS. Je me demande bien à quoi sert la fonction _SampFixBug18471()

PPS. Inutile de paniquer sur la présence d'une variable globale _SampSecretEncryptionEnabled, c'est juste pour dire que SYSKEY est activé.