Première édition de recon en Belgique en ce début d’année! Le logo de l’évènement change, mais le programme reste le même: Reverse engineering et exploitation. Du coup, pas une seule conférence n’a oublié son screenshot d’IDA Pro (qui est d’ailleurs le sponsor de l’évenement). Comme pour l’édition 2016 de Montréal, les conférences ont duré trois jours avec une seule track, donc pas de remords ni de regrets. 🙂
Je vous propose un aperçu de quelques conférences de cette première édition Européene:
Hackable Security Modules Reversing and Exploiting FIPS-140-2 lvl3 HSM firmware
Cette présentation traitait de l’analyse d’un firmware de HSM dans le but d’y déceler des vulnérabilités. Un HSM (Hardware Security Module) permet de stocker et gérer des clés cryptographiques de manière sécurisée. Ils sont typiquement utilisés par les autorités de certification afin de protéger l’accès à leurs clés privées.
Le HSM testé est produit par la société Ultimaco et est certifié FIPS-140-2 level 3. Cette certification implique que le boitier dispose d’un mécanisme de détection des intrusions physiques en plus d’un système bloquant l’accès aux clés contenues dans le module. L’appliance est un système Linux doté d’un module HSM connecté en PCIe. Lors du premier démarrage, une clé de chiffrement et une clé de backup sont générées afin de protéger toutes les autres clés stockées sur le système.
La première étape a consisté à décompresser le firmware qui utilisait un format propriétaire (MPKG) et qui contenait différents firmwares pour chaque module de l’appareil au format MTC. Ce format MTC est une version modifiée du standard COFF. Après l’avoir reversé, le code binaire a pu être extrait. Sauf que le HSM utilise un processeur de signal (DSP) TMS320C64x produit par Texas Instrument qui n’est pas pris en charge par les logiciels de désassemblage classiques. Ainsi il était nécessaire de créer un module de désassemblage pour ajouter cette architecture dans Capstone. La complexité de l’architecture a rendu la tâche très ardue mais finalement le code a pu être désassemblé.
L’analyse du code a permis de mettre en évidence au moins une vulnérabilité. En effet, un contrôle est effectué au moment d’ouvrir une base de données afin d’empêcher l’accès aux clés. La routine de vérification contrôle que la base de données ne soit pas la chaine de caractères VMBK1 (nom de la base contenant la clé de backup). Sauf que le nom de base peut être préfixé par la localisation de cette dernière, ainsi FLASH\VMBK1.db permet de récupérer les clés.. 🙂
L’entreprise qui développe le produit à mis près d’une année pour corriger la faille… Cependant il ne lui a fallu que quelques jours après la présentation pour demander à l’auteur de retirer ses outils hébergés sur Github.
Breaking Code Read Protection on the NXP LPC-family Microcontrôlers
L’auteur présente le contournement de la protection Code Read Protection (CRP) implémentée dans les microcontrôlers de la famille NXP LPC. Cette protection permet normalement d’éviter que le code du microcontrôleur puisse être extrait de la flash. Chris Gerlinsky nous montre comment mettre en place une attaque par glitching afin de neutraliser le CRP.
Le contournement débute par l’acquisition d’un microcontrôleur de cette famille. Le chip est programmé avec un code simple qui consite en une boucle infinie dans laquelle deux variables sont incrémentées de manière identique puis comparées. Le but étant de détecter si l’une des deux variables n’a pas été incrémentée correctement à cause d’un glitch.
Un circuit particulier (Xmega-A1 MAX4619) est utilisé pour générer les glitchs (impulsions de tension basses) en switchant entre deux sources d’alimentation: Une source à la tension nominale (1.9v) et une autre plus basse qui va permettre de générer les erreurs (~0.7v). Ce circuit est directement utilisé pour alimenter le microcontrôleur. Des glitchs sont ensuite générés en variant la tension basse afin de trouver une valeur qui génère un maximum d’erreurs dans la comparaison des deux variables incrémentées sans interrompre l’alimentation du microcontrôleur. L’étape suivante consiste à faire varier la longueur des impulsions et finalement de décaler l’impulsion dans le temps afin qu’elle affecte la vérification du flag CRP.
Lorsque l’impulsion arrive au bon moment, le résultat de la comparaison du flag CRP est modifiée et l’accès au bootloader est autorisé permettant ainsi de lire la flash.
Le code du module de glitch est disponible sur github.
Transforming Open Source to Open Access in Closed Applications
Un grand nombre de logiciels propriétaires intègrent du code Open Source afin de réduire le temps de développement et par conséquent les coûts. Cette démarche à cependant un certain nombre de désavantages en termes de sécurité qui ne sont pas forcément pris en compte par l’éditeur du logiciel. D’une part, les mises à jour du logiciel Open Source doivent être intégrées dans le projet ce qui retarde la correction effective des vulnérabilités dans la solution propriétaire. D’autre part, l’abandon d’un projet Open Source utilisé expose fortement le logiciel dont le/les composants ne seraient plus mis à jour.
Ce cas de figure est illustré dans la présentation par le logiciel Acrobat Reader. En effet, le moteur de traitement XSLT d’Acrobat est basé sur le projet Open Source Sablotron, qui a cessé d’être maintenu en mai 2015. Les auteurs utilisent une technique de matching de code binaire pour trouver des correspondances entre le code propriétaire et le logiciel Open Source.
L’analyse du code source des fonctions/parties reprisent a permis de mettre en évidence plusieurs vulnérabilités critiques (exécution de code) dans le lecteur de PDF.
miLazyCracker
Kevin Larson a apporté sa pierre à l’édifice du cracking NFC contre les cartes Mifare Classic et Mifare Plus. Il a présenté son outil miLazyCracker qui, faute d’améliorer l’attaque, rend l’exploitation extrêmement simple. En effet, l’outil développé n’attend aucun argument et se met en attente d’une carte Mifare. De plus il exploite un hardware bon marché, le SCL3711.
Vous trouverez son outil directement sur Github miLazyCracker.
Teaching Old Shellcode New Tricks
Le framework Metasploit utilise une technique baptisée Stephen Fewer’s Hash API (SFHA) qui permet de simplifier l’appel d’une fonction particulière de l’API Windows en utilisant un hash. Les solutions antivirus ont fini par utiliser ce pattern afin de détecter Meterpreter (la partie cliente de Metasploit). De plus, l’outil EMET de Microsoft détecte et bloque l’exécution de shellcode qui emploie cette technique.
Ce talk présente une technique basée sur IAT / LLAGBA qui permet de remplacer le SFHA. L’outil développé traite un payload généré à l’aide de msfvenom et remplace le stub SFHA afin de bypasser EMET. En plus de cela, il permet de supprimer les hashs originaux afin de limiter la détection du payload par les anti-virus.
Pour son outil, c’est par ici: fido.
Harnessing Intel Processor Trace on Windows for fuzzing and dynamic analysis
Cette présentation décrit la nouvelle fonctionnalité intégrée dans les processeurs Intel de génération Skylake, à savoir Intel Processor Trace. Cette fonctionnalité permet de tracer l’exécution d’un programme directement en hardware, ce qui réduit largement la charge CPU nécessaire au suivi.
Les deux présentateurs travaillent sur le développement d’un driver Open Source pour Windows qui supporte le multiprocesseur. Un plugin permettant de visualiser la trace directement dans IDA Pro est également disponible. Le code du driver et du plugin sont disponible dans ce repository WindowsIntelPT.
Le driver active la fonctionnalité dans le processeur. Ce dernier commence alors à enregistrer les instructions dans plusieurs fichiers de log (un par processeur logique). En parallèle le driver collecte certaines informations sur la mémoire. Les différentes informations récupérées sont croisées avec le binaire lui-même afin de retracer l’exécution. Finalement le plugin IDA permet de charger la trace et de visualiser graphiquement le chemin d’exécution. D’après les conférenciers, un overhead de l’ordre des 10% serait constaté.