SecurityInsider
Le blog des experts sécurité Wavestone

Compte-rendu du SSTIC 2016 - Jour 3



Et pour clore notre compte-rendu de l'édition 2016 du SSTIC, retour ci-dessous sur la 3ème et dernière journée ! Bonne lecture !
MacOS : System Integrity Protection
System Integrity Protection, abrégé SIP, est un mécanisme de sécurité spécifique à Mac OS X qui bloque l’accès en écriture – même pour l’utilisateur root – à des dossiers (/System, /bin, /sbin…), des liens symboliques (/etc, /tmp, /var), des processus système signés par Apple (accès à la mémoire du processus, débogage, analyse DTrace…), et restreint le chargement d’extensions noyau non signées. Dans cette présentation, Nicolas Ruff présente les différentes manières de contourner SIP. Jusqu’à OS X 10.10, il est possible de désactiver SIP via un argument de démarrage, ou d’exploiter le fait que la vérification de la signature est effectuée en espace utilisateur : recompiler la commande « kextload » depuis les sources publiques permet par exemple de faire accepter des signatures invalides. D’autre part, il existe une liste blanche d’extensions noyau acceptées sans signature, identifiées par leur condensat SHA1, qui est mise à jour silencieusement par Apple – sans pour autant être manipulable par un attaquant. Enfin, certaines applications légitimes (qui possèdent les bonnes autorisations) comme fsck_cs peuvent être détournées pour passer outre SIP, ce cas particulier ayant été corrigé dans OS X 10.11.5.
Nicolas a conclu en soulignant que si SIP essaye de transformer le modèle de permissions assignées à des utilisateurs vers un modèle de permissions assignées à des applications, ce modèle est complexe à implémenter et qu’il faut s’attendre à la découverte de nouveaux bugs permettant de contourner ses restrictions.
Java Card Session
Cette partie est constituée de deux présentations sur la sécurité des JavaCards, par Jean Dubreuil (Serma Safety and Security) sur une attaque au niveau logiciel puis une attaque combinée, et par Guillaume Bouffard et Julien Lancia (THALES Communications and Security) sur du fuzzing évolutionnaire qui a permis de trouver un buffer overflow et d’exécuter du code arbitraire sur une JavaCard.
Après un rappel sur l’omniprésence des Secure Elements, l’architecture des Java Cards a été détaillée : avant d’être installés sur la Java Card, les applets doivent être validés par le Byte Code Verifier (BCV) pour éviter notamment l’exécution de code malveillant ou d’instructions illégales (accès à des zones mémoire d’une autre application par exemple).
Jean Dubreuil a donc présenté une attaque logicielle exploitant un buffer overflow dans la JVM, qui permet le contournement du pare-feu entre les applications de la JavaCard et donc une élévation de privilèges. Sa deuxième attaque est une attaque combinée, utilisant une applet composée d’une partie « légale » et d’une partie « malveillante » jamais exécutée (l’applet est donc considérée comme « légale » par le BCV et acceptée sur la carte), et de l’injection de faute pour perturber l’exécution du programme. En concevant l’applet de manière astucieuse, il est possible de modifier l’adresse de retour grâce à l’injection de faute, permettant d’accéder et d’exécuter la partie « illégale » du programme. Cette deuxième attaque permet également de contourner le pare-feu et d’exécuter du code arbitraire.
La deuxième présentation s’est quant à elle focalisée sur une vulnérabilité dans le BCV et sur la méthode qui a permis de la découvrir. En utilisant un algorithme évolutionnaire pour muter le fichier CAP (Converted APplet, qui contient l’application), une faille dans le BCV a été découverte – et ce dès la seconde génération. Une vérification manquante dans une implémentation du BCV permet donc d’obtenir un accès complet en lecture et écriture sur la mémoire de la carte.
Noyaux Linux durcis
Yves-Alexis PEREZ a présenté le patch de durcissement Linux grsecurity, en expliquant en quoi il permettait d’obtenir une sécurité accrue pour le noyau et le système. Grsec est composé de PaX (contre les corruptions mémoire), de RBAC (contrôle d’accès basé sur des rôles) et d’autres éléments de durcissement, et il protège contre certaines vulnérabilités (use-after-free par exemple). En revanche, il reste peu déployé, notamment car il n’est pas inclus dans le noyau mainline, qu’il provoque des problèmes de compatibilité et de support et également une légère baisse des performances. Pour résoudre ce problème de difficulté d’installation et de maintenance, l’auteur a donc publié des outils permettant de recompiler facilement le noyau, et propose des adaptations pour un usage desktop (la configuration par défaut empêche par exemple d’utiliser le navigateur chromium).
Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne
Charles Hubain et Philipe Teuwen, de Quarkslab, ont présenté les attaques de type « crypto white-box » où l’attaquant a un accès total sur le matériel et peut donc utiliser toutes les possibilités physiques et logiques pour en extraire les données sensibles. C’est par exemple le cas rencontré avec les DRM, ou le paiement mobile.
Les attaques académiques sur les modèles existants ont conduit à de nouveaux modèles, à leur tour cassés par des attaques académiques, ce qui a poussé les industries à garder leurs designs secrets en utilisant des techniques d’obfuscation pour augmenter le coût des attaques. Ces attaques peuvent néanmoins être remplacées par des techniques comme l’identification visuelle de l’algorithme cryptographique : en enregistrant toutes les instructions et les accès mémoire, que ce soit sur le code, la pile ou les données, et en les représentant en fonction du temps, l’algorithme peut être facilement et rapidement reconnu. Sur l’image ci-dessous, on peut par exemple reconnaître DES grâce à ses 16 rounds successifs.

