Retour sur l'édition 2019 de la HITB

XMCO a assisté à la 10e édition de la conférence Hack In The Box (HITB) qui s’est déroulée le 9 et 10 mai derniers. Comme les années passées, la conférence a eu lieu en plein centre de la ville, au sein du célèbre hôtel De Beurs van Berlage, un édifice considéré comme l’un des grands monuments de l’architecture néerlandaise du 20e siècle.

Cette année a été marquée par de nombreux concours:

  • IA / Human : concours de conduite d’une voiture téléguidée / autonome sur un circuit présent au sein de la conférence.
  • Capture the Signal : un CTF organisé par Trend micro où les équipes doivent reverser un signal inconnu.
  • A Women Cyber CTF: un CTF dédié aux femmes organisé par CyberTalents.
  • Le traditionnel CTF par équipe qui s’est déroulé pendant les 2 jours de conférence.

Tous ces concours ont donné lieu à une remise de prix allant de lots matériels à 1500e euros. Également, les gagnants du CTF ont gagné leur place pour le prochain CTF à Abu Dhabi où les 25 meilleures équipes du monde s’affronteront pour 100 000 $.

DSCF0968-4

Deux tirages au sort ont ponctué le déroulement de la conférence pour aller à Abu Dhabi et Singapour pour les prochaines éditions de la HITB.

Egalement de nombreux ateliers orientés electronique étaient disponible. Ils permettaient de « build stuff ».

DSCF0985-13

En attendant le prochain numéro de l’Actu-Sécu, nous vous proposons de revenir sur quelques conférences qui nous ont marquées. Les supports de quasi toutes les présentations lors des conférences sont disponibles à l’adresse suivante:

Les vidéos des conférences seront prochainement mises à disposition sur la chaîne YouTube officielle :

 

Toctou Attacks Against Secure Boot – Trammell Hudson et Peter Bosch

SLIDES

DSCF0964-2

Trammell Hudson et Peter Bosch sont venus présenter leurs travaux sur le composant de sécurité Intel nommé Boot Guard. Cette protection permet de se prémunir contre l’installation de rootkit / bootkit sur votre ordinateur. La sécurité repose principalement sur des méthodes cryptographiques (composants signés par Intel):

  • Des clés AES sont utilisées pour déchiffrer les updates du microcode.
  • Des clés RSA sont utilisées pour vérifier que l’intégrité du code.

Les chercheurs ont d’abord rappelé les différentes publications sur ce sujet:

Lors d’un démarrage, Boot Guard va s’assurer que la « chaîne de confiance » est respectée tout au long du process. Cette phase est décomposée en 2 étapes :

  • Vérification des éléments signés par Intel comme notamment le BIOS ACM (Authenticated Code Modules) présent au sein de la mémoire SPI Flash
  • Puis la vérification des éléments signés par les OEM comme le bootloader présent sur le disque dur.

Les premiers constats concernent les OEM qui n’initialisent même pas la protection Boot Guard sur le PC vendu. Un attaquant peut ainsi déployer ses propres clés de chiffrement et ainsi installer un malware qui ne pourra jamais être enlevé. Autre fun fact, lors des updates Windows 10, Windows parvient à désactiver Boot Guard :

