Retour sur la 14e édition du SSTIC (2016)  – Jour 3

Retour sur la 14e édition du SSTIC (2016) – Jour 3

Cet article fait suite au résumé du 1er et du 2e jour du SSTIC.


MacOS : System Integrity Protection, par Nicolas RUFF (@newsoft)

SLIDES / VIDEO / ARTICLE

Nicolas Ruff a initié cette dernière journée en s’intéressant à la fonctionnalité SIP (System Integrity Protection) a.k.a « rootless » d’OS X (désactivable en mode Recovery). L’objectif est de définir un ensemble de permissions propres à chaque application et non plus liées à un utilisateur. Il est ainsi question d’établir des restrictions au niveau du compte root ou des sudoers afin de protéger l’intégrité des fichiers et répertoires à risque sur le système en bloquant notamment l’accès en écriture aux (/System, /bin, /sbin, etc.), aux processus systèmes signés par Apple, etc. Le tout est défini dans le fichier de configuration /System/Library/Sandbox/rootless.conf ou visualisable via un « ls -lO <path> ».

Bien évidemment, il ne s’agit là que de la théorie. Nicolas a démontré qu’avec un peu de lecture et de documentation il était possible de contourner cette composante. À titre d’exemple, en abusant des commandes kext*, en installant des extensions noyau non signées, en abusant de certaines extensions signées ou encore en détournant d’anciennes versions d’applications à l’instar de GDB ou de XCode, il est possible de passer outre ces restrictions. En l’état, ajouter un composant de sécurité sur un modèle ayant des failles s’avère complexe et apporte son lot de bugs, mais de là à dire que la sécurité est un échec il n’y a qu’un pas…

 

Java Card security, Software and Combined attacks, par Jean Dubreuil

SLIDES / VIDEO / ARTICLE

Jean Dubreuil et Guillaume Bouffard ont tout d’abord réalisé une introduction commune autour des concepts Java, JavaCard, des notions de Java Card Virtual Machine (JCVM), de Byte Code Verifier (BCV), et des principales attaques qu’il est possible de mener. On retrouve notamment des injections de fautes, des attaques combinées, des attaques par canaux cachés, des techniques de fuzzing, etc.

Jean a pris le relai afin de présenter son travail permettant de contourner le mécanisme de sécurité protégeant les clés cryptographiques embarquées (avec un BCV correct). A ce titre, un exemple permettant de contourner le firewall (destiné à séparer des applications sur la carte et pour le routage d’apdu) à l’aide d’un stack overflow a été exposé permettant d’altérer et de maîtriser dans une certaine mesure la stack afin d’abuser du security context. Le problème vient donc d’un bug de la VM au moment du runtime et conduit à une élévation de privilèges.

Seconde technique, injection de fautes avec une attaque combinée en utilisant une opérande RET (permettant de réaliser un saut vers une adresse en fin d’une subroutine déclenchée via un bloc finally). Il en résulte la lecture d’une variable locale maîtrisée par l’attaquant et l’exécution du code malveillant.

En l’état, le BCV ne peut assurer à lui seul la sécurité, il est important de protéger à la fois la partie software et hardware afin de se prémunir de ce type d’attaques, mais la surface d’exploitation demeure importante.

 

Fuzzing and Overflows in Java Card Smart Cards, par Guillaume Bouffard (@_Stroumph) et Julien Lancia (@JulienLancia)

SLIDES / VIDEO / ARTICLE

Julien et Guillaume ont poursuivi la séquence JavaCard en parlant de fuzzing et d’overflow.

Dans le cas présent, il s’agissait de présenter une faille dans le Byte Code Verifier (BCV) permettant de l’exécution native dans la VM résultant en l’exécution de code arbitraire. Basé sur du fuzzing génétique, ils ont muté chaque génération de fichiers CAP afin d’obtenir un CAP muté. Il est important de préciser que le CAP d’origine vient d’un CAP valide. Leurs tests ont été réalisés à l’aide de la VM de référence fournie par Oracle. Si la VM crash ou si une erreur est levée alors que le BCV a validé comme correcte cette application, un bug est détecté.

Une fois le bug découvert, ils l’ont exploité sur une implémentation en boîte blanche. Enfin, ils ont présenté une technique pour caractériser la modification du flux de contrôle en boîte noire.

 

