NoSuchCon – Jour 3

Keynote #3

Dimitri Alperovitch

La dernière journée de conférence commence par une keynote de Dimitri Alperovitch dans une salle bien moins fournie que les jours précédents (sans doute suite à la NoSuchParty du jeudi soir). Dimitri est un des fondateurs de CrowdStrike Inc.  Auparavant, il travaillait chez McAfee dans la recherche de code malveillant. Il a notamment développé des techniques de détection de spam, de malware ou d’intrusion. Vous pourrez lire bien plus d’informations sur sa page personnelle.

La keynote s’est concentrée sur les différentes attaques informatiques modernes, des attaques plus  massives et plus destructrices. Le travail effectué par la communauté sécurité est important mais reste en retard par rapport aux attaquants.

Les attaquants ont des profils et des motivations qui varient. Si certains tentent d’attaquer votre compagnie et se retrouvent face à une impasse, ils iront voir ailleurs. Par contre, si c’est votre compagnie qui les intéresse, ils chercheront un moyen d’entrer, que ce soit directement chez vous ou bien en passant par l’un de vos partenaires.

D’autre part, il existe de grandes différences entre les moyens à mettre en œuvre pour se défendre et ceux nécessaires pour attaquer. En effet, il est complexe d’imaginer des défenses pour des attaques qui n’existent pas encore, tandis qu’il est simple d’inventer des attaques pour des défenses que l’on connait. De la même façon, un attaquant sait ce qu’il veut obtenir. Un défenseur, lui, ne sait même pas si les protections qu’il met en œuvre le protégeront.

Nous, la communauté travaillant dans la sécurité des Systèmes d’Information, devons continuer à avancer tout en faisant preuve d’imagination car de nouvelles menaces impliquent de nouvelles défenses.

Crashdmp-ster Diving the Windows 8 Crash Dump Stack

Aaron LeMasters

Aaron LeMasters est un chercheur en sécurité senior chez CrowdStrike Inc. Avant cela, Aaron a travaillé chez Mandiant, société au sein de laquelle il a mis en place des méthodes de reverse-engineering de rootkit. Il est aussi le coauteur de « Hacking Exposed: Malware and Rootkits » (October 2009, McGraw-Hill). Bloggeur sur son temps libre, il a participé à de nombreuses conférences sécurité comme la BlackHat. Son dernier projet, http://crashd.mp, est un site dédié au partage d’informations sur le mécanisme de crash dump de Windows.

Le crash dump de Windows est l’un des mécanismes les moins documentés. Celui-ci est utilisé par Windows pour l’hibernation, le fast boot de Windows 8 et les crashs système. La présentation d’Aaron dévoile un abus dans la pile du driver crashdump.sys. Comme l’orateur nous le rappelle, les techniques utilisées ne sont pas nouvelles et ceci ne constitue pas une vulnérabilité.

Aaron nous explique que ce mécanisme permet un accès en lecture et écriture à la mémoire de masse lorsque des bugs apparaissent ou lorsque le système se prépare à hiberner. La présentation commence avec quelques rappels des précédentes recherches puis se poursuit par une présentation de crashdmp.sys et des filtres de crash dump.

L’objectif de crashdmp.sys est de conserver l’état de la machine en cas de crash ou bien d’hibernation. Les filtres quant à eux, permettent de modifier les requêtes en lecture et écriture effectuées via le crash I/O path. L’idée ici est d’abuser de la fonctionnalité de journalisation apparue dans Windows 8, afin d’accéder à des informations protégées. Ce type d’abus n’est cependant possible que lors d’une hibernation ou d’un crash Windows, les fonctions en question n’étant utilisées qu’à ce moment-là.

Pour finir, la présentation se termine par une démo utilisant les sources du Boston CTF challenge. La présentation est disponible ici.

Exploiting Hardcore Pool Corruptions in Microsoft Windows Kernel

Nikita Tarakanov

Nikita Tarakanov est un chercheur en sécurité informatique spécialisé dans l’exploitation des vulnérabilités du noyau Windows, sujet sur lequel il a déjà publié quelques articles.

