Catégories
conférences

SSTIC 2016 – Jour 2

A first glance at the U2F protocol

Dans les protocoles d’authentification à deux facteur du web, on a souvent le choix entre des « authenticators » qui fonctionnent sur un secret partagé et qui génèrent une clef dérivée du temps, stockée en base, donc potentiellement récupérable. Et l’authentification via SMS, qui repose sur le protocole SS7 dont on sait qu’il est aisément écoutable, et en plus lesdits SMS circulent en clair.

Le protocole U2F repose sur un token USB et nécessite une action utilisateur pour que l’authentification soit négociée. Bon par contre coté support, ça ne fonctionne qu’avec Chrome/Chromium > 41.

Les orateurs nous présentent ensuite leur analyse de sécurité de ce protocole. En gros, un attaquant qui fait un MITM ne pourra pas spoofer le channelID signé par le token U2F. Pour que ça fonctionne, il faut 1) que le channel ID soit traité de manière non-optionnelle, 2) il faut qu’il soit vérifié par le serveur. Le problème c’est que pour l’instant, seul Google supporte U2F, et ne vérifie pas le ChannelID, parce-que plein d’entreprises ont des Proxy MITM (type bluecoat) pour détecter les malware dans les flux web.

How to not break LTE crypto

Vulnérabilités au sein des modems 4G/LTE. Qualcomm est un des leaders du marché à faire des puces 2G/3G/4G et des CPU.  Les puces récentes utilisent une architecture basée sur Hexagon: 3 cœurs physiques qui font tourner un OS Realtime sans ASLR avec des stack cookies. Il existe un plugin IDA pour cette architecture. Coté Mediatek, autre constructeur de modems LTE, fournit un modem traditionnel. Coté samsung, ils ont leur propre modem dont le firmware est obfusqué/chiffré mais un menu caché *#9900# fournis un crashdump de la mémoire du modem, avec code et firmware en clair. Exploité a pacsec en 2015, une présentation aura lieu à la RECON en 2016 sur ce sujet. (les slides sont denses).

Les orateurs nous présentent ensuite comment se déroule une connexion LTE. la particularité de la LTE, c’est que le coeur de réseau choisit les protocoles de chiffrement utilisés par le téléphone. Coté radio, il est possible de forcer un mode sans chiffrement (RRC-EIA0) au niveau d’une fausse antenne relais pour dégrader la sécurité, et intercepter les connexions data lorsque le téléphone se re-connecte. En dehors de ce cas, la sécurité du protocole NAS empêche une connexion initiale dans le mode RRC-EIA0. Certains bugs sont présents dans la Stack du modem, faisant en sorte qu’il donne plus d’informations qu’il ne devrait lorsque la connexion NAS n’est pas encore établie. Chez un autre fabricant, il y a un bit de « politesse » qui une fois set à 1 fait que le téléphone donne toutes les informations demandées malgré l’absence de sécurité lors de l’établissement de la connexion.

Méthodologie d’extraction de signatures issues des signaux AIS

 AIS est un système de signalisation maritime pour identifier les navires. Bon par contre, ce type de signalisation est basé sur la bonne-foi des utilisateurs des transpondeurs, et en plus le protocole n’est pas chiffré. Il est possible du coup de spoofer des signaux et de faire des dessins sur les interfaces de contrôle des opérateurs de contrôle du trafic maritime. Du coup, coté logiciel, difficile de détecter ces attaques par usurpation. Pour pouvoir détecter une usurpation, les orateurs ont choisi d’utiliser la couche physique et d’analyser les signaux radio. Après avoir fait tourner une antenne pour écouter les signaux dans la rade de Brest, et ils ont fini par identifier un « tricheur » qui ré-émettait un signal légitime. Ce qui à permis de l’identifier, c’est la puissance d’émission beaucoup plus faible que la moyenne.

Comparaisons et attaques sur le protocole HTTP2

HTTP c’est très très trèèèèès vieux. Google à donc proposé d’améliorer le protocole sans patcher TCP pour améliorer les perfs. Par exemple 1 requête HTTP = 1 requête TCP. du coup pour éviter ça, ils ont proposé SPDY ou l’ont maintient la connexion TCP en mode statefull et ou l’on vient pousser toutes les requêtes HTTP avec en-têtes compressées sur cette connexion, et on y ajoute l’utilisation de TLS par défaut.

