Décodeur de crédentiel C-Ark

Outil d'exploitation pour CVE-2021-31796
Un outil pour décoder les fichiers de crédentiel C-Ark

Par : Aaron Mizrachi - https://twitter.com/unmanarc/
Enrique Vaamonde - https://twitter.com/_ejvm
Première version : 2/Sep/2019
Divulgation : 11/Oct/2021

Références

Divulgation responsable :

Cette vulnérabilité était en attente de publication depuis septembre 2019.

Et... voici la chronologie :

2019-08-1x Lors d'un exercice, notre équipe a découvert et signalé au représentant local du fournisseur une faiblesse cryptographique potentielle dans certaines méthodes de stockage de crédentiels utilisées.
2019-08-30 Jusqu'à cette date, nous n'avions qu'une preuve de concept en mémoire avec "ollydbg" utilisant leurs propres outils. Nous essayions de démontrer comment cela pouvait devenir un vecteur d'attaque dans certaines situations spécifiques, mais nous n'avons pas réussi à convaincre. Nous avons donc décidé de coder cette preuve de concept pour avoir un argument plus évident.
2019-09-02 Nous avons implémenté avec succès le hachage et l'algorithme cryptographique dans notre propre preuve de concept (totalement indépendante du produit).
2019-09-03 Nous avons annoncé nos résultats au fournisseur et notre intention de les rendre publics.
2019-09-20 Nous avons reçu une demande du fournisseur de retarder la publication publique jusqu'à ce que le problème soit corrigé.
2020-05 Nous les avons recontactés pour obtenir l'autorisation de publier l'outil et avons échangé quelques courriels indiquant qu'ils n'étaient pas prêts.
2021-09/2021-10 Nous avons constaté que d'autres chercheurs non liés avaient également récemment découvert et divulgué publiquement la même vulnérabilité, et de ce fait... nous avons finalement (après 2 ans !) reçu l'autorisation du fournisseur de partager avec vous nos résultats et notre outil de preuve de concept pour exploiter la faiblesse cryptographique de CreateCredFile.

Utilisation potentielle :

Lors d'un test d'intrusion, si quelqu'un est assez intelligent pour atteindre le PSM et obtenir accidentellement accès au CredFile, il peut potentiellement utiliser ce fichier pour établir une connexion au Vault et prendre le contrôle total...

Pour contrer cela, la plupart des fichiers de crédentiels imposent certaines "restrictions" pour éviter que le mot de passe soit utilisé dans un environnement/ordinateur différent (par exemple, le propre PSM du pirate).

Cependant, ces restrictions peuvent être modifiées si vous effectuez un reverse engineering et obtenez la partie brute de la clé. Cette partie de clé déchiffrée peut être utilisée pour recréer un autre fichier avec d'autres paramètres de "sécurité" (par exemple, un autre hôte, une autre application, un autre utilisateur OS).

Mode de fonctionnement

Pour générer la clé de déchiffrement brute AES-256 (32 octets), nous prenons une paire de SHA1SUM du champ de crédentiel "AdditionalInformation" en ajoutant "0x00000000" et "0x00000001" pour chaque hachage ; le premier hachage fournit les 20 premiers octets de la clé, et le second uniquement les 12 derniers octets.

S'il existe des restrictions environnementales (comme IP/Hôte/chemin d'exécution/...), nous préfixons chaque valeur en clair à AdditionalInformation avant de prendre les deux SHA1SUM.

Il est important de mentionner que le champ "ClientApp" est transformé avec BASE64(SHA1SUM(strlower(ClientApp))) avant d'être préfixé à "AdditionalInformation" et de générer les deux SHA1SUM.

Le déchiffrement est effectué à l'aide de la fonction OpenSSL AES-256-CBC en utilisant le champ Password ou NewPassword. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

Nous utilisons (verificationflags-16) pour déterminer quelle validation/restriction est en place :

usingClientApp      = ((uVerificationsFlag&0x1) != 0);
usingAppPath        = ((uVerificationsFlag&0x2) != 0);
usingClientIP       = ((uVerificationsFlag&0x4) != 0);
usingOSUser         = ((uVerificationsFlag&0x8) != 0);
usingClientHostname = ((uVerificationsFlag&0x20) != 0);

et dans le cas où certaines restrictions ne sont pas affichées dans le fichier de crédentiel en sortie, vous pouvez toujours les introduire manuellement. Je pense que nous pouvons tous deux convenir que ni "chemin d'application" ni "IP client" n'est une valeur véritablement aléatoire.

Atténuation :

Utilisez le HSM \o/, ne stockez pas la clé de déchiffrement dans le fichier cred.

Compilation :

qmake . 
make -j8

CACredDecoder

Populaires