Blackhoodie17, of reverse and women

Filtrer par catégorie :

13 Décembre 2017 by Nha-Khanh Nguyen
Digital Security au Blackhoodie

Blackhoodie17, of reverse and women

"Parce qu'une conversation entre femmes est bien plus fructueuse qu'une classe entière avec seulement une ou deux filles cachées dans un coin". Tels sont les mots de Marion Marschalek (@pinkflawd), organisatrice du workshop Blackhoodie qui depuis cette année s'est transformé en véritable bootcamp. Prenant place dans les locaux du CIRCL au Luxembourg pour sa 3ème édition, l'évènement centré sur le Reverse Engineering a accueilli du vendredi 24 au dimanche 26 novembre 2017, un peu moins de 70 apprenties reverseuses et même initiées. Venues des quatre coins du globe et de tous les domaines de l'informatique, se sont réunies des développeuses, architectes réseau, cloud, data scientists, reverseuses mais également des juristes (et oui le RE peut également être un hobby!). Toutes partagent un centre d’intérêt commun : le désir de pouvoir casser du malware à la fin du week-end.

Vous l'aurez compris, c'est une conférence de reverse engineering destinée uniquement à la gente féminine. Marion explique les raisons de son choix durant la conférence HamburgSides 2015. Ainsi que sur son blog. Être une minorité n'est pas toujours simple surtout dans un domaine ultra technique comme l'est le Reverse Engineering. C'est par son expérience dans l'enseignement devant une assemblée majoritairement masculine (classe, workshop, conférence) mais également celle en tant que femme dans le domaine que lui vient l'idée de la Blackhoodie.

C'est donc ainsi que je me suis retrouvée embarquée dans un week-end entre filles, qui l'eût cru, pas tout à fait ordinaire...

Badges
Badge et feuillet de la Blackhoodie... Mais quelle est cette chaîne d'hexadécimale en fond ?


De nombreuses présentations intéressantes

11h, dans les locaux du CIRCL, la matinée commence par quelques présentations courtes des participantes des anciennes éditions (mais pas que), ayant pour but de partager un projet, un retour d'expérience ou encore une restitution de connaissance. En voici le programme :


Flash dumping - Kylma (@_Kylma)

Kylma nous explique dans sa présentation comment dumper une puce électronique. Pour ce faire, elle nous explique en détail les étapes de son projet de l'extraction de la puce de la carte initiale, grâce à ce qui s'apparente à un genre de "super sèche-cheveux" à la conception puis fabrication d'un PCB destiné à accueillir la puce afin d'en faciliter le dump du firmware.
 

Malware analysis using logic - Barbie Auglend (@barbieauglend)

Assez souvent, lors d'une analyse de malware, la plupart des gens foncent tête baissée sur l'analyse du code et de son comportement. Barbie nous donne une autre vision de l'analyse d'un binaire en faisant appel à la logique, grâce à un solveur SMT.
 

Monitoring Engineers with the Cloud - Carly Schneider (@_5chn31d3r_)

Carly Schneider nous parle de Cloud Google Platform, une solution alternative à AWS. L'ennui c'est qu'il n'existe à ce jour aucun outil dédié à la sécurisation du serveur. Carly nous raconte alors comment son équipe a commencé à implémenter leurs propres outils puis petit à petit en sont venus à travailler avec Google. Le fruit de leur collaboration a donné naissance à Forseti, un outil de sécurisation pour une meilleure gestion des projets sur CGP.
 

Sandbox evasion - MyShelle

MyShelle nous expose les différentes méthodes d'évasion de sandbox à l'aide de Powershell et PS2EXE ou encore grâce à l'obfuscation de code en manipulant les chaînes de caractères, rajoutant du code parasite. Mais cette dernière méthode ne fonctionne qu'en analyse dynamique. Il est donc important de combiner l'analyse dynamique avec l'analyse statique si l'on veut étudier de façon efficace un malware.

 

Network forensics - Essy (@casheeew)

C'est en reprenant le cas de BadRabbit qu'Essy illustre l'analyse forensique orientée réseau du malware. Grace à un lab constitué de deux machines virtuelles, Essy nous montre comment le malware infecte l'une des VMs au travers de l'analyse des trames sur Wireshark, puis infecte la deuxième machine via les partages SMB/CIFS.

SIMtrace - Chrysh (@chrysh4)

