SSTIC 2018 - J1

C’est parti pour cette nouvelle édition du SSTIC, avec comme nouvautée cette année un amphi de 800 places dans le couvent des Jacobins. Les barbus & sweat à capuches sont venu en nombre, et je n’ai croisé que deux personnes en costard perdu dans l’assemblée.

Keynote d’ouverture  – Halvar Flake

2x speaker à SSTIC, Thomas Dullien « Halvar Flake » va nous faire une retrospective sur le reverse-engineering tiré de ses expériences. L’outillage à bien changé depuis ses débuts, et maintenant que ça fait 20 ans qu’Halvar utilise IDA, il se considère comme « vieux ».

IDA n’a pas des masses changé en 20 ans, et ça reste son outil préféré pour faire du reverse-engineering. Après 13 ans de RE, Halvar à fait un break de 6-7 ans pendant lequel il a managé des équipes de dev et de sécu. Il s’y est remis, et voila ce que ça fait:

Beaucoup de choses ont évolué: les solveurs sont devenu utilisables pour générer des entrées pour des programmes, plein d’outils de RCE ont fait leur apparition: r2, frida, Angr… Bref il semblerait que plein de problèmes d’il y à quelques années soit résolus. Du coup reverser du C++ devrait être plus simple non ? Ben en fait, quand tu l’essayes sur des cas réels, bah ça marche pas (échec ?). Exemple avec MPENGINE.DLL dont il est difficile d’obtenir des traces de couverture. Le live debug sur les systèmes mobile sont galère à obtenir, etc…

Pourquoi ça ne marche pas très bien ? Certaines raisons sont externes à la communauté du reverse, d’autres sont liés au fonctionnement de cette communauté. Les fournisseurs de plateformes (iOS, Android, etc…) sacrifient très vite la « débuggabilité » pour freiner le reverse à diverses fins de « sécurité » mais qui en fait privilégie les « gros » acteurs offensifs (gamma group, nsa, etc…) qui ont les moyens de les péter, là ou les défenseurs qui n’en ont pas les moyens sont à la traine.

Exemple avec iOS, ou il faut mettre en place des hacks complètement débiles et coûteux pour pouvoir déboguer une application correctement. Souvent on conseille aux constructeurs de supprimer le JTAG, alors que l’attaque physique ne fait pas parti du threat-model. Du coup on perd en observabilité, et on ne peut pas mettre simplement en place des moyens d’analyse et d’investigation dans ces devices.

Quand on augmente le seuil d’accès au debug sur un device, ont diminue la population capable de travailler sur sa sécurité, et du coup cela maintient la rentabilité des exploits pour les attaquants au long terme. Pour résumer: moins de hackers = un durcissement de la plateforme plus lent, ce qui fait le jeu des attaquants.

Le time-to-market à forcé les developpeurs à « compresser » les temps de dev, déploiement & tests. Du coup il est fréquent qu’ils travaillent sur des devices pas finis, et pas très debuggables, ce qui complique le diagnostique des défauts de ces applications, et donc leur sécurité.

Le marché pour des produits de reverse est très petit, et du coup permet à peine de soutenir correctement entre 12 et 60 ingénieurs dans le monde. Le coût « technique » de conception d’outils de reverse n’est pas récupéré par les ventes du fait de la petitesse du marché des outils de reverse, ce qui complique la rentabilité d’entreprises focalisés sur l’outillage du reverse-engineering. Sans compter que les reversers sont loin d’être de bon développeurs. Souvent des petits scripts tous-pourris écrits à la va-vite deviennent des outils utilisés sur le long terme à défaut d’autre chose. C’est cool de réussir des reverses complexes avec des outils de merde, mais quand on vieillit, on aimerait avoir des outils robustes et professionels. Le problème c’est que la communauté du reverse code pour terminer le taff, et ne prend pas le temps de penser à l’avenir et d’investir dedans. Par exemple, on ne fait pas attention à l’empreinte mémoire des scripts, ou encore à la capacité de distribuer ces calculs sur plusieurs noeuds.

