recon 2016

Première fois à recon et, oh waww! Assez différente des autres conférences, recon (dont le site web est recon.cx et non recon.com) est fortement orientée sur le Reverse Engineering et l’exploitation, que ce soit hardware ou software.

Étalée sur 3 jours avec une seule track, la conférence est pleine de talks à la fois intéressants et hallucinants, que nous tentons donc de résumer dans ce long post!

Hardware-Assisted Rootkits and Instrumentation: ARM Edition

Cette première présentation introduit le PMU (Performance Monitoring Unit), une extension CPU présente sur de nombreux systèmes ARM permettant d’obtenir des informations du système en temps réel. En fixant un compteur de -1 sur une instruction il est possible de recevoir une ISR (Interrupt Service Request), et ainsi d’accéder à une capture des registres au moment de l’instruction.. ou presque, puisqu’un délai appellé “skid” peut survenir entre l’instruction et l’interruption associée, auquel cas il est nécessaire de s’adapter par différents mécanismes.
Il est alors possible d’utiliser les propriétés du PMU afin de hooker des instructions tel que SVC sur ARM afin de surveiller les syscalls effectués sans patcher directement l’Exception Vector Table (EVT), qui est la technique classique intrusive, susceptible d’être détectée par des outils de sécurité.
2 exemples de monitoring des syscalls via le PMU sont alors présentées:

  • rootkit classique sur Android qui cache des fichiers / processus en hookant getdents, et une autre démonstration sur read()
  • détection/prévention d’attaque ROP, de façon similaire à la détection de stack pivot EMET sur Windows en monitorant l’état de la stack lors de requête mprotect (démonstration contre l’exploit Stagefright). Évidemment c’est ici une mesure basique loin de vraiment bloquer le ROP, mais une démonstration intéressante

Black box reverse engineering for unknown/custom instruction sets

L’auteur a présenté “deux” techniques:

  • On triche car l’architecture n’est en réalité pas inconnue et il existe de la documentation (datasheets, press release, etc.)
  • Il n’y a pas de documentation et il faut donc statistiquement analyser les données.

Bien entendu, la présentation s’est focalisée sur la deuxième partie. On peut en général visualiser les interrupt table ou les vector table, et a grand coup d’analyses statistiques, il est possible de déterminer quelle instruction est le call et en déduire laquelle est le ret. Les instructions push/pop apparaissent aussi avant les call/ret et des comparaisons sont généralement utilisées juste avant les jump. En procédant ainsi il est possible de commencer à écrire un désassembleur pour l’architecture et déduire d’autres instructions.

Une partie dynamique consiste alors à capturer les états, et si l’instruction mov est connue, déduire ce que font les autres instructions basé sur ces états via un “oracle“.

Visiting The Bear Den

Les analystes de ESET décrivent ici leur suivi des activités d’un groupe d’attaquants connu sous plusieurs noms dont APT28, Fancy Bear, sofacy… qui est connu pour avoir ciblé des embassades et ministères dans plus de 40 pays ainsi que l’OTAN. Ces derniers commencent leur attaque par du spear phishing, et utilisent plusieurs 0days (flash, windows, office) afin d’exécuter du code arbitraire, élever les privilèges et établir une communication chiffrée avec des serveurs de C&C (malware Sednit). L’exploit kit – SEDKIT – se compose de plusieurs composants dont un dropper en delphi, un bootkit, un rootkit, un outil de pivot… l’éventail d’armes attendu pour une APT.

Un aspect intéressant de l’analyse est la présence de quelques fails découverts tel que l’oubli de configurer bitly en mode privé permettant ainsi de découvrir les URLs, le code C++ commenté du composant XAGENT laissé en ligne, ou encore du code et messages de debug laissés dans les exploits (non obfusqués).

Shooting the OS X El Capitan Kernel Like a Sniper

La team Keen (aka Team Sniper à pwn2own 2016) introduit tout d’abord les mitigations présentes dans le dernier kernel OS X: les classiques kASLR, DEP, SMEP et SMAP (qui est supporté par le hardware des derniers mac). La structure vm_map_copy – utilisée pour garder une copie de certaines données, et cible privilégiée des exploits kernel pour obtenir un arbitrary read – a par ailleurs été modifiée: le pointeur kdata a été retiré, puis une vérification a été ajoutée sur le champ size qui se faisait alors utiliser afin de contourner la première mitigation. Ces dernières rendent l’exploitation bien plus complexe malgré la présence d’un TOCTOU possible sur la vérification du champ size.

Leur observation est que la kslide fixée pour l’ASLR du kernel 64-bit est relativement faible, avec une couverture d’environ 512MB. Il est donc possible de faire du Heap Spraying afin d’obtenir de façon fiable des données contrôlées à une adresse fixe, dont des adresses kalloc‘ed et une ropchain kernel permettant de contourner SMAP/SMEP.

Ils démontrent ensuite cette technique sur leur exploit pwn2own: un bug permettant un write-what-where restreint de 8 floats dans un range de [-0xFFFF:0xFFFF]. Afin de l’exploiter ils sprayent la mémoire en mettant un tag (0x41414141) à un endroit précis, itèrent sur tous leurs objets jusqu’a retrouver ce tag, puis avancent octet par octet jusqu’à obtenir une adresse de vtable, permettant ainsi de retrouver l’adresse de base du kernel. Ils peuvent alors ensuite remplir à nouveau leurs objets avec une ropchain et finir par réécrire la vtable afin de pivoter dans la ropchain.

JavaJournal

