SSTIC 2014 - Jour 3
Bon, bah on est reparti, de pas trop bonne heure :] cette année on à eu 15min de sommeil potentiel en plus. Certains ne se sont pas couchés, d’autres ont été raisonnable mais l’amphi est quand même rempli.
Fuzzgrind sous windows
A la base était fuzzgrind, un fuzzer basé sur l’algorithme sage. L’algorithme ayant trouvé 1/3 des vulns présentes dans Windows 7. Pour faire le portage sous Windows de fuzzgrind, on peut utiliser PIN tools pour l’instrumentation, mais il faut une représentation intermédiaire pour ça. L’exécution symbolique consiste à représenter les instructions par une version plus abstraite (cf miasm tout à l’heure). L’analyse de teinte consiste à marquer les inputs et à suivre leur propagation dans un programme. Il faut donc s’éplucher la doc Intel, et implémenter tout ça dans la représentation intermédiaire. Du coup pour la propagation de la teinte, on représente tout les registres du CPU etc… Certains font le marquage au niveau du bit. Ici l’auteur a choisi l’octet comme granularité pour la propagation de teinte.
Obfuscation d’application python
par Serge Guelton et Ninon Eyrolles
Python, c’est intéressant à obfusquer parce que l’on fourni souvent le bytecode à l’attaquant, il faut donc trouver des moyens pour cacher ce bytecode, l’obfusquer pour le protéger et éviter qu’il remonte aux sources (ex ici avec le reverse du client dropbox). L’évaluation dynamique permet de faire beaucoup de choses tordues. La permutation d’opcode dans l’interpréteur permet de faire croire à une addition alors qu’en fait c’est une soustraction. Il faut donc aller vérifier dans l’interpréteur comment c’est géré. Pour la décompilation uncompyle2 et pycdc sont là. L’orateur nous présente plein de tricks intéressants d’obfuscation python (cf les actes).
L’obfuscation au niveau bytecode et interpréteur sont en suite couplés à de l’obfuscation du source pour compliquer l’analyse. Avec AST python, on peut obtenir l’AST correspondant au code source, et on peut y appliquer des transformations. Déroulement de boucles, transformation d’ IF en WHILE, Obfuscation de constantes par prédicats opaques. On peut aussi transformer le source en code fonctionnel (argh ça ressemble à du LISP).
Désobfuscation de DRM par attaques auxiliaires.
L’approche choisie consiste à tracer l’exécution et en suite de travailler avec cette trace par analyses successives. Du coup ils ont implémenter un outil: ptra pour python trace analyzer. Avec une chtite archi autour de mongodb. Pour obtenir la trace, ils ont utilisé PIN, mais ça pouvait marcher avec IDA ou Miasm. Pour le désassemblage, c’est Miasm. Des scheduler et du cache pour accélérer ça et le faire tourner le week end.
Le process d’analyse consiste à identifier les briques logicielles (fonctions, modules etc…) puis d’identifier les I/O de ces briques, puis de retrouver l’algo original à partir de ces briques. Tous les détails de ce process sont dans les actes.
Challenge du SSTIC
Présentation de la création du challenge.
Chall décomposé en 3 parties: une trace USB, Un crackme obfusqué et un service a exploiter en remote qui tourne sur un émulateur de micro-controleur. Le tout est dispo sur github en l’état. L’obfuscateur ne marche pas très bien, et du coup c’était galère à mettre au point.
Présentation de la solution
Objectif : un e-mail en sstic.org. Il faut parser le fichier pour obtenir les données à partir de la trace USB. c’est de l’usbmon, un format standard d’un outil linux. Il y à 3 protocoles imbriqués: les trames USB issues d’ADB, avec un protocole de requête sync qui sert au transfert du fichier badbios.bin.
En suite on reverse le binaire elf 64bit arm64. Pour tester le binaire, soit on monte une VM arm64, soit on à accès à une machine arm64. Qemu à un JIT pour transformer à la volée le arm64 en x86, du coup on peut l’exécuter.
Le packer est une espèce de loader elf un peut bizzare. lors du reverse on identifie une machine virtuelle avec 17 instructions utilisés sur 31 et 15 registres. L’espace mémoire de la vm est chiffré avec chacha et une clef « 0BADB105… ». Il faut donc développer un désassembleur pour analyser le programme de la VM. On tombe en suite sur un prog de déchiffrement d’un bloc par LFSR (Linear Feedback Shift Register). Il y à une attaque possible en jouant sur les conditions de padding. Les 8 derniers octets sont à 0, du coup on peut inverser le LFSR. Avec la clef on obtient un payload.bin
Il faut en suite exploiter le micro-contrôleur. Il utilise le format Intel HEX. Dans l’archive, on à un upload.py qui pousse le programme sur le micro-contrôleur, l’exécute et qui récupère en suite la réponse. On comprend rapidement qu’il faut dumper une zone mémoire sur le µC. En fabriquant un assembleur/desassembleur pour le langage cible du µC, et par essais successifs, ont peut découvrir divers appels systèmes. On n’arrive pas à dumper la zone secrète, mais on peut récupérer la mémoire du kernel et donc reverser les syscall. On fini par découvrir une vulnérabilité dans le syscall et on récupère la zone mémoire à dumper.
On obtient un .nfo avec un toutou et l’e-mail.
Exemple de renforcement de la sécurité d’un OIV.
Bon après audit, les gens n’implémentent pas forcément les recommandations. Et quand ils se font défoncer, bizarrement ils n’ont plus d’excuses pour prendre en compte ces fameuses reco. En plus, l’impact de la compromission n’est pas forcément immédiat, mais à horizon 5 à 10 ans lorsque la perte de marché se fait sentir sur l’emploi.
Bon sur un système industriel, c’est plus direct, ça casse au niveau soft, ça explose au niveau physique. Du coup c’est tout de suite bien pris au sérieux. En fonction de la génération de la centrale, il y a plus ou moins d’informatique pour piloter le système indus. En plus de la production, on à la partie R&D/Ingéniérie qui donne de la latitude pour faire évoluer les systèmes de production.
La sureté de fonctionnement dans le nucléaire est très mature et pragmatique, formel, simple et efficace contrairement à pas mal de docs 27k. Le RSSI n’est pas forcément soutenu avec les moyens permettant d’agir et d’influer sur la sécurité du système.
Coté SI industriel, c’est très hétérogène, avec un gros legacy et une durée d’exploitation extrêmement longue comparé à la bureautique. Du coup ça complique les choses, notamment la gestion des protocoles de communication et leur filtrage. C’est beaucoup de travail et peu d’uniformité. Et on voit arriver des technos bureautiques type AD dans les centrales. Heureusement les contraintes de sureté sont simples, et les algo sous-jacents sont faciles à comprendre. Mais du coup les contraites liés à leur vitesse d’exécution en temps contraint fort (voir du temps réel dur) implique qu’on ne peut pas utiliser tout les outils de la SSI traditionnelle (crypto, authent, etc…).
Les réseaux sont souvent bien cloisonnés pour chaque usage (indus, telecom, bureautique, etc…) mais il reste des interfaces entre eux pour des raisons de performance et de rentabilité. Du coup il à fallu coordonner tout ça pour que ces passerelles ne se transforment pas en passoires. La SSI étant mise au service de la sureté, elle à plus de poids que la DSI, ce qui permet de pousser des changements plus facilement que dans des entreprises classiques.
Fun with VM in the cloud
(J’ai changé le titre, juste parce que c’était un peu trop lourd ;))
C’est quoi les nouvelles classes de vulns introduite par les techno clouds. L’adaptation des ressources, leur gestion, la colocalisation des VM sur un même hôte. Tout ça peut avoir des effet de bords d’une machine sur l’autre, et donc une VM malveillante peut perturber ses voisines. Vu que tout le monde prend plus de ressources que nécessaire, les hébergeurs font du surbooking.
L’attaque consiste à jouer avec l’algo d’allocation des ressources pour le forcer à migrer des VMs victimes, les impactant au niveau perf. Pour ce faire, les vmVMs malveillantes jouent sur leur conso de ressources pour générer de la charge sur le cluster. Du coup l’algo vmware migre les autres VM pour équilibrer la charge sur le cluster, ce qui coûte cher en perf pour la VM migrée.
RPCView
Exploration et décompilation d’MS-RPC. par la PME locale.
Des MS-RPC yen a plein, presque tout les services de l’OS sont des MS-RPC, ainsi que pas mal d’éditeurs d’anti-virus notamment. Sysinternals c’est cool, process-explorer/process-hacker c’est chouette, mais on à pas ça pour les RPC 🙁
En plus toutes les interfaces RPC ne sont pas forcément enregistrés dans l’Endpoint-mapper, et les outils de décompilation des MS-RPC sont tous obsoletes. La décompilation s’appuie en partie sur la doc microsoft (tout n’est pas documenté, comme d’hab). Le listing des MS-RPC se fait par une technique non-documentée. Il faut donc se pallucher les runtimes RPC à la recherche de la structure.
S’en suit une demo d’analyze du serveur RPC de Stuxnet. Via la RPC on force Stuxnet à se desinstaller. On décompile l’interface rpc avec RPCView, on intègre ça dans un client RPC générique, et on lance la commande de désinstallation.
Outil dispo sur http://www.rpcview.org
Haka: un langage orienté réseaux et sécurité
Un langage qui étend LUA construit sur un core C. Ce core fonctionne avec NFQueue ou pcap. Et le langage qui va sur ce core est séparé en deux parties: des dissecteurs, et des règles de sécurité. L’objectifs de ces règles, c’est de faire du filtrage, de la réaction, voir de la modification de paquets ou de la création de paquets. (ARGH un exemple ou on utilise une regexp pour parser du HTML c’est mal).
C’est open-source, et c’est publié, on peut créer ses propres dissecteurs, et des dissecteurs de base serons fournis.
De la dissuasion numérique aux cyberguerillas
Petit slide troll politico-philo-strategico-numérique pour introduire le tuto miasm2. kamoulox.
Petit tutoriel miasm façon école des fans :] avec un « volontaire ». Il y a aussi des tests de régression de miasm (quand on parlais de cailloux dans le c…). Miasm comprend un desassembleur. Pensez à lancer les tests de non-régression avant d’utiliser l’outil pour éviter les mauvaises surprises (cf doc sur le site).
Intro des concepts de miasm sur la représentation intermédiaire (cf sstic 2013).
On peut importer le graph IR dans IDA.
meb/python disasm_meb01b.py mebroot_C.exe
xdot graph_execflow.txt
On voit bien que c’est dégeu, du coup on dit à miasm de simplifier le langage intermédiaire. Ensuite, on guide miasm pour comprendre les indirections et les @ mémoire qu’il obtient par analyse. Ce qui permet de nettoyer le graph.
meb/python disasm_meb01g.py mebroot_C.exe
xdot graph_execflow.txt
Du coup c’est propre. En suite on peut utiliser des visiteurs (pas ceux du film) pour parcourir l’AST et transformer les expressions mémoire et patcher le déréférencement pour re-injecter les info et simplifier le tout. On obtient le même graph mais avec des jnz au lieu des jmp.
Ensuite on va dire a miasm de fusionner les basic blocs dont l’enchainement est systématique, pour ensuite simplifier tout ça. On peut faire ça comme un clodo avec du pattern matching, c’est moche mais pragmatique. Après avec elfesteem on peut re-assembler le graph simplifié et en refaire un binaire pour l’analyser dans nos outils favoris genre IDA. On obtient alors un binaire propre, avec les imports patchés et c’est beau. C’est comme aligner les spaguetti dans l’assiette pour les avoir tous bien droit, les boulettes de viande à coté et la sauce à part.
Ensuite on a un exemple d’émulation de shellcode avec le jitter.
(j’arrive plus à suivre…. Serpi 1, n0secure 0).
On peut aussi attacher un stub gdb de debug sur le binaire, et donc debugguer le shellcode sous IDA dans le Jitter.
