Reverse Engineering d’une application WinDev v16

Reverse Engineering d’une application WinDev v16

Après une longue période de vacances, voici un nouvel article sur notre blog.

Cela fait un moment que l’on n’a pas parlé de Reverse Engineering sur le blog, il est temps d’y remédier.

Aujourd’hui nous allons nous intéresser aux applications Windev que nous avons découvertes lors d’un audit. WinDev est un langage de développement développé par PcSoft, société Française.

L’objet de cet article concerne plus précisément l’outil WDModfic.exe qui a pour objectif de modifier les fichiers d’analyse d’une application WinDev et qui est embarqué avec toute application WinDev.

Il est important de savoir que WinDev utilise 2 grands types de fichiers :

  • Un fichier d’analyse permettant de décrire la structure des fichiers de données
  • Les fichiers de données eux-mêmes

Le but de ce Reverse est d’arriver à prendre la main sur les fichiers de données de l’application protégés par une couche de chiffrement supplémentaire basée sur un mot de passe paramétré directement dans WinDev. Ce mot de passe est souvent identique à celui configuré sur le fichier d’analyse de l’application WinDev (en tout cas dans les applications WinDev que l’on a audité)

Le processus d’attaque est le suivant :

  1. Téléchargement de l’outil wdmodfic.exe
  2. Reverse Engineering de ce dernier
  3. Découverte de la vulnérabilité
  4. Extraction du mot de passe embarqué dans l’outil wdmodfic.exe
  5. Récupération des données contenues dans les fichiers de données dans le cas ou le mot de passe du fichier d’analyse est le même que celui du fichier de données

Ceci permet donc via un utilitaire WinDev disponible librement de prendre le contrôle de n’importe quelle application développée sous WinDev.

Attention ceci n’est valable que pour la version 16 de WinDev (qui est plutôt récente et datant de Juin 2011). Nous n’avons pas réalisé le test sur WinDev 17

Retour sur la technologie Windev :

Une application développée via WinDev est composée de plusieurs éléments. L’application elle-même (souvent un exécutable compilé), des fichiers .fic (HyperFileSQL) contenant notamment les données de l’application, les dll Windev ainsi que différents outils pour faciliter le travail du développeur. C’est sur un de ces outils que nous allons nous attarder.

Le chiffrement est réalisé sur plusieurs couches :

  1. Au niveau des communications entre le client et le serveur
  2. Au niveau des fichiers de données .fic par l’intermédiaire d’un mot de passe supplémentaire non connu et embarqué directement dans les DLL de WinDev

Nous verrons que via notre attaque, ces 2 sécurités seront contournées

Au niveau du chiffrement, la documentation windev précise qu’elle gère trois types de chiffrement, RC5_12, RC5_16 et un chiffrement rapide. On y reviendra par la suite.

 

 

Du coté des principales DLL utilisées on retrouve :

  • WD160VM.DLL : La « machine virtuelle » qui exécute le langage Windev (WLangage)
  • WD160OBJ.DLL : Gère principalement la création des objets de l’interface graphique.
  • WDMOD160.DLL : D’après ce que nous avons compris cette dll à l’air de coordonner les autres DLL, telle que les chargements de tous les modules.
  • WD160HF.DLL : Cette dll est la plus intéressante pour nous, en effet elle se charge des modifications des fichiers HyperFileSQL ainsi que du chiffrement et déchiffrement des fichiers HyperFileSQL.

 

L’application WDModfic.exe :

 

Comme nous l’avons dis plus haut, Windev possède différents outils permettant de simplifier la vie du développeur ; WDModfic.exe en fait partie. Elle a pour objectif de modifier les fichiers de données de l’application.

L’interface de cet outil est tout ce qu’il y a de plus commun. On retrouve une page de bienvenue puis l’interface de chargement du fichier qui définit la structure de la base (fichier d’analyse .WDD).

 

On arrive ensuite sur la page permettant de spécifier le mot de passe de déchiffrement du fichier .wdd. Chose importante, l’authentification  à l’air de fonctionner même quand l’on n’ai pas connecté en réseau.

Le mot de passe a donc l’air d’être stocké dans les fichiers de Windev.

 

Comme vous l’aurez deviné l’objectif de ce papier va être de trouver un moyen de trouver le mot de passe de l’application.

 

Reversing de WDModfic.exe :

 

On lance l’application via IDA, une fois sur la page de login on place un BP Hardware sur la fonction « strlen » puis on valide.

On  place à nouveau un BP hardware sur la zone mémoire ou est stocké notre mot de passe. Et on continue l’exécution pour arriver dans la fonction « memcpy ».

On refait la même chose, un BP Hardware sur l’adresse 0x27E20A8.

On arrive encore dans un « memcpy » qui copie notre mot de passe dans l’adresse 0x18EA30. Cet emplacement est le dernier endroit où notre mot de passe est stocké en clair.

On continue ensuite l’éxécution Step by Step. On tombe sur une première fonction qui créé un bloc de 256 octets avec le mot de passe au début et le reste complété par des 0x20.

On continue et on arrive sur une fonction du même style que celle trouvée précédemment sauf que cette dernière crée un nouveau bloc de 256 octets en 0x18E88C, toujours avec le mot de passe et le reste complété par des 0x20 et lui applique en plus un XOR.

 

En continuant l’exécution, on tombe sur ce qui semble être une fonction de chiffrement à l’adresse 0x2547743C. On passe la dll wd160hf dans « Hash & Crypto Detector ».

Notre chiffrement n’est pas reconnu par l’outil.