La plupart des reversers sont réticents à lire du code Java. Bien que le bytecode se décompile facilement, reverser du code Java obfusqué dans lequel toutes les classes, méthodes et variables sont renomées en variantes de oO0o0O() s’avère vite pénible.
JavaJournal s’intéresse alors plutôt à la création de traces Java pour extraire les informations au runtime (tel que des chaînes de caractères déchiffrées), en tracant un processus Java avec le Java Debug Wire Protocol. L’application et le framework pyspresso sous-jacent sont codés en python et disponible sur github.

The Remote Metamorphic Engine

L’objectif du RME est d’obfusquer du code afin d’empêcher l’analyse par un reverser ou par une intelligence artificielle d’AV avec machine learning. Le concept (simplifié) est d’avoir une zone “trusted” à distance, et une zone “untrusted” en local qui exécute du code polymorphe/métamorphe en utilisant un challenge envoyé par la zone trusted . Le code est généré de sorte à ce qu’il faille exécuter le challenge pour y répondre, et de nombreuses mesures de détection de modification de la mémoire, détection d’émulation / debug, et d’obfuscation sont ajoutées pour complexifier le tout.

La question qui persiste toutefois est l’intérêt pratique de toute cette complexité puisqu’un analyste pourrait toujours analyser les syscalls effectués sans être détecté; tout le reste des opérations pourrait alors s’effectuer de manière beaucoup plus simple directement à distance dans la zone trusted

BBS-Era Exploitation for Fun and Anachronism

Cette présentation revient à l’ère du modem, avant l’apparition d’Internet, en gardant les connaissances d’exploitation modernes. Les BBS – Bulletin Board System – n’étaient évidemment pas sujets aux protections actuelles telles que DEP, ASLR, /GS, SafeSEH ou encore CFI… un fuzzing simpliste est suffisant pour découvrir des vulnérabilités, et l’exploitation s’avère donc très simple.

Ils ont terminé par une démonstration d’exploitation de RIPTerm.exe dont le payload lance le jeu Doom.

Dangerous Optimizations and the Loss of Causality

Les compilateurs optimisent le plus possible le code compilé, en enlevant typiquement le code jugé inutile ou inatteignable, sans forcément retourner de warnings à la compilation. Un exemple serait de tenter de détecter les integer overflows avec un code tel que if (ptr + len < ptr || ptr + len > max_ptr), que le compilateur pourrait optimiser en if (ptr + len > max_ptr) si len est unsigned, rendant ainsi le code vulnérable.

La recommandation est alors d’éviter les comportements indéfinis (ex: if (len > max_ptr - ptr)) et d’ajouter l’option -Wstrict-overflow=N à la compilation pour mieux détecter ces comportements.

Breaking Band

Cette recherche a été motivée par le lancement de Mobile PWN2OWN en 2012 avec un prix de départ de 100’000 $ pour un exploit dans un baseband. Pour rappel, le baseband est un système embarqué dans les téléphones mobiles et permet la communication sur les réseaux mobiles. Personne n’avait gagné ce prix jusqu’en 2015, ou l’équipe de Comsecuris a finalement exploité un baseband de Samsung Galaxy S6 pour la modique somme de 150’000 $.

Le baseband du S6 edge utilise le processeur cellulaire “Shannon”, à priori développé par Samsung. Il s’occupe de toute la couche mobile, 2G-4G, la carte SIM, la communication avec le système, etc. L’architecture est un ARM Cortex-R7. Afin de débuter l’analyse, les chercheurs ont d’abord tenté de reverser le blob binaire contenu dans les mise à jour de firmware Samsung. Ce dernier était composé d’un code de démarrage (bootstrap) et d’un binaire de 38MB, ayant une forte entropie. Ils n’ont pas réussi à le déchiffrer de manière statique.

Ils ont ensuite découvert qu’il était possible de générer des ramdump du CP (cellular processor) via la commande cbd (root) ou encore depuis le téléphone en utilisant le code *#9090# (spécifique à samsung) et en forçant le dump. Cela a permit de récupérer le binaire de 38M depuis le dump de 130MB en clair. Afin de le reverser plus facilement, ils ont ensuite identifié les fonctions au moyens de strings de debug, et les chemins des nom de fichiers. Ils ont ainsi pu générer ~20’000 functions nommées et il a fallu ensuite reverser les tâches kernel et la gestion de la mémoire.

Ils ont ensuite cherché des moyens de débugger les crash, et ont trouvé que les commandes AT permettent de lire ou d’écrire dans la mémoire (entre autre), permettant ainsi de connaître l’état de la pile au moment de crash. Pour rechercher des failles dans le baseband, ils ont identifié les fonctions gérant les messages dans la couche réseau L3 et ont pu retrouver le handler de messages 3G.

Un bug a été rapidement trouvé dans la gestion de message “PROGRESS” ou l’élément envoyé spécifie sa valeur et sa longueur, permettant d’effectuer un stack buffer overflow classique. Leur poc démontrait la prise de contrôle en redirigeant les appels reçu par la victime suite à un SMS reçu. Ils ont terminé leur présentation avec quelques pistes possibles pour escalader d’une compromission de baseband vers l’OS du téléphone.

Process Failure Modes

Alors que relativement simple à effectuer sur les systèmes UNIX, la création sécurisée de nouveaux processus sur Windows peut s’avérer complexe et peut être abusée à des fins d’élévation de privilèges.