Côté logiciels, un grand nombre de frameworks ont des fonctionnalités similaires, mais ne couvrent pas touts vos besoins en reverse, et certains sont loin d’être stable ou efficaces au niveau cpu/mémoire. « On dirait la communauté JavaScript » tellement il y a de trucs fait en double ou en triple sur X frameworks. Sans compter qu’ils sont parfois développés à coup de deadlines de conférences. Sur le papier, beaucoup de problèmes ont été « résolus », mais en réalité, pour un travail quotidien, ces outils sont loin de tenir leur promesses.

Côté publications: les résultats sont rarement reproductibles, les données ne sont pas disponibles, et la publication des sources n’est pas systématique. De plus à la lecture d’un papier on n’arrive plus à distinguer si l’auteur exagère, ou si le problème à bien été résolu correctement.

Côté outillage, on n’a pas de distribution ou de framework stable orienté reverse engineering.

L’outillage du reverse engineering est très focalisé sur le code source et la récupération de ce dernier, mais peu sur la compréhension de l’ensemble logiciel que constitue l’outil que l’on reverse.

Fin des critiques, voici quelques propositions constructives: Il faut que les développeurs de plateformes logicielles/matérielles les rendent débuggables pour faciliter l’analyse. Il faudrait trouver un moyen d’échanger les données de reverse-engineering de façon standard pour qu’on puisse échanger les outils pour passer du binaire à l’assembleur, de l’assembleur au CFG, etc… Il faudrait des représentation intermédiaires standardisés adaptés au différentes données utilisées et générées par les outils de reverse. Ainsi, on pourrait passer « simplemement » d’un outil à l’autre sans avoir à re-développer tous les scripts & outils existants pour ce nouveau framework.  Une distribution Linux pour le reverse comme il en existe pour le pentest, sur laquelle on pourrait avoir tous les outils nécessaires & interopérables afin de faciliter l’échange d’outils sur cette base. Afin d’améliorer la fiabilité des outils de reverse, il faut des données sur lesquelles tester et valider le fonctionnement des outils de reverse.

Les choses changes avec le Cloud, et maintenant n’importe quel logiciel n’est un tas de petits bouts de code qui tournent sur plein de machines un peu partout dans le monde. On est passé d’un monde ou les OS était fermés et non accessible à un monde et on déboguait sur un seul hôte. Maintenant le debug dans le cloud est un cauchemar car on à pas de « Cloud debugger » permettant de gérer un système si éclaté. L’éclatement des types d’infrastructures CPU/GPU/µC/FPGA présentent un sacré défi pour les outils de reverse. Sans compter qu’on aura peut-être dans le futur à reverser les poids des réseaux de neurones intégrés dans nos appareils pour comprendre ce que font ces composants spécialisés. Le hardware va se spécialiser, et on ne peut pas s’attendre à ce que ces composants soit bien documentés. Une vulnérabilité sur ce type de composants va être très compliqué à gérer pour les défenseurs (ex: spectre/meltdown …).

Backdooring your server though its BMC: the HPE iLO4 case

