La première édition de la NoSuchCon, un fork de la Hackito Ergo Sum, s’est tenue la semaine passée. Comme l’édition 2012 de la Hackito Ergo Sum, l’événement s’est déroulé au sein de l’espace Niemeyer du Parti Communiste situé place du Colonel Fabien à Paris. Comme à l’accoutumée, l’ambiance était à la convivialité.
Voici un résumé des présentations de la première journée de ce cycle de trois jours :
Keynote #1*
Andrea Barisani
Andrea Barisani est un chercheur en sécurité informatique fort d’une solide expérience dans ce domaine. Il est aussi connu pour être le fondateur de l’oCERT effort (the Open Source Computer Security Incident Response Team).
L’introduction de la keynote revient notamment sur ses premières conférences, comme celle sur le hack de l’informatique embarqué au sein d’une voiture. Il tient d’ailleurs à souligner le fait qu’il travaille aussi bien sur du hack logiciel que matériel. Il introduit alors la première No Such Con, en la présentant comme étant « the badass hardcore technical security conference of death » : un cycle de conférences techniques sans « bullshit ».
Andrea enchaîne ensuite sur les problèmes actuels que l’on rencontre lors des conférences sur la sécurité informatique : quand elles ne sont pas à des fins publicitaires, on y présente tout et n’importe quoi. Il tient à signaler qu’il faudrait envisager d’arrêter de « hacker tout ce qui bouge ».
Enfin, il revient sur un phénomène déviant et récurrent lié à la presse. Les articles de presse généralistes relatant les présentations des conférences déforment bien souvent les sujets évoqués. C’est comme cela que l’on passe d’une faille dans les firmwares des batteries des MacBook, à un article indiquant qu’un hacker peut faire exploser votre Mac…
Pour finir, il rappelle qu’il y a l’art et la manière. Certaines présentations manquent, selon lui, de style, et se contentent de présenter des aspects sans entrer dans le détail, sans attribuer le crédit des recherches aux bonnes personnes. Il s’étonne également que l’on ne montre que des conférences où le chercheur a réussi à « casser » un système mais très rarement des recherches ayant abouti à la conclusion que le système est sûr.
Abusing the Windows Kernel: How to Crash an Operating System with Two Instructions
Mateusz “j00ru” Jurczyk
Mateusz Jurczyk est un ingénieur en sécurité informatique qui travaille actuellement chez Google à Zurich. Ses sujets favoris concernent la sécurité des clients logiciels, l’exploitation de vulnérabilités, mais surtout les profondeurs des noyaux des OS, avec une préférence pour Microsoft Windows. Son blog reprend souvent ces sujets.
Sa présentation à la NSC s’intitule « Abusing the Windows Kernel: How to Crash an Operating System with Two Instructions ». Mateusz a en effet choisi un sujet très bas niveau , relevant par certains aspects du reverse engineering et a présenté des techniques récentes d’exploitation de vulnérabilités au sein de drivers Windows. Les exploitations présentées étaient d’autant plus intéressantes qu’elles étaient encore « 0-day », puisqu’elles seront patchées en juin 2013, après la conférence.
En particulier, Mateusz a démontré en quoi une mauvaise implémentation d’une fonction overlap(), utilisée par memcpy(), peut permettre une élévation de privilèges via un driver.
La fonction memcpy prend en paramètres une adresse mémoire source de destination et la taille de la zone à copier. La fonction overlap() utilisée par memcpy() est censée effectuer une série de contrôles pour vérifier la validité des adresses envoyées en paramètres. Pour des raisons d’optimisation, cette fonction a fait l’objet d’une nouvelle implémentation ne respectant pas l’intégralité des spécifications, en particulier en ce qui concerne les contrôles sur les adresses mémoire. Dans la mesure où une zone mémoire en kernel-land est toujours positionnée avant une zone mémoire en user-land, Mateusz démontre que, pour certaines versions de Windows, il est possible de modifier une adresse précise en kernel-land. En effet, lors d’une copie, celle-ci se fait dans l’ordre inverse. Il suffit donc de copier une zone mémoire positionnée après une zone non allouée en jouant sur la taille et en décalant le début de la zone copiée. La mémoire sera copiée à partir de la fin puis, en arrivant dans la zone non allouée, la copie s’arrêtera, évitant ainsi les effets de bord.
La présentation de cette faille se conclut par une preuve de concept aboutissant à l’exécution d’une invite de commande avec les droits système. La présentation est disponible ici.
Ninjas and Harry Potter: “Spell”unking in Apple SMC Land
Alex Ionescu
Alex Ionescu est chef architecte chez CrowdStrike. Il est spécialisé dans les systèmes bas-niveau, le développement Kernel et l’ingénierie inversée. Il est également co-auteur de Windows Internal Series avec M. Russinovich et D. Solomon. Son travail a permis de corriger de nombreuses failles de sécurité dans le kernel Windows. Il est également chef développeur du kernel du ReactOS, un système d’exploitation développé « from scratch » afin d’être une alternative à Windows.
Malgré son énorme bagage sous Windows, il a cette fois choisi d’analyser une puce présente sur les machines Apple. Celle-ci a la particularité de pouvoir être mise à jour par n’importe qui mais de ne pouvoir être lue par personne.
Cette puce a pour rôle :
- la gestion du capteur de luminosité ;
- la protection des disques durs contre les chocs ;
- la régulation du voltage de la machine ;
- la gestion des ventilateurs ;
- le stockage de la clé FileVault.
Cette puce est bien protégée, mais elle peut être en partie déverrouillée grâce à un sort d’Harry Potter. Il s’agit de la SMC ou System Management Controller.
Alex Ionescu s’est intéressé à la version présente dans les MacBook récents, la Renesas H8S/2117. Cette puce dispose d’une documentation incomplète donnant des spécifications globales mais lacunaires ainsi qu’un SDK. La puce ne pouvant pas être lue, il faut obtenir un update pour analyser le code. L’analyse de ce code a permis de découvrir un tableau de SMC_Keys, il s’agit en fait de fonctions et de variables qui peuvent être appelées. Parmi ces clés, il y a notamment :
- #NUM permettant d’obtenir le nombre de clés ;
- OSK0 (o u r h a r d w o r k b y t h e s e w o r d s g u a r d e d p l) et OSK1 (e a s e d o n t s t e a l ( c ) A p p l e C o m p u t e r I n c) utilisées par le système OS X pour vérifier qu’il est bien lancé sur une machine Apple ;
- Deux clés cachées car placées au-delà de la borne #NUM, soit KPPW (Kernel Protect PassWord) et KPST (Kernel Protect STatus).
En examinant la fonction KPPW, Alex s’est aperçu que le mot de passe était « SpecialisRevolio », le sort de révélation d’Harry Potter. Un appel correct à cette fonction permet de débrider la fonction de lecture mais pas suffisamment pour pouvoir lire le code de la puce.
Pour conclure, bien qu’Alex ait découvert de nombreux détails intéressants, il n’est pas encore possible d’obtenir le code contenu dans cette puce. N’importe qui peut donc en modifier le comportement sans qu’il soit possible de le contrôler.
La présentation est disponible ici.
Nifty Tricks and Sage Advice for Shellcode on Embedded Systems
Travis Goodspeed
Travis Goodspeed est un spécialiste des attaques sur le hardware, principalement dans l’embarqué.
Pour cette présentation, Travis commence par expliquer que la notion d’APT n’est, selon lui, qu’un nouveau moyen de blâmer les Chinois pour les cyber-attaques.
Il souligne que le plus gros problème dans les APT est le nombre de semaines nécessaires pour fabriquer des preuves qui incriminent les Chinois.
Pour remédier à ce problème, il a développé un outil qui permet d’extraire les caractères chinois des fichiers binaires.
Après cette première digression, la présentation continue par une explication sur la réelle fonction du badge fourni aux auditeurs de la conférence.
Il s’agit en fait du circuit imprimé d’un matériel programmable en Python pour permettre la simulation de périphériques et d’hôtes USB.
Pour mieux comprendre l’utilité d’un tel dispositif, Travis présente une attaque réalisée sur des télévisions. L’attaque exploite une vulnérabilité dans le système de mise à jour de ces postes. En effet, ceux-ci commencent par lire le nouveau firmware et vérifient sa signature, puis dans un second temps, le fichier est utilisé pour flasher le firmware de la télé. L’attaque est donc très simple, lors de la première lecture le dispositif présente le firmware signé par le constructeur et à la seconde lecture, il présente le firmware modifié par l’attaquant.
Après cette seconde digression, Travis nous explique que l’exploitation de vulnérabilités sur les systèmes embarqués, contrairement aux exploitations sur PC, ne vise généralement pas à obtenir l’exécution de code, mais à obtenir le code.
La suite de la présentation peut être qualifiée de « boîte à outils » pour l’extraction de code contenu dans des microcontrôleurs. Certaines des méthodes s’avèrent d’ailleurs très complexes, alors que certaines sont relativement élémentaires.
Un exemple de méthode simple est celle utilisée pour extraire les données de la majeure partie des microcontrôleurs de type PIC. Le code de ces microcontrôleurs est stocké dans différentes « banks » indépendantes les unes des autres. Par conséquent, il suffit généralement d’avoir deux puces identiques. Une première « bank » est alors flashée avec un code permettant de lire le code contenu dans les autres « banks ». Puis, une seconde « bank » est flashée pour lire le code de la première.
Parmi les méthodes très complexes, j’ai trouvé très astucieuse une méthode utilisée par Travis pour récupérer le code d’un microcontrôleur en faisant clignoter des LED, sans avoir à gérer l’horloge. Il suffit en fait de disposer de deux LED. La première est alternativement allumée puis éteinte en fonction de la parité du tour de boucle pour servir d’horloge. La seconde est allumée ou éteinte en fonction de la donnée lue.
Pour conclure, il faut être très créatif pour extraire le code d’un microcontrôleur. Il est donc préférable de se référer à la présentation de Travis.
Dumb fuzzing XSLT engines in a smart way
Nicolas Grégoire
Après 12 années passées dans le domaine des tests d’intrusion, Nicolas Grégoire a fondé sa propre société, Agarri, spécialisée dans la recherche de vulnérabilités. Son travail l’a amené à intervenir lors de conférences dans le monde entier (Hack In The Box, Hack In Paris, ZeroNights). Son blog est maintenu à jour régulièrement.
Après s’être présenté, il explique que ses recherches se concentrent sur XML, XSLT et XPath.
Contrairement à ce que l’on peut penser, les vecteurs d’attaques ne se résument pas seulement aux navigateurs Internet, mais incluent également les moteurs de bases de données (PostgreSQL, par exemple). Il est également possible d’utiliser du code XSLT dans Adobe Reader (Via JavaScript et/ou XFData) pour déclencher un exploit, entre autres.
Il précise qu’il n’a pas accès à des outils comme SAGE (outil Microsoft), LangFuzz ou encore ClusterFuzz, ce qui ne simplifie pas l’étape du fuzzing, mais le fait qu’il soit motivé et qu’il connaisse assez bien XSLT contrebalance la donne.
Le fuzzing peut être long et peut coûter cher (sur une large gamme de produits). De plus, les vecteurs d’attaques sont relativement complexes (échappement des $ dans PostgreSQL, par exemple).
Le point positif est qu’une bibliothèque OpenSource existe : libXSLT. Elle dispose d’une interface en ligne de commande (CLI wrapper: xsltproc). L’idée est de fuzzer directement le wrapper ce qui permettrait d’avoir une aide considérable lors du fuzzing (performance, reproductivité…).
Il présente les étapes nécessaires pour la suite de l’étude pour :
- identifier l’engine XSLT pour les applications cibles.
- Hacker Way : rechercher dans la doc, le code, string et comportement.
- XSLT Way : introspection via system-property(). Des informations standards sont disponibles (xsl:vendor, xsl:vendor-url, xsl:version.) et d’autres sont des extensions propres à l’application.
- préparer les wrappers en ligne de commande (CLI wrapper).
Il en existe en OpenSource (libXSLT) et en code propriétaire (OraXSL).
Pour le fuzzing, il emploie Radamsa (déjà utilisé pour trouver des vulnérabilités dans Microsoft Excel et des applications bancaires) pour générer les tests sur des VM disponibles dans le Cloud (Amazon) pour quelques centaines d’euros.
Afin d’automatiser ses tests, il utilise un script Python pour gérer :
- la génération des tests ;
- le serveur X en parallèle pour les wrappers en ligne de commande ;
- l’attente du « plantage » de l’application ;
- le classement du « plantage » via des calculs heuristiques ;
- la génération d’un rapport et son envoi par email.
Quelques exemples de découvertes lors des tests avec « plantage » de l’application :
- Sur une application Intel, lors d’une division par 1.0 ;
- Sur Oracle, découverte d’un stack overflow qui pourrait peut-être permettre le contournement de l’ASLR sur Safari ;
- Une erreur de segmentation dans Adobe Reader.
Tous ces bugs ont été trouvés via le wrapper (en ligne de commande), Nicolas a donc testé ces bugs sur les applications elles-mêmes, comme Adobe Reader. Le résultat est sans appel : le bug est également présent.
Les tests ont parfois fait « planter » l’application, parfois non. Le fait que l’application se soit « plantée » signifie potentiellement un bug. Cependant, Nicolas souligne le fait que les tests sans « plantage » de l’application sont également importants et peuvent passer inaperçus lors de tests automatiques (mémoire non initialisée, use after free ou double free et quelques overflows).
Les résultats sont intéressants, globalement des bugs dans M$, Adobe Reader, Safari, Firefox, Oracle et Intel (pas patché et pas de CVE), allant d’un buffer overflow à des left/right heap overflow en passant par un use after free.
Il termine en faisant un appel afin de récupérer LangFuzz en échange d’un binaire vulnérable Intel (dorénavant introuvable sur le site officiel) qui lui permettrait d’utiliser un autre fuzzer pour ses recherches.
Les slides sont disponibles ici.
Deadly Pixels – Innovative (and pretty) exploit delivery
Saumil Shah
Saumil Shah (@therealsaumil, saumil[at]net-square.com) est le fondateur et PDG de Net-Square qui traite des domaines du reverse engineering, de la création d’exploit, mais aussi des test d’intrusion. Net-Square fournit des services de sécurité de l’information de pointe à des clients partout dans le monde. Saumil est conférencier et formateur reconnu internationalement, il a notamment participé à la BlackHat, RSA Conference, CanSecWest, PacSec ou encore Hack.lu, Hack In The Box, entre autres conférences. Il est l’auteur de deux livres intitulés « Web Hacking: Attacks and Defense » et « The Anti-Virus Book ».
Son introduction présente le principe de l’attaque qui consiste à embarquer du code malveillant (JavaScript,…) dans une image.
La première démonstration présente une attaque appelée « Exploits as Grayscale Images » qui traite de la transformation d’un texte en image PNG. Saumil utilise d’ailleurs des pages PHP développées par lui-même, lui permettant de transformer du code malveillant en image, et inversement, à savoir une petite image carrée noire.
Le décodage de cette image est ensuite présenté. Par la suite, la même démonstration est faite avec un code JavaScript qui est transformé en image. Lors de l’affichage de l’image, le JavaScript est exécuté.
Une deuxième démonstration présente un shellcode qui est converti en image. L’exécution de ce payload se fait lors du clic sur l’image qui ouvre alors la calculatrice. Un nouveau test est effectué présentant une autre image utilisant le JavaScript « onmouseover » et écrivant du texte en boucle à chaque passage de la souris.
Saumil présente ensuite un tableau comparatif des exécutions en fonction des différents navigateurs.
Pour conclure, il propose une solution qui consisterait à mettre en place sur le navigateur une fonctionnalité permettant d’avertir l’utilisateur de l’exécution d’un code ressemblant à une image et non à un JavaScript.
Les slides sont disponibles ici.
Pythonect-Fu: From Function to Language
Itzik Kotler
Itzik Kotler est devenu consultant en sécurité informatique indépendant après avoir travaillé chez Radware ou encore Security Art. Il a effectué de nombreuses présentations lors de conférences telles que la BlackHat, la DEFCON ou encore Hack In The Box. Par ailleurs, il est membre de l’autorité de standardisation israélienne (SII).
La présentation faite ici se concentre principalement sur une bibliothèque Pythonect qui a été développée en Python. Celle-ci permet de réaliser des DSL très facilement.
L’outil Pythonect est développé entièrement en Python 2.7, il est donc « cross-platform » et fonctionne avec JPython et CPython.
La procédure de récupération et d’installation est la suivante :
git clone git://github.com/ikotler/pythonect.git cd pythonect python setup.py install
Qu’est ce qu’un DSL ?
Un Domain Specific Language est un langage de programmation dont les spécifications sont dédiées à un domaine d’application précis. C’est une sorte de mini-langage regroupant quelques fonctions utiles dans un domaine, simplifiant grandement le travail du développeur par la suite, lorsque ces dernières sont utilisées régulièrement. Par conséquent, il est possible de faire évoluer ce langage facilement. On retrouve parmi les DSL : XSLT / awk / sed / make / yacc et les moteurs d’expressions régulières.
Quelles sont les particularités de Pythonect ?
Il permet le développement de DSL en utilisant un paradigme de développement en flot de données.
Les avantages de ce paradigme sont donc :
- Il a été choisi car il permet nativement le parallélisme et les accès concurrents ;
- La représentation en flot de données est naturelle pour représenter un processus ;
- Les programmes en flot de données sont plus facilement modulables, ils s’appliquent donc mieux au développement d’un DSL.
Les contraintes sont :
- Ce paradigme est peu connu des développeurs ;
- Cela peut s’avérer coûteux en ressources.
Afin de facilement se rendre compte de la simplicité d’un tel paradigme voici quelques exemples de programmation qui ont été donnés lors de la présentation :
'Hello World' -> print
Quand on veut ajouter plusieurs actions en parallèle, il suffit d’utiliser les listes.
'Hello World' -> [print,print] // La fonction print sera donc appliquée 2 fois à l'argument.
['Hello World', 'Test World'] -> print // Ici, on envoie les 2 arguments à la fonction print.
Ensuite, Itzik Kotler montre qu’il est facile d’ajouter un bloc à un programme :
'Hello World' -> string.split -> print
De plus, Pythonect inclut un auto-loader de modules, ainsi il n’est plus nécessaire de faire des “imports”, les modules seront directement chargés dans le DSL que l’on est en train de créer.
Quel est le rapport avec la sécurité ?
Par la suite, la présentation s’est focalisée sur le lien que pouvait avoir cet outil avec la sécurité. Itzik Kotler a donc développé deux DSL y ayant trait.
Le premier qui a été présenté est SMALL : Simple Malware AnaLysis Language. Il regroupe 14 fonctions simples afin d’étudier des malwares, c’est un DSL développé à l’aide de Pythonect. Voici quelques-unes de ces fonctions :
- Extraction d’adresses IPv4 depuis un binaire ;
- Extraction de chaînes en Base64 depuis un binaire ;
- Calcul de MD5/SHA1/… ;
- Définition du type de fichier (/usr/bin/file) ;
- Création de rapports en XML.
Afin de le lancer, il suffit d’utiliser la commande suivante :
pythonect -m SMALL -i (m pour charger la bibliothèque SMALL, -i pour avoir une invite de commande interactive).
Ensuite, des exemples de traitement ont été proposés :
from_file('malware.exe') -> extract_base64_strings -> to_xml // Permet d'extraire les chaînes en Base64 du binaire et de présenter la sortie sous format XML.
from_file('malware.exe') -> extract_base64_strings -> to_xml // La syntaxe très facile de cette bibliothèque présente d'elle-même les avantages d'un tel produit.
Le deuxième DSL présenté est Hackersh. C’est un langage permettant l’interfaçage d’outils utilisés lors de tests d’intrusion (par exemple Nmap, W3af…) et l’utilisation des fonctions de traitement (comme convertir en URL, convertir en adresse IPv4…) afin d’obtenir un shell utilisable par les pentesters très facilement.
Voici la procédure d’installation :
git clone git://github.com/ikotler/hackersh.git cd hackersh python setup.py install
Le plus simple est encore la démonstration par l’exemple :
"http://localhost" -> url -> nmap -> [_['PORT'] == '8080' and _['SERVICE'] == 'HTTP'] -> w3af -> print
Cette ligne récupère une URL qu’elle donne à Nmap, l’outil fait ensuite un scan. Si le port 8080 est ouvert avec un service HTTP, alors w3af effectue un scan sur l’URL, le rapport est ensuite affiché en sortie standard.
'192.168.1.0/24' -> ipv4_range -> ping // Transformation de 192.168.1.0/24 en une plage d'adresses IP, puis une requête Ping est envoyée à chaque adresse IP.
'127.0.0.1' -> ipv4_address -> nmap -> nikto // Là encore, la syntaxe, très simple, parle d'elle-même.
En conclusion, Hackersh a besoin d’être développé par des pentesters afin que ceux-ci puissent ajouter tous les outils dont ils ont besoin (par exemple, Hydra, Burp, Metasploit…) ainsi que d’autres fonctions pouvant s’avérer nécessaires. Cet outil pourrait faire gagner énormément de temps lors d’un test d’intrusion.
Les slides sont disponibles ici.
Auteurs du billet : Antoine Cervoise, Jean Lacassagne, Romain Leonard, Grégory Charbonneau, Pierre Le Calvez, Geoffrey Bertoli, relu par Isabelle Feetz.