Typiquement des problèmes liés à l’impersonation de l’utilisateur peuvent surgir lors de la création par un service privilégié (Task Scheduler, UAC, …); plusieurs exemples d’anciens bugs découverts dans Windows sont ainsi présentés, tel que l’utilisation du jeton d’accès (token) du service plutôt que celui de l’utilisateur, l’absence de token par l’utilisation de CreateProcess – qui lorsque lancée en contexte d’impersonation d’utilisateur laisse à l’utilisateur la possibilité de définir son propre handler d’exécutable afin de lancer une autre commande (avec les privilèges du service) que celle hardcodée dans l’application, la création d’un processus en Session 0 (utilisée pour les services) avec un token anonyme – ce qui peut avoir plusieurs conséquences tel que d’ouvrir la porte à d’autres attaques comme que le squatting de nom d’objet.

Le dernier exploit présenté est un bug de reference cycle provoqué par l’impersonation d’un LowBoxToken (AppContainer). Les objets du kernel restent présents tant que leur reference count n’atteint pas zéro. Puisque le bug maintient le reference count et permet donc de conserver un objet de processus malgré qu’il soit terminé. L’exploit “raising the dead” parvient alors à en abuser pour effectuer un Session ID Use-After-Free, nécessitant de se déconnecter et attendre qu’un administrateur se connecte et réutilise l’ID de session.

Quelques tricks pouvant induire en erreur les équipes de réponse à incident sont ensuite présentés, tel que la suppression d’un exécutable en cours d’exécution, l’exécution directe de DLL en processus, ou encore confondre WMI et Process Explorer afin qu’ils voient le chemin d’un autre exécutable.

How Do I Crack Satellite and Cable Pay TV?

Probablement la présentation la plus impressionnante techniquement. Chris Gerlinsky s’est attaqué au protocole Digicipher 2 utilisé dans de nombreuses set-top-boxes aux USA.

Il s’est focalisé sur le chiffrement utilisé pour le flux vidéo, et surtout comment le casser. Ayant identifié le chip responsable du déchiffrement en hardware sur un boîtier, il a entrepris de mapper les pins afin de trouver lesquelles pouvaient être reliées à quoi sur le PCB. Il a ainsi pu identifier qu’une batterie alimentait le chip, donc que les clés étaient probablement stockées en RAM et paramétrées par le constructeur en usine.

Chris a alors décidé de décaper le chip à l’acide couche par couche, et de l’observer au microscope électronique. Ceci a permis d’extraire visuellement la ROM bit par bit (!) et reconstituer le firmware exécuté sur le chip. Le CPU a été identifié comme un Motorola 6502.

Il a ensuite tenté de glitcher ce chip pour essayer d’obtenir une exécution de code en redirigeant le flux d’exécution sur la pile, permettant à terme de lire la mémoire et d’extraire les clés de chiffrement. En envoyant son payload via le bus SPI et en glitchant l’alimentation du chip, il a pu exécuter son shellcode, consistant en une boucle infinie de réception de shellcode sur le bus SPI. Le dump optique de la ROM a alors pu être comparé à celle lue via le shellcode. La comparaison bit à bit a montré un taux d’erreur de seulement 0.04%!

Le chip en test ayant été dessoudé du PCB, la RAM est donc vide. Il a par la suite ponté les pins d’un autre chip sur une batterie externe afin de maintenir les données en RAM avant de le dessouder à son tour. L’implémentation DES a alors été analysée car les résultats démontraient un algorithme non standard. Certains bits étaient en effet XORés lors de la lecture des données chiffrées avant le déchiffrement.

Il a finalement implémenté le tout en software et visualisé la mire d’attente d’un programme en pay per view. La présentation se conclut par “This was somewhat useless as there is nothing worth watching on TV

Monitoring & controlling kernel-mode events by HyperPlatform

HyperPlatform est un hyperviseur qui se veut simple à étendre et rapide d’exécution (contrairement à Boschs par exemple), tout en supportant les versions modernes de Windows (7-10 x86/x64). Le code est open-source ici.

L’hyperviseur est basé sur Intel-VT et hook les événements VM-exit, fournissant ainsi le contexte d’exécution et l’accès à la mémoire avec EPT. Cela permet alors de créer une API rapide et invisible du point de vue de l’OS. Le but original était d’analyser la protection patchguard du kernel Windows, mais les possibilités d’utilisation sont nombreuses. Une démonstration de EopMon basé sur HyperPlatform montre alors la détection et prévention d’une attaque de vol de jeton d’accès à des fins d’élevation de privilèges.

More Flash, More Fun!

Flash, bien que supposé être en voie de disparition, reste la cible privilégiée des attaques sur les navigateurs*. Sa surface d’attaque se décompose en 3 composants:

  1. ActionScript 2 (AS2): ensemble d’APIs ancien et réduit ayant de nombreux bugs mais dont l’exploitabilité peut s’avérer complexe
  2. ActionScript 3 (AS3): plus récent, moins de bugs mais exploitation plus simple
  3. “anticorpus”: les fonctionnalités présentes en dehors des langages de script: parseurs MP4, décompression…

En plus d’être affecté par les bugs tels que Heap Overflow ou Use-After-Free, Flash est notoirement susceptible aux bugs de Type Confusion, qui surgissent lorsqu’un type est casté en un autre “mauvais” type invalide avant utilisation, permettant alors d’écrire des valeurs arbitraires qui se retrouvent utilisées en pointeur par l’autre type.