Nikita parle dans un premier temps de la difficulté croissante d’attaquer les applications du fait de l’utilisation de sandbox. Toutefois, les vulnérabilités du noyau Microsoft étant principalement des manipulations de mémoire, l’attaque du noyau via les sandbox est envisageable.

Des techniques d’exploitation du Heap (ou tas du noyau) ont été mises en œuvre, notamment par Tarjei Mandt, sur Windows 7. Ces techniques sont basées sur la modification des tailles de blocs dans le tas. Cependant, elles ne sont plus efficaces sur Windows 8.

Nikita propose une technique plus complexe consistant à modifier l’entête de l’objet puis à procéder à un appel système pour déclencher l’attaque. La démonstration de ladite technique n’ayant pas fonctionné lors de la présentation, il conclut la conférence en précisant que cette technique d’attaque n’est pas fiable à 100%.

La présentation est disponible ici.

XML Out-Of-Band Exploitation

Yunusov Timur, Alexey Osipov

Timur Yunusov et Alexey Osipov sont les deux orateurs de cette présentation. Timur Yunusov est chercheur en sécurité des applications Web et l’auteur de nombreuses recherches autour de ce domaine, incluant brute force of PHPSESSID, classée dans les 10 meilleures techniques de hacking en 2012 par WhiteHat Security. Il est également pentester professionnel et a été développeur à l’International forum on practical security « Positive Hack Days ».

Quant à Alexey Osipov, il est chercheur en mécanismes de prévention d’attaque et a développé plusieurs outils de sécurité et Proof of Concept. Il a également pris la parole dans de nombreuses conférences, notamment à la DEFCON de Russie. Il est membre de l’équipe « SCADA StrangeLove ».

Leur présentation concerne une fonctionnalité avancée de la spécification XML : les « entités XML », et les risques qu’elle peut induire.

Plusieurs sortes d’entités XML existent. Les plus connues sont les entités prédéfinies telles que « & », « &lt », ou encore « % ». Typiquement, les entités XML sont utiles pour définir des « raccourcis » ou des variables qui réfèrent à des chaînes de caractères ou des caractères spéciaux.

Plus généralement, Tiur et Alexey rappellent que des entités XML peuvent être déclarées de manière interne (dans le DTD courant) ou externe (définies dans un document externe). Celles qui intéressent cette présentation sont bien évidemment les externes (XML eXternal Entities / XXE). En effet, elles peuvent constituer un risque en termes de sécurité. Elles peuvent tout particulièrement permettre de :

• Lire un fichier local ;
• Effectuer des requêtes sur Internet ;
• Effectuer des scans de ports internes/externes ;
• Exécuter du code, dans une moindre mesure ;
• Réaliser un déni de service.

Pour illustrer ces concepts, il est possible d’utiliser des exemples, une entité XML interne pourrait être déclarée comme suit :

<!ENTITY writers “Timur & Alexey”>

<!ENTITY copyright “Copyright NSC.”>

<author>&writers;&copyright;</author>

Une entité XML externe, quant à elle, pourrait être déclarée comme suit :

<!ENTITY writers SYSTEM “http://www.w3schools.com/entities.dtd”>

<!ENTITY copyright SYSTEM “http://www.w3schools.com/entities.dtd”>

<author>&writers;&copyright;</author>

Ce dernier exemple permet d’avoir un aperçu du risque que peut représenter l’appel à un document externe. Les techniques d’attaques typiques sont :

• XXE à base d’erreur (DTD ou validation de schéma) ;
• Brute force de valeurs XSD, à l’aveugle.

Pour de plus amples détails, je vous recommande vivement de consulter les slides de la présentation, très intéressante. Enfin, il peut être intéressant de suivre le compte Twitter de Timur Yunusov.

Revisiting MAC OS X Kernel Rootkits

Pedro Vilaca aka fG!

Pedro Vilaca a suivi une formation d’économiste, il est titulaire d’un MBA (Master of Business Administration). Après avoir travaillé dans le milieu bancaire, il est maintenant chercheur en sécurité pour la société COSEINC. Il a notamment écrit un article dans MISC sur les rootkits pour MAC OSX.