Noyaux Linux durcit, par Yves-Alexis Perez

SLIDES / VIDEO / ARTICLE

Présentation du composant Grsecurity permettant d’apporter un niveau de sécurité supplémentaire au noyau Linux. Grsecurity inclut notamment le système de contrôle d’accès PaX utilisé afin de renforcer la sécurité du système (espaces d’adressage mémoire aléatoires, protection contre le ROP, etc.) ou encore RBAC (Role Based Access Control) permettant d’affiner la gestion des droits des utilisateurs. Yves-Alexis a ici évoqué l’éternel problème de correction des bugs alors qu’une surveillance « active » semble une solution bien plus pérenne.

Avec Grsecurity, il est question d’autoprotection du noyau afin d’endiguer une partie des exploits contrairement aux solutions SELinux ou encore AppArmor visant le userland. L’idée est bonne, mais les problématiques d’implémentation de l’outil (compilation, configuration, etc.) éloignent une partie des utilisateurs qui ont parfois peur de mettre les mains dans le code ou la ligne de commandes.

 

Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne, par Charles Hubain et Philippe Teuwen (@doegox)

SLIDES / VIDEO / ARTICLE

Présentation d’une attaque par analyse différentielle de calcul (Differential Computation Analysis – DCA) avec illustration de l’efficacité d’extraction de clés secrètes. Il s’agit là de la contrepartie logicielle des attaques dites de Differential Power Analysis (DPA) basées sur la consommation électrique.

Comme stipulé par Charles et Philippe, aujourd’hui encore, beaucoup trop d’entreprises vendent des solutions de cryptographie white-box supposées « sécurisées » en pensant détenir le Graal. Leur solution miracle ? La cessation de publication des implémentations ou comment revenir aux bons vieux démons de la sécurité par l’obscurité.

Pourtant, en développant des greffons applicables sur des outils d’instrumentation binaire dynamique, il a été possible d’enregistrer les adresses mémoire et les données qui sont utilisées afin d’établir des corrélations permettant d’obtenir les clés voulues.

L’approche présentée ici permet donc d’extraire automatiquement les clés d’une white-box très rapidement et sans connaissance des détails de sa conception. Plus rapide, plus efficace, moins contraignant, que dire de plus ?

 

Windows Error Reporting, par Aurélien Bordes

SLIDES / VIDEO / ARTICLE

Aurélien Bordes a présenté le composant WER (Windows Error Reporting), le remplaçant de Docteur Watson. Il permet de générer un rapport d’erreur (crash d’application, crash noyau, etc.) qui sera envoyé à Microsoft. Un rapport WER est situé au du répertoire utilisateur (Appdata/local/Microsoft/Windows/WER/ReportQueue) et est composé des éléments suivants :

  • un rapport texte (wer)
  • fichier de dump mémoire (complet ou partiel)
  • fichiers liés aux plugins d’analyse

Seuls les rapports d’erreur sont archivés (WER Report) après été envoyé.

Microsoft reçoit plus de 10 millions de rapports par jour. Ces rapports sont très précieux pour découvrir des 0days. Notamment nous vous conseillons la lecture sur le blog de Microsoft de l’origine de la découverte de la MS08-067. Seul Microsoft reçoit ces rapports. Néanmoins, il est possible de se déclarer comme tiers de confiance pour avoir accès à ces rapports.

Il est également possible de configurer son propre serveur (Collecteur WER entreprise) pour recevoir les rapports. Les échanges utilisent le protocole Coroporate Error Reporting (CER) v1 en SMB ou v2 en HTTP(s). Cette fonctionnalité est très pratique notamment en cas d’analyse Forensics (tous les crash dumps sont ainsi centralisés).

Une autre fonctionnalité permet de configurer des actions qui seront réalisées lors du prochain crash :

  • récupération de fichier arbitraire
  • exécution de commande WMI
  • lecture ou modification de clé de registre
  • génération d’un dump mémoire

Heureusement, toutes ces actions sont réalisées dans le contexte de l’application qui a crashé. Donc en cas de crash noyau, WER peut avoir accès à l’ensemble des fichiers. Mais c’est transparent pour l’utilisateur, l’ensemble des fichiers transmis sera détaillé au sein du rapport (report.wer).

