Sécurité

Retour sur le SSTIC 2016

Publié le : Auteur: llaise Laisser un commentaire
Logo_sstic

Sodifrance était de nouveau présent au SSTIC cette année ! Encore une belle édition, et ce ne sera sans doute pas la dernière 😉 Profitons-en pour faire un retour rapide sur certaines présentations.

Conférence d’ouverture – Brad Spengler / grsecurity

Brad Spengler est l’auteur de grsecurity, un patch permettant d’ajouter des fonctionnalités de sécurité au kernel Linux. Après une brève présentation des nouveautés de grsecurity, l’orateur s’est attardé sur les problématiques touchant la communauté, avec notamment un mot sur les vulns « hype » qui influent sur les choix et priorités de développement et/ou de correction.

Egalement, Brad considère que trop de « white papers » ou de présentations sont faites, sans pour autant que le contenu ne soit utile à la communauté. Il évoque aussi la problématique des CVE, reprochant qu’aujourd’hui tout soit « CVE-able », que l’application soit critique ou non pour un système, et bien qu’elle n’affecte parfois qu’un nombre réduit d’utilisateurs.

Enfin, Brad a donné plusieurs conseils aux membres de la communauté qui voudrait se rendre utiles. Notamment, « Anyone can complain, fix something » !

Démarche d’analyse collaborative de malware – ANSSI/SOGETI

Dans le cas d’une analyse de malwares, les « reversers » font face à plusieurs problématiques : grand nombre d’échantillons, stockage, IOC, centralisation de données, automatisations de tâches, travail collaboratif (ne pas être plusieurs à travailler sur la même tâche), …  C’est pour répondre à ces besoins que « Polichombr » a été conçu. Il est disponible sur le github de l’ANSSI, est en développement depuis 2013, et est utilisé depuis 2014.

Plusieurs briques le composent : une WebUI, une base de données pour le stockage des métadonnées ainsi que les résultats d’analyses et une API, un moteur de disass (metasm ), un moteur d’analyse et d’émulation, et un script « Skelenox » IDA (python) en guise de user endpoint.

Dans Polichombr, la classification des malwares se fait par familles et sous familles de code. Ceci se fait en grande partie grâce aux « machocs », un hash murmurhash3 généré à partir des fonctions du binaire et des Control Flow Graph d’IDA.

Les échantillons peuvent être poussés via WebUI, API ou IDA directement. Polichombr supporte plusieurs types d’entrée : PE, ELF, Shellcode, .doc, …

Développement rapide d’outils de sécurité réutilisables / Pierre AUFFRET

Metabrik a été pensé par son auteur pour répondre au concept du « Do It Once », afin de centraliser, réutiliser et automatiser l’utilisation de scripts.

En mixant un shell type UNIX, un vrai langage Read-Eval-Print Loop et des Briks (autrement dit des modules ou block built-in), nous obtenons un outil en CLI permettant même d’améliorer les outils existants, comme par exemple l’ajout d’une sortie en CSV. A noter également que Metabrik est en PERL (!) et utilise une syntaxe normalisée « Human readable » à la Metasploit.

Lors de la démonstration, l’auteur présente la manipulation de machines virtuelles via Metabrik (Démarrage, arrêt, snapshot, analyse mémoire avec volatility et d’autres commandes). Bref, du bon.

Broken Synapse / Ivan Kwiatkowski

Dans le jeu Broken Synapse, un mode propose un « brouillard de guerre » et réduit la vue de l’utilisateur sur les unités ennemies.  L’auteur s’est alors mis en tête de trouver une solution pour « tricher » et désactiver ce brouillard.

Il s’est pour cela essayé à plusieurs méthodes. Tout d’abord, l’interception des flux réseaux avec Wireshark. Il obtient bien quelques informations sur la partie en cours (score de la partie, nom de l’adversaire, …), mais impossible d’avancer plus dans les recherches.

Viens ensuite le moment de lancer le jeu dans un debugger. Là encore, peine perdu, l’auteur se retrouve pris dans un switch-case géant dont il ne se sort pas, et découvre que le jeu utilise un moteur spécifique (Torque Game Engine) qui utilise son propre langage de script.

De fil en aiguille, il récupère les sources du moteur (open source) et écrit son propre décompilateur et finit par réécrire le code original quasiment à l’identique.