Une présentation courte sur le ponçage du système iLO4 HP. C’est très répandu chez pas mal de fabriquants de serveurs sous la forme d’un chipset autonome et indépendant du système principal sur base ARM, avec sa propre RAM et sa propre interface réseau. Ce système démarre dès que le serveur est alimenté électriquement.  Souvent en pentest, ces iLO sont exposés sur les VLAN de production, et certains sont même en frontal sur internet. Un premier exploit leur permet d’aller récupérer des informations en mémoire sur le système managé par l’iLO et d’y écrire du code arbitrairement afin d’obtenir un shell via netcat sur le serveur principal. (https://recon.cx/2018/brussels/talks/subvert_server_bmc.html) Le service web de l’iLO fait l’objet de deux CVE depuis un an. Il fait un usage massif de scanf pour parser les headers HTTP (ça ne peut que bien se passer en C…). Il y a quelques buffer overflow dont un dans le header Connection qui permet d’écraser une variable permettant de bypasser l’authentification et d’accéder à l’API REST du iLO.

A partir de cette RCE, les orateurs ont bossé sur le firmware iLO pour patcher le bootloader, pour en suite patcher le noyau et insérer une backdoor userland dans la flash de l’iLO. Le serveur web à été choisi comme cible pour installer la backdoor vu qu’il dispose de toute les primitives de communication, et qu’en plus il à un accès DMA à la mémoire de la machine principale.

Pour installer la backdoor dans le système linux, il faut créer un thread dans le noyau, allouer de la mémoire pour le canal de com iLO <-> Linux, et mettre en place les primitives d’exécution des commandes reçus sur le buffer mémoire. Pour que la backdoor du serveur web fonctione, les orateurs ont du patcher un bug dans ce dernier.

Comment faire pour savoir que son iLO est compromis ou pas ? bah tout simplement en utilisant la vuln pour aller dumper la flash du iLO, et comparer si les hash du firmware correspondent ou non à des serveurs connus.

T-Brop – Taint-based Return Oriented Programming
Dorat – Développement orienté sur la teinte.

Petit retour sur l’exploitation d’une vulnérabilité type buffer overflow, avec les protection qu’il faut contourner en re-utiliser le code existant dans le binaire. Pour ce faire on va réutiliser des petits bouts de code aka gadgets, ces gadgets se terminent souvent par un ret (d’ou le ROP). Le DEP ça suffit pas, il faut aussi utiliser du CFI, etc… Bon quand il s’agit de chercher des gadgets, soit les outils vont faire des grep dans le programme (rp++), soit ils font ça en symbolique mais c’est super coûteux en temps(angrop). Afin d’optimiser ça, les orateurs proposent une approche hybride qui soit plus rapide que l’analyse symbolique, et plus expressif que les approches syntaxiques. Du coup on à un entre-deux moins performant que le syntaxique mais plus rapide que le symbolique. Avec RP++, on se galère à construire notre ropchain à la main en greppant les gadgets qu’on veut.. Avec angrop, il commence par râler parceque le binaire est trop gros, et du coup il passe en « fast mode » ou lorsque le gadget est trop compliqué, il le jette, et ça prend 15 min. T-Brop est un peu plus rapide (7min) et propose quelques gadgets intéressants basés sur rsp & esp, ou sur des données un peu au dessus de la pile.  Pour conclure, Angrop c’est bien pour les cas autoroutes, RP++ c’est pour les pro de la regexp, et T-Brop propose parfois des trucs chelou mais originaux.

Comme indiqué dans le titre, T-Brop se base sur de la teinte pour gérer quel registre dépend de quel autre dans l’enchainement des gadgets. Cette influence se représente sous forme de matrices de dépendances pour chaque gadget. Pour savoir quel impact à l’enchainement de plusieur gadgets sur les registres, il suffit de faire un produit matriciel. En généralisant ce principe, il est possible d’identifier s’il est possible ou non d’influencer tel ou tel registre en enchainant un nombre arbitraire de gadgets, et quels registres il faut contrôler pour pouvoir utiliser la ropchain. L’implémentation se fait à base de python3 avec capstone + scipy + numpy. Le « throwaway script » et disponible sur github (https://github.com/DGA-MI-SSI/T-Brop)

Certificate Transparency – Assurance Maladie

Comment ce nouveau standard permet d’améliorer la veille face aux menaces. La certificate transparency vise à couvrir le risque d’une AC malveillante ou piraté qui signe un certificat sur un domaine wildcard pour lequel il n’a pas l’autorité. Du coup lorsqu’un MITM survient, le petit cadenas vert est tout de même présesent, et l’utilisateur se sent faussement en sécurité. C’est une initiative de Google repris par l’IETF qui force les AC à consigner les certificats qu’elle signe dans un registre ouvert à la consultation. Les navigateurs du coup vont venir contrôler la validité du certificat dans les journaux et viennent positionner une alerte à l’utilisateur si jamais le certificat présenté n’est pas dans les journaux des AC. A l’aide de la certificate transparency, l’assurance maladie à pu mettre en place un monitoring de l’ensemble des certificats émis. Ce qui permet d’identifier les tentatives de MITM, ou encore l’émission d’un certificat dans un sous-domaine sans passer par la DSI (code de monitoring dispo sur https://github.com/assurancemaladiesec ). En surveillant l’apparition de certificats pour des noms de domaines similaires ou proches de celui de l’organisation on peut voir venir les tentatives de phishing. C’est low-cost et efficace (merci à eux d’avoir publié leur outil)

Signaux parasites comprométants

Les orateurs sont des membre d’un labo de l’ANSSI qui bosse sur le TEMPEST. Dans les signaux radio sans fil, il y a les signaux volontairement émis (radio, wifi, bt, etc…), et les signaux radio émis à l’insu du système. Par exemple les écrans cathodique d’antan qui générait un rayonnement qui pouvait être décodé au loin à l’aide d’une antenne. Bon avant, c’était galère et il fallait du gros matos, maintenant avec la radiologicielle (SDR ftw), il faut un piti dongle avec une pitite antenne pour capter ces signaux. Bien que les cathodiques ont disparu, il y a pas mal de composant qui émettent à notre insu, nottament les câbles vidéo entre ordi & écran. Petite démo avec tempestsdr, outil radiologiciel pour recomposer ce type de signal, dont la principale difficulté d’utilisation réside dans sa compilation… Et du coup l’orateur intercepte le signal de son propre laptop de présentation. Le VGA décompose chaque couleur dans un fil, avec les pixels géré en fréquence, et l’intensité lumineuse en… intensité 🙂 Pour le DVI, ils ont fait grosso-modo comme le VGA. Et pour HDMI, ils ont fait comme pour DVI… le son est transmis dans l’image à l’emplacement de la marge. Le signal parasite est généré lorsque l’intensité du signal change, et du coup à chaque pixel ça émet une onde radio. Plus la variation de potentiel est rapide, plus le rayonnement est fort. En VGA, ça va pas vite, donc les fronts sont plus mou, et le rayonnement est plus faible. En DVI, la fréquence est rapide, et les changement de fronts forts, du coup ça rayonne plus, et il ne reste plus que le blindage pour vous sauver. Le blindage doit être complet, s’il y a un trou, bah ça fuite, et votre écran avec. Le problème c’est que la qualité des cables est très variable, Si le capot métallique n’est pas connecté a la tresse métallique du cable bah c’est foutu. Les cables fournis par les constructeurs avec un équipement neuf sont plutôt bons car ils réspectent les normes, alors que les cables individuels sont plutôt mauvais.

A l’usage, il faut privilégier le VGA ou le DisplayPort au HDMI ou au DVI, les murs en métal plutôt qu’en pierre… bref c’est pas facile 🙂

Télévisions connectés: DVB-T et Sécurité

En gros une télé connecté, c’est un ordinateura avec un tuner TNT. Ya tout dessus, wifi, bluetooth, réseau, usb, HDMI. Parfois ces télé sont moins chères que des écrans, et sont souvent déployés dans des salles de réunion en lieu et place d’un vidéoprojecteur ou d’un écran d’ordi. Chaque chaîne qui émet, peut dans une zone donnée de la transmission, distribuer une application ou des fichiers à la télé. La HbbTV utilise ce flux d’information pour récupérer le contenu de l’appli interactive, ou bien une URI pour aller chercher l’appli ou ses ressources. Une appli HbbTV est en fait une page HTML avec une api JS spécifique. Pour éviter l’injection arbitraire d’appli HbbTV, le consortium DVB à ajouté des mécanismes de signature. Reste à savoir comment c’est implémenté ? Bah pas bien, du coup l’attaquant peut « dé-signer » une appli, ne pas signer l’appli, etc… La gestion de la confiance dans la norme se base sur des chaines de certificats, dont le certificat racine peut être fournis soit par une autorité de certification, soit inclu dans le flux DVB sous la forme d’un manager-certificate (fail!). Une « protection » temporelle est en place sur la validation des certificats, mais elle est contournable par l’attaquant modulo un peu de patience en diffusant le manager-certificate jusqu’à ce que la télé l’accepte. (Il est possible sur certaines télé de désactiver les fonctions HbbTV).

Three vulns, one plug – Acceis

Tout est parti de prises connectés en promotion lors d’une visite au magasin de bricolage du coin. Les « smart » plug fonctionnent en wifi avec une technologie d’appairage « smart » pas basée sur WPS, et sans moyen d’entrer manuellement la clef wifi du réseau. La configuration se fait via une application android, ou on entre le mot de passe du wifi, et paf la prise se retrouve connectée au wifi et apparait. Lorsqu’on sniff le réseau et qu’on regarde ce qui s’échange à l’envoi des information de sécurité, on voit passer des paquets wifi complètement random. Les messages sont envoyés vers des IP au pif, et les messages de broadcast sont constitué d’une série de messages de taille fixe, puis des paquets de taille variable qui viennent encoder la clefs du wifi à enregistrer sur la prise. Bref un gros CESAR en side channel via la taille des paquets. Quand on regarde la doc du module wifi, on se rend compte qu’il écoute en UDP, et qu’il accepte des commandes AT qui permettent de faire tout ce qu’on veut avec le module wifi au niveau config. Sur le hard, on à deux port UART qui permettent de récupérer la clef du réseau wifi directement. On découvre dans la doc qu’un mec à implémenté WPS sur le module wifi, mais c’est pas activé. via l’UART l’orateur à mis au point un patch pour activer WPS avec un arduino.

Escape room pour la sensibilisation à la sécurité informatique.

L’objectif de l’escape room est d’apprendre aux joueurs les bons réflexes en sécurité informatique et comment se protéger des attaques d’ingénierie sociale courants. Deux scénarios sont proposé, l’un visant à sécuriser un environnement de travail, et à trouver l’attaquant à l’origine de l’attaque. L’autre consiste en trois participants dont l’objectif est de voler des documents à une entreprise fictive. Le scénario dure 1h, et de nombreux éléments sont disponibles pour éviter l’ennui.

Hacking BLE – digital-security

La technique de base du hacking hardware, c’est de prendre un analyseur logique, on choppe un uart, et hop on à un shell. Bon c’est pas toujours comme ça. En pratique, il faut un peu de méthode. Comprendre le fonctionnement est essentiel, par exemple sur une serrure connectée avec 18h d’autonomie implique forcément l’utilisation d’une technologie basse énergie. Côté hardware, quand on regarde, il n’y a pas de protections électriques contre les surtentions sur le port USB, ou d’élément de repérage de la position du rotor de la serrure. Du coup le logiciel ne sait pas dans quelle position est la serrure. Côté chipset, on identifie rapidement un module BLE, un pilote de moteur. Pour comprendre les interconnexions, on peut utiliser un multimetre, on peut aussi étudier la doc du composant. Une fois les ports JTAG/UART/SWD identifiés, on peut aller tenter de récupérer le firmware pour pouvoir analyser les µLogiciels présents. On peut aussi récupérer les firmwares au niveau réseau ou sur le smartphone lors d’une action de mise à jour. (le syndrome de l’écran noir frappe l’orateur ;( http://blog.eavs-groupe.com/guides-et-dossiers/guide-hdmi-comprendre-ledid-et-le-hdcp-pour-eviter-lecran-noir/ ). Quand on regarde le code, on découvre que la partie authentification de la serrure est complètement cassée. l’orateur présente un man in the middle bluetooth qui lui permet de capturer le jeton d’authentification, et de le rejouer à volonté.

Wookey: usb devices strike back

Conception d’une clefs USB sécurisé chiffrante capable de répondre à une menace type BadUSB. Le tout pas trop cher et partageable en open-hardware/open-source. Dans le cadre de la norme USB, c’est le périphérique qui déclare ses fonctionnalités à l’OS. Si le périphérique ment sur ses fonctionnalités, l’OS n’a que d’autres choix que de faire confiance à la clef, c’est le scénario BadUSB. Côté solutions libres, pas grand chose de correct. L’orateur veux se protéger aussi contre le vol de données à coup de crypto, il faut donc un SoC suffisament solide pour permettre leur mise en oeuvre de façon sûre. L’utilisation d’un secure-element pour stocker les clefs de chiffrement, un clavier/touchscreen indépendant de l’hôte pour la saisie du code pin, un slot µSD pour acceuillir le stockage, et deux ports USB. Le firmware de la clef contient un firmware de boot, et un firmware de backup en cas de pépin. Une partie est reservée pour des éléments de signature crypto, et un mécanisme de mise à jour déclenchable par pression d’un bouton physique. Bien entendu, le JTAG à été désactivé. Chaque module logiciel gérant chaque fonction de la clefs doit bien entendu être isolé des autres. Les orateurs sont donc parti sur un micro-noyau léger et conçu pour un µC dès fois qu’un des composants se fasse compromettre. Comme ils n’ont pas trouvé leur bonheur, ils ont codé le leur, il s’appelle Ewok, et gère les modules applicatifs de crypto, usb, code pin, secure-element. Comment isoler sans mmu ? bah on utilise la MPU pour définir des droits et des attributs sur des régions mémoire. A l’ordonancement, il va jouer sur la conf de la MPU pour n’autoriser que la zone mémoire de l’appli qui va bien, et les seuls registres dont elle à besoin pour fonctionner. Lors d’un switch d’appli, le µNoyau reconfigure les droits d’accès via la MPU pour permettre à la suivante de fonctionner. Pour sécuriser les syscall qui représentent la seule surface d’attaque entre le code des appli et le µNoyau, les orateurs ont utilisé Ada et SPARK. Ainsi, en fonction de la sensibilité ou pas de telle ou telle fonctionnalité, les orateurs ont choisi le langage adapté, du moins restrictif (le C), au plus contraint (SPARK).

Dump de flash sur circuit imprimé

Quand on veut récupérer le contenu d’une flash, traditionellement, on va se brancher sur les pattes de la puce qui vont bien, et hop, on dump. Mais dès fois on tombe sur une puce dont les pin sont SOUS la puce, il faut donc désouder la flash, puis avoir le bon adaptateur ou se fabriquer le sien. L’orateur à décidé de fabriquer le sien. Il faut en suite re-souder la flash sur l’adaptateur, et on peut en profiter.  Sur une flash au format BGA, dans le cas d’illustration, il n’y avait que 8 pin sur les 24 qui était utilisés. A coup de kicad on conçoit son PCB. Méthode chimique avec du toner, du perclo et zou. L’autre technique c’est d’utiliser une CNC pour découper les pistes directement dans le cuivre, puis on ajoute une pâte isolante verte caractéristique, et hop on peut l’utiliser. Pour la soudure BGA à la main, il faut mettre chaque bille au microscope, et c’est très galère. On ressoude en suite la puce à l’air chaud.  Pour l’attaque hardware, on peut microsouder la chip « adaptée » sur le device d’origine. Il faut donc compter 1200€ pour les deux techniques, et un coût par pcb qui est lui négligeable. Si le BGA est grand, genre 64 billes, c’est l’enfer, du coup l’orateur est passé sur une CNC laser pour gagner en précision.