Chrysh nous présente son projet de recherche effectué durant sa thèse de Bachelor: la transformation d'une SIMtrace Osmocom en sniffer et émulateur de vieux téléphone Nokia ou Motorola à l'ancienne.


Kernel Shim Engine - Gaby (@pwissenlit)

Dans cette présentation, Gaby nous présente un composant relativement récent dans les derniers systèmes Windows: le shim kernel shim engine. Les shims, utilisés dans la rétrocompatibilité des systèmes Windows, sont habituellement côté userland. Ici, il s'agit d'un composant similaire mais du côté kernel. Gaby nous explique alors de A à Z comment ces shims fonctionnent, à quoi ils servent et comment les créer.

Malware analysis for policy muggles - Mara (@marasawr)

Pour finir, Mara nous expose la vision des politiques et les amalgames souvent faits entre la recherche de malware et les armes de destructions massives, parlant souvent de cyberguerre et d'attributions lors d'attaques APT.
Certaines présentations sont maintenant disponibles sur https://www.blackhoodie.re/archive/.

Présentations
Kylma présentant le Flash dumping sur PCB. Crédit photo :  Securitymadein.lu


Les choses sérieuses commencent...

La première journée, commence par l'analyse d'un binaire compressé. Marion commence par présenter notre meilleur ami du week-end: IDA pro. Une première présentation de l'outil et de ses multiples fonctionnalités sont alors exposées: l'affichage des blocs décisionnels, les fonctions implémentées, les bibliothèques Windows importées...
 
IDA présentations
Marion Marschalek en peine explication d'un binaire désassemblé sur IDA. Crédit photo: @S_I_NI

La suite prend la forme d'un workshop où chacune tente de de comprendre le fonctionnement du binaire. On pose des breakpoints, on exécute le binaire, on observe. Sous les astuces et les conseils avisés de Marion, les participantes apprennent à décompresser un binaire pas à pas. Puis l'analyse. L'analyse c'est beaucoup, beaucoup de patience (armez-vous de vos painkillers, vous en aurez-besoin). "On passe une éternité pour juste trouver une toute petite brique d'information. C'est ça, le reverse engineering. Yay!".
Le second binaire dont il fallait comprendre l'utilité, était en fait un botnet IRC. Il fallait naviguer dans les fonctions disponibles et comprendre l’enchaînement des instructions. En réalité, nul besoin de comprendre chaque instruction ligne par ligne. Le tout est surtout de comprendre le fonctionnement de chaque bloc et leurs enchaînements logiques. Le reverse, c'est aussi beaucoup de lecture dans la documentation MSDN de Microsoft afin de comprendre les appels de fonctions Windows faits dans le code et d'identifier les raisons pour lesquelles elles sont appelées. La diversité de métiers de chacune a permis d'avancer en complémentarité sur l'exercice, chacune apportant leurs lots de connaissances spécifiques: les développeuses pour la compréhension de l'algorithme induit par le code C et manipulation de la pile, les investigatrice en forensique pour les mécanismes communs et artefacts Windows utilisés chez les malwares, les architectes réseaux pour les mécanismes de connexion aux serveurs, etc.

Pendant que les unes ingurgitaient avec engouement les rudiments de l'art du désassemblage, des workshops avancés pour les anciennes participantes prenaient place en parallèle à l'arrière de la salle. Durant les journées du samedi et dimanche, se sont succédés les workshops suivants :

Advanced workshops
Noutoff présentant l'exécution symbolique  avec MIASM. Crédit photo: @barbieauglend

De belles rencontres et des discussions très riches

Au final, que retenir de ce week-end à regarder du code assembleur jusqu'à en mourir - comme le dit si bien Marion Marschalek ? Tout d'abord, l'initiative d'une conférence sur le reverse engineering pour les femmes a été globalement très bien reçue et saluée dans le milieu de la sécurité informatique. Si elle a pu aider certaines participantes à s'épanouir ou se trouver dans ce milieu très masculin, Marion a pu également transmettre son savoir et sa passion pour le reverse engineering à toutes celles qui ne savaient pas comment aborder la bête. En plus de tout cela, l'évènement a également été un véritable lieu de rencontre multiculturel dont le fruit des échanges a été extrêmement riche au niveau social comme au niveau partage de connaissances, de quoi abattre tous les clichés féminins que l'on peut encore entendre. Il a également permis à certaines de s'essayer à leur première présentation technique ainsi que dans leur premier workshop, pour oser enfin franchir le pas de la conférence internationale dans un avenir proche, ou nous les attendons avec impatience.

Et cette suite en hexadécimale dans tout ça ?

Une fois n'est pas coutume, lorsque l'on met entre les mains de hackers en herbe quelque chose semblant être un code informatique, il faut s'attendre à ce que ce dernier tombe dans le désassembleur favoris de chacun (ou plutôt chacune !).

Après quelques minutes de labeur et une rétine en moins (parce qu'avec une écriture noir sur fond vert foncé, l'OCR ne marche pas très bien, mais nos yeux non plus), nous extrayons la chaîne hexadécimale suivante :


90 90 90 90 55 48 89 E5 48 89 7D E8 48 89 75 E0
89 55 DC 8B 45 DC 89 45 FC EB 2F 8B 45 FC 48 63
D0 48 8B 45 E0 48 01 C2 8B 45 FC 48 63 C8 48 8B
45 E8 48 01 C8 0F B6 00 89 C1 8B 45 FC 29 C1 89
C8 83 F0 42 88 02 83 6D FC 01 83 7D FC 00 79 CB
48 8B 45 E0 5D C3 CC CC CC CC 00 00 00 00 6F 75
74 70 75 74 20 3D 20 01 36 32 24 29 2C 21 2F 33
55 23 1C 22 1D 15 17 52 21 14 10 4E 0C 09 1F 54
57 56 47 5D 4E 00 00 00 00 00 00

Ni une ni deux, on remarque une répétition du nombre 90 et certains motifs par-ci par-là. Reverseuses chevronnées que nous sommes maintenant, on se dit que c'est un NOP-sled, serait-ce un payload en ASM ? Désassemblons tout cela.


Hexa disassembled


A première vue, il ne semblerait pas s'agir d'un payload mais d'une fonction. En effet, nous observons qu'après ce qui ressemblait à un NOP-sled (mais qui du coup n'en est pas un), le prologue d'une fonction.

push   rbp
mov    rbp,rsp


Le prologue permet, lors d'un appel de fonction, de sauvegarder dans la pile l'adresse en cours afin de pouvoir y retourner à la fin de l'exécution de la-dite fonction et ainsi continuer le programme.

On remarque que 3 arguments sont passés à la fonction :

mov     [rbp-24], rdi
mov     [rbp-32], rsi
mov     [rbp-36], edx


L'utilisation des registres rdi, rsi et edx nous indique qu'il s'agit là d'un code compilé pour du Linux x64, selon la convention d'appel . On a donc notre premier argument, rdi, à l'adresse [rbp-24], le second, rsi à l'adresse [rbp-32] et le dernier à l'adresse [rbp-36].

On identifie ce qui a l'air d'une boucle: le premier jump jmp     short loc_46 nous emmène directement au test d'une valeur : dword ptr [rbp-4] avec 0 suivie d'un second jump jns     short loc_17. Tant que tant que la valeur contenue à l'adresse dword ptr [rbp-4] n'est pas égale à 0, on boucle dans loc_17. Qui dit boucle et condition de fin, dit compteur d'itération. Or on remarque l'accès répétitif à l'adresse [rbp-4] ainsi qu'une soustraction de la valeur qui y est contenue en fin de boucle. Voilà donc sans nul doute notre compteur, contenant à la première itération, le dernier argument. Pour la suite, nous l'appellerons i.

Regardons de plus près cette boucle. Elle semble faire plusieurs opérations avec nos arguments. Pour être plus précis, on repère même 4 opérations arithmétiques : 2 add et 2 sub, toutes précédées de divers mov. Pour y voir plus clair, découpons notre fonction après chacune des opérations, ce qui nous donne 4 parties.

mov     eax, [rbp-4]
movsxd  rdx, eax
mov     rax, [rbp-32]
add     rdx, rax

mov     eax, [rbp-4]
movsxd  rcx, eax
mov     rax, [rbp-24]
add     rax, rcx

movzx   eax, byte ptr [rax]
mov     ecx, eax
mov     eax, [rbp-4]
sub     ecx, eax

mov     eax, ecx
xor     eax, 66
mov     [rdx], al
sub     dword ptr [rbp-4], 1


Pour effectuer chaque opération, les valeurs intermédiaires sont sauvegardées dans des registres comme eax.

Analysons le premier bloc d'instruction.

mov     eax, [rbp-4]
movsxd  rdx, eax
mov     rax, [rbp-32]
add     rdx, rax


Les quatre premières instructions semblent opérer une addition entre le contenu des adresses [rbp-4] et [rbp-32], contenant respectivement à la première itération le dernier argument, c'est-à-dire le compteur de boucle i et le second argument.

A ce stade, nous avons alors : rdx = i + arg2

Le deuxième bloc fait exactement la même opération mais cette fois, avec le premier argument.

mov     eax, [rbp-4]
movsxd  rcx, eax
mov     rax, [rbp-24]
add     rax, rcx


On à donc cette fois-ci : rax = arg1 + i

Intéressons-nous maintenant au troisième bloc.

movzx   eax, byte ptr [rax]
mov     ecx, eax
mov     eax, [rbp-4]
sub     ecx, eax


Dans ce bloc, la première instruction permet d'obtenir la valeur contenue à l'adresse rax à savoir arg1 + i. Cette valeur est un octet qui est ensuite soustrait de i, puis stockée dans ecx.

ecx = byte - i

Enfin, voyons le dernier bloc :

mov     eax, ecx
xor     eax, 66
mov     [rdx], al
sub     dword ptr [rbp-4], 1



Ici, la valeur que nous venons d'obtenir au bloc 3, ecx,  est xorée avec la constante 0x42. Puis l'octet résultant (al étant la partie basse de eax, correspondant donc à 8bit), est stocké à l'adresse ayant pour valeur rdx, c'est à dire à l'adresse i + arg2 (et non pas l'adesse de i + arg2).

Notre dernière instruction décrémente tout simplement i.

A ce stade, on comprend que 3 arguments sont passés à la fonction. Le dernier argument correspond au nombre d'itération qu'effectue la boucle.

Au total, les deux premiers blocs nous permettent d'obtenir deux adresses mémoires dans les buffers fournis en paramètres : rax = arg1 + i et rdx = i + arg2. Un accès en lecture est fait sur l'adresse rax tandis que sur rdx c'est un accès en écriture. A chaque tour de boucle, un octet est récupéré de rax, soustrait de i puis xoré avc 0x42 pour être finalement stocké dans rdx.

Une fois sortie de notre moulinette, rax qui est par convention notre valeur de retour, contient alors le contenu de l'adresse [rbp-32], anciennement arg2. Nous avons donc une fonction qui xor chaque caractère d'une chaîne de caractère après l'avoir soustrait de la valeur de l'incrémentale puis nous retourne le résultat.

Il ne nous reste donc plus qu'à recoder cette fonction sans oublier de renverser le xor afin de pouvoir déchiffrer ce qui semble se trouver après du padding dans notre code hexadécimal et qui n'a donc pas été désassemblé en instructions tout à l'heure :

90 90 90 90 55 48 89 E5 48 89 7D E8 48 89 75 E0
89 55 DC 8B 45 DC 89 45 FC EB 2F 8B 45 FC 48 63
D0 48 8B 45 E0 48 01 C2 8B 45 FC 48 63 C8 48 8B
45 E8 48 01 C8 0F B6 00 89 C1 8B 45 FC 29 C1 89
C8 83 F0 42 88 02 83 6D FC 01 83 7D FC 00 79 CB
48 8B 45 E0 5D C3 CC CC CC CC 00 00 00 00 6F 75
74 70 75 74 20 3D 20 01 36 32 24 29 2C 21 2F 33
55 23 1C 22 1D 15 17 52 21 14 10 4E 0C 09 1F 54
57 56 47 5D 4E
00 00 00 00 00 00

#include <stdio.h>

void cipher(unsigned char *word, int size) {
    char    xor[size];

    while (size >= 0) {
        xor[size] = (word[size] ^ 0x42) + size;
        size--;
    }
    printf("flag = %s \n", xor);
}

int main() {
    unsigned char    xor[30] = {0x01, 0x36, 0x32, 0x24, 0x29, 0x2C, 0x21, 0x2F, 0x33, 0x55, 0x23, 0x1C, 0x22, 0x1D, 0x15, 0x17, 0x52, 0x21, 0x14, 0x10, 0x4E, 0x0C, 0x09, 0x1F, 0x54, 0x57, 0x56, 0x47, 0x5D, 0x4E};
    cipher(xor, 29);

    return 0;
}


Merci à Gaby pour la conception de ce petit challenge d'initiation au reverse engineering constituant une sympathique mise en bouche de l'activité, rappelant quelques notions et conventions de bases.