HTTP/2 c’est une copie de la norme de SPDY, c’est un protocole binaire assez complexe avec une gestion des priorités, un mode PUSH coté serveur, etc… Et c’est pas de la théorie, ça fonctionne avec Google, Facebook, Twitter, etc… Pour trouver un navigateur compatible, il suffit de jeter un oeuil sur l’excellent caniuse.com.

Du coup, comme c’est un protocole très récent, assez complexe, bah ça laisse la porte ouverte à pleins de problèmes de sécurité, pleins d’erreurs de dev, etc… Du coup comment venir checker la qualité de ces implémentations ? Pour se faire, l’orateur à utilisé l’algo LSTAR via pylstar, qui va regarder les échanges entre le client et le serveur, et ensuite il va vous donner l’automate qu’il aura identifié à partir des échanges réseaux qu’il a vu passer. Pour que LSTAR puisse fonctionner, il faut lui donner les messages d’entrée et de sortie du protocole. L’orateur à utilisé netzob pour avoir les messages. Après analyse de différentes implémentations serveur, on obtient les automates représentant l’implémentation.

A partir de ces automates, il est possible d’écrire des super-fuzzers. On peut faire du fingerprint pour détecter les implémentations si les automates diverges, en générant les messages qui provoquent des divergences dans le comportement. Il est aussi possible de faire de l’évasion d’IDS statefull en jouant sur des séquences de messages.

Toutes ces attaques sur les divergences d’automates viennent du fait que les RFC n’imposent aucun automate de référence pour l’implémentation.

Evolution des techniques d’attaques de circuits intégrés – Texplained – conférence invité

Une présentation sur les attaques hardware. Il existe 3 types d’attaques sur le hardware: les attaques non-invasives ou on joue avec les entrées-sortie du device. Les attaques semi-invasives ou on vient se brancher partout sauf dans la puce, et les attaques invasives ou on vient ouvrir la puce.

Bon une fois la puce ouverte, découpée radiographiée, il faut réussir à analyser ces vues 2D différentes pour venir comprendre quelles sont les portes & fonctions de la puce qui sont construites en 3 dimensions. L’orateur passe en revue les différents types de portes logiques construites à base de transistors.

Les attaques non-invasives se font à l’aide de « chocs » électriques, ou l’on va causer un défaut dans la puce et voir si elle crache de l’information. C’est une sorte de fuzzing hardware. L’autre technique c’est les side-channel, ou l’on va stresser la puce et lui faire faire des calculs, et on va observer ses consommations etc.. pour identifier d’éventuelles fuites d’info par induction electro-magnétique. (Ex: quand vous avez des écouteurs sur un laptop, vous pouvez entendre le bus de donnée grésiller dans les aigus si vous avez l’ouïe fine ou le volume à fond).

Les attaques semi-invasives consistent à décaper le haut de la puce et à  utiliser un laser pour faire de l’injection de faute, en faisant chauffer le semi-conducteur, ce qui provoque des changements dans le comportement physique du composant. On peut aussi identifier certains composants comme les horloges par les émissions lumineuses (infrarouge?) du composant (merci le microscope).

Les attaques invasives consistent à décaper la puce couche par couche pour en retrouver les circuits et les fonctions qui la composent. Bon après faut re-constituer le sandwich en analysant chaque image obtenue sur chaque couche. Bon bien sûr c’est jamais idéal, il y a des déformations optiques etc… avec lesquelles il faut composer. Exemple d’attaque classique: lire une ROM ou il suffit de regarder si les transistors sont connectés ou pas pour savoir si les bits sont à 1 ou à 0.

Beaucoup de techniques impressionnantes pour des informaticiens mais qui semblent assez basiques pour l’orateur.

App vs Wild

Comment protéger un code applicatif contre un environnement hostile complètement corrompu ? et ce sans toucher au code source de l’application, ni suppositions sur le fonctionnement de l’OS. Du coup pour ce faire l’orateur emploie la virtualisation. Il s’agit d’une micro-virtualisation basée sur Ramooflax. L’objectif c’est de protéger le code, mais pas les données, et sans gestion des attaques physiques. Les applications sont déployés de manière chiffrées grâce à une toolchain. L’hyperviseur s’occupe de déchiffrer à la volée les pages mémoires. En gros le micro-hyperviseur vient se glisser entre l’OS et l’application et le hardware. Ainsi les applications « secrètes » sont déchiffrées uniquement lorsqu’elles accèdent au CPU et que l’hyperviseur identifie leur exécution sur ce dernier.

Winbagility : Débogage furtif et introspection de machine virtuelle