Cependant, ses scripts ne parviennent pas à générer les sources du jeu, pour des problèmes de versions entre le moteur et les fichiers DSO du jeu. Il parvient malgré tout à adapter ses scripts et peut enfin réécrire les fichiers contenant le code, et désactiver le brouillard en changeant la valeur d’une variable. Et il a de la chance, vu que la VM Torque recrée le bytecode à la volée en lui passant des scripts. En somme, une présentation sympa =)

Eurisko – Développement d’une carte électronique sécurisée / ANSSI

Cette présentation est axée autour d’un RETEX sur le développement d’une carte électronique basée sur l’utilisation d’une chaîne de démarrage sécurisée, et intégrant un mécanisme d’authentification pré-boot. L’objectif est de répondre à des contraintes fonctionnelles (2 interfaces GbE, carte de 70x70mm, consommation < 5W, composants COTS), de sécurité (Authentification pré-boot, update sécurisé, compatible avec Linux et GrSec, maîtrise du code) et d’industrialisation.

L’orateur a abordé les notions d’aspects matériels, de plate-forme SoC, de micro contrôleurs sécurisé, de développement et a conclus sur le RETEX.

Pour rappel, les SoC regroupent le CPU, les interfaces d’IO, le block d’entrée matériel, le tout relié par un bus de contrôle AHB.

Dans la majorité des cas, on est obligé de faire confiance à l’éditeur sur les mécanismes de boot.

Mécanisme de boot de l’Eurisko :

  • Alimentation du cortex M0
  • Alimentation du composant ST33 qui maintient la pile de reset du SoC
  • Le composant ST33 va effectuer des vérifications avant levé du reset pour l’intégrité et l’authentification du pré-boot
  • Envoie du stage SoC via le bus SPI
  • Exécution du stage par la BootROM
  • Négociation du canal sécurisé entre le composant ST33 et le SoC
  • Déverrouillage de la plate-forme

Le token externe (composant ST33) permet de réaliser des mises à jour signées et gérées par des stages dédiés.

La protection des stages s’appuie sur l’utilisation de la MPU (ST33) du SC300 (SecureControl, certifié EAL5+).

Les résultats de cette expérimentation sont positifs :

  • Carte fonctionnelle
  • Architecture réutilisable
  • Montée en compétence sur les logiciels et outils utilisés (développement, plate-forme ARM)
  • Délai relativement court ~20 semaines

L’orateur précise qu’un environnement hardware sécurisé ne veut pas dire qu’il faut faire fi de la sécurité du code et qu’elle doit être maitrisée par l’utilisation de toolchains, telles que « clang » et des règles de développement comme la réalisation d’un typage fort, la non-utilisation d’allocation dynamique, etc.

Une release est à prévoir au format OpenSource, certainement sous licence BSD.

USB Toolkit – Usbiquitous / Benoit Camredon (Airbus)

Au SSTIC 2015, Benoit Camredon a réalisé une rump sur la résolution d’un challenge portant sur l’analyse d’une communication USB d’une souris. Il est venu cette fois nous présenter l’outil qu’il a développé sur ce même sujet.

Usbiquitous est principalement né de deux besoins :

  • Simplifier l’analyse des communications USB
  • Faciliter la recherche de vulnérabilités assez simples liées au protocole USB (modifications d’attributs, par exemple)

Le projet consiste à développer un driver USB faisant office de proxy USB et qui sera placé en rupture entre un hôte et son device USB.

Dans la communication entre l’hôte et le device, il y a différents types de messages (CONTROL, BULK INTERRUPT, ISOCHRONOUS, etc.) et de descripteurs liés au device (device, configuration, interface, endpoint, etc.). Il est également à noter que la communication en USB est toujours dirigée pour l’hôte.

La carte possède 2 ports USB (pour le MITM), et l’OS est un Linux (Kernel 4.1) avec des modules de drivers pour gérer les devices qui vont être connectés. Trois modules sont principalement utilisés : le module Gadget réalise l’émulation de device USB, le module Driver permettant de transmettre les communications USB dans le UserLand et du UserLand au device, et enfin l’API USBQAPI/USBQ-Apps, dédiée aux tâches récurrentes. L’utilisateur communique/pilote le composant en UDP.

Les cas d’usages portent sur la dissection de trames USB, la mise en œuvre de pare-feu USB, l’USB mutation (altération de message USB), keylogger, etc.

Liens

Pour toutes les présentations (slides & vidéos)c’est par ici, et pour des notes sur toutes les présentations, c’est par là.