Keynote #2*
Thomas Lim
Thomas Lim est le fondateur et PDG de COSEINC, société d’expertise en sécurité informatique basée à Singapour. Il est également connu pour la création de la conférence de sécurité SyScan.
Thomas ouvre la seconde journée de la NoSuchCon en nous ramenant dans le passé avec un récapitulatif de l’histoire de la Chine et ses échecs. Cette introduction vise à poser le contexte politique de la Chine et comprendre l’intérêt que ce pays porte à la cyberattaque et la cyberdéfense, deux sujets suscitant l’intérêt des gouvernements du monde entier et traités lors du colloque sur la cyberdéfense au sénat ce 16 mai 2013.
Thomas Lim explique que les raisons de l’effort chinois pour exceller en termes de hacking peuvent se diviser en 3 catégories : politique, économique et militaire.
Politique d’abord pour lutter contre la volonté d’indépendance taïwanaise mais aussi par peur de la concurrence et de l’invasion japonaises. Le hacking permet ainsi au gouvernement chinois de garder un œil sur le contexte politique des pays environnants, ce qui rejoint la thématique économique. En effet, la Chine basant son modèle économique sur l’export, il devient impératif de surveiller le marché et l’éventuelle concurrence. Enfin, la maîtrise de la sécurité informatique s’inscrit dans le domaine militaire en appui au PLA, force militaire du parti communiste chinois.
Pour conclure, la présentation de Thomas Lim a permis, sur un ton humoristique, de mieux comprendre l’intérêt de la Chine pour la maîtrise de la cyberdéfense, suite au traumatisme, peut-être, de ses échecs passés.
« The Great Wall is the most useless piece of military hardware ever built » – Thomas Lim, NSC 2013.
BIOS Chronomancy
John Butterworth, Corey Kallenberg, Xeno Kovah[IFZ1]
Les différents auteurs sont chercheurs en sécurité au MITRE. John Butterworth et Corey Kallenberg sont spécialisés, en autres, dans le développement bas niveau et s’intéressent actuellement à la sécurité de l’UEFI au sein du BIOS. Xeno Kovah, spécialiste du noyau Windows est aussi le fondateur de http://opensecuritytraining.info, un site permettant des formations gratuites de sécurité informatique.
L’introduction de la présentation est axée sur le fait que toutes les sécurités du BIOS sont stockées dans son firmware et que ce dernier peut être mis à mal. La présentation se poursuit ensuite par une explication des terminologies suivantes : Trusted Platform Module (TPM), Platform Configuration Registers (PCR), Trusted Boot et Static Root of Trust for Measurement (SRTM).
L’acquisition de la ROM du BIOS est ensuite présentée, les méthodes proposées par les orateurs sont les suivantes :
- Lecture via les logiciels constructeurs;
- Lecture dans la puce du BIOS via des logiciels tiers ;
- Lecture physique de la puce BIOS.
L’analyse est ensuite assez complexe. L’orateur présente, par exemple, une analyse du BIOS d’un Dell Latitude E6400 connecté à un débugueur Arium CPU ainsi que le principal point de faiblesse du BIOS : la Platform Configuration Registers (PCR).
L’orateur détaille ensuite les conséquences d’une faible implémentation de la PCR pouvant modifier la majorité du BIOS E6400, sans modifier les données de la PCR. Il enchaîne ensuite sur la problématique principale de cette présentation, à savoir ce qu’implique le fait de pouvoir modifier n’importe quelle partie du BIOS, et ce sans limite.
La première démonstration débute par la vidéo du BIOS d’un DELL E6400 sans modification. L’orateur lance ensuite un exécutable qui modifie l’écran d’accueil. Un autre logo apparaît donc en lieu et place du logo du constructeur (DELL).
Après un bref redémarrage, l’exécutable est à nouveau lancé, puis un malware est injecté dans le BIOS de façon complètement transparente pour l’utilisateur.
La deuxième démonstration présente le malware « the flea ». On update le BIOS, le malware persiste. La technique consiste à modifier le nouveau BIOS pour lui réinjecter le malware déjà présent.
Les contre-mesures proposées par l’orateur sont les suivantes :
- Nonce/Pseudorandom Number(PRN) ;
- Read own data ;
- Read own instruction and data pointers ;
- Do all the above in millions of loop iterations.
L’orateur présente également des exemples de codes qui vérifient le checksum dont un qui prend en compte l’évolution en fonction du temps. Pour conclure, l’outil Copernic développé par les orateurs est présenté : il permet de lire le BIOS. Ils finissent la conférence en invitant d’autres chercheurs à creuser le sujet.
La présentation est disponible ici.
Who’d have thought they’d meet in the middle? ‘ARM Exploitation’ meets « Hardware Exploitation » Sharable memoirs from a very surprising last year
Stephen A. Ridley
Stephen A. Ridley a plus de dix ans d’expérience en matière de sécurité logicielle et en reverse engineering. Il est à la tête d’une petite équipe de chercheurs chez Accipiter Research où il dirige le développement des périphériques embarqués de sécurité.
Après une petite blague sur les Irlandais, Stephen A. Ridley nous présente brièvement son collaborateur (absent), Stephen C. Lawler, chercheur spécialisé dans l’exploitation kernel et logicielle qui s’est peu à peu tourné vers l’exploitation matérielle, notamment sur ce qui a trait à l’architecture ARM. Au sein de leur société, ils ont été amenés à donner beaucoup de formations pratiques sur l’exploitation et le reverse sur une plateforme ARM.
L’orateur nous explique que sa présentation parle de hacking matériel pour des hackers logiciels, car il utilise des failles matérielles pour comprendre, espionner ou modifier ce qui se passe au niveau logiciel. Un des axes d’attaque principal est la communication entre chaque microcontrôleur qui utilise très souvent des protocoles de communication standards comme le protocole « serial » des vieux ports série. On retrouve ce type de protocole un peu partout, notamment dans les équipements d’un réseau : modem, routeur, …
Il nous présente en détail son travail sur un modem filaire intégrant un serveur HTTP équipé d’une puce ARM Broadcom. La carte mère du modem présente 4 PIN en série qui permettent le débuggage du PC. Après fuzzing, les 2 collaborateurs arrivent à faire planter le serveur HTTP intégré. Comment étudier et exploiter ce bug ? Et surtout, avec quels outils ?
La présentation s’est alors orientée vers le sujet suivant : quels matériels/logiciels utiliser pour faire du reverse sur ARM ?
Les deux collaborateurs ont d’abord émulé ARM avec QEMU, mais au bout d’un certain temps, l’émulation ne leur suffisait plus. Ils ont donc cherché une architecture ARM idéale pour le développement, les téléphones portables n’incorporant pas les outils de développement nécessaires. Les Raspberry Pi, ARMini, … leur posèrent des problèmes de firmware, gênant la création d’une distribution Linux répondant parfaitement à leur besoin.
Après des mois de recherche, ils se sont finalement mis d’accord sur la plateforme Gumstix. Après une longue période de tests, ils ont créé leur ROM : une distribution Linux adaptée spécifiquement à leur usage, contenant tous leurs exploits et outils nécessaires à leurs travaux.
Ils ont ensuite développé une bibliothèque standard CROP (programmation orientée reverse) avec des fonctions permettant de contourner certaines protections matérielles comme le XN (protection contre l’exécution de certaines plages mémoire). Puis, pour améliorer la rapidité du développement des exploits, ils ont développé des classes Python simplifiant l’usage de leur « libc ».
La présentation s’est ensuite tournée vers la fabrication de diverses interfaces hardware permettant le débugage de la prise IPhone au port USB, en passant par la prise d’alimentation de n’importe quels périphériques. Ceci permet de remonter des informations sur les communications et d’étudier des vecteurs d’attaques logicielles.
Enfin, en dernière partie, l’orateur a parlé du projet Osprey ayant pour but la création d’un périphérique spécialisé dans la sécurité et l’exploitation matérielle. Le projet comprend évidemment le développement d’un firmware adapté ainsi que d’un logiciel pour PC communiquant avec ce dernier.
Le produit est censé répondre aux critères suivants :
- Communiquant par RF (ZigBee, …) ;
- Contenant une EEPROM et un emplacement Micro SD ;
- Programmable, sans recourir à l’assembleur ;
- Avec une faible consommation et un coût moindre (probablement quelques centaines de dollars US) ;
- Avec une interface série afin de le relier à un PC ;
- Avec une carte mère qui doit être conçue de façon extensible, de manière à pouvoir recevoir d’éventuelles cartes « filles » additionnelles.
Après avoir promu efficacement son projet, il conclut la présentation en soulignant que l’exploitation ARM est plus simple que l’on ne le pense et qu’il y a beaucoup de failles d’ores et déjà trouvées et à trouver dans les usages que l’on en fait. Pour finir, on n’en est qu’aux prémices de l’ère des architectures « Post PC ». Par ailleurs, il remarque que les matériels spécialisés pour la sécurité, comme Osprey, faciliteraient encore les exploits ARM…
On notera qu’à la question sur la diffusion des codes mentionnés lors de la présentation, et surtout celle des codes d’Osprey, Stephen a répondu qu’il ne comptait pas les diffuser gratuitement, mais plutôt les revendre.
Les slides sont disponibles ici.
Advanced Heap Manipulation in Windows 8
Zhenhua (Éric) Liu
Éric est un chercheur en sécurité chez Fortinet, au Canada. Il se concentre essentiellement sur l’étude des mécanismes de protection des systèmes d’exploitation afin d’y trouver des vulnérabilités et des façons de les exploiter.
Avec l’arrivée de Windows 8, de nombreuses méthodes de corruption de mémoire sont devenues inopérantes, notamment grâce à des corrections apportées au noyau de Windows 7 (amélioration de l’ASLR, tests d’intégrité du noyau…) mais aussi grâce à de nouvelles protections permettant de diminuer davantage le déterminisme (guard pages par exemple).
Pourquoi s’intéresser alors aux techniques permettant de manipuler le tas ? Éric justifie ce choix en citant Ben Hawkes : « Application Specific data attacking are the future », à savoir : pouvoir manipuler le tas. Le but recherché sera le dépassement de tampon sur le tas avec les données visées situées juste après, le tout sans provoquer le lancement du LFH (Low-Fragmentation Heap).
La première étape consiste à maîtriser le placement en mémoire d’un objet précis, en plaçant ce dernier juste derrière le tampon vulnérable. Cela est possible grâce à l’utilisation de FreeLists au niveau du noyau et dans le tas. En effet, les métadonnées des FreeLists sont vulnérables aux attaques et on peut prédire l’endroit où sera alloué le prochain bloc de mémoire. Il est donc possible de maîtriser la fragmentation du tas afin d’avoir deux blocs adjacents, dont la taille respective est égale à celle du tampon vulnérable et celle des données que l’on veut corrompre. Le débordement de tampon permettra alors de directement modifier l’objet en mémoire.
Il est possible de réutiliser cette méthode afin de modifier des données dans la mémoire du noyau (car les FreeLists y sont utilisées) en jouant sur l’allocation de nouvelles pages. En effet, si la recherche d’un bloc de mémoire libre échoue, une nouvelle page sera allouée possédant une taille, codée en dur, de 4096 octets. En forçant l’allocation d’une nouvelle page, on peut facilement la fragmenter de façon à obtenir deux blocs ayant les tailles désirées.
Pour finir, Éric présente un exemple d’attaque visant à modifier les données du _HEAP_USERDATA_HEADER en utilisant les méthodes vues précédemment, les principales difficultés étant la présence du LFH et des guard pages.
De nombreuses améliorations ont été réalisées depuis Windows 7 rendant inutiles la plupart des méthodes d’exploitation classiques. Cependant, d’anciens algorithmes encore utilisés (ici, les FreeLists) nuisent à la sécurité du système d’exploitation.
La présentation est disponible ici.
A hesitation step into the blackbox Heuristic based Web-Application Reverse-engineering
Fabien Duchêne, Sanjay Rawat, Jean-Luc Richier, Roland Groz
Fabien Duchêne est doctorant (Ph.D) au Laboratoire d’Informatique de Grenoble (LIG). Il a fondé la GreHack, une conférence en sécurité informatique à Grenoble. Sanjay Rawat est un chercheur postdoc à VERIMAG, basé à l’Université Joseph Fourier, également à Grenoble. Jean-Luc Richier est chargé de recherche au CNRS et membre du Laboratoire d’Informatique de Grenoble. Roland Groz est enseignant-chercheur et membre du Laboratoire d’Informatique de Grenoble.
Note : Seul Fabien Duchêne est présent lors de la NSC.
Fabien commence par souligner le fait que le reverse engineering a été effectué en blackbox, contrairement au classique reverse engineering qui sous-entend une étude en greybox.
Faire le reverse engineering d’une application Web permet de récupérer des informations sur le site et de les utiliser pour trouver des vulnérabilités et automatiser la génération d’exploit(s).
Par la suite, il dresse l’état de l’art du reverse engineering sur des Web appli et indique que sa contribution et celle de ses collègues consistent à des améliorations heuristiques de recherches existantes.
La méthodologie est la suivante : il crée un arbre de données (un modèle, trié par champ et par balise) à partir du contenu de la page Web (DOM). Il cherche ensuite à détecter les changements d’états dans l’arbre généré en regénérant le modèle de page récupérée après la validation d’un formulaire (suite à un POST/GET). Pour identifier la requête changeant d’état, un système de points a été créé (heuristique).
L’étude est agrémentée d’arbres et de graphes en couleur permettant de détecter si ce changement d’état a déjà eu lieu. Cet outil sera disponible en guise de POC (H-WAR) en Python et utilisera le DOM généré par Chrome pour analyser la sortie.
L’orateur poursuit avec une comparaison entre Wget, Wapiti, w3af, Skipfish et leur outil, H-WAR qui arrive en 1ère place dans la couverture du code par rapport aux autres.
Son outil s’en sort également bien dans l’évolution de la couverture (nombre de requêtes). En effet, H-WAR ne semble pas effectuer de trop nombreuses requêtes, contrairement à certains outils.
Son POC peut-il servir à des pentesters ? Globalement oui, selon lui, cela faciliterait la détection des injections (LFI, XSS, etc.) et il permettrait également d’effectuer plus rapidement le test d’intrusion.
Il conclut en expliquant qu’il est possible de coupler la sortie de H-WAR à H-FUZZ qui se chargerait du fuzzing. Testé sur Gruyère, un site intentionnellement vulnérable fourni par Google, le couple H-WAR + HFUZZ s’avère plus efficace que H-WAR + w3af.
Les slides de présentation ne sont pas disponibles, suite à une demande directe de l’orateur
Corroding Immobilizer Cryptography
Karsten Nohl
Karsten est un cryptographe et chercheur en sécurité travaillant chez Security Research Labs. Son activité consiste principalement à tester les mécanismes de sécurité des systèmes propriétaires.
Sa présentation porte sur les « immobilizers », des systèmes anti-démarrage pour voiture, matérialisés par une puce présente au sein des clés de voiture. Ces puces jouent le rôle de token dans le processus défi-réponse entre le contrôleur de la voiture et la clé. Introduit à la fin des années 1990, ce système aurait permis de réduire le nombre de vols de voitures aux États-Unis.
Le marché est dominé par trois technologies : DST 40 (Texas Instruments), Hitag 2 (Philips, NXP) et Megamos (EM Micro). Malgré leur position dominante, ces technologies sont vulnérables à des attaques comme le brute force (smart ou non), la cryptanalyse ou la duplication. Les protections de ces mécanismes sont souvent insuffisantes et sont de plus en plus exploitées. Pour illustrer cela, Karsten explique que les Smartphones, réputés peu sécurisés, possèdent de meilleures protections que les contrôleurs des voitures.
Le niveau global de sécurité des voitures est faible, les technologies les plus répandues souffrent de défauts de conception et ne respectent pas les bonnes pratiques établies depuis plusieurs années. De plus, les fabricants ajoutent toujours plus de fonctionnalités qui ont besoin d’être protégées (Remote Assistance, WiFi…) alors que celles-ci reposent souvent sur le contrôleur de la voiture, réputé peu fiable.
Karsten conclut en prédisant une forte augmentation du hack de voiture étant donné leur faible niveau de protection et leur surface d’attaque très large. Il conseille aux fabricants de garder les voitures simples au niveau technologique ou d’investir afin d’améliorer la conception de leurs systèmes.
La présentation est disponible ici.
Taint Nobody Got Time for Crash Analysis
Richard Johnson & pa_kt
Richard Johnson est un spécialiste en sécurité américain qui a passé de nombreuses années à travailler sur l’analyse de vulnérabilités logicielles. Il est actuellement directeur de l’équipe de recherche de vulnérabilités chez Sourcefire. Il intervient avec un orateur Polonais surnommé PA_KT (« Packet »), annoncé simplement comme un collaborateur du projet.
Cette présentation porte sur des outils permettant d’automatiser l’analyse des bugs logiciels pour en faire ressortir les éventuelles failles de sécurité. Dans un premier temps, ils ont recherché un outil permettant d’extraire les éléments utiles de la masse d’informations récupérées lors de l’exécution du programme. D’après les orateurs, parmi les outils existants, il n’y a rien d’assez bien automatisé pour pouvoir être utilisé efficacement. Ils ont donc créé un outil basé sur BAP (Binary Analysis Platorm) permettant de tracer les points (notamment les entrées/sorties) précédemment sélectionnés lors de l’exécution.
Une fois les données extraites, vient l’étape du « Trace Slicing » consistant à créer des arbres entre les dépendances présentes entre les variables. Cela permet de déterminer quelles variables influencent quelles autres.
Ensuite, vient l’étape de la « symbolic execution » qui consiste à exécuter des instructions, sans utiliser de valeurs concrètes pour les variables. On a donc, à la place des sorties standards, une formule correspondant à la valeur de sortie en fonction des variables d’entrée. La solution des formules est ensuite calculée à l’aide d’un « SMT solver ». Ceci permet, dans l’arbre créé au « Trace Slicing », d’exclure les branches dans lesquelles il n’y a plus rien d’influencé par les entrées qui nous intéressent.
Une fois cette procédure effectuée, les feuilles de l’arbre restantes représentent les actions exécutées par le programme qui ont été injectées par nos entrées malveillantes : cela met donc en évidence les failles.
Après un rapide retour sur la fiabilité de cette méthode, qui nous est décrite comme étant très souvent efficace tout en contenant cependant quelques faux positifs, les orateurs ont conclu sur le fait que la valeur d’un bug est directement liée à notre capacité à l’analyser et que, par conséquent, ce type d’outils avait de l’avenir…
On notera que cette présentation était censée être accompagnée de plusieurs démonstrations de l’outil permettant de mieux comprendre son fonctionnement mais un défaut d’adaptateur VGA en a empêché le déroulement.
La présentation est disponible ici.
Transporting evil code into the Business: Attacks on SAP TMS
Juan Perez-Etchegoyen
Juan Perez-Etchegoyen est directeur de la technologie chez Onapsis. Il est responsable des équipes de Recherche et Développement. Il a également participé activement à la coordination et à la recherche de vulnérabilités de sécurité critiques dans les applications ERP et infrastructures telles que SAP ou Oracle. Juan possède une vaste expérience dans le domaine de la sécurité de l’information, l’implication dans une grande recherche, les tests d’intrusion, l’évaluation de la vulnérabilité et les projets de mise en œuvre en matière de sécurité, entre autres.
Après un rappel de SAP et de son utilisation dans les entreprises (les plus grandes compagnies dans le monde l’utilisent), l’orateur présente les risques en cas de compromission d’un SAP, à savoir : espionnage, sabotage et fraude. Globalement, en cas de compromission d’un SAP, une perte d’argent pour la société compromise est immédiatement remarquée. 95% des SAP audités peuvent être compromis sans avoir à en connaître les credentials. Transport Management System (TMS) n’est pas installé par défaut. Utilisé par/pour le business, il doit être customisé pour chaque business en particulier. Toutes les informations sont dans des bases de données, le but est donc de prendre la main sur la DB.
Les systèmes SAP sont généralement interconnectés entre les différentes équipes (DEV, PRD et QA). Les connecteurs créés sont connectés à tous les systèmes dans le même domaine de transport (full-mesh).
Rapport à l’authentification (TMS authentification), il s’avère que l’utilisateur standard (TMSADM) est de type SYSTEM par défaut avec un password par défaut « PASSWORD ». Les nouveaux standards préconisent « $1Pawd2& ». L’utilisateur « Admin » possède un certain de nombre d’autorisations par défaut qui autorisent le debug, l’accès au système de fichiers, etc.
Les contre-mesures consistent à changer le mot de passe standard pour chaque système (PRD, QA et DEV), ne pas configurer de droits inutiles et risqués pour des utilisateurs qui n’en ont pas besoin et enfin implémenter les recommandations de SAP relatives à la sécurité.
Un espace d’échange de données implémenté par des répertoires partagés SMB ou NFS (le plus souvent) est utilisé par les systèmes SAP : Common Transport Directory (CTD). Sur la production (PRD), le CTD est souvent hors scope car il est généralement « sécurisé ». Sur la plateforme de développement (DEV), le CTD n’est généralement pas considéré comme contenant des données sensibles, par conséquent, les contrôles d’accès sont plus souples et les fonctionnalités de sécurité sont rarement mises en place. Un attaquant a donc plus de chance d’exploiter les applications SAP.
DEV et QA sont généralement de bons pivots car ils sont liés PRD et partagent les mêmes mots de passe. La contre-mesure préconisée est de sécuriser tous les systèmes SAP comme s’ils étaient en production.
Les requêtes de transport représentent les données qui passent d’un système SAP à un autre. Toutes les requêtes de transport sont stockées dans le CTD dans deux fichiers : « data » et « cofile », ce dernier contenant les journaux d’activités des requêtes de transport.
Les requêtes de transport ne sont pas chiffrées, mais compressées. L’entête est en clair, la date, l’utilisateur et la version sont disponibles. Le reste est sous forme de code binaire. Une fois décompressé, il s’avère que le protocole est du texte brut. Il est à noter qu’un checksum (CRC32) est présent. Il est donc possible de générer des transports malveillants qui peuvent être passés de système SAP en système SAP contenant du code malveillant : création d’utilisateurs, backdoor ou autres.
Les contre-mesures préconisées par l’orateur sont d’analyser toutes les requêtes de transport avant qu’elles ne soient importées dans le système PRD. Il est évident que mettre en place un tel système est relativement lourd et complexe.
Un binaire utilisable en ligne de commande, appelé TP, peut également être appelé en remote via la passerelle. Si les contrôles d’accès ne sont pas mis en place, il est possible d’importer n’importe quel transport de requêtes en production. Les contre-mesures consistent à sécuriser la passerelle SAP en n’autorisant que des systèmes sûrs afin de démarrer des serveurs tels que le serveur TP. Il est à noter que depuis peu, la passerelle est sécurisée par défaut.
L’orateur souligne le fait qu’il est possible de journaliser les changements de table, les exécutions de transports, les commandes TP, ce qui faciliterait les analyses en cas d’intrusion.
Il conclut en récapitulant les risques encourus si le SAP n’est pas sécurisé. Il recommande à nouveau de sécuriser tous les systèmes SAP comme s’ils étaient tous destinés à la production, de mettre à jour toutes les solutions SAP et d’appliquer les notes de sécurité rédigées par SAP.
On regrettera que les démonstrations n’aient pas pu être présentées suite à des problèmes techniques. Cependant, l’orateur a présenté avec brio les vulnérabilités ainsi que les recommandations associées.
La présentation est disponible ici.
Auteurs du billet : Myriam Goupil, Antoine Cervoise, Pierre Le Calvez, Yann Gascuel, Alexis Grancher, Grégory Charbonneau, relu par Isabelle Feetz.