Sa conférence porte sur les kernel rootkits sous MAC OSX, elle est basée sur 2 idées très simples qu’il va développer.

Les hypothèses nécessaires à ce type d’exploitation sont :

• L’utilisateur doit déjà être « root », soit avoir les droits maximaux sur le système ;
• La cible est l’OS : Mountain Lion 10.8.2 64 bits ;
• L’attaquant doit savoir développer des extensions kernel.

Une rapide revue de l’état de l’art montre que peu de recherches ont été faites sur ce sujet. En effet, rien n’a été publié depuis les exploits sur Leopard, on remarquera seulement des rootkits « Made In Italy » en cours d’exploitation mais dont les recherches ne sont pas rendues publiques.

Quels sont les problèmes récurrents du développement de rootkits?

#Problème 1

Afin de développer un rootkit, un utilisateur a besoin des symboles noyau (ou « kernel symbols »), or ceux-ci ne sont pas exportés, certains étant disponibles mais pas suffisamment pour un rootkit stable.

La récupération de ces symboles est possible depuis certaines extensions noyau mais seulement dans la version Lion et Mountain Lion de l’OS.

#IDEE 1

Les symboles sont récupérables directement en lisant l’image du noyau dans le système de fichiers. Malgré le fait qu’un mythe existe concernant la difficulté de lire le système de fichiers, cette solution possède l’intérêt de rester exploitable malgré l’utilisation de l’ASLR.

Comment procéder ?

Grâce à l’utilisation de VFS (Virtual File System), il est possible de lire le mach_kernel (micronoyau de l’OS).

#Problème 2

Beaucoup de fonctions intéressantes dans le développement d’un kernel sont statiques et ne sont pas récupérables via ces symboles. Faire une recherche hexadécimale ne semble pas être une solution viable.

#IDEE 2

Il suffit  d’intégrer un désassembleur directement dans le rootkit. Pedro Vilaca utilise pour sa part diStorm qui fonctionne à merveille. De plus, cette solution est très performante. En effet, la décompilation du noyau dure une seconde sur un processeur moderne.

Ensuite, une fois le rootkit développé, Pedro Vilaca a fait une démonstration des principales fonctions qu’il pouvait implémenter :

• Lancer des processus en mode « userland », directement depuis le rootkit, en cachant ce processus à l’utilisateur ;
• Être totalement indétectable par le système ;
• Utiliser la machine cible dans un botnet.

La présentation est disponible ici.

Exploiting Game Engines For Fun and Profit

Donato Ferrante, Luigi Auriemma

Luigi Auriemma et Donato Ferrante sont les fondateurs de ReVuln qui fait de la recherche de vulnérabilités, du consulting et des tests d’intrusion. Au sein de l’entreprise, les orateurs réalisent de la recherche  sécurité.

Pourquoi cibler des jeux ?

Parce que la surface d’attaque est vaste! En effet, certains moteurs de jeu sont vendus avec des licences spécifiques aux organisations militaires ou au FBI par exemple. Toutes sortes de personnes jouent une fois de retour à la maison. Même les directeurs de grandes entreprises peuvent être des joueurs pendant leur temps libre. Cela peut s’avérer être une bonne façon d’exploiter leur entreprise.

Un moteur de jeu est un ensemble de composants logiciels qui effectuent les calculs de géométrie et de physique utilisés dans les jeux vidéo. L’ensemble forme un simulateur en temps réel souple qui reproduit les caractéristiques des mondes imaginaires dans lesquels se déroulent les jeux. Le but visé par un moteur de jeu est de permettre à une équipe de développement de se concentrer sur le contenu et le déroulement du jeu plutôt que sur la résolution de problèmes informatiques. C’est en quelque sorte le noyau d’un jeu.

Ainsi, un même moteur de jeu peut être partagé entre plusieurs jeux. Par conséquent, la même vulnérabilité peut être réutilisée et offrir un gain de temps et d’argent à un attaquant.

Les moteurs de jeu peuvent être corrompus selon cinq angles d’attaque :