Aurelien a illustré sa présentation de diverses démonstrations, s’appuyant sur un script PHP disponible publiquement et permettant de simuler le comportement d’un collecteur.

 

Bypassing DMA remapping with DMA, par Benoît Morgan, Eric Alata, Guillaume Averlant et Vincent Nicomette

SLIDES / VIDEO / ARTICLE

La conférence s’est tout d’abord orientée autour d’un état des lieux des attaques DMA (accès à la mémoire principale depuis les périphériques qui sont indépendants sur processeur donc potentiellement accès au code et à la mémoire d’applications privilégiées). Puis une attaque d’IOMMU (Input–Output Memory Management Unit) mettant en avant une erreur de conception au sein du firmware et du driver d’IOMMU Intel pour Linux a été présentée. Comment ça se passe ?

  • Un périphérique PCI Express développé sur FPGA ;
  • Les spécifications matérielles Intel ;
  • Le code source de Linux ;
  • Un peu de YOLO, on croise les doigts et ça marche ! ;

En conclusion, les IOMMU ne sont pas utilisés pour le cloisonnement et il est nécessaire de revoir les responsabilités firmware / OS vis-à-vis du Direct Memory Access Remapping (DMAR).

 

Scapy en 15 minutes, par Guillaume Valadon et Pierre Lalet (@pi3rre)

SLIDES / VIDEO / ARTICLE / NOBEBOOK

15 minutes pour parler de Scapy, « challenge accepted » et avec brio. L’outil de manipulation de paquets en Python a été décrit en présentant un échantillon de ses nombreuses fonctionnalités (génération de paquets, manipulation des champs, snippet de code python, composants graphiques de visualisation, gestion des piles réseau, gestion d’automates, etc.). Avec le support ASN1 et X509, l’outil devient de plus en plus complet, mais attention une version Python 3 n’est pas encore d’actualité.

 

Plaso & Timesketch, par Romain Gayon

SLIDES / VIDEO / ARTICLE

Romain Gayon travaille chez Google au sein de l’équipe de réponse à incident est venu présenter les deux outils Plaso & Timesketch qui permettent la génération d’une frise chronologique des évènements identifiés.

Plaso regroupe plusieurs outils :

  • Log2timeline.py qui permet de parser tout évènement contenant des timestamps.
    • On peut ainsi importer de manière simple une image disque. Il supporte quasiment tous les systèmes de fichiers (EXT, FAT, …) ainsi que tous les formats d’image disque (RAW, VDI, VMDK, etc.). Des plugins peuvent également être ajoutés pour automatiser les tâches fastidieuses, comme l’interaction avec Virus Total.
  • psort.py qui permet de filtrer/trier ces mêmes évènements.
    • Cet outil fournit une sortie exploitable pour utiliser le meilleur outil de forensics « grep ». L’outil permet également de faire certaines analyses.

L’outil est disponible sous Mac, Windows et Linux. Il est installable facilement notamment via les gestionnaires de paquets (python-plaso).

Timesketch est un outil basé sur Elasticsearch qui fournit une riche GUI pour afficher la timeline. Il permet notamment :

  • d’annoter des évènements ;
  • d’afficher plusieurs systèmes sur une même timeline ;
  • de travailler de manière collaborative.

Cet outil est testable en ligne à l’adresse suivante :

 

Graphes de dépendances : Petit Poucet style, par Aymeric Vincent, Camille Mougey (@commial), Caroline Leman, Fabrice Desclaux et Mathieu Blanc

SLIDES / VIDEO / ARTICLE

