Liens vers les comptes-rendus des autres jours :
MacOS X: System Integrity Protection (Nicolas RUFF)
L’orateur présente SIP de MacOs X (System Integrity Protection), mécanisme de sécurité visant à limiter les privilèges de l’utilisateur root : pas d’accès à la mémoire des processus Apple signés, pas de chargement de modules noyau non signés, accès en lecture seule à certains répertoires comme « /System », etc. L’objectif de SIP est de préserver le système d’exploitation contre une perte permanente d’intégrité.
Quelques problèmes de sécurité identifiés dans SIP (certains seraient déjà corrigés depuis) sont ensuite passés en revue : de nombreux pilotes non signés sont présents dans une liste blanche, certains pilotes ont été signés avec des bugs permettant de contourner SIP, les applications « entitled » donnent à l’instar des binaires setuid des droits à l’application que l’utilisateur n’est potentiellement pas censé avoir…
Java Card security, Software and Combined attacks (Jean Dubreuil)
Deux présentations sur Java Card se suivent, Jean Dubreuil commence par une introduction commune rappelant le fonctionnement de ce type de puces. Le modèle de sécurité des Java Card repose sur deux mécanismes :
- Un mécanisme dit hors ligne : les applications à charger dans la carte sont vérifiées via un analyseur de ByteCode (BCV) puis signées par une autorité de confiance avant d’être chargées dans la carte (fichiers CAP) ;
- Un mécanisme de cloisonnement intégré à la carte (pare-feu) assure que l’application accède uniquement aux ressources légitimes.
S’ensuit une brève présentation des différents types d’attaques possibles : contournement du BCV, exploitation de failles dans la JCVM (JVM spécialisée Java Card), ou encore attaques combinées où du code malveillant est caché (donc non détecté par le BCV) et exécuté par l’injection de fautes laser.
La première présentation prend en postulat que le BCV est sécurisé et s’intéresse aux vulnérabilités logicielles ou aux attaques combinées. Sont notamment présentées :
- Un contournement du pare-feu Java Card via une stack overflow
- Une injection de faute via laser pour perturber le fonctionnement de la puce et faire exécuter du code mort
En conclusion, les mécanismes de sécurité peuvent être contournés, et les Java Card (et plus généralement l’ensemble des cartes à puces) doivent être protégées contre les attaques logicielles ou combinées, même si la présentation « Évolution des techniques d’attaques de circuits intégrés » d’Olivier Thomas la veille semble rendre caduque de nombreux systèmes de protection.
Fuzzing and Overflows in Java Card Smart Cards (Guillaume Bouffard et Julien Lancia)
Cette présentation s’intéresse plus particulièrement à la recherche de vulnérabilités au sein du BCV.
La présentation débute par des attaques par fuzzing : partant d’un fichier CAP valide, du fuzzing évolutionnaire est réalisé ; successivement, des mutations sont réalisées tout en essayant de conserver certaines propriétés sur les fichiers CAP générés (longueurs de tableaux, offsets…). Cette étape construit plusieurs fichiers CAP qui vont être soumis au BCV (phase de sélection), ceux qui ne sont pas valides sont directement écartés. Ceux passant les tests du BCV vont suivre à nouveau une phase de mutation, etc. Au bout de deux générations de mutations, une vulnérabilité au sein de BCV a été identifiée.
La présentation continue par des attaques par overflow qui permettent l’exécution arbitraire de code natif sur la carte (le Social Event étant passé par là, nous vous invitons à consulter les actes pour plus de détail)
Noyaux Linux durcis (Yves-Alexis Perez)
Yves-Alexis Perez a présenté des techniques de durcissement du noyau Linux afin de faciliter son installation et son utilisation au quotidien. Même si le noyau est la pièce centrale du système d’exploitation, on constate régulièrement que les seules modifications sont des corrections de vulnérabilités une fois qu’elles ont été très largement exploitées. Ce procédé n’est pas suffisant pour assurer une bonne protection du système.
Plusieurs fonctionnalités de sécurité peuvent être activées par défaut lors de la compilation d’un noyau, assurant une meilleure isolation des processus, des utilisateurs et des différentes ressources.
GRSecurity quant à lui est un patch noyau orienté sécurité et maintenu activement depuis plus de 15 ans. Yves-Alexis a ensuite détaillé une partie des fonctionnalités proposées par GRSecurity.
Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne (Charles Hubain et Philippe Teuwen)
Les attaques de type « white-box » reposent sur le postulat que les attaquants ont un accès total sur le matériel et peuvent donc utiliser tous les moyens possibles et imaginables, tant physiques que logiciels pour extraire les données sensibles.
Il existe donc des modèles d’implémentation de la cryptographie visant à protéger les secrets cryptographiques contre ce genre d’attaque. Cependant, tous ces modèles « académiques » ne résistent qu’aux attaques « académiques ».
La présentation illustre donc des attaques et des outils permettant d’extraire des informations de ces implémentations, par exemple les traces d’exécution. Ces traces d’exécution permettent d’en extraire des schémas identifiant des implémentations de cryptographie, ou encore par de la ‘Differential Power Analysis’ qui corrèle la consommation électrique aux poids de Hamming des valeurs internes.
Windows Error Reporting (Aurélien Bordes)
Windows Error Reporting (WER) est une technologie introduite depuis Windows Vista et qui permet de générer des traces lors d’une erreur dans une application ou dans le système d’exploitation. Cette technologie est le remplaçant de Docteur Watson qui avait été introduit avec Windows XP.
WER est notamment utilisé par Microsoft pour centraliser plusieurs dizaines de millions de traces par jour dont l’objectif est :
- D’identifier rapidement des bugs qui impactent de nombreux systèmes (par ex. lors de l’installation de KB) ;
- De détecter des attaques informatiques (par ex. MS08-067).
Un accès aux rapports est disponible pour les éditeurs de logiciels tiers et fabricants de matériel via le portail Hardware Dev Center. Il est également possible de configurer les stations d’un parc pour envoyer les rapports vers un collecteur interne à l’entreprise. L’envoi vers un collecteur interne évite la fuite d’informations et permet de disposer d’informations précieuses pour la détection de compromission (par ex. crash du service « lsass » sur un contrôleur de domaine à 2h du matin).
Un serveur PHP minimaliste WER (https://github.com/aurel26/wer-server) est ensuite présenté par Aurélien Bordes. Celui-ci centralise en base de données l’ensemble des crashs remontés par les stations du parc et consigne l’ensemble des rapports d’erreurs.
Bypassing DMA remapping with DMA (Benoît Morgan, Eric Alata, Guillaume Averlantn et Vincent Nicomette)
Benoît Morgan nous a présenté une attaque sur la RAM via le bus PCIExpress contournant la protection IOMMU (gestionnaire d’accès mémoire).
L’outil inception permet de lire/écrire à n’importe quelle adresse de la mémoire (dans les 4 premiers Go, l’adressage étant sur 32bits) via un accès DMA (par ex. une carte Firewire branchée sur le port PCIExpress). Cependant, et pour contrer cette technique, le module IOMMU développé par Intel ajoute un niveau d’indirection en virtualisant l’espace d’adressage des périphériques via du filtrage et de la traduction.
Ce module de protection peut cependant être contourné. Un périphérique malveillant branché sur la carte mère va modifier le contexte d’éléments en RAM afin d’annuler la restriction d’accès une fois le module IOMMU chargé. Il est alors possible d’accéder en lecture/écriture sans restriction.
En résumé, si l’ordinateur est déjà démarré avec le module IOMMU chargé, il n’est pas possible d’accéder arbitrairement à une zone mémoire. Pour y parvenir, un périphérique malveillant doit être branché sur le port PICExpress avant le démarrage.
Scapy en 15 minutes (Guillaume Valadon et Pierre Lalet)
L’objectif de cette présentation est de faire découvrir ou redécouvrir le framework réseau Scapy. Les fonctions présentées sont :
- La fonction ls() qui permet de lister les champs des paquets
- La fonction sr1() qui permet d’envoyer un paquet et de recevoir la réponse
- La fonction srp() envoie une liste de trames et retourne la réponse
- Les paquets peuvent être sauvegardés et lus directement depuis un PCAP
- La fonction sniff() permet de capturer les paquets
- La fonction multiplot() permet de tracer des courbes afin d’obtenir un rendu visuel
- La fonction canvas_dump() affiche une représentation du contenu d’un paquet
- Implémentation d’un nouveau protocole en quelques lignes
- L’objet StreamSocket permet à Scapy d’utiliser une socket TCP
- Utilisation de scapy en mode répondeur : plutôt qu’émettre un paquet on se met en écoute et on réagit à ce que l’on reçoit afin de mettre en place par exemple des attaques MITM (l’exemple donné portait sur l’envoi d’un message WiFi ProbeResponse, pour tout message ProbeRequest reçu, avec l’objectif de faire apparaître un faux-réseau).
Concernant les prochains commits, il y aura :
- L’intégration des pipes permettant un transfert simple entre les interfaces
- Le support des certificats X.509
- La possibilité de signer des certificats
- Les OS dérivés de BSD seront supportés nativement, sans modules externes
Plaso & Timesketch (Romain Gayon)
Cette présentation introduit deux outils open-source de forensic : Plaso et Timesketch.
Plaso sert à parser les évènements normalisés à partir d’une image disque, afin de créer une table chronologique des évènements et de la sortir dans de nombreux formats. Ceci afin de faciliter et d’accélérer le travail de réponse à incident d’un analyste. De plus, Plaso permet de vérifier les hashes sur VirusTotal.
Timesketch permet de visualiser des données, par exemple celles extraites par Plaso, mais en ajoutant une intelligence, avec par exemple des annotations des évènements, d’avoir plusieurs timelines, de travailler en collaboration, etc.
Ces deux outils permettent donc de corréler les évènements, de faire des recherches sur un grand nombre de logs, et de classifier les alertes. De plus, et à la fin d’une investigation, Timesketch permet de présenter de façon synthétique toutes les informations intéressantes pour faciliter la rédaction d’un rapport.
Graphes de dépendances : Petit Poucet style (Aymeric Vincent, Camille Mougey, Caroline Leman, Fabrice Desclaux et Mathieu Blanc)
Il existe deux manières d’analyser les flots de données lors de la rétro-ingénierie d’un binaire, l’analyse d’influence et l’analyse des dépendances. Cette présentation se concentre sur l’analyse des dépendances.
Après une présentation de l’état de l’art, des outils existant ainsi que de leurs choix respectifs, les orateurs indiquent que les implémentations existantes ne répondaient pas ou que partiellement à leurs attentes.
L’approche retenue pour leur outil est la suivante : l’assembleur est tout d’abord traduit en langage intermédiaire puis il utilise un algorithme qui suit les dépendances en partant d’un basic block puis procède par itération pour remonter les prédécesseurs et donc suivre les dépendances de la variable suivie.
Le but de l’algorithme implémenté est d’affiner au mieux les résultats tout en ayant un temps de réponse rapide.
Conférence de clôture (Karthikeyan Bhargavan)
L’orateur dirige l’équipe Prosecco de l’INRIA qui s’intéresse à la programmation sécurisée dans le contexte de la cryptographie.
Cette équipe a, entre autres, créé une bibliothèque TLS appelée miTLS qui a la particularité d’être formellement vérifiée. Cette implémentation stricte des RFC et d’un outillage dédié les a amenés à découvrir plusieurs vulnérabilités dans le protocole et dans ses implémentations (par exemple dans la machine à état du client TLS de Java qui permettait à un attaquant, en position de MITM, de désactiver le chiffrement des échanges sans que le client ne s’en aperçoive).
Le cœur de la présentation portait ensuite sur l’explication de plusieurs vulnérabilités qu’ils ont découvertes (Freak, Sloth, Logjam).