Bon, les malwares Ring0 c’est la galère, et PatchGuard vient aussi mettre la grouille dans votre analyse dynamique de malware. L’introspection c’est la reconstruction de l’état de l’invité sans l’altérer (pas d’agent, pas d’artefacts). L’objectif c’est de pouvoir poser des breakpoints pour l’analyste. La plupart des outils de debug utilisent un agent qui debug le process, soit qui hookent ntdll et/ou kernel32. Il existe pas mal de tricks pour détecter le debugging, du coup il faut aller plus profond.

Pour faire des memory breakpoints, l’orateur utilise des EPT. Les breakpoints traditionnels ne sont pas très efficaces s’il n’y a pas de mode debug d’activé. Du coup il faut implémneter des hyperbreakpoints pour des pages mémoire (c’est hyper technique.). L’orateur détaille les différentes techniques employées pour obtenir ses hyperbreakpoints.

L’orateur à en suite développé un stub GDB nommé Windbgability qui viens s’interfacer avec l’hyperdebugger FDP qui permet de debugger des malwares ring0, faire des dumps mémoire et de « faire caca dans la mémoire » pour provoquer des BSOD.

Déverrouillage d’Android en simulant un clavier/souris

Pour déverrouiller une smartphone android, l’orateur utilise le mode OTG du port usb Android pour brancher un clavier tout en maintenant la charge du téléphone. Il existe des cables qui font charge et OTG mais c’est pas très très fiable, voir pas du tout. Du coup, l’orateur est parti sur un premier système à base d’Arduino mais qui ne pouvait pas faire de détection. Du coup ils ont couplé un Tensy et un RaspberryPi avec une webcam USB pour venir faire le bruteforce et détecter le déverrouillage du téléphone. Les comparaisons entre les screenshots sont fait avec ImageMagick, mais la luminosité impacte le diff entre les images. L’orateur à donc mis son système dans une valise, et il a malgré tout constaté des variations liée au chat venu se coucher sur la valise.

The Metabrik Platform: Rapid Development of Reusable Security Tools

Metabrik est un mix entre un shell unix classique, un vrai langage avec une read-eval-loop et un framework pour faire des composants ré-utilisables et modulaire. L’objectif c’est le « do it once » pour ne pas avoir à refaire tout le temps les choses. Metabrik n’est pas fait pour automatiser les entrées-sorties. Les outils sont là pour aider l’humain mais pas pour les remplacer.

Démonstration du shell interactif avec gestion de variables à la python, et wrapping des commandes shell type ls & cie. Le shell est personnalisable (variables d’environement, briks, etc…). L’auto-complétion des commandes, variables, fichiers etc… et une gestion des dépendances entre les briks.

Les briks sont des wrappers autour d’outils classiques, qu’on peut enrichir de fonctions supplémentaires dont les résultats serons rendu disponibles dans des variables. Exemple d’utilisation d’une brik virtualbox et volatility, et de leurs interactions.  Ainsi vous pouvez capitaliser sans trop d’efforts vos scripts.

Les commandes ainsi tapés peuvent servir de base pour coder vos bricks, c’est donc un meta-outil avec plus de 200 briks disponibles le tout en open-source.

DYODE : Do Your Own DiodE, Une diode open source à moins de 200€ pour réseaux industriels

La diode consiste à utiliser les propriétés physiques d’une transmission optique pour obtenir une diode de transfert de donnée. Le problème c’est que les diodes réseau existantes, bien que performantes sont très chères (environ 10k). L’objectif est donc de réutiliser du matériel standard et des logiciels open-sources pour moins de 200€. Le composant le plus coûteux étant le boitier (59€).
.
Pour faire la diode, les orateurs ont utilisé des convertisseurs cuivre/optique standard avec une interco des fibres up et down. Un 3ème convertisseur sert pour maintenir la liaison optique up en permanance. Ce qui fait une centaine d’euros de convertisseurs. En suite les RaspberryPi servent de guichet d’entrée et de sortie pour gérer le transfert de données.

Pour le protocole de transfert ils ont utilisé udpcast, un protocole utilisé pour le transfert de fichiers sur UDP.  Pour modbus, un client modbus vient requêter l’automate, et un serveur modbus est monté de l’autre coté. Autre exemple avec un système de partage d’écran à coup de screenshots transférés au travers de la diode.

Reste à durcir et fiabiliser la solution, et ajouter des protocoles industriels.

Résultats du challenge SSTIC