• Au niveau des paquets fragmentés : les jeux sont basés sur le protocole UDP, mais ils essaient de mettre en place un réseau TCP over UDP. Lorsque la fragmentation se produit, le moteur doit reconstruire le paquet d’origine. Ce processus est effectué dans la mémoire. Qu’en est-il en essayant de placer la charge utile d’un paquet dans une autre zone de mémoire ?
• Au niveau de la compression, plus précisément au niveau de la structure des numéros d’index : les numéros d’index constituent une manière particulière de représenter les nombres, ils permettent de transmettre et de sauvegarder les nombres en utilisant un minimum de bits. En effet, pour un nombre en 32 bits signé, le premier bit permet de déterminer le signe et le dernier bit permet de vérifier si une nouvelle séquence de bits suit ou non (1 bit de signe, 6 bits de valeur, 1 bit de suite). Cependant, si on inverse le premier et le dernier bit d’un nombre cela aboutit le plus souvent à un « integer overflow ».
• Au niveau des protocoles de jeu, grâce aux Opcodes (Opération Codes – Code d’opération) : les Opcodes sont des parties d’une instruction de langage machine qui spécifient l’opération à effectuer. Pour chaque moteur de jeu, donc chaque protocole, un set d’Opcodes est utilisé. La base d’Opcode est fournie par le moteur de jeu et une table de fonctions basées sur cette table d’Opcode est utilisée par les développeurs et fournie  par le moteur de jeu. Ainsi, pour chaque jeu, la table de fonctions (table du protocole) sera différente alors que la table d’Opcode est pour un moteur de jeu constant. Dans ce cas, afin de déterminer la table d’Opcode d’un moteur de jeu, il faudra récupérer dans tous les jeux utilisant le même moteur de jeu la table de protocole qui apparaît en mémoire seulement au lancement du jeu.
• Grâce à la personnalisation : les moteurs de jeu proposent de plus en plus la possibilité de personnaliser les jeux. En effet, des options telles que la création d’animations, de modèles, de son ou de création de carte par les joueurs sont de plus en plus fréquentes. L’option permettant de créer soi-même une carte est très intéressante. En effet, il est possible de compromettre le moteur de jeu via des formats de binaire complexe (fuzzing) ou des routines d’analyse complexes (IDA). Le plus intéressant est le fait que les cartes soient automatiquement téléchargées par le serveur.

Les moteurs de jeu peuvent aussi être utilisés pour personnaliser les arguments des lignes de commande, permettant ainsi d’établir un exploit local. Cependant, grâce à des plateformes telles que Steam et Origin, ces exploits locaux peuvent être réalisés à distance.

La commande « Devmode » est prévue pour être utilisée pour débuguer / tester / jouer avec les personnalisations. La commande « Loading » permet de télécharger arbitrairement des fichiers en mémoire ou dans le système de victimes. La commande « Logging » permet d’écrire des fichiers de personnalisation sur le système d’une victime.

Via les serveurs maîtres : ils contiennent toutes les données des jeux, telles que des informations sur les serveurs, les hébergeurs et parfois,  des informations sur les joueurs. Ces serveurs sont accessibles en ligne afin que les joueurs puissent rejoindre une partie par exemple, ce qui devient très intéressant pour un attaquant. En effet, à partir du serveur maître, il est possible de connaître toutes les adresses IP des autres serveurs et, par ce biais, de les compromettre.

Après la théorie, les présentateurs ont effectué quelques démonstrations en direct. La présentation est disponible à l’adresse suivante : http://www.nosuchcon.org/talks/D3_05_Ferrante_Auriemma_Exploiting_Game_Engines.pdf.

Any Input is a Program

Sergey Bratus

Sergey Bratus est professeur assistant de recherche au sein du département des sciences de l’informatique à l’université de Dartmouth. Il présente un travail réalisé par ses étudiants.

Un format d’entrée suffisamment complexe peut devenir un bytecode pour une sorte de machine virtuelle dans le logiciel qui gère cela. Dans de nombreuses techniques de programmation d’exploits classiques, les entrées quelles qu’elles soient, s’exécutent sur un analyseur, quel qu’il soit.

Deux exemples sont présentés de programmation de « Turing-complete » avec des types de données qui ne sont pratiquement jamais utilisées dans ce but :

