XMCO était partenaire de la 9ème édition de la Hack In Paris. Cette édition s’est une nouvelle fois tenue à la Maison de la Chimie à Paris du 16 au 20 juin 2019. Comme les années précédentes, celle-ci a débuté avec 3 jours de formation pour se terminer avec 2 jours de conférence.
Nos consultants ont assisté aux différentes conférences et vous présentent un résumé de celles qui ont retenu leur attention. L’ensemble des conférences auxquelles nous avons assisté seront disponibles dans le prochain numéro de l’ActuSécu.
DPAPI and DPAPI-NG: Decrypting All Users’ Secrets and PFX Passwords (Paula Januszkiewicz – @PaulaCqure)
Paula Januszkiewicz nous a présenté le résultat des travaux de son équipe autour de l’interface de protection des données de Windows (Data Protection API, ou “DPAPI”).
Cette interface permet, dans un environnement Active Directory, de protéger des données et des secrets des utilisateurs tels que des mots de passe pour des sites web, des clés privées ou encore des jetons de sécurité.
Ces données sont ensuite stockées de manière chiffrée au sein du répertoire de l’utilisateur et peuvent aussi être sauvegardées à distance.
Cependant, les données sont non seulement chiffrées à l’aide d’une clé privée possédée par l’utilisateur, mais aussi par une clé privée générée et stockée par l’Active Directory.
Les contrôleurs de domaines AD sont des cibles particulièrement prisées par les pirates qui tenteront d’en prendre le contrôle afin de dominer tout le parc informatique de l’entreprise.
Si le contrôleur de domaine est compromis, les attaquants seraient en mesure d’en extraire la clé privée associée à l’interface de protection des données utilisateurs afin de pouvoir déchiffrer tous les secrets des utilisateurs ainsi stockés.
Paula Januszkiewicz introduit donc le fonctionnement de l’API, le processus de stockage des données et de chiffrement. À l’aide d’outils développés spécifiquement à ces fins, Paula démontrera la possibilité d’extraire la clé privée et de s’en servir afin de dérober les secrets des utilisateurs.
Cette possibilité introduit un nouveau risque non négligeable. Si l’on peut penser que la compromission de l’Active Directory est dors est déjà une victoire écrasante pour des pirates qui auront alors la porte ouverte, la possibilité de dérober les secrets d’utilisateur est aussi lourde en conséquence.
En effet, il serait possible de pivoter et compromettre plus en profondeur l’entreprise (infrastructures non contrôlées par l’Active Directory) ou encore d’accéder à des services tiers (compte Twitter officiel de l’entreprise, site principal, etc.).
Les recommandations sont principalement associées à la sécurité de l’environnement Active Directory et à l’importance de protéger comme de véritables forteresses les contrôleurs et les comptes d’administration.
whoami /priv – show me your privileges and I will lead you to SYSTEM (Andrea Pierini – @decoder_it)
La présentation d’Andrea Pierini s’est articulée autour des différentes approches et techniques pour élever ses privilèges dans un environnement Windows.
Selon le procédé, un pirate ayant gagné un accès à un compte / session Windows peut se retrouver avec des privilèges limités. Cette limitation peut fortement endiguer le processus de compromission pour lequel des privilèges élevés sont souvent requis (récupération des mots de passe hachés, pivot, etc.).
L’élévation de privilège constitue alors l’une des phases clés d’une compromission. Il n’est pas nécessaire de posséder un exploit 0-Day pour ce faire, souvent, il suffit de découvrir des défauts de configuration.
Les permissions des groupes et utilisateurs peuvent être gérées par plusieurs mécanismes comme les “User Right Assignment”, les politiques locales ou globales ou encore l’API Windows.
Parfois, il est aussi possible d’abuser de comptes et groupes par défaut et qui ne sont pas toujours protégés (sauvegarde, services, imprimantes, etc.). Des comptes et services peuvent aussi être créés par des services tiers et posséder d’importants privilèges.
Andrea Pierini introduit aussi le fonctionnement des jetons d’accès (Windows Access Token), leur fonctionnement et comment abuser de ce mécanisme afin d’élever ses privilèges.
Ainsi sont passées en revue des permissions spécifiques qui peuvent être abusées afin d’augmenter ses droits : SeDebugPrivilege, SeRestorePrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, etc.
Enfin, Andrea souligne que Microsoft met de plus en plus de protections afin de limiter ces abus dans les dernières versions de Windows. Maintenir son parc de systèmes à jour est particulièrement important que ce soit pour intégrer ces nouveaux mécanismes de sécurité ou combler des failles importantes pouvant être exploitées.
IronPython… OMFG (Marcello Salvati – @byt3bl33d3r)
Marcello Salvati, plus connu de son pseudonyme byt3bl33d3r, a présenté IronPython et Boolang comme outils de compromission.
L’introduction a rappelé l’utilisation massive de PowerShell lors d’attaques et de compromission sur des environnements Windows. Il est fréquent que l’exécution initiale (téléchargement de la charge utile d’un malware par exemple) se fasse au travers de scripts PowerShell.
PowerShell introduit en effet des capacités bien plus accessibles et de plus nombreuses fonctionnalités souvent privilégiées par les attaquants.
Afin de faire face à cette émergence, de nombreuses solutions de sécurité intègrent maintenant des contrôles pour y faire face. Que ce soit de la prévention (antivirus) ou du durcissement (End Point Protection, Exploit Mitigation, etc.), les outils pour combattre les utilisations malveillantes de PowerShell se sont multipliés.
Marcello introduit donc une approche connue, mais encore peu employée afin d’exécuter du code sur des environnements Windows en limitant au maximum toute détection ou solution de mitigation. Pour ce faire, il faut utiliser le Framework Microsoft .NET.
Cependant, il n’est pas aisé d’utiliser .NET directement ou d’adapter ses outils afin de le supporter. Il faut donc reposer sur des technologies qui vont permettre de s’interfacer avec des langages tels qu’IronPython (Python), IronRuby (Ruby) ou encore le BooLang (langage syntaxiquement proche du Python).
Il est alors possible d’adapter plus aisément ses scripts et outils afin de reposer sur le framework .NET qui n’est encore que peu protégé.
Marcello Salvati a pu appuyer sa présentation en démontrant la détection puis le contournement des mécanismes de sécurité à l’aide de ce procédé.
Se protéger n’est pas impossible, notamment au niveau de la détection et des mécanismes mis en place dans les dernières versions du framework .NET. Il sera cependant plus difficile de détecter ces attaques que celles reposant purement sur PowerShell pour encore quelque temps.
Abusing Google Play Billing for fun and unlimited credits ! (Guillame Lopes – @Guillaume_Lopes)
Le chercheur en sécurité de la société Randorisec, Guillaume Lopes, a présenté lors de cette édition, ses recherches sur le contournement du service permettant aux développeurs d’effectuer des ventes au sein de leurs applications, le Google Play Billing.
Enrichie de quelques démonstrations en direct, cette présentation de 45 minutes a permis au conférencier de mettre en avant les vulnérabilités liées à l’utilisation de la validation du paiement uniquement du côté du client.
En effet, une simple application se positionnant entre les demandes de paiement et le serveur de validation de Google suffit pour intercepter, modifier et retourner une réponse valide à l’application ciblée sans que la requête n’ait jamais atteint les services Google. Suite aux modifications de Google pour corriger cette vulnérabilité, il est également nécessaire de changer le nom du paquet whitelisté pour pouvoir associer l’Intent (description d’une opération à réaliser) créé avec l’application pirate.
Sur 40 applications testées, 25 se sont montrées vulnérables à ce type de contournement et 5 seulement utilisaient un serveur externe pour effectuer les vérifications liées au paiement.
Enfin, le chercheur a souligné que parmi les bibliothèques de paiement mobile, seule celle de Google autorise une vérification via le client uniquement.
Who watches the watchmen? Adventures in red team infrastructure herding and blue team OPSEC failures (Mark Bergman, Marc Smeets – @xychix, @MarcOverIP)
Cette conférence, présentée par Mark Bergman et Marc Smeets de la société néerlandaise Outflank, abordait la problématique des équipes de Red Ream, de la mise à l’échelle de l’infrastructure et du traitement des données récupérées lors des différentes missions réalisées.
Elle s’est ouverte sur la présentation de l’infrastructure classique utilisée pour une mission de Red Ream, en reprenant chaque élément :
- Les canaux de communications disponibles au sein de l’infrastructure du client, avec l’impact de leur utilisation
- Les redirecteurs, qui doivent être :
- Flexibles
- Jetables
- Résilients
- Le serveur de contrôle et de commande
S’en est suivi un retour sur les différents challenges rencontrés dans la gestion de cette infrastructure et dans le traitement des données brutes générées, puis de l’outil résultant de ces problématiques : RedELK.
Il prend la forme d’un SIEM fondé sur la stack elastic et poursuit deux buts concrets :
- Être capable d’avoir une vue d’ensemble de tous les IOCs les concernant, effectuer des recherches précises parmi les données récoltées par les keyloggers, de parcourir les différentes captures d’écran récoltées ou encore de pouvoir être en mesure de savoir si une action a été effectuée sur un système donné à une date précise.
- Être alerté dès les premiers soupçons de découvertes de la part de la Blue Team pour pouvoir réagir rapidement et efficacement.
Pour détecter une activité suspecte, l’outil analyse deux sources d’informations :
- Le trafic reçu par les différents composants de l’infrastructure
- Chargement d’une preview par un logiciel de messagerie instantanée
- La visite d’une IP absente de la whitelist des auditeurs
- Des user-agents propres à des solutions automatisées comme python-requests, curl ou Python-urllib
- Les outils publics permettant l’analyse d’URLs ou de fichiers malveillants, les blocklists…
Enfin, la conférence s’est terminée par la présentation d’un autre outil à destination des redirecteurs et de la première ligne de défense, RedFile.
Cet outil, pour l’instant peu développé, permet de leurrer les personnes investiguant sur l’infrastructure de la Red Team en modifiant sa réponse en fonction de la source de la requête. Cela permettrait par exemple de brouiller les pistes quant au but et à la portée réelle de l’opération.
You « try » to detect mimikatz (Vincent Le Toux – @mysmartlogon)
Lors de cette conférence, Vincent Le Toux est revenu sur l’état actuel de la détection de Mimikatz et des différentes options qui s’offrent aux RSSIs.
Il a commencé par rappeler que Mimikatz ne servait pas uniquement à la récupération d’identifiants en mémoire, mais permettait également, entre autres, d’extraire des certificats ou d’abuser des mécanismes d’authentification d’Active Dicrectory. Pour prétendre à « bloquer Mimikatz », il est donc nécessaire de bloquer toutes ces techniques et ne pas se concentrer uniquement sur ses fonctionnalités les plus connues.
Le chercheur a ensuite souligné le manque de connaissance et d’analyse de la communauté vis-à-vis de certaines attaques de Mimikatz, en prenant comme exemple le manque de réactivité à l’annonce de l’attaque du « Golden Ticket ». Par exemple, le CERT-FR n’a publié de bulletin d’actualité concernant cette attaque qu’un an après le whitepaper du CERT-EU ; aucune communication n’a été faite du côté du CERT-US.
Deux solutions sont actuellement utilisées pour détecter les attaques de Mimikatz, mais atteignent vite leurs limites :
- Un IDS basé sur un framework et une veille en vulnérabilité :
- Toutes les attaques ne rentrent pas dans le framework
- La veille ne peut pas être totalement exhaustive
- Les vulnérabilités basiques ne sont parfois pas traitées
- Un SIEM :
- Les logs collectés ne sont pas forcément pertinents
- Il ne faut pas se reposer sur les règles de détection de l’éditeur
- Une grande quantité de logs à traiter augmentent le risque de faux négatifs
D’après le chercheur, les origines du problème posé par la détection des attaques sur Active Directory de Mimikatz ne se trouveraient pas dans le processus d’authentification, mais dans la gestion des secrets et de la confiance abusive portée à des réseaux tiers. Les vulnérabilités soulevées par de telles attaques ne sont pas tant techniques que fonctionnelles. Se pose donc la question : est-ce qu’un projet technique est une réponse viable à ce genre de vulnérabilité ?
Plusieurs recommandations sont ensuite données pour essayer de détecter au mieux ces attaques.
Le premier conseil est de ne pas se concentrer sur des éléments uniques à Mimikatz car il existe plusieurs outils pour exploiter chacune de ces vulnérabilités. De plus, l’implémentation de tels exploits peut varier à l’infini.
Le deuxième indique comme base de travail les recommandations mises à disposition par l’auteur de l’outil sur Github, sous la forme de règles YARA et Splunk.
Enfin, il est crucial de connaître son périmètre AD pour le maitriser et être en mesure de mettre en place des mesures de protection et de détection pertinentes.
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 !
