XMCO était partenaire de la 14e édition de la Hack.lu qui s’est déroulé au Luxembourg du 17 au 19 octobre derniers. Le programme de la conférence était très dense et proposait plus d’une trentaine de conférences, sans compter les workshops et les rumps. Nous allons donc réaliser une suite d’article pour revenir sur l’ensemble de la conférence.
La Hacklu a mis à disposition sur YouTube les conférences filmées, accessibles à l’adresse suivante :
De plus, les supports des présentations sont consultables sur le site officiel de la conférence (archive.hack.lu). Néanmoins, pour l’instant peu de supports sont disponibles.
Veuillez trouver ci-dessous nos résumés de la première journée.
Randori, a low interaction honeypot with a vengeance (Bouke van Laethem)
Le speaker est venu présenter un honeypot un peu particulier. Sa particularité est de se connecter chez l’attaquant avec ses identifiants utilisés pour compromettre le honeypot. Le projet a commencé sur le protocole Telnet qui est très utilisé au sein du monde des botnets. Néanmoins, son implémentation n’a pas été aussi facile que prévu, due à des problématiques d’ordre technique. En effet, le procotole en lui-même n’est pas très « carré ». L’implémentation de son homologue sécurisé, SSH, fut assez facile et surtout fut plus souple. En effet, la gestion d’une connexion réussie vers l’attaquant est très simple sur SSH. Il est par exemple, possible de se connecter sans obtenir de shell, action complexe pour le protocole Telnet.
De plus sur SSH, il existe déjà un module PAM (Pluggable Authentication Modules) appelé pam_steal qui permet de voler les mots de passe des personnes se connectant sur le serveur. En réalisant quelques changements légers, Bouke van Laethem a pu ainsi facilement récupérer les identifiants des attaquants.
Pour l’instant l’outil n’intègre pas d’outil d’analyse. Les analyses présentées lors de la conférence ont été réalisées à l’aide de l’outil Kathe (https://github.com/avuko/kathe). Sans grande surprise, le grand gagnant est le couple admin/admin qui arrive en première position des identifiants utilisés. Les graphiques générés permettent également d’identifier rapidement les serveurs infectés par les malwares au travers de noeuds (basés sur les adresses IP et les identifiants utilisés du malware). Pour réaliser cette analyse, aucune action de représailles n’a été nécessaire.
Pour l’instant l’outil se limite aux protocoles Telnet et SSH mais il est prévu d’implémenter le support d’autres protocoles tel que RDP/VNC:
La conférence se conclut sur « it is not Cyberwar out there, it is a cyberpandemic », bonne réflexion …
ManaTI: Web Assistance for the Threat Analyst, supported by Domain Similarity (Raúl B. Netto)
Raul B. Netto présenta son outil ManaTI de Thread Intelligence. La particularité est d’utiliser la technologie de Machine Learning pour réaliser l’analyse des différents éléments techniques (WHOIS, IOC, logs, …). La conception de l’outil a voulu répondre aux problèmes actuels que rencontrent les analystes de Thread Intelligence:
- Analyser un volume très conséquent d’informations.
- Traiter les différents IOC sur leur pertinence, notamment concernant le contenu posté sur les différents blogs.
- Réaliser des tâches fastidieuses de manière récurrente.
- Perdre des données concernant notamment concernant les IOC au cours du temps.
ManaTI a donc pour vocation à être un outil collaboratif, mais surtout être en mesure de traiter dans un délai assez court l’ensemble des malwares découvert tous les jours. Également, ManaTI souhaite également s’adresser au plus grand nombre d’utilisateurs possible :
- Les analystes non techniques ayant besoin d’une interface graphique claire et conviviale.
- Egalement aux chercheurs en sécurité nécessitant une API pour s’interfacer avec ses propres scripts ou outils.
La présentation s’est conclue par une démonstration de l’outil notamment au niveau de la classification des IOC si importants aux yeux de Raul B. Netto. L’outil open source est disponible sur Github :
Un workshop dédié a également été réalisé par Raul B. Netto le vendredi pour prendre en main l’outil :
Let’s Play with WinDBG & .NET (Paul Rascagneres)
À force d’analyser de nombreux malware codés en Powershell et .NET, Paul Rascagneres a automatisé WinDBG pour extraire des informations de manière automatique. La première question que l’on peut se poser, pourquoi utiliser WinDBG pour des scripts PowerShell ?
- La première raison est que PowerShell a été développé en .NET.
- La deuxième est que Windbg est parfaitement intégré au sein de l’environnement Windows (notamment mis à disposition des fichiers de symboles PDB) et est disponible gratuitement. Sa syntaxe est certes assez curieuse, mais une fois la nomenclature comprise, l’utilisation de l’outil devient assez simple. La grande majorité des commandes utiles est disponible au travers de cette documentation non officielle (http://windbg.info/doc/1-common-cmds.html).
Pour pouvoir utiliser WinDBG de manière performante, Paul Rascagneres utilise l’extension peu connue appelée SOS. Elle permet de réaliser le debugging « natif » du langage .NET. Par exemple, la fonction .NET Assembyload() repose sur 5 fonctions « assembleur » différentes. L’extension SOS permet ainsi de mettre un breakpoint sur la fonction .NET qui s’arrêtera sur l’exécution de toutes les fonctions « assembleur » associées. Voici une liste non exhaustive des autres avantages de l’extension :
- Récupérer les arguments d’une fonction au travers de la stack .NET (!CLRStack).
- Récupérer tous les attributs d’un objet .NET (!DumpObj).
Attention, lors de l’utilisation de l’extension SOS, il est important de ne la charger qu’après le chargement du framework .NET au sein du malware.
La suite de la présentation continua sur une démonstration live de 2 cas :
- Étude d’un script PowerShell au travers du couple WinDBG / extension SOS.
- Analyse d’un malware « packé » en .NET.
Pour ceux allergiques au JavaScript, Paul Rascagneres présenta l’extension nommée PYKD qui permet de piloter WinDBG au travers d’un script Python. Cette extension permet également d’exporter les résultats au format JSON pour facilement l’importer au sein des outils de Thread Intelligence. PYKD est disponible à l’URL suivante :
Pour conclure la conférence, Paul Rascagneres a également précisé qu’il était possible de réaliser l’analyse de malware codé en JavaScript au travers de WinDBG. Il a notamment rédigé un article sur le blog de TALOS :
Device sensors meet the web – a story of sadness and regret (Lukasz Olejnik)
Le chercheur Lukasz Olejnik est revenu sur les API peu connues mises à disposition ces dernières années. Toutes ces API n’ont bien évidemment pas été conçues en cherchant à garder privées les données des utilisateurs. Voici les 2 exemples les plus marquants de la présentation :
- La première concerne l’API nommée API Battery Status. Elle permet de récupérer des informations sur le niveau de batterie restant au sein du téléphone. Aucune raison de s’alarmer me direz-vous ? Sauf qu’il est possible de l’exploiter de manière malveillante et c’est ce qu’a fait la société Uber. En effet, les prix étaient considérablement majorés lorsque le niveau de batterie était faible …
- Le deuxième exemple concerne l’API nommée Ambient Light Sensor API. Comme son nom l’indique, cette API permet de récupérer le niveau de la lumière ambiante. Le chercheur a ainsi montré qu’il était possible de récupérer l’historique de navigation. Bien qu’aucune démonstration n’était réalisée lors de la conférence, il a présenté des preuves théoriques d’un tel scénario exploitable. Cette méthode d’extraction de données est basée sur les réflexions de lumière de l’écran sur les différents objets.
D’autres exemples furent présentés sur des capteurs plus connus tels que le capteur d’empreinte digitale ou encore le GPS. Bien évidemment, toutes ces données ne sont récoltables que si l’utilisateur accepte de donner les droits adéquats à l’application. Néanmoins, qui peut se douter que le capteur de lumière ambiante peut permettre l’extraction de données ! Le chercheur souhaiterait ainsi que ces API ne soient pas présentes ou que la composante donnée privée soit prise en compte lors de leur conception. Cette conférence avait le mérite d’exposer des risques peu connus.
Malicious use of Microsoft “Local Administrator Password Solution” (Maxime Clementz, Antoine Goichot)
Cette conférence n’avait pas vocation a présenté de nouvelles vulnérabilités sur la technologie LAPS. Notamment l’ensemble des scénarios présentés nécessite d’être administrateur local. Les deux consultants ont montré un moyen récupérer le mot de passe (en clair et non son empreinte NTLM) administrateur local.
La fonctionnalité de Microsoft nommée Local Administator Password Solution (LAPS), permet de définir un mot de passe unique administrateur local différent sur chaque poste (workstation ou serveur). Le seul prérequis est que l’élément ciblé soit intégré au sein d’un domaine. L’ensemble des mots de passe est ainsi conservé en clair dans l’attribut ms-MCS-AdmPwd au sein du contrôleur de domaine. Ce que peu de gens savent c’est que LAPS est au départ un projet Open Source nommé AdmPwd développé par Jiri Formacek:
- https://code.msdn.microsoft.com/windowsapps/Solution-for-management-of-ae44e789
- https://jozemarkic.wordpress.com/2016/07/21/from-admpwd-to-laps-and-now-laps-e
Une ancienne version du code source de la DLL en charge de la gestion du mot de passe est donc disponible sur Github. De plus, il est important de noter que :
- Aucun contrôle d’intégrité n’est réalisé sur la DLL par Windows.
- L’ancienne version (celle disponible sur Github) est compatible avec le LAPS actuel.
Les 2 consultants ont ainsi modifié la DLL AdmPwd.dll pour récupérer le mot de passe lors du changement de ce dernier (par exemple au sein d’un fichier texte sur le poste). Dans un souci d’être le plus discret possible, ils ont utilisé le projet SigThief pour que la DLL ne soit pas détectable au premier abord (version, signature …). Ils nous ont ainsi présenté 3 scénarios d’exploitation pour illustrer cette version modifiée malveillante :
- 2 élévations de privilèges
- 1 scénario de compromission persistante
Pour pouvoir élever ses privilèges, il suffit d’être en capacité d’obtenir les droits d’écriture sur la DLL AdmPwd.dll pour pouvoir la remplacer par celle malveillante. La première raison peut provenir d’un mauvais déploiement de LAPS. Notamment une méthode de déploiement consiste à copier/coller la DLL sur le système. Une fois copiée, il suffit d’exécuter la commande suivante pour activer LAPS: regsvr32.exe AdmPwd.dll. Si l’emplacement de destination est mal choisi, accessible en écriture par tous les utilisateurs, un attaquant pourra ainsi remplacer la DLL et ainsi élever ses privilèges.
Pour la seconde élévation de privilège, les 2 consultants pensaient avoir trouvé une vulnérabilité de type 0day. En effet, ils arrivaient au travers du service Windows Installer Service ou plus précisément la fonctionnalité de réparation MSI, à écraser la DLL LAPS. Lors de l’envoi des informations à Microsoft, l’équipe sécurité de Microsoft leur a demandé quelle version de la bibliothèque msi.dll ils utilisaient. Il s’est avéré que le système où ils ont découvert la vulnérabilité était obsolète et qu’il s’agissait en fait de la vulnérabilité MS14-049.
Afin de se protéger contre ce type d’attaque, il suffit de réaliser un contrôle d’intégrité sur la DLL LAPS.
The Bicho: An Advanced Car Backdoor Maker (Sheila Ayelen Berta, Claudio Caracciolo)
Cette présentation avait pour but de se différencier des présentations « traditionnelles » qui visent les voitures connectées (Jeep, Tesla …). Le but de la chercheuse était de présenter sa backdoor pour véhicule nommée Car Backdoor Maker (CBM). Le scénario est le suivant : vous avez un accès physique au véhicule et vous souhaitez récupérer des informations (vitesse, position GPS) ou même pouvoir prendre le contrôle du véhicule à distance. Pour se faire, il suffit de prendre le contrôle du bus CAN. Ce système permet la communication entre les différents organes de la voiture. Il est donc un point névralgique de la voiture où transite l’ensemble des informations (allumage des feux, déclenchement des essuie-glaces, vitesse …).
Dans un premier temps, la chercheuse a essayé d’identifier les actions supportées au niveau de la voiture, et plus particulièrement au niveau du bus CAN. Pour se faire, la démarche fut assez basique:
- Se brancher sur le bus CAN de la voiture.
- Se mettre en écoute à l’aide de l’outil CANSPY. Il existe des alternatives commerciales permettant de réalisant les mêmes actions notamment l’outil CAN BUS Analyzer Tool.
- Isoler chaque action et récupérer le bus CAN associé.
Ensuite, il suffit ainsi de rejouer les trames CAN capturées pour réaliser l’action comme allumer les feux de la voiture par voiture. Une fois la partie de reverse engineering fini, la chercheuse a créé son propre hardware (les plans sont disponibles sur son Github). La backdoor dispose donc d’un module GSM pour communiquer de manière distante via SMS, et d’une prise USB pour charger la partie logiciel. L’ensemble du projet est disponible sur son Github:
Si vous ne souhaitez pas passer par l’étape reverse engineering, il existe un site communautaire (http://opencandb.online) qui recense l’ensemble des trames CAN pour plusieurs modèles/marques de voitures différentes. Attention, se connecter et jouer directement avec le bus CAN peut avoir des conséquences irréversibles pour votre voiture. Sheila Ayelen Berta en a notamment fait les frais en cassant sa propre voiture …