Trace d’exécution logicielle d’une implémentation « white-box » de DES
Après avoir identifié l’algorithme, il est possible de récupérer la clé en utilisant une technique de Differential Power Analysis ! Cette technique est performante, mais d’autres techniques comme la Differential Fault Analysis permettent d’atteindre des résultats similaires voire encore meilleurs.
Les auteurs ont également publié 5 outils dédiés aux attaques side-channel sur le Github SideChannelMarvels : Tracer, Deadpool (automatisation d’attaques), Daredevil (Computation Power Analysis), JeanGrey (Differential Fault Analysis) et enfin Orka qui propose des images Docker de ces outils pour une utilisation simplifiée.
Windows Error Reporting
Aurélien Bordes a présenté le système de traitement des rapports d’erreur de Windows (WER – Windows Error Reporting), qui sont générés en cas d’exception, de freeze d’une application ou d’un crash système. Les rapports sont utilisés pour corriger les bugs des applications Windows, mais des éditeurs de logiciels reconnus peuvent également demander à recevoir les rapports relatifs à leurs propres produits. Ces rapports contiennent des métadonnées qui peuvent parfois contenir des informations sensibles, ce qui pousse certaines entreprises à utiliser un collecteur WER en interne. Un tel collecteur permet d’éviter la fuite de données, mais peut également être utilisé en cas d’investigation numérique (un crash peut indiquer l’exploitation d’une vulnérabilité).
En revanche, ces rapports sont parfois transmis en clair, en HTTP. Or, un serveur a la capacité de demander des informations supplémentaires au client qui rapporte le crash, ce qui implique la lecture de fichiers arbitraires et même l’exécution de commandes côté client. Les commandes étant exécutées dans le contexte de l’utilisateur possesseur du programme (administrateur en cas d’un crash noyau), un collecteur compromis pourrait prendre le contrôle des postes concernés par un crash ! La sécurisation du collecteur est donc cruciale : s’il est désigné collecteur d’un datacenter, il est au moins aussi sensible que l’élément le plus sensible du datacenter.
Aurélien a également publié une implémentation d’un collecteur en PHP, disponible sur son Github.
Bypassing DMA remapping with DMA
Benoît Morgan (LAAS-CNRS) a présenté une « attaque d’IOMMU » exploitant une vulnérabilité au sein du firmware et du driver d’IOMMU Intel pour Linux. La fonction Direct Memory Access (DMA) permet à des périphériques d’accéder à la mémoire principale indépendamment du CPU. Pour contrôler la légitimité des accès mémoire, les Input Output Memory Management Unit (IOMMU) effectuent une virtualisation de l’espace d’adressage grâce à une traduction d’adresse.
L’attaque présentée permet de prendre le contrôle complet de la mémoire, tout en préservant l’intégrité du code système. Ces IOMMU ne sont pas utilisées systématiquement par les OS pour effectuer du cloisonnement : désactivées par défaut sous Linux, non utilisées sous Windows… Un périphérique malveillant connecté sur le bus PCI peut donc prendre le contrôle complet du système.
Scapy en 15 minutes
Guillaume Valadon (ANSSI) a présenté les bases de Scapy, l’outil de manipulation de paquets réseau codé en Python et utilisable en ligne de console. Parmi les astuces également présentées, on pourra remarquer : .ls() permet de lister les propriétés d’un objet, .summary() pour afficher un résumé du paquet, ou .command() qui donne la commande à taper pour reproduire le même paquet. Plusieurs fonctions de visualisation ont également été présentées : .show() affiche le paquet couche par couche dans la console tandis que .ps_dump() l’affiche avec la position des champs, comme sur l’exemple ci-dessous.