• Les entêtes ELF au format binaire avec uniquement de la relocalisation bien formée et des entrées de symboles dynamiques (par l’exécution de la liaison) ;
• La mémoire x86 et les tables de descripteurs d’interruption (par l’unité centrale de traitement de la page de gestion des erreurs et la logique de commutation de contexte, sans aucune instruction envoyée avec succès).

Si ces formats de données peuvent cacher un calcul « Turing-complete », que dire de tous les autres, plus complexes ? Comment un format peut se prêter à être un équivalent d’un jeu d’instructions? Est-ce que la recherche de “drôles de machines” aide à la conception de systèmes fiables?

Singularités ELF

L’orateur montre comment construire une machine de Turing sur les délocalisations et les symboles du format binaire ELF. D’autres aspects du format peuvent être tout aussi « tordus ». D’un point de vue de linguistique théorique, le format ELF est très sensible au contexte : beaucoup de métadonnées sont stockées de manière redondante et des évènements intéressants peuvent se produire lorsque les métadonnées sont incompatibles. En outre, il est possible que ces dépendances soient l’une des raisons de la manipulation difficile des binaires.

L’orateur a mis au point une technique d’exécution via le MMU où tous les mécanismes de gestion des pages « fault » n’utilisent qu’une seule instruction de type « Turing-complete ».

La présentation est disponible ici.

Killing RATs, the Arsenic Framework

Robinson Delaugerre, Adrien Chevalier

C’est à Adrien Chevalier (@00_ach) et Robinson Delaugerre (@Rob_OEM) que revient la responsabilité de clore ces trois journées de conférence. Ils sont consultants sécurité chez Conix Security et travaillent sur la réponse à incidents ainsi que sur l’analyse inforensique.

Le sujet est d’actualité : les Remote Access Tools.

L’approche qui en est faite s’ouvre sur les aspects inforensiques et la relative incapacité actuelle à récupérer les traces de ces infections, voire à les détecter. Le constat est simple : les attaquants sont présents depuis suffisamment longtemps sur les systèmes pour parfois mieux les connaître que les administrateurs eux-mêmes.

Les processus d’attaque sont donc complexes et varient d’une attaque à l’autre. La capacité à les détecter, identifier les assets compromis et cerner le périmètre d’une compromission repose sur la capacité à détecter les actions des attaquants en quasi temps réel.

L’approche retenue du framework Arsenic segmente les attaques en trois piliers majeurs : l’analyse réseau, l’inforensique sur les machines infectées et le reverse-engineering. Cette conception en trois piliers trouve son écho dans un traitement de trois éléments : les signatures de trafic réseau, l’analyse des hôtes compromis et l’analyse profonde du trafic réseau.

Les signatures de trafic réseau permettent d’utiliser des règles Snort pour la détection des patterns. Une approche comportementale est envisageable mais ne semble pas être utilisable aujourd’hui. L’analyse comportementale de la machine sur laquelle le framework est déployé permet d’identifier les patterns utilisés en mémoire, de détecter les modifications apportées au registre ou encore certains motifs révélateurs dans les fichiers (analyse effectuée en sandbox). L’étude du trafic réseau permet de déchiffrer le trafic émis et reçu par l’attaquant, fournissant une visibilité complète sur ses actions.

La démonstration effectuée consiste donc à utiliser ce framework sur une machine infectée par Poison Ivy (version ancienne de RAT toujours utilisée).

Le framework est fonctionnel, la détection quasi instantanée, l’ensemble des connexions déchiffrées et analysées en temps réel. La capacité d’Arsenic à se propager dépendra principalement de la communauté qui pourra se mettre en place autour de l’outil, principalement pour la partie signatures et création de modules. Les travaux entrepris semblent clairement aller dans cette direction afin de tout faire pour améliorer l’exploitabilité de l’outil.

Le code n’est pas encore disponible mais gageons que ce sera bientôt le cas (@ArsenicRats pour infos).

La présentation est disponible ici.

Auteurs du billet : Antoine Cervoise, Romain Leonard, Myriam Goupil, Jean Lacassagne, Geoffrey Bertoli, Sarah Bébon-Aubert, Yannick Fournel, relu par Isabelle Feetz.