Fabrice Desclaux et Camille Mougey sont venus présenter un algorithme permettant de déterminer les variables dont dépend une fonction donnée. Pour commencer, il a réalisé un état de l’art sur les différents algorithmes existants :

  • BackwardSlice qui est utilisé au sein du framework Angr.io. Cet algorithme est statique sans distinction des chemins d’exécution. Il dépile ainsi tous les chemins possibles sans prendre en compte les liens entre les différents chemins. Il peut ainsi présenter des ensembles de valeurs qui ne sont pas possibles.
  • PathGroup également utilisé au sein de Angr.io. Contrairement à l’algorithme précédent, celui est « path sensitive ». Il va donc trouver un ensemble de chemins d’exécution valide et ainsi des groupes de valeurs possibles. Son principal désavantage est son temps d’exécution notamment à cause des boucles qui sont systématiquement parcourues.
  • Backtrace implémenté au sein du logiciel Metasm. Cet algorithme est similaire au précédent sauf que pour pallier aux problèmes de temps d’exécution, les boucles sont limitées à une seule passe afin de traverser rapidement les parties inutiles du code assembleur. Néanmoins cette approche « destructive » peut engendrer d’importantes erreurs.

Les chercheurs ont ensuite présenté de manière naïve (sans code assembleur) leur propre algorithme. Le but est de réaliser un algorithme suffisamment précis en réduisant la complexité due aux boucles. Pour ce faire les chercheurs ont introduit un concept nommé DépendencyState qui rassemble les informations rencontrées dans l’étude d’un chemin d’exécution donné. L’idée est de remonter les parents d’une variable afin de vérifier qu’aucune collision n’est rencontrée lors de l’analyse des différents chemins d’exécution. Dans ce cas, seul un chemin sera gardé permettant d’accélérer de manière notable le temps de calcul.

Cet algorithme est disponible sous forme d’un script IDA pour être exécuté sous MIASM.

 

Conférence de clôture, par Karthikeyan Bhargavan

SLIDES / VIDEO / ARTICLE

Cette conférence était la seule traitant du sujet de la sécurité SSL et notamment des différentes attaques. Karthikeyan Bhargavan dirige le projet nommé Programming Securely with Cryptography ou Prosecco à l’institut de recherche de l’INRIA.

Une raison principale de la présence des bugs est la promiscuité des différents modes. En effet, un protocole de chiffrement, pour des raisons de rétrocompatibilité, embarque de multiples algorithmes qui augmentent le risque de failles. De plus, ces algorithmes sont souvent plus considérés comme robustes et permettent ainsi de réaliser des attaques de type « downgrade ».

Tous sont basés sur Transport Layer Security (TLS), qui peut être considéré comme un framework de communication sécurisé. En effet, il existe plus de 100 combinaisons de protocoles (ex : TLS 1.2), de méthodes pour l’échange des clés (ex : ECDHE), de modes d’authentification (ex : RSA) et d’authentication Encryption schemes (ex : RC4). La robustesse de TLS est donc en général garantie par un assemblage spécifique et limité de ces briques.

Afin de vérifier les diverses implémentations, l’équipe du chercheur a implémenté un fuzzer nommé FlexTLS qui avait été présenté l’an dernier par Benjamin Beurdouche et Jean Karim Zinzindohoue. Cet outil permet d’assembler les diverses briques requises afin de tester les transitions entre les différents algorithmes utilisés. La recherche s’applique uniquement sur l’enchaînement des différentes phases, mais pas sur les messages chiffrés envoyés.

Ils ont par exemple identifié la vulnérabilité appelée SKIP (Message Skipping Attacks on TLS), qui permet de réaliser des attaques man-in-the-middle entre un client Java TLS (JSSE) et le serveur. L’attaquant est en mesure de convaincre sa victime de réaliser une connexion sans chiffrement.

Les chercheurs proposent une implémentation sécurisée appelée miTLS dont l’enchaînement des différentes briques a été vérifié (avec FlexTLS bien sur).

Le chercheur a ensuite détaillé les attaques suivantes :

  • LOGJAM : attaque qui permet de « casser » le protocole Diffie Hellman en downgradant la clé négociée à 512bit. Cette attaque est un reliquat de FREAK. Pour l’anecdote, le site du FBI qui permet de donner des informations de manière anonyme utilise du Diffie Hellman avec une clé de 512bits…
  • SLOTH : attaque basée sur les collisions. En effet, l’attaquant va signer les paquets issus des deux victimes de manière à qu’ils soient reconnus par les deux parties comme viables.

Avec cette édition 2016, le SSTIC a encore une fois été à la hauteur de sa réputation. Nous attendons la prochaine édition avec impatience !

Enfin, vous pourrez également trouver d’autres comptes-rendus aux adresses suivantes :


Cert-XMCO