D’autres fonctionnalités sont également utiles : répondeurs, automates (clients TCP, TFTP) équipés d’une fonction graph() pour en visualiser l’état, support du format X.509, et même signature de certificat pour faire de la génération de certificats à la volée.
Plaso & Timesketch
Romain Gayon, de l’équipe Réponse à Incidents de Google, a présenté Plaso et Timesketch, des outils d’assistance à l’investigation numérique (Digital Forensics).
Plaso est un ensemble d’outils écrits en Python, utilisés pour analyser tout ce qui contient des timestamps et générer des évènements normalisés (log2timeline.py), et pour trier et filtrer ces évènements (psort.py). Il est ensuite simple d’écrire son propre script d’analyse pour effectuer des investigations plus poussées. Plaso supporte un grand nombre de formats en entrée : images de disque (EWF, QCOW, Raw, VDI, VHD, VMDK), de volumes système (GPT, MBR, BitLocker...), de systèmes de fichiers, et gère également le déchiffrement, la catégorisation et l’annotation automatique, et même l’envoi de fichiers vers VirusTotal ou Viper.
Timesketch est utilisé pour gérer le workflow de la réponse à incident, de manière collaborative et centralisée. En l’alimentant avec Plaso, un analyste peut alors investiguer sur une timeline consolidée à partir de nombreuses sources, en ajoutant des commentaires, en visionnant le résultat de scripts d’analyse automatique, et en ajoutant des annotations pour faciliter la lecture.
Graphes de dépendances : Petit Poucet style
Dans cette présentation très rythmée de travaux de recherche du CEA, la problématique d’analyse automatisée de logiciels malveillants a été abordée sous la problématique : « comment retrouver la valeur d’une variable à un instant donné, en connaissant le code du logiciel ? ». Il faut alors remonter le flux d’exécution pour trouver qui participe à la valeur finale de la variable.
Pour répondre à cette question, la méthode manuelle sous IDA est inadaptée (lent et facile de faire des erreurs), et les outils automatisés comme Angr.io et Metasm soit fournissent un sur-ensemble de solutions, soit nécessitent une heuristique (lourd et peut oublier des solutions) pour gérer les boucles, soit ne récupèrent pas toutes les solutions. Les auteurs ont donc créé un nouvel algorithme capable de distinguer les chemins d’exécution pour n’étudier les boucles que le nombre de fois où c’est nécessaire, en évitant les chemins « équivalents en dépendance ».
Conférence de clôture
Pour cette dernière conférence, Khartikeyan Bhargavan a présenté sa vision sur la sécurité de TLS au travers des attaques découvertes au cours des dernières années. La question principale est la suivante : comment prouver que le protocole remplit bien ses objectifs de confidentialité et d’intégrité des données échangées ?
L’agilité cryptographique, qui permet de faire évoluer les « protocoles cryptographiques » de manière souple, est nécessaire pour conserver la sécurité sur le long terme. On citera par exemple la transition de SSLv3 vers TLS, de DH-768 vers Curve25519, ou de MD5 vers SHA-256. Cette agilité repose sur la capacité des parties prenantes à négocier le meilleur jeu de protocoles en fonction de leurs capacités respectives, mais les failles au niveau du protocole ou des implémentations les exposent aux « downgrade attacks » où un attaquant force l’utilisation d’un protocole obsolète pour espionner la communication ou altérer les données échangées. D’autres attaques sur SSL et TLS, au niveau protocolaire ou implémentation, existent également : SKIP et FREAK par exemple correspondent à une mauvaise implémentation de l’automate d’état de TLS, attaques qu’il est possible de trouver en fuzzant ces automates d’état.
Pour résoudre ces problèmes, il est possible de prouver les propriétés de sécurité d’un programme grâce à la vérification formelle. L’INRIA et Microsoft Research ont développé miTLS, une implémentation de TLS formellement vérifiée et développée en F#. Si miTLS est prouvée conforme au protocole, elle est en revanche toujours sujette aux failles protocolaires comme SLOTH ou Logjam (attaques par collision de transcript), d’ailleurs découvertes par l’équipe de Karthik.
Enfin, des failles cryptographiques peuvent rester cachées pendant de longues années : il est important de trouver et de se débarrasser de ces failles d’implémentation. Ici, Karthik rejoint Brad Spengler (conférence d’ouverture) : la sécurité ne s’atteint pas en corrigeant sans cesse des bugs, mais en intégrant la sécurité dès la conception, notamment en prouvant formellement les propriétés de sécurité aussi bien des protocoles cryptographiques que des implémentations. La première chose nécessaire pour atteindre ce but est simple : que les chercheurs en cryptographie et les concepteurs de protocole travaillent ensemble. TLS 1.3, encore en cours de conception, est une tentative d’appliquer ce modèle.

En conclusion, cette édition 2016 du SSTIC n’a pas déçu par la qualité et la variété des interventions. Nous ne pouvons qu’espérer une plus grande capacité l’an prochain ;)

Mickaël BERGEM

Aucun commentaire:

Enregistrer un commentaire