Afin de complexifier l’exploitation et éviter les techniques classiques tel qu’écraser le champ size dans un Vector adjacent afin d’obtenir un arbitrary read/write, plusieurs mitigations ont été introduites, tel que l’isolation des classes utilisées de façon récurrentes dans les exploits dans un heap différent et l’application de checksums sur les structures sensibles. Évidemment ces derniers ne suffisent pas à bloquer toutes les attaques, ce qui est démontré en décrivant un exploit dans le reste de la présentation.

A Monitor Darkly: Reversing and Exploiting Ubiquitous On-Screen-Display Controllers in Modern Monitors

La journée s’est terminée par une présentation assez drôle, de par les slides mais aussi de la mise en scène faite par cette équipe de chercheur qui ont remarqué par hasard qu’un nouvel écran s’affichait en tant que device DDC. Après pas mal de recherche, ils se sont lancés dans le reversing du firmware et de l’OSD de leur écran, afin de pouvoir afficher n’importe quoi.

Plusieurs exemples ont été présentés avec une licorne apparaissant sur l’écran, ou encore l’affichage d’un cadenas vert dans firefox lors de l’accès à 4chan.

Sol[IDA]rity

Sol[IDA]rity est un nouveau plugin alternatif pour effectuer du Reverse Engineering collaboratif dans IDA. Plusieurs projets s’y attèlent déjà, mais ces derniers sont soit difficiles à utiliser, soit nécessitent l’utilisation de services externes.

Ce plugin permet de créer un projet (un par binaire), et de partager les modifications effectuées avec certains utilisateurs choisis: structures, noms/types de fonctions/variables, contenu décompilé par hex-rays, etc. Le tout en temps réel, avec la possibilité de se resynchroniser (replay des modifications) lorsqu’on se reconnecte au serveur.

Sol[IDA]rity est implémenté tout en python et hook de nombreux composants Qt afin de customiser IDA. Le code du client et du serveur devraient être open-sourcé, et on ne peut être qu’impatient de tenter de l’utiliser!

Des démonstrations sont disponibles sur https://solidarity.re/

Keystone: the last missing framework of Reverse Engineering

Après avoir publié les frameworks Capstone (désassembleur) et Unicorn Engine (émulateur CPU), le seul composant manquant à l’auteur était un assembleur: Keystone. L’objectif de ce dernier est d’exposer un framework simple d’utilisation et de le maintenir à jour avec les instructions ajoutées par les derniers CPUs, sans faire le choix simple mais lent d’utiliser masm ou binutils et de parser l’output.

De même que les 2 autres frameworks du même auteur, Keystone est multi-architecture et multi-plateforme, dispose d’une API C/C++ et de bindings pour python et quelques autres langages hipster. Keystone est implémenté au dessus de LLVM, ce qui lui fournit un très bon support de par l’implication de plusieurs vendeurs CPU dans le projet.

When Governments Attack

L’EFF (Electronic Frontier Foundation) agit sur plusieurs sujets tel que défendre les droits digitaux aux tribunaux, publier des articles sur la loi & la confidentialité, ou développer des projets tel que le récent Let’s Encrypt. Dans cette présentation plusieurs scénarios d’attaque effectués par des gouvernements contre des journalistes et activistes sont décrits, et révèlent que les attaques n’ont pas nécessairement besoin d’être sophistiquées pour marcher: des bloggeurs vietnamiens étaient ciblés par des fichiers Office malicieux, l’Éthiopie en utilisant des techniques similaires avait installé l’outil de surveillance FinFisher sur l’ordinateur d’un citoyen américain, ou encore des appels téléphoniques de Social Engineering ont été tentés sur des personnes travaillant en relation avec des activistes iraniens.

Des domaines qui n’appartenaient plus à l’EFF tel que electronicfrontierfoundation.org ont été utilisés dans des attaques plus sophistiquées tel que Pawn Storm (Russie?), qui de leur expérience inclut l’utilisation conjointe de spear phishing et de 0days Java (Désactivation du click to play + vulnérabilité de désérialization d’objet) pour finallement déployer le malware Sednit.

Reverse Engineering ISC controllers

Après avoir vu le cours Coursera “Computer Architecture”, l’auteur a décidé d’acquérir une carte FPGA Xilinx afin de développer son propre processeur. Par la suite, il s’est rendu compte qu’il n’était pas possible de le faire depuis Linux. Il s’est donc concentré sur le reversing des outils de Xilinx afin de développer une librairie opensource permettant de communiquer avec n’importe quelle board FPGA.

L’auteur a d’abord analysé le traffic USB du controlleur Xilinx, dumpé son firmware et reversé le protocole utilisé par ce controlleur pour communiquer en JTAG vers les boards. Certains des outils développé sont publiés sur github :

https://github.com/diamondman

Abusing the NT Kernel Shim Engine

Le Kernel Shim Engine (KSE) est un composant non documenté du kernel Windows permettant d’intercepter divers appels effectués par les drivers. La structure utilisée par ces derniers (fonctions Kse du kernel) est obtenue par Reverse Engineering due à l’absence de symboles.
Le KSE permet de poser des Device Shims et Driver Shims. Par défaut Windows enregistre et utilise plusieurs shims, dont certains built-ins: KmWin7VersionLie (falsifie la version de Windows perçue par le driver), KmWin8VersionLie, KmWin81VersionLie, SkipDriverUnload (curieux..), DriverScope… La setup du KSE est contrôlé par des clés de registre et la Shim Database (SDB). Dans un premier temps l’IAT est hookée, puis les callbacks et gestionnaires d’IRPs (I/O Request Packets).
Le KSE permet donc d’intercepter proprement de nombreux appels intéressants dans le kernel, et semble donc être une bonne cible pour les malwares (ou solutions anti-malware).
La fin de la présentation introduit DriverMon: un outil graphique de monitoring de l’activité des drivers, qui devrait être ajouté à cette URL dans un futur proche.