La conception c’est faite avec 11 personnes pour développer les challenges, et 3 bêta-testeurs. Le challenge était organisé en 3 niveaux, chaque niveaux proposant N challenges. Chaque niveau est protégé par un secret cryptographique de shamir, de sorte que lorsqu’un certain nombre de challenges du niveau 1 sont résolus, il est possible de déchiffrer le niveau suivant.

Coté solutions originales on a le cassage d’un crc32 à la main avec un papier et un crayon. Plein d’analyses par exécution symbolique. Du patch de binaire, du Ripp de code windows pour le faire tourner sous linux. Et bien entendu du bruteforce. De belles illustrations, et des updates de tools comme l’EBC pour miasm. Et l’Itanium dans IDA c’est moche 🙂

Level 0: téléchargement d’une capture réseau qui est en fait une requête HTTP qui télécharge un .zip
On trouve dedans un jeu RPGJS, et le joueur incarne un personnage qui interagit avec le monde créé. Chaque lvl contiens des pnj qui fournissent les épreuves.

Au lvl1, un fermier fournis un pcap qui contient un échange entre un pc attaquant et un RAT qui s’appelle gh0st, et le mitre fournis un python pour le déchiffrer. En analysant les échanges on récupère un .zip. Un scientifique en blouse file un fichier 8XP pour calculatrice TI. Et il existe des décompilateurs pour ce bytecode. Une fois le source obtenu, il faut lire un code C d’un crc32, plus agréable que le bytecode gavé de goto. Le 3ème pnj file un .zip d’un flux de donnés décodable par le compagnon gnuradio. Dans les échanges gsm, on retrouve des paquets correspondant à la reception d’un SMS avec la clef.

Au Lvl 2, il y a un fichier zip avec beauuuuucoup de 0, un sparsefile qu’il faut soit extraire dans un filesystem type lzfs qui gère ce genre de fichiers, ou optimiser la décompression. On trouve en suite un binaire avec plein de petits bouts de codes. Une fois le programme reconstruit, il donne la clef du challenge. Autre épreuve, le loader. Le fichier charge une font créée avec FontForge, et le ? contient deux images superposées. On découvre alors que chaque caractère peut être accompagné de code à exécuter lors de l’affichage de la font. Le programme lié au caractère ? est fait d’un ensemble d’opération simples qui fournit une série d’entiers qui correspondent à la font. Enfin le UEFI fou. Du coup pour résoudre ce challenge, l’orateur à développé à l’arach un support miams pour le code de l’UEFI. Grâce au moteur d’exécution symbolique, on peut simplifier le code en question ce qui permet de déduire le mot de passe.

 Au Lvl 3, il y a 4 épreuves. USB correspond à un PE qui charge un driver, qui fait plein de manips crypto et qui stocke le résultat sur une clef USB. Une vidéo : c’est un écran de veille windows, et c’est une succession d’images avec plein de couleurs. Il lit le contenu d’une clef de registre et affiche une couleur en fonction de la valeur de la clef et de la couleur précédente. Strange, c’est un binaire elf itanium 64 bits. Le binaire attend un un fichier PGM Ascii, il lit l’image par carrés de 20 pixels, et fait des manip dessus. Après analyse on identifie un réseau de neurones capable de reconnaître des caractères spécifiques, et on les retrouve quelque-part dans le binaire. Il suffit de brute-forcer la clef en donnant les caractères au réseau de neurones qui reconnait ou non les caractères ce qui vous donne la clef. Ring est un anneau de process qui se debug entre eux et qui communiquent via des exceptions. De nombreuses commandes sont implémentées, keylogging, récupération de la clef, validation de la clef, anti-debug. Une zone mémoire est créée a l’adresse sstic en leetspeak. La clef dépend des caractères tapés, et du temps écoulé entre chaque frappe, et elle est dérivée à l’aide d’un gros tas d’instructions SSE. L’appel de fonctions se fait à grand coup d’interruptions int3. Du coup pour s’en sortir l’orateur à rippé le code SSE et l’a mis dans un ELF et utilise ptrace pour intercepter les int3. A l’analyse, il y a une fonction souvent appelée, qui s’avère être une multiplication de deux nombres. D’entrée-sortie de fonction à l’autre, on fini par déduire le fonctionnement de chaque fonction, ce qui permet au final de remonter à la fonction. Au final il s’agit d’un « K^2 mod 2 ». Le step 4 est une simple chaîne en ROT13.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *