Challenge SSTIC 2018 Solution
Total Page：16
File Type：pdf, Size：1020Kb
Challenge SSTIC 2018 Solution Auteur : Nicolas Surbayrole Table des mati`eres Table des mati`eres 1 Introduction 2 1 Anomaly Detection 3 1.1 Enonc´e´ ...............................................3 1.2 Analyse du trafic.........................................4 1.3 Analyse du Javascript......................................5 1.4 D´esassemblage du WebAssembly................................5 2 Disruptive JavaScript6 2.1 Analyse pr´eliminaire.......................................6 2.2 Reverse du WebAssembly....................................7 2.3 Analyse de l'algorithme de d´echiffrement............................7 2.4 Cr´eation d'un contexte......................................7 2.5 D´echiffrement...........................................8 3 Battle-tested Encryption9 3.1 Analyse du binaire........................................9 3.2 Analyse de l'´etablissement de la connexion scomm...................... 11 3.3 D´echiffrement du flux suspect 31337.............................. 12 4 Nation-state Level Botnet 15 4.1 Recherche du botnet....................................... 15 4.2 Recherche d'une vuln´erabilit´e.................................. 16 4.3 Exploitation de la vuln´erabilit´e................................. 19 4.4 Infiltration............................................ 22 Conclusion 24 Bibliographie 25 A Annexes 26 1 Introduction Ce document pr´esente les diff´erentes ´etapes du challenge SSTIC 2018 ainsi que mon cheminement pour les r´esoudre. Le challenge de cette ann´eecomprend trois flags interm´ediaires permettant de distinguer 4 phases diff´erentes. Ces phases comprennent des ´etapes de reverse, de cryptographie ainsi que de l'analyse r´eseau et du pwned. 2 Anomaly Detection 1.1 Enonc´e´ From : [email protected] To : j.raff@goeland-securite.fr Bonjour, Nous avons r´ecemment d´ecouvert une activit´esuspecte sur notre r´eseau. Heureusement pour nous, notre fine ´equipe responsable de la s´ecurit´ea rapidement mis fin `ala menace en ´eteignant imm´ediatement la machine. La menace a disparu suite `acela, et une activit´enormale a pu ^etre reprise sur la machine infect´ee. Malheureusement, nous avons ´et´econtraints par l'ANSSI d'enqu^eter sur cette intrusion inopin´ee. Apr`es analyse de la machine, il semblerait que l'outil malveillant ne soit plus r´ecup´erable sur le disque. Tou- tefois, il a ´et´epossible d'isoler les traces r´eseau correspondantes `al'intrusion ainsi qu'`al'activit´ed´etect´ee. Nous suspectons cette attaque d'^etre l'œuvre de l'Inadequation Group, ainsi nomm´edu fait de ses optimisations d'algorithmes cryptographiques totalement inad´equates. Nous pensons donc qu'il est possible d'extraire la charge utile malveillante depuis la trace r´eseau afin d'ef- fectuer un < hack-back > pour leur faire comprendre que ce n'´etait vraiment pas gentil de nous attaquer. Votre mission, si vous l'acceptez, consiste donc `aidentifier le serveur h^ote utilis´epour l'attaque et de vous y introduire afin d'y r´ecup´erer, probablement, une adresse e-mail, pour qu'on puisse les contacter et leur dire de ne plus recommencer. Merci de votre diligence, Marc Hassin, Cyber Enqu^eteur Isofax SAS Figure 1.1 { Email introductif On commence donc avec une capture r´eseau 33Mo des derni`eres communications de la machine avant qu'elle ne soit ´eteinte. 3 1.2 Analyse du trafic Pour commencer l'analyse, j'ai utilis´eWireshark pour visualiser les diff´erents flux compris dans la capture. En survolant le trafic, on remarque que l'adresse IP 192.168.231.123 revient `achaque paquet. Il s'agit donc de notre machine affect´ee. La majorit´edu flux provient d'une navigation sur internet avec des requ^etes DNS et des flux HTTP et HTTPS. La majorit´edes sites consult´essont des journaux. L'user- agent des requ^etes HTTP nous laisse penser que la navigation a lieu avec Firefox 53.0 sous Linux. Figure 1.2 { Capture d'un flux HTTP Afin d'analyser plus en d´etail la capture et en sortir les flux potentiellement ind´esirables, on peut demander `awireshark de lister les flux TCP. On remarque alors six connexions sortantes vers le port 8080, une vers le port 1443 et une vers le port 31337. Figure 1.3 { Liste des connexions TCP avec les 8 connexions suspectes Les six connexions sur le port 8080 sont en HTTP. On peut donc extraire les pages charg´ees (cinq 4 scripts JS et un WASM). Pour la connexion sur le port 1443, il s'agit de HTTPS. Enfin, le port 31337 n'est pas standardis´e. Le protocole ne ressemble `arien de connu et semble chiffr´ed`es le d´ebut. 1.3 Analyse du Javascript Apr`es l'extraction des flux HTTP, on se retrouve avec cinq scripts (stage1.js, stage2.js, utils.js, pay- load.js, blockcipher.js) et un fichier WebAssembly (blockcipher.wasm). Il apparait assez vite que stage1.js charge les autres scripts et pr´epare un exploit `abase d'une chaine d'appel (ROP). La charge utile est contenue dans le fichier payload.js, mais doit d'abord ^etre d´echiffr´ee. Le fichier stage2.js s'occupe des diff´erentes ´etapes du d´echiffrement. Diverses fonctions cryptographiques sont pr´esentes dans le blockci- pher.wasm qui est import´epar le blockcipher.js. Dans une des fonctions de stage2.js, on remarque le commentaire getFlag(0xbad). Il faut donc appeler cette fonction pour obtenir le premier flag. Pour appeler la fonction, j'ai cr´e´eun petit fichier HTML qui importe les diff´erents scripts. Le chargement du wasm doit se faire avec un serveur web pour avoir les bons ent^etes. Il est ´egalement n´ecessaire de changer l'URL d'acc`es dans le blockcipher.js. Apr`es avoir r´egl´etous les probl`emes de chargement des diff´erentes parties, on peut appeler la fonc- tion getFlag avec le param`etre 0xbad. La fonction ne ressort aucun r´esultat ni de log dans la console. La fonction getFlag faisant appel `ala fonction getFlag du wasm, on va essayer de la d´esassembler. 1.4 D´esassemblage du WebAssembly Le WebAssembly permet d'ex´ecuter un assembleur dans les navigateurs. Le langage est pens´ecomme une machine `apile avec des registres. Il est possible de compiler directement du C ou du C++ vers du WebAssembly. Dans notre cas, on trouve dans le loader (blockcipher.js) un lien vers le wiki du compila- teur Emscripten. Pour d´esassembler le wasm, il est possible d'utiliser les navigateurs qui poss`edent des consoles de debug. Ainsi, dans Firefox, il est possible de trouver le wasm d´esassembl´eainsi que les diff´erents import et export. En regardant la fonction associ´ee `a getFlag, on remarque que le param`etre est compar´e`a89594904. On obtient le flag en passant cette valeur `ala fonction getFlag. Figure 1.4 { Condition dans getFlag SSTIC2018f3db77149021a5c9e58bed4ed56f458b7g Figure 1.5 { Premier flag 5 Disruptive JavaScript 2.1 Analyse pr´eliminaire Lors de l'´etape deux, on va essayer de d´echiffrer le payload. On commence donc par analyser les diff´e- rentes ´etapes de d´echiffrement dans l'espoir de les reproduire et de trouver un moyen de les contourner. Le sch´ema ci-dessous illustre les diff´erentes ´etapes du d´echiffrement. Figure 2.1 { Etape´ de d´echiffrement du payload On remarque que le d´echiffrement a besoin d'un mot de passe pour se d´erouler correctement. Le mot de passe est charg´een HTTPS et correspond au flux sur le port 1443. Comme il est impossible de forcer une clef de 32 octets, on regarde les param`etres de s´ecurit´ede la connexion HTTPS. La connexion HTTPS utilise TLSv1.2 avec TLS ECDHE RSA WITH AES 128 GCM SHA256. On a donc une connexion authentifi´ee par clef RSA, chiffr´epar AES-128-GCM avec des clefs ´echang´eesavec Diffie-Hellman et une int´egrit´ev´erifi´eepar SHA256. Diffie-Hellman est utilis´eavec la courbe elliptique x25519. Il est donc inutile d'essayer de casser le certificat, car la connexion utilise des clefs temporaires pour le chiffrement. De plus, la courbe x25519 offre une s´ecurit´ede 128 bits soit 16 octets. On a donc une meilleure attaque que sur la clef, mais qui reste encore impossible `ar´ealiser. 6 Comme il n'est pas envisageable de casser le chiffrement TLS, on peut essayer de forcer le mot de passe. N´eanmoins, PBKDF2 est une fonction de d´erivation de clef con¸cue pour ^etre relativement lente. De plus, il n'est pas possible de d´eduire une taille probable du mot de passe envoy´epar le serveur. La recherche du mot de passe sera s^urement plus longue que la recherche de la clef `acause de PBKDF2. On peut essayer quelques valeurs (le flag de l'´etape 1, le tag cherch´e,etc.), mais sans succ`es. Il va doit falloir s'attaquer aux fonctions de d´echiffrement elles-m^emes. Avant cela, il est n´ecessaire de comprendre l'attaque que l'on peut r´ealiser. On poss`ede en effet un couple clair-chiffr´ede 16 octets. Si on consid`ere l'algorithme de d´echiffrement en boite noire, on sait qu'il prend en entr´eeun bloc de 16 octets et un contexte de 160 octets (d´eriv´ed'une clef de 32 octets). Pour un algorithme qui travaille sur des blocs de 16 octets, il existe 2128! permutations clairs-chiffr´espossibles. Comme la clef est de 32 octets, seules 2256 permutations sont accessibles. Le fait de fixer un couple clair-chiffr´er´eduit les permutations possibles de 2128. En consid´erant que les 2256 permutations accessibles sont ´equitablement r´eparties dans l'espace initial des permutations, il nous reste 2128 clef de 32 octets qui poss`ede ce couple clair-chiffr´e.Il faut donc s'attendre `aune grosse faiblesse dans l'algorithme pour arriver `ad´echiffrer la charge utile.