Movfuscator-Be-Gone

L’instruction mov a été prouvée Turing-complete il y a quelques années. L’année dernière un obfuscateur nommé M/o/Vfuscator a été publié, qui compile un programme en instructions mov seulement, anéantissant alors le CFG et rendant le code beaucoup plus dur à reverser. Cette présentation introduit le Demovfuscator, qui rétabli le CFG (testé sur des épreuves de CTF) en utilisant une combinaison de static taint analysis et le solveur SMT z3.

Defcon 2014

Ah, Las Vegas…

Comme chaque année, une délégation de SCRT s’est rendue dans la capitale du jeu pour participer à la conférence Defcon. Cette année toutefois, sept ingénieurs ont pris part à cette expédition :

  • Une personne pour assister aux conférences
  • Une personne pour participer en tant que conférencier (et au CTF)
  • Le reste de l’équipe (6 personnes) pour participer au Capture The Flag

Après un week-end plutôt intense, voici un petit aperçu du CTF tel que nous l’avons vécu.

Capture The Flag

Le challenge Capture The Flag de Defcon est le plus prisé des concours de ce type. Son fonctionnement est un peu différent de concours comme Insomni’hack où il s’agit uniquement de résoudre des énigmes et épreuves techniques. Ici, chaque équipe se voit attribuer un serveur sur lequel plusieurs services sont disponibles. Chaque service renferme un “flag” qui doit être protégé et ce flag change toutes les cinq minutes. Chaque équipe possède les mêmes services et le but du jeu est multiple :

  1. Garder ses services fonctionnels durant tout le jeu, sous peine de perdre des points si le service ne répond plus
  2. Analyser les services afin de trouver les vulnérabilités qu’ils contiennent et :
    1. Corriger ces failles pour que les adversaires volent plus vos flags sinon, perte de points.
    2. Exploiter la vulnérabilité chez les adversaires afin de voler leurs flags, et ainsi gagner des points.

Comme on peut le voir, la tâche n’est pas de tout repos, et l’action est permanente, ne laissant que peu de répit à toute l’équipe.

Qualifications

Nous avons obtenu notre place en finale de justesse après avoir terminé en dix-septième place aux qualifications qui ont eu lieu un peu plus tôt dans l’année. Cette place nous a permis de nous retrouver parmi les vingt équipes qualifiées.

flag

Une fois dans la salle, un bloc de tables était attribué à chaque équipe. Un unique câble permettait de se connecter au réseau du jeu, qui nous a permis de nous connecter à notre serveur. Cette année, le serveur fonctionnait sur une carte ODROID U3 (processeur ARM) avec une distribution Ubuntu. Les organisateurs ont laissé une heure aux équipes pour mettre en place leur stratégie avant d’ouvrir le réseau, et ainsi commencer les hostilités.

Epreuves

En début de jeu, seuls deux services étaient proposés aux équipes, puis les organisateurs ont progressivement ajouté de nouveaux services, augmentant le nombre de paramètres à prendre en compte au cours du jeu.

Une épreuve très originale se présentait sous cette forme :

badge

Ce badge fonctionne avec un FPGA et possède un émetteur/récepteur radio. Il permet d’envoyer et de recevoir des messages aux autres équipes. Le processeur utilisé est un MSP430 modifié et une version du firmware est accessible pour analyse.

Au final, cinq services étaient disponibles. Certains d’entre eux ont été mis à jour plusieurs fois au cours du jeu, mais restaient sensiblement identiques tout en retirant on introduisant de nouvelles vulnérabilités.

La plupart des services étaient des binaires ARM – dynamique et statique – vulnérables à des corruptions mémoire, en particulier buffer overflows et Use-After-Free. Cette année nous retrouvions les services suivants:

  • Un jeu de space trading (binaire x86 lancé par qemu)
  • Un serveur Web
  • Un serveur imap
  • Un protocole binaire inventé par les organisateurs

Attaque

Comme les équipes n’ont pas d’accès root sur les serveurs de jeu, il n’y a pas de possibilité d’analyser le trafic réseau entrant. Les organisateurs ont bien entendu prévu une solution à ce problème et proposaient de télécharger le trafic réseau des cinq dernières minutes de jeu, et ce pour chaque équipe.

Une tactique de jeu que nous avons utilisé consistait à analyser le trafic réseau d’une attaque réussie, de récupérer l’exploit d’une autre équipe et ainsi de gagner du temps sur l’exploitation d’une vulnérabilité.

Toutefois il n’est pas possible de se contenter d’analyser et de rejouer les attaques des autres équipes: plusieurs vulnérabilités ne sont pas immédiatement rejouables et nécessitent une bonne compréhension du binaire affecté et du chemin d’exécution menant à la vulnérabilité. Il est donc nécessaire de consacrer beaucoup de resources sur le reverse-engineering des binaires afin de comprendre leur fonctionnement, trouver des vulnérabilités, les patcher puis les exploiter.

Défense

Le maintien du serveur est également une tâche difficile tant les attaques sont nombreuses et leur suivi difficile. Le maintien des services opérationnels est important puisqu’il influe directement sur le score. Dès lors, de nombreux scripts et outils d’analyse ont été mis en place pour que nous ayons un suivi presque continu sur de nombreux éléments du système, comme par exemple :

  • les fichiers créés par les services
  • les modifications des services en eux-même
  • la limitation du temps d’exécution des services