Les chercheurs ont commencé par une approche assez évidente. Une chaîne de confiance est sécurisée seulement si tous les éléments de la chaîne le sont. Ils ont donc porté leur attention sur la phase de boot (IBB – Initial Boot Block) à l’aide de l’outil UEFITool (https://github.com/LongSoft/UEFITool) qui permet de visualiser les informations liées à chaque secteur. Les analyses menées ont permis à Trammell Hudson d’identifier deux vulnérabilités (CVE-2018-9062 et CVE-2018-12169).

Les chercheurs ont repris un constat du chercheur Alexander Ermolov, cela ne sert à rien d’attaquer l’algorithme, il faut attaquer son implémentation (https://2016.zeronights.ru/wp-content/uploads/2017/03/Intel-BootGuard.pdf).

Ils ont donc analysé quel composant était utilisé et quelles zones mémoire étaient utilisées. Au travers de cette analyse, ils ont ainsi pu identifier que l’ensemble des composants était initialisé au sein de la mémoire SPI Flash et également les zones mémoires accédées. Ils ont ainsi pu identifier des zones mémoires qui étaient réutilisées entre le moment où la vérification du code était réalisée et son exécution.

En partant de ce constat, les chercheurs sont parvenus à exploiter une vulnérabilité de type TOCTOU (Time Of Check To Time Of Use). Ce type de vulnérabilité repose sur un principe : l’altération de données entre les vérifications de sécurité de la donnée et son utilisation. Pour ce faire, les chercheurs ont donc conçu un FPGA capable de dialoguer avec la carte mère. Ce composant va ainsi détourner le « flux d’exécution » de la séquence de démarrage. Après avoir validé le code présent au sein de la carte mère, le module FPGA (SPISpy) va altérer son contenu pour exécuter du code arbitraire.

Une vidéo illustrant la preuve de concept a été montrée : un message en morse est joué avant que l’OS démarre alors que le PC est configuré avec le Boot Guard d’activé.

Cette conférence fut très didactique et les chercheurs sont parvenus à faire comprendre des éléments très techniques à l’ensemble de l’audience. Les chercheurs ont donc prouvé que le « Big Hack » de Bloomberg était possible (https://trmm.net/Modchips). L’ensemble des schémas du module SPISpy seront bientôt disponibles sur leur Github.

fn_fuzzy – Fast Multiple Binary Diffing Triage – Takahiro Haruyama

SLIDES

Le chercheur Takahiro Haruyama de la société CarbonBlack est venu présenter son outil de fuzzing fn_fuzzy sous forme de plugin IDA. Pour rappel, IDA Pro est l’outil le plus utilisé dans le monde du reverse et les analystes sauvegardent leur travail au format IDB (IDA pro DataBase). Il existe donc de nombreux outils permettant de faire l’analyse de fichiers IDB, notamment pour identifier des ressemblances entre deux analyses de malwares. Par exemple, si une fonction de chiffrement propre à un malware est identifiée, il sera sauvegardé au sein du fichier IDB correspondant. L’idée est de scanner les nouveaux malwares à la recherche de la fonctionnalité identifiée. Pour réaliser cette tâche, il existe 2 types d’outils:

  • Ceux qui réalisent une comparaison entre 2 échantillons (Diaphora, BinGrep, et BinDiff);
  • Ceux qui réalisent une comparaison à partir d’un échantillon analysé sur autant de binaires que l’on souhaite (Kamin0 et BinDiff automation tool).

Néanmoins ces 2 logiciels (Kam1n0 et BinDiff automation tool), présentent de nombreux inconvénients :

  • BinDiff: Le logiciel bindiff est propriétaire et comporte de nombreux bugs qui ne permettent pas d’utiliser l’outil à grande échelle.
  • Kam1n0 : Bien qu’il permette d’identifier les fonctions très offusquées notamment des fonctions de cryptographie (blowfish par exemple), l’outil requiert beaucoup de puissance.

C’est la raison pour laquelle le chercheur a donc voulu développer son propre outil respectant les 3 règles suivantes: il doit être rapide, léger et peu consommateur en puissance de calcul. L’outil repose sur le calcul de 2 algorithmes :

En combinant les 2 métriques, fn_fuzzy arrive donc à donner des scores de similitude et identifier des fonctions au sein de différents malwares. L’outil permet de configurer 3 différents seuils :

  • La valeur du score de similarité en prenant en compte le CFG.
  • La valeur du score de similarité sans prendre en compte le CFG.
  • La taille minimum de la fonction pour générer le fuzzy hash de type ssdeep.

En toute transparence, selon le chercheur, le logiciel BinDiff reste le meilleur outil en termes de précision des résultats. Mais fn_fuzzy permet une analyse plus rapide. Il permet donc une analyse plus aisée sur de nombreux binaires de taille importante. Par contre, dans certains cas, aucun outil n’est efficace (pour l’échantillon shadownhammer par exemple), ou il est nécessaire de développer un nouvel algorithme pour le détecter.

Son outil est disponible sur github:

The Birdman and Cospas-Sarsat Satellites – Hao Jingli, 360 Technology

SLIDES

Le chercheur de la société 360 Technology a présenté ses travaux sur le système COSPAS-SARSAT. Ce système est utilisé pour les missions de recherche et sauvetage (SAR), par exemple pour les navires en détresse. Il est composé de deux réseaux distincts de satellites (67 satellites au total) :

  • LEOSAR (Low-Earth Orbiting Search and Rescue), des satellites à orbite basse traversant les pôles.
  • GEOSAR (Geostationary Search and Rescue), des satellites en orbite géostationnaire.

Depuis sa création en 1982, le système Cospas-Sarsat a permis de sauver 35 000 vies humaines avec plus de 41 000 missions SAR. Pour utiliser ce système, il y a plus d’une centaine de centres de contrôle répartis à travers le monde.

Tout d’abord, pour pouvoir communiquer et intercepter les communications, le chercheur a construit sa propre antenne OpenATS (https://github.com/OpenATS/OpenATS). Cette antenne va se verrouiller sur un satellite en basse altitude (LEOSAR) et ainsi récupérer les communications. Une vidéo a été montrée pour illustrer à quelle vitesse les satellites vont :

Une fois les signaux captés, il a utilisé les outils traditionnels du milieu :

  • GNU Radio : c’est une suite logicielle dédiée à l’implémentation de radios logicielles et de systèmes de traitement du signal. Il est très utilisé notamment pour réaliser des communications satellites à moindre coup et dispose d’une très grande communauté.
  • SDR Console / SDR Sharp / PlutoSDR : ce sont des logiciels appelés SDR ou Software-Defined Radio ou SDR, qui permettent de réaliser l’acquisition du signal au niveau logiciel.
  • AirSpy : c’est une carte d’acquisition permettant de récupérer des signaux de type VHF (Very High Frequency) et UHF (Ultra High Frequency)

En s’aidant de la documentation publique sur le système (modulation, débit des symboles …), il a ainsi pu décoder et intercepter les communications échangées. Il a notamment montré une vidéo où l’on pouvait entendre des communications en chinois. Une fois qu’il avait un système fonctionnel, il a émulé l’ensemble de cette chaîne de communication pour ne pas perturber le système COSPAS-SARSAT. Il a ainsi introduit un nouveau module appelé HackSAR qui lui permet de générer des signaux dans son laboratoire.

Le chercheur a ainsi dévoilé 2 scénarios d’exploitation :

  • Attaque de type DDoS sur l’infrastructure COSPAS-SARSAT
  • Utilisation de l’infrastructure pour communiquer des messages de manière gratuite et « chiffrée »

Le premier scénario est assez trivial, il suffit à l’attaquant d’envoyer de faux messages de détresse. La raison est assez simple, tout le monde peut envoyer et recevoir des messages au travers de la bande L (entre 1GHz et 2GHz). Également dû à la sensibilité des satellites, les attaques de Déni de Service (DoS) sont assez faciles à mettre en place. De plus, le message une fois envoyé est relayé au sein de tout le réseau des satellites. Le chercheur a donc réussi à réaliser un DDoS en envoyant de manière continue des messages de détresse de type EPIRB ou Emergency Position Indicating Radio Beacon.

Le deuxième scénario est un peu plus élaboré. Puisqu’il est possible d’émettre un signal sans contrôle, et que ce message est relayé au travers de tout le système, on peut ainsi envoyer des messages de manière anonyme sur tout le globe. De plus, du fait de la haute sensibilité des satellites, il est possible de camoufler son message très proche de la porteuse et ainsi de les faire passer pour des interférences (bruit blanc). Bien sûr, c’est à l’attaquant de réaliser son propre système de chiffrement applicatif des messages qu’il envoie.

Selon le chercheur, son système pourrait être ainsi utilisé par les espions pour communiquer. Néanmoins, même s’il a montré quelques spectres avec des interférences, aucune preuve n’a pu confirmer son hypothèse. De plus, si les opérateurs ont un doute concernant un signal, ils peuvent facilement localiser l’émetteur.

H(ack)DMI– Changhyeon-Moon

SLIDES

DSCF0975-7

Avant de présenter ses découvertes, le chercheur est revenu sur 3 protocoles utilisés au sein du standard HMDI :

  • HDMI CEC ou Consumer Electronics Control qui permet de contrôler des équipements audiovisuels au travers du câble HMDI. Par exemple, lorsque vous allumez votre amplificateur, votre télévision s’allume également. Les communications sont réalisées au travers d’un protocole qui est divisé en 2 catégories :
  • les en-têtes contenant les adresses de destination et source.
  • les blocs de données contenant les commandes à réaliser appelées opcode ou les arguments associés appelés operand. Plusieurs blocs de données peuvent être envoyés dans une seule même trame. Par exemple, 0x32 est l’opcode pour changer la langue. L’opérande indiquerait quelle langue configurée serait localisée dans le data bloc suivant.
  • HDMI DDC ou Display Data Channel permet à l’écran de communiquer ses spécifications et les fonctionnalités disponibles à l’émetteur du flux vidéo. Lors de la communication, les informations (résolutions supportées, fréquences, etc.) sont communiquées au travers de l’EDID, ou Extended Display Identification Data. Pour réaliser cet échange, une communication « serial » appelée I2C est réalisée.
  • HDMI ARC ou Audio Return Channel permet d’extraire les données audio directement depuis le câble HDMI sans utiliser de câble dédié à cet effet.

Il a ensuite présenté les 2 fuzzers qu’il a construit. Le premier est CEC-Fuzzer constitué des éléments suivants :

  • PySerial : librairie Python qui permet de réaliser des communications série.
  • USB-CEC Adapter(Pulse-Eight) – https://github.com/Pulse-Eight/libcec : ce boitier permet de réaliser des actions depuis un terminal qui ne supporte pas le CEC. Il est supporté notamment par le Raspberry Pi.
  • Un cable HDMI.

A l’aide du fuzzer, ils ont ensuite envoyé tous les opcodes possibles (0x00 à 0xff) à l’exception de 0x36 correspondant à l’extinction du terminal. Pour chaque commande, toutes les valeurs possibles (0x00 à 0xff) d’operand ont été envoyées. Ainsi, 2 vulnérabilités de type déni de service ont été identifiées. L’une est de type one-byte stack overflow au sein d’un memcpy(). L’appareil n’a pas été cité, mais il semblerait que cela soit un équipement Android Xiaomi.

La fabrication du DDC-Fuzzer a été un peu plus complexe. Le chercheur a dû concevoir son propre HDMI pour pouvoir le brancher sur un Arduino ATMega 2560. Les échanges DDC n’étant réalisés qu’à la connexion de l’écran, les chercheurs ont ainsi simulé l’extinction et l’allumage de l’écran en envoyant 2 signaux (un faible et un fort) sur le pin Hot Plug Detected (HPD). Une fois la connexion I2C établie, le fuzzing est réalisé sur le EDID. Une vulnérabilité de type déni de service a été identifiée au niveau du noyau de la Mibox3 (Android TV).

Les chercheurs ont ensuite présenté un fuzzer au niveau du driver Ubuntu. En effet, les performances des 2 fuzzers hardware n’étaient pas très bonnes. Il repose principalement sur 2 outils Linux:

  • Kretprobe qui permet de positionner des break points au sein de n’importe quelle routine kernel (notamment sur la fonction drm_do_probe_ddc_edid qui récupère la valeur de l’EDID).
  • Ftrace qui permet de tracer des évènements, notamment des appels système.

A l’aide de ces deux outils Linux, ils parviennent donc à récupérer puis à modifier l’EDID à la volée pour réaliser le fuzzing. La même démarche a été tentée sur Windows sans succès pour le moment. En effet, ils n’ont pas réussi à simuler le même comportement.

Battle of windows service: Automated discovery of logical privilege escalation bugs – Wenxu Wu et Shi Qin, Tencent

SLIDES

DSCF0976-8

Les 2 chercheurs de la société Tencent ont présenté comment découvrir de manière automatique des élévations de privilèges au sein de Windows. En particulier, ils se sont intéressés aux vulnérabilités concernant les ALPC.

  • CVE-2018-8440 : vulnérabilité au sein du planificateur de tâches (interface RPC ITaskSchedulerService) qui permet de changer un DACL d’un fichier. Cette vulnérabilité a été étudiée au sein de l’actusecu #50 (Retour sur la vulnérabilité Microsoft TaskScheduler).
  • CVE-2019-0636 : cette vulnérabilité permet de récupérer le contenu d’un fichier sans disposer des autorisations nécessaires. La vulnérabilité provient de Windows Installer et plus particulièrement de la fonction MsiAdvertiseProduct().

Tout d’abord, les chercheurs sont revenus sur quelques notions techniques avant d’expliquer la vulnérabilité. Les “Remote Procedure Call” ou RPC permettent de mettre à disposition des développeurs des fonctions utilisables à distance (modèle client-serveur). Chaque système d’exploitation dispose donc de son propre système de RPC. Sous Windows, il s’agit de Microsoft RPC ou MSRPC. Pour discuter avec les ALPC (Asynchronous Local Inter-Process Communication), Windows utilise le langage IDL (Interface Definition Language).
Pour identifier les ALPC, ils ont utilisé l’outil RPCView :

À l’aide de l’outil, ils ont pu identifier la routine SchRpcSetSecurity qui est vulnérable. A l’aide de reverse engineering (non utile puisque ces informations sont disponibles sur le site MSDN), ils ont retrouvé les arguments nécessaires pour utiliser cette fonction qui sont :

  • path : le nom de la tâche (porte bien son nom …).
  • SDDL : le descripteur de sécurité à appliquer.
  • flags : indique s’il s’agit d’une tâche ou d’un répertoire.

La routine SchRpcSetSecurity permet donc de changer les DACL (Discretionary Access Control List) d’un fichier contenu au sein du répertoire C:Windowstasks. La question est donc, comment contourner cette restriction et changer les DACL de n’importe quel fichier. Pour ce faire, les chercheurs vont utiliser des liens symboliques. Il en existe 3 sortes sur le système d’exploitation Windows :

  • Junction : ou softlink permet uniquement de créer un lien vers un dossier. Ce type de lien repose sur la fonction CreateSymbolicLinkW() de la WinAPI.
  • Hardlink : ce type de lien permet de créer un lien vers un fichier directement en reposant directement sur le système NTDS. La WinAPI utilisée est CreateHardLinkW().
  • DeviceMap

Dans le cas de la CVE-2018-8440, il suffit de donc de créer un hardlink vers le fichier de notre choix et le positionner au sein du répertoire spécifié, par exemple lien de C:WindowsTaskspoc.job vers C:Windowswin.ini.

La seconde vulnérabilité CVE-2019-0636 est de type TOCTOU (Time Of Check To Time Of Use). Lors de l’installation d’un paquet MSI, son contenu est parsé par le service Windows Installer (qui tourne en tant que SYSTEM). Ensuite, son contenu est copié au sein d’un paquet MSI temporaire au sein du dossier C:WindowsInstaller. Or le paquet MSI à installer est ouvert 2 fois de manière consécutives. L’attaque est donc réalisée en 2 temps:

  • Un lien symbolique pointe vers un fichier MSI valide.
  • Le lien symbolique est redirigé vers le fichier de notre choix.

Ceci aura pour effet de récupérer le contenu d’un fichier arbitraire (avec les droits SYSTEM du service). En effet, tout le monde dispose des droits de lecture sur le fichier MSI créé au sein du répertoire C:WindowsInstaller.

Pour exploiter la vulnérabilité, les chercheurs ont utilisé des OpLock qui permettent de configurer des hooks sur les accès d’un fichier. Cela leur permet de changer le lien symbolique une fois la première lecture effectuée.

Les chercheurs ont ensuite dévoilé leur technique pour tenter d’identifier de manière automatique de nouvelles vulnérabilités au sein de Windows. À l’aide de script Python pour IDA, les chercheurs ont identifié les services qui utilisent des fonctions à risque. Leur approche est assez simpliste et repose sur 3 fonctionnalités IDA :

  • Pour chaque fonction, il récupère l’adresse de début et de fin avec la fonction IDA GetFunctionAttr().
  • Ensuite, il itère sur chaque instruction à l’aide de GetMnem() pour identifier des instructions de type Call.
  • Si un appel de type Call est détecté, suivant la localisation de la fonction appelée (région .text ou .data du binaire), le nom de la fonction est vérifié au sein d’une liste préétablie par les chercheurs.

Les chercheurs sont parvenus à identifier de nouvelles vulnérabilités en utilisant cette méthode.

  • La première se situe au sein de l’assistant de compatibilité (Program Compatibility Assistant Service – interface RPC RaiGetFileInfoFromPath du fichier pcasvc.dll) qui permet d’obtenir les droits de lecture (vulnérabilité de type TOCTOU).
  • La deuxième se situe au sein du service de déploiement AppX (CVE-2019-0841) qui permet de changer les permissions d’un fichier arbitraire. Comme pour la CVE-2018-8440, un attaquant peut ainsi élever ses privilèges. Un analyse détaillée est disponible à l’adresse suivante : https://krbtgt.pw/dacl-permissions-overwrite-privilege-escalation-cve-2019-0841/
  • La troisième se situe au sein du service collecteur standard du Hub de diagnostic Microsoft et permet également des réaliser un changement de permission d’un fichier arbitraire.

Les chercheurs ont conclu leur présentation en expliquant comment exploiter le gadget sur l’imprimante XPS. En effet, en changeant la DLL PrintConfig.dll, un attaquant est en mesure d’obtenir une invite de commande avec les droits NT SYSTEM.

[line]

Nous vous donnons rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette édition ! En attendant voici quelques photos de la conférence.

DSCF0996-18

DSCF0997-19

DSCF0967-3

DSCF0969-5

DSCF0972-6

DSCF0979-9

DSCF0981-11

DSCF0983-12

DSCF0986-14

DSCF0987-15

DSCF0988-16

DSCF0995-17

DSCF0980-10

 

Adrien Guinault

Découvrir d'autres articles

  • Conférences

    Retour sur WestDataFestival 2024

    Lire l'article
  • Conférences

    DORA et la résilience opérationnelle des fournisseurs

    Lire l'article
  • Conférences

    Retour sur la Black Hat Europe 2023

    Lire l'article