D’après la documentation, le chiffrement par défaut utilisé est un chiffrement rapide sur 128 bits qui à l’air d’être développé maison.

Au début de la fonction, on remarque l’écriture de 16 octets, puis on enchaine sur l’algorithme de chiffrement.

On traduit cette algorithme en langage C :

Initialisation du block 256 octets :

 

Unsigned char * bloc = malloc(0xFF);

memset(_bloc, 0x20, SIZE_BLOCK);

memcpy(_bloc, MDP, strlen(MDP));

bloc[0] = bloc[0] % 0x1D;

for(int i = 1 ; i < 0xFF ; i++ )

 {

        bloc[i] = bloc[i] ^ bloc[i-1];

 }

 

 

Chiffrement du block :

 

unsigned char key[16] = {0x09, 0x1C, 0x0A, 0x00, 0x0D, 0x07, 0xFD, 0x00, 0x65, 0x20, 0x20, 0x03, 0x0D, 0x01, 0x55, 0x0A};

block[0] = (block [254] + block [0]) ^ key[15];

 

    for(int x = 1 ; x < taille ; x++ )

    {

        if( x == 0x7F)

        {

            block [x] = (block [x-1] + block [x]) ^ key[(15-((x-1)%16))];

            block [254-x] = (block [254-x] + 0x11) ^ key[((x-1)%16)];

        }

        else

        {

            block [x] = (block [x-1] + block [254-x] + block [x]) ^ key[(15-((x-1)%16))];

            block [254-x] = (block [254-x] + block [x]) ^ key[((x-1)%16)];

        }

    }

 

Ce qui nous donne comme résultat :

 

En poursuivant l’exécution on se rend compte que les données obtenues servent à définir une nouvelle clé de chiffrement.

Cet algorithme est exécuté sur l’emplacement mémoire suivant :

 

 

On en déduit le code c :

 

unsigned char key[16] = {0x88, 0x05, 0x09, 0x02, 0x45, 0x00, 0x12, 0x33, 0x01, 0x04, 0x03, 0x09, 0x1C, 0x22, 0x65, 0x66};

 

    for(int i = 0 ; i < 0xFF ; i++)

    {

        key[i%16] = (bloc[i] + key[(i+1)%16]) ^ (unsigned char)(i*0xFF);

    }

 

La clé ainsi obtenue est utilisée pour chiffrer le bloc mémoire situé à l’adresse 0x18EA30 dont nous avons parlé un peu plus haut. Pour le chiffrement il utilise le même algorithme que pour le bloc mémoire permettant de définir la clé.

Voici le résultat du bloc chiffré :

Notre Reverse se termine par la fonction de comparaison de notre mot de passe avec celui stocké dans l’application Windev (0x45CEA0C).

 

 Recherche du mot de passe :

Au début nous étions partis pour brute forcer le mot de passe en utilisant l’algorithme de chiffrement déterminé précédemment. Cependant nous n’avons aucune connaissance de la politique de mot de passe utilisé par Windev. On sait juste qu’un mot de passe ne peut dépasser 256 caractères, ce qui est assez mince.

Nous nous sommes donc mis à jouer un peu avec l’algorithme et là, miracle.

On sait que le mot de passe est complété par des 0x20 donc, à moins qu’il fasse 256 caractères, ce qui est peu probable on connait la fin. Quand on lui met une clé avec certains octets valides et le reste invalides on remarque qu’une partie du bloc se déchiffre correctement.

Voici le déroulement de l’opération (on peut voir que la clé se déchiffre au fur et à mesure des captures d’écran)

Il nous reste plus qu’a coder le brute forceur qui va bien. Ce que nous avons fait c’est de brute forcer les 4 premier octets de la clé, une fois trouvés, nous testons les 2 prochains et ainsi de suite. L’avantage est que le temps de cassage ne dépend pas de la taille du mot de passe (tant que la taille du mot de passe ne tend pas vers 256 caractères)

Maintenant on va tester notre petit brute forceur codé comme un pied 🙂

 

Le brute force à duré environ 2h avec un programme pas du tout optimisé. On remarque que notre outil trouve des débuts de clé qui pourraient correspondre mais qui ne donnent rien dans la suite du brute force.

Il continue ensuite l’exécution et une fois les 4 premiers octets découverts le reste du brute force ne dure que quelques secondes.

 Conclusion :

Une fois le mot de passe découvert, nous avons accès à tous les fichiers de données de l’application (dans le cas ou le mot de passe du fichier d’analyse est le même que celui du fichier de données ce qui est le cas dans la plupart des applications WinDev que nous avons rencontrés). De plus le mot de passe utilisé dans WDModfic.exe se retrouve dans plusieurs autres applications Windev. Cependant nous n’avons pas vérifié si les clés de chiffrement stockées en dur dans l’application ou le mot de passe étaient identiques dans les autres dll WD160HF.DLL.

Pour la version 16 de Windev il est primordial de ne surtout pas utilisé le chiffrement rapide et d’opter pour un chiffrement RC5.

Pour information, PCSoft a été prévenu de cette vulnérabilité le 25/07/2012, une réponse datant du 03/09 a été reçue ne spécifiant si la vulnérabilité ou pas sera corrigée. Nous avons donc préféré attendre un délai raisonnable de 2 mois avant de poster cet article.

 Outil :

L’outil développé dans le cadre de ce reverse et permettant de bruteforcer les mots de passe est disponible sur demande à l’adresse audit_at_nes.fr

 

Thierry Doré.