Au cours du jeu, certaines failles ont permis aux équipes d’obtenir un shell sur les serveurs adverses. Dès lors, une partie du travail du sysadmin consiste a constamment surveiller les processus du serveur et de tuer les processus non désirables en attendant un patch de la vulnérabilité exploitée. Tâche rendue compliquée par la créativité de nos adversaires pour maintenir un accès à notre serveur. A titre d’exemple, nos scripts ont tué environ 1338 processus /bin/sh sur la journée de dimanche…

Conférence – “Playing with car firmware… or how to brick your car”

photo

Cette année (et pour la deuxième année consécutive),  nous avons également eu la chance d’être sélectionnés pour présenter un sujet lors de cette 22ème édition de Defcon.

De nos jours, les voitures ne sont plus purement mécaniques. Les véhicules actuels contiennent tous de nombreux composants électroniques (ECU) reliés entre eux grâce à un réseau (CAN BUS).

Les communications sur le réseau CAN Bus sont d’ailleurs quelque chose de normalisé grâce aux standards ISO-TP ou ISO 15765-2.
Ces différents ECU surveillent et contrôlent en permanence l’état du véhicule.
Plusieurs travaux de recherche ont d’ailleurs été présentés lors de la dernière édition de Defcon, on retiendra entre autres la démonstration assez impressionnante de Charlie Miller & Chris Valasek. Pour rappel, leurs recherches portaient sur les modèles Ford Escape (2010) et Toyota Prius (2010) et ils ont notamment expliqué comment ils avaient réussi à prendre le contrôle de la direction, de l’accélération, du freinage et d’autres fonctions importantes de ces véhicules. Les chercheurs ont même trouvé un moyen de réaliser des attaques persistantes en modifiant le firmware de l’ECU pour envoyer de mauvais signaux, même quand ils n’étaient plus physiquement connectés aux unités de contrôle.

La plupart des recherches faites jusqu’à présent ont principalement porté sur les interactions possibles avec les différents ECU du véhicule au travers du réseau CAN Bus et plus particulièrement au travers de la prise OBD2.

Je n’ai trouvé que peu de publications concernant les systèmes multimédia qui équipent la plupart des véhicules récents. Ces équipements se matérialisent généralement au travers d’un écran permettant de contrôler le GPS et diverses fonctionnalités du véhicule : Bluetooth, lecteur musique/MP3, lecteurs vidéo, carnet d’adresse, GPS.. mais aussi : climatisation, éclairage, verrouillage centralisé, position des sièges pour ne citer que quelques exemples…

Comme on peut s’en rendre compte ces équipements ont une interaction assez importante avec le véhicule et peuvent contrôler bien plus de choses que le simple volume de la musique.
Il semblerait même que certaines options du véhicule (wifi à bord, télévision…) soient présentes « par défaut » sur tous les véhicules équipés du GPS et qu’il s’agisse juste d’une activation électronique.

….c’est donc le fruit de mes recherches sur ce thème que j’ai eu la chance de présenter pour Defcon.

Utilisateurs codés en dur dans le véhicule, mots de passe “par défaut”, SSID, ranges IP internes du constructeur…. il semblerait bien que l’industrie automobile aient encore quelques progrès à faire dans le domaine de la sécurité…

Ce fut un véritable plaisir de présenter ce sujet à un salle enthousiaste … et, il faut l’avouer, assez impressionnante (tant par sa taille, que par les personnes qui étaient présentes)

Les slides de ma conférences seront très prochainement disponibles sur le site de la defcon (en attendant, si vous demandez gentiment, c’est avec plaisir que nous vous les fournirons)

 

Conclusions

Le CTF fut une vraie réussite, tant sur le système de jeu que sur l’organisation et le niveau très élevé de la compétition.

Defcon reste une “immense” conférence avec les avantages et les inconvénients que cela représente…. il faut être motivés pour faire la queue partout (pour obtenir son badge, pour essayer d’accéder aux salles des conférences, pour manger…) mais c’est une occasion unique de croiser et cotoyer de nombreux passionnés et professionnels de la sécurité informatique.

Nicolas,Paul, Adrien, Michael, Alain,Florian,Karim

SCRT Security day : 13 Juin 2013 à Chavannes de Bogis

/* EN BREF */
Quand : 13 Juin 2013 de 09h30 à 16h30
Ou : Chavannes-de-bogis, hotel Best Western
Qui : SCRT, Fortinet, Fireeye, Entrust, Juniper, Barracuda, Varonis
Quoi : démonstrations. nouveautés, réponses à vos questions
inscriptions : par email aurpès de votre contact chez SCRT , avant le 03 Juin 2013, places limitées

/* PROGRAMME DE LA JOURNÉE */
9h00-9h30 : arrivée des participants avec petit déjeuner
09h30 – 10h00 : Introduction par SCRT : nouveautés et évolutions
10h00 – 11h00 : Fortinet
Présentation/démonstration des nouveautés liées à FortiOS 5 : BYOD , Device recognition, wifi, unified access layer…
11h00 – 12h00 : Fireeye
Démonstration de Fireeye, solution de nouvelle génération visant à luter contre les logiciels malveillants avancés (Advanced Malwares), les vulnérabilités non connues (zéro day) et les attaques ciblées (APT Attacks).
12h – 13h30 : Lunch offert
13h30 – 14h30 : Entrust
Démonstrations autour de la solution IdentityGuard (solution d’authentification forte) : nouveautés, solution anti-fishing, démonstration d’intégration avec une application web, vérification des transactions
14h30 – 15h15 : Juniper WebApp secure
Présentation et démonstration de Juniper Web App Secure (anciennement Mykonos) , solution de défense pro-active visant à pièger l’attaquant en temps réel, établir son profil afin d’évaluer le niveau de menace et déployer des contre mesures de protection adéquates en temps réel afin de protéger un site ou application web
15h15 – 16h00 : Barracuda Web Application Firewall
Présentation et démonstration du WAF Barracuda, solution de protection contre les tentatives d’exploitation de vulnérabilités des sites ou d’applications Web
16h00 – 16h40 : Varonis Datadvantage
Présentation et démonstration de la suite Datadvantage de management et protection des données : audits des accès, identification des propriétaires des données, gestion du risque…
à partir de 16h30 : Apéritif offert

/* INSCRIPTIONS */
Événement gratuit.
Le nombre de places étant limité, nous vous remercions de nous confirmer votre présence par email ou téléphone (021 802 64 01), avant le 03 Juin 2013.

Nous nous réjouissons de vous accueillir et de pouvoir répondre à toutes vos questions à la suite des différentes présentations

—-

Compte rendu : Hack in The box Malaysia (HITB)

Hack In The Box Secconf 2012 Malaysia

HITB est l’une des conférences avec la meilleure réputation. Basée en Malaisie, c’est une très bonne occasion de faire un saut en Asie.
Pour le dixième anniversaire, toutes les stars ont fait le déplacement et la proximité avec les speakers a permis de nombreux échanges très productifs.
Les conférences étaient séparées en trois tracks dans le fabuleux “Intercontinental Hotel”.

Jour 1

Practical Exploitation of Embedded Systems – Andrea Barisani & Daniele Bianco
La première conférence portait, comme son nom l’indique, sur l’exploitation des systèmes embarqués.
La première étape consiste à découvrir l’interface console afin de pouvoir ensuite débuguer le firmware.
Pour cela, les pins sont “scannés” à l’aide d’un microcontrôleur afin de déterminer le type de connecteur.
Ensuite l’analyse du firmware peut commencer.
Ils ont alors montré comment découvrir rapidement le type de checksum qui peut être mis en place sur le firmware. Par exemple, la présence de la constante 0x04C11DB7 indique du CRC-32 (qui est le plus courant). Différentes implémentations sont par contre rencontrées, nécessitant une analyse plus profonde.
Finalement pour étudier le kernel, ils ont proposé une méthode intéressante : patcher directement les fonctions dans /dev/mem avec des wrappers. Ces wrappers permettent par exemple d’afficher les paramètres passés à la fonction avant de rediriger l’exécution vers la fonction initiale.
Ils ont terminé par une démonstration sur le protocole SMC d’Apple. Ce protocole est par exemple utilisé pour communiquer l’appui sur le bouton power, le capteur de lumière et autres détails hardware.
Ils ont alors patché ce firmware SMC d’apple.
Une talk plutôt technique et très bas niveau pour bien commencer la journée.

Don’t Stand So Close to Me: An Analysis of the NFC Attack Surface – Charlie Miller
Charlie Miller n’ayant pas pu faire le déplacement, ils ont entrepris de faire la présentation via Skype.
Malheureusement, cette conférence a juste servi à montrer que Skype n’est vraiment pas adapté.
La communication était très mauvaise gachant complétement la présentation.
Juste via les slides, on a pu comprendre qu’il a entrepris un fuzzing massif du NFC sur son téléphone Android.
Résultat : des exceptions Java, et des 0days permettant de l’execution de code via simple scan.

OPSEC: Because Jail is for wuftpd – The Grugq
Un talk non technique cette fois, expliquant toutes les précautions à prendre si l’on décide de mener une activité de “freedom fighter”.
The Grugq est un très bon speaker, sa présentation était très intéressante car ponctuée d’extraits du dossier Lulzsec sur les erreurs qu’ils ont commises menant à leur arrestation.
Conclusion, il faut vraiment avoir une double personnalité pour pouvoir mener ce genre de vie, être parano et tout prévoir longtemps à l’avance.
D’après lui, il faut six mois et environ 2000 $ pour monter une fausse identité.
Il a terminé sa conférence par l’annonce de son projet PORTAL https://github.com/grugq/portal Personal Onion Router To Avoid LEO, un petit routeur encapsulant automatiquement les connections vers le réseau TOR. A suivre…

A Historical Look at The Personal Computer and The Phreaking Scene – John ‘Captain Crunch’ Draper
La légende Captain Crunch donnait un talk sur les débuts du hacking et plus particulièrement du Phreaking. Il a expliqué comment fonctionnait la BlueBox, comment à son époque, les gens s’étaient réunis dans le Home Brew Computer Group pour partager leurs découvertes et a terminé son talk en parlant de ses projets futurs (écriture d’un livre et production d’un film…).

Pwn@Home: An Attack Path to “Jailbreaking” Your Home Router – Fred Raynal
Malgré la conférence sur iOS 6 security ayant lieu en même temps dans un autre track, ce talk semblait mériter un coup d’oeil.
Un ISP français a proposé un audit blackbox du routeur de Monsieur tout le monde.
Ils ont décrit toutes les étapes de leur pentest.
L’exploitation de nombreuses vulnérabilités leur a permis de prendre la main sur leur routeur, mais malheureusement pas de faire de remote code executions assez intéressants pour remonter chez les routeurs voisins.
Beaucoup de choses dans ce talk qui s’est pourtant terminé 20 minutes avant la fin, me permettant de sauter vite dans le track iOS 6 bondé à coté. Un petit bémol, le cheminement des slides/vulns était un peu chaotique, ce qui me laisse quelques incompréhensions.

iOS 6 Security – Mark Dowd
J’ai juste pu assister aux 15 dernières minutes. Le talk avait l’air vraiment très technique. Ils ont expliqué tous les mécanismes de sécurité présents dans cette nouvelle version (ASLR NX…) et comment ils ont tout de même réussi un partial jailbreak avec des heap overflow niveau kernel. Le seul souci de ce jailbreak est qu’il nécessite d’installer une application signée.

IPv6 Insecurity Revolutions Marc ‘VAN HAUSER’ Heuse
Un talk de Van hauser qui est également un très bon speaker.
Il travaille sur l’IPv6 depuis bien longtemps, ce qui lui permet d’amener dans sa présentation des statistiques intéressantes.
Mais rien de nouveau : plus d’IPv4, de plus en plus de CVE mettant en cause les mauvaises implémentations du protocole, plein de techniques de flooding, la fragmentation pour bypasser certains firewalls…
Il a ensuite expliqué comment trouver des hosts dans la multitude d’IP qu’apporte l’IPv6.
D’après ses stats, la plupart des ::1 ou ::2 sont utilisées.
Questionner RIPE permet de retouver des IPv6.
Et bien sûr, le reverse dns leak aussi les adresses IPv6.

Jour 2

Pour des raisons personnelles, la présentation tant attendue de PEDA-GDB a été annulée, remplacée par une “openbottle” rassemblant tous les trolleurs, bref, du master trolling à la place de Thanh ‘RED DRAGON’ Nguyen.

Innovative Approaches to Exploit Delivery – Saumil Shah
Ayant suivi le training de Saumil, je ne pouvais manquer son talk.
Une des meilleures présentations, pleine de lol et d’originalité.
Saumil nous a montré comment rendre vraiment plus sexy les exploits de navigateurs.
Il intègre désormais tous ses exploits dans des images.
En effet, à l’aide des fonctionnalités du canvas HTML 5, il cache son payload à l’intérieur des données alpha d’un PNG.
Il lui suffit alors de charger l’image, puis d’en extraire son payload via un bout de Javascript.
Mais ce n’est pas tout ! Il inclut également le Javascript dans un GIF ou un BMP qu’il charge d’abord en tant qu’image puis en tant que script.
Les images sont bien affichées par le navigateur, en gérant bien le cache, on peut imaginer charger l’image contenant le payload depuis Facebook par exemple, puis une semaine après, loader l’image depuis le cache pour en extraire le payload rendant l’analyse forensique bien plus complexe.

Finding the Weak Link in Binaries – Ollie Whitehouse
Présentation ici de toutes les mitigations mises en place par Windows contre les corruptions de mémoire.
Ollie Whiehouse a ensuite présenté son outil qui permet de rapidement rassembler des informations sur les protections présentent dans un binaire.
Recx binary assurance (son outil) a la particularité de ne pas nécessiter la présence des symboles mais il n’est pas open source… Décevant donc.

Ce talk s’étant terminé rapidement, j’ai pu sauter dans le track de Mikko Hypponen intitulé Behind Enemy Lines.
Mikko est vraiment impressionnant, il présentait ici l’évolution des menaces et s’excusait au nom de l’industrie de l’antivirus de ne pas pouvoir arrêter les James Bond du malware (stuxnet, duqu, flame et gauss) qui sont bien trop ciblés et qui ont bien trop de moyens.

Hacking Huawei VRP – Felix ‘FX’ Linder
FX, roi du troll et du reverse de routeur, a présenté ici sa dernière dissection : les routeurs Huawei.
Rien ne vaut ses slides http://conference.hitb.org/hitbsecconf2012kul/materials/D2T3%20-%20Felix%20FX%20Lindner%20-%20Hacking%20Huawei%20VRP.pdf, la conclusion est simple, total pwnage !

Element 1337 in the Periodic Table: Pwnium – Chris Evans
Chris Evans, le big boss de la team security de Chrome, est venu retracer l’histoire des security reward programs.
Jusqu’à présent, Google a dépensé 650K $ dans son programme pour 489 bugs reportés dans Chrome.
Il est ensuite revenu sur les événements marquants des 0days Chrome. Par exemple, la vidéo que VUPEN avait publié sur YouTube prouvant l’exécution de code, mais sans publier d’informations supplémentaires. Par la simple analyse de la vidéo, la Google security team a réussi à déterminer que l’exploit était dans Flash. Leur réaction face à ça : du fuzzing de masse et l’ajout de flash dans leur sandbox.
Il a terminé par la présentation des résultats du pwnium 2.
Pinkie pie a encore frappé ! Il est cette fois le seul à avoir réussi l’exploit total de Chrome.
Après avoir trollé un peu sur l’essai raté de Nikita Tarakanov via une 0day dans le driver wifi du laptop utilisé au pwnium, Chris Evans a expliqué le fonctionnement de l’exploit de Pinkie Pie. Un use-after-free dans le moteur SVG, puis un memory leak via une mauvaise mise en place de l’aslr sous Windows 7 et enfin le sandbox escape en allant modifier des messages IPC à la volé pour dire à Chrome d’aller écrire ce qu’il veut dans le fichier qu’il veut.
Il faut noter que le record personnel de patching Chrome a été battu ! En seulement 12 h, la mise à jour était disponible au public.

Tous les slides sont disponibles ici : http://conference.hitb.org/hitbsecconf2012kul/materials/

Florian