XMCO s’est rendu à Londres pour la Black Hat Europe 2023 les 6 et 7 décembre derniers afin d’assister aux présentations des dernières recherches de la communauté en matière de cybersécurité.
Retour sur 4 « briefings » qui ont particulièrement intéressé nos auditeurs.
Millions of Patient Records at Risk: The Perils of Legacy Protocols by Sina Yazdanmehr
Dans cette présentation, le chercheur Sina Yazdanmehr fait l’état de l’art de la sécurité du protocole d’imagerie médicale DICOM (Digital Imaging and Communication in Medecine).
Le protocole DICOM permet de faire le lien entre les machines d’imagerie et les serveurs de stockage. C’est ce protocole qui est utilisé par les scanners pour stocker les images obtenues lors de la réalisation d’un scan ou encore par les stations de travail des médecins lors de la récupération des images afin de les visualiser.
Pour cela, les serveurs DICOM sont amenés à exposer quatre services principaux :
- C-FIND : permets de rechercher un objet ;
- C-GET : permets de retrouver un objet ;
- C-MOVE : permets de déplacer un objet ;
- C-STORE : permets de stocker un objet.
L’étude menée par Sina a révélé que la majorité des serveurs DICOM ne protègent pas assez l’accès à ces services. En effet, soit l’authentification n’est pas activée, soit le secret permettant d’obtenir un accès à ces services est faible.
Ainsi, lorsque l’authentification sur le serveur est faible et que les services listés précédemment sont exposés, un attaquant peut en profiter pour extraire l’ensemble des données médicales contenues sur le serveur ou pour modifier les données existantes afin de les rendre incorrectes voir illisibles.
Le protocole DICOM est souvent hébergé sur les ports TCP/104, TCP/4242 et TCP/11112. En scannant l’intégralité d’Internet, Sina et son équipe ont pu identifier qu’au moins 3800 serveurs DICOM sont exposés sur Internet. Parmi ces serveurs au moins 2900 avaient désactivé l’authentification et 750 utilisaient un secret d’authentification faible. L’exposition de ces serveurs permettrait actuellement d’accéder à plus de 40 millions de documents médicaux.
Pour remédier à cela, les solutions suivantes sont proposées par Sina :
- Côté exploitant :
- Assurer que les serveurs DICOM ne sont pas exposés sur Internet ;
- Mettre en place de la segmentation pour bloquer l’accès aux services DICOM depuis un réseau utilisateur ;
- Mettre en place de contrôle d’accès forts aux interfaces web permettant d’interagir avec les serveurs DICOM.
- Côté vendeur :
- Forcer l’utilisation d’authentification forte au niveau logiciel ;
- Mettre en place des dates d’obsolence régulières pour les serveurs DICOM.
- Côté autorités nationales :
- Assurer que les serveurs DICOM sont revus lors des audits de certifications et qu’une mauvaise configuration de ces derniers est bloquante ;
- Scanner les IP du pays pour identifier les serveurs DICOM vulnérables et aider les hôpitaux à régler les potentiels défauts de configuration.
Le support complet de la présentation est disponible à l’URL suivante : https://i.blackhat.com/EU-23/Presentations/EU-23-Yazdanmehr-Millions_of_Patient_Records_at_Risk.pdf
Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules by Brett Hawkins (ADOkit)
Brett Hawkings a présenté ses recherches concernant Azure DevOps Services et des méthodes de contournement des 18 règles de détection par défaut de Microsoft Sentinel (solution SIEM de Microsoft dans le Cloud).
Le chercheur revient sur les différentes méthodes d’attaques pouvant être déroulées sur Azure DevOps Services :
- l’obtention des accès initiaux (login/mot de passe faible, compromission d’un Personal Access Token (PAT), compromission d’un cookie d’authentification) ;
- la reconnaissance via le l’énumération des projets, repositories, users, code, etc. et les possibilités permises par l’interface web (https://dev.azure.com/{myOrg}) ou l’API REST dédiée ;
- la persistance via la création de PAT ou de clés SSH ;
- les élévations de privilèges via l’ajout d’utilisateurs à des groupes privilégiés ;
- la modification de pipeline de build pour exécuter du code arbitraire ;
- la compromission d’un hôte on-premise via les self-hosted agents ;
- la récupération de variables de build et des secrets des pipelines.
Pour chacune des attaques, Brett précise si les règles par défaut de Microsoft Sentinel permettent une détection ou pas. Il s’avère que, pour la plupart des attaques, les détections ne sont pas efficaces. Il revient également sur des mécanismes d’évasion des défenses habituellement utilisés (ex.: désactivation des flux d’audit, ajout d’une source de paquets externes malveillante, etc.) et identifie les règles Sentinel permettant leur détection.
Le chercheur effectue ensuite une analyse des 5 règles Sentinel suivantes :
- Utilisation d’un PAT Azure DevOps avec un navigateur ;
- Mauvaise utilisation d’un PAT Azure DevOps ;
- Modification d’une pipeline Azure DevOps par un nouvel utilisateur ;
- Nouveau PA, PCA ou PCAS ajouté à Azure DevOps ;
- Surveillance du groupe Azure DevOps Administrator.
Pour chaque exemple, une analyse de la règle de détection et un moyen de contournement est donc expliqué.
Brett propose une amélioration des règles 2, 4 et 5 ainsi qu’une nouvelle règle concernant la détection des techniques de persistance.
Pour conclure, le chercheur présente son outil ADOKit (https://github.com/xforcered/ADOKit) qui permet de faciliter la mise en place des attaques sur Azure DevOps Services. Le repository inclut aussi des règles de détection Yara/Snort/Sentinel afin de détecter l’usage d’ADOKit.
Github : https://github.com/xforcered/ADOKit
Whitepaper : https://www.ibm.com/downloads/cas/5JKAPVYD
Slides : https://i.blackhat.com/EU-23/Presentations/EU-23-Hawkins-Hiding-in-the-Clouds.pdf
X : https://x.com/h4wkst3r
The Pool Party You Will Never Forget: New Process Injection Techniques Using Windows Thread Pools by Alon Leviev
Dans cette présentation, Alon Leviev expose ses recherches concernant les injections de processus (ou process injection).
Il revient d’abord sur les généralités concernant ce type d’attaque, souvent utilisée pour contourner des mécanismes de défense mis en place par des antivirus ou des EDR. Le but dess process injections est d’exécuter du code arbitraire au sein d’un processus choisi. Alon explique qu’habituellement, pour mener à bien ce type d’opération, 3 étapes sont nécessaires :
- L’allocation en mémoire sur le processus ciblé (ex. : VirtualAllocEx());
- L’écriture de code arbitraire au sein de la mémoire allouée (ex. : WriteProcessMemory());
- L’exécution du code précédemment écrit (ex. : CreateRemoteThread()).
Les techniques d’injections de processus se sont démocratisées et les EDR modernes permettent de détecter les plus classiques, principalement lors de la primitive d’exécution précédemment décrite selon les tests du chercheur.
Alon s’est alors fixé comme objectif de mettre en place une injection de processus basée sur les primitives d’allocation et d’écriture, et de déclencher la primitive d’exécution via une action légitime, tout cela afin de contourner les mécanismes de détection modernes.
Le chercheur présente donc le fruit de ses travaux sur les Windows Thread Pools et revient sur 8 variantes d’injections de processus permettant de ne pas être détecté sur les EDR suivants :
- Palo Alto Cortex ;
- SentinelOne EDR ;
- CrowdStrike Falcon ;
- Microsoft Defender for Endpoint ;
- Cybereason EDR.
Alon a également créé un outil, disponible sur Github (https://github.com/SafeBreach-Labs/PoolParty), permettant de faciliter l’exploitation des 8 techniques d’injection de processus qu’il a présenté.
Github : https://github.com/SafeBreach-Labs/PoolParty
Blogpost : https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
Slides : https://i.blackhat.com/EU-23/Presentations/EU-23-Leviev-The-Pool-Party-You-Will-Never-Forget.pdf
X : https://x.com/_0xDeku
Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates by David Ori
Dans cette présentation, David Ori (Akamai) présente un nouveau type d’attaque ciblant les serveurs DNS au sein d’environnements « Active Directory ».
Chaque domaine « Active Directory » dispose de sa propre zone DNS (Active Directory Integrated DNS – ADIDNS), cette zone est en charge de la gestion des noms associés aux différents composants du domaine.
Les enregistrements DNS au sein de l’ADIDNS sont gérés automatiquement à l’aide d’une fonctionnalité nommée « Dynamic Updates ». Cette fonctionnalité permet à l’ensemble des clients authentifiés sur le domaine de gérer leurs enregistrements DNS (création, modification et suppression). Afin de protéger l’ensemble des composants du domaine, la fonctionnalité de sécurité « Secure Update » s’assure de vérifier que chaque client ne peut modifier que ses propres enregistrements.
Une autre fonctionnalité présentée par David est la fonctionnalité « DHCP Dynamic Updates » (disponible sur les serveurs Windows DHCP et activée par défaut). Cette fonctionnalité permet aux serveurs Windows DHCP configurés au sein d’un domaine de créer des enregistrements DNS à la place de leurs clients. Ainsi, lorsqu’un client précise le FQDN qu’il souhaite utiliser au serveur DHCP, le serveur DHCP peut s’occuper de la création de l’enregistrement à la place client. Dans ce scénario, le client n’a donc pas besoin de s’authentifier auprès du serveur DHCP, cela permet donc d’utiliser la fonctionnalité « Dynamic Updates » sans authentification.
Lorsque la fonctionnalité « DHCP Dynamic Updates » est utilisée, la modification des enregistrements DNS est faite au nom du serveur DHCP, on parle de « Managed Records ». Par défaut, il est donc possible d’abuser la fonctionnalité « DHCP Dynamic Updates » pour modifier l’ensemble des « Managed Records » créé par le serveur DHCP du domaine, étant donné que tous les enregistrements appartiennent au serveur DHCP (la protection « Secure Updates » n’entre donc pas en compte).
Cependant, il n’est pas courant d’observer des « Managed Records » au sein d’un domaine « Active Directory ». Les clients Windows récents créent eux-mêmes leurs enregistrements DNS lorsqu’ils rejoignent un domaine. Mais, même si aucun client ne s’est enregistré sur le domaine à l’aide de la fonctionnalité « DHCP Dynamic Updates », un attaquant peut toujours exploiter la configuration par défaut afin de modifier l’enregistrement DNS du serveur DHCP du domaine.
Enfin, lorsque le serveur DHCP est configuré sur le contrôleur de domaine, alors il devient possible d’abuser la fonctionnalité « DHCP Dynamic Updates » pour modifier l’ensemble des enregistrements ADIDNS. En effet, par défaut, la création des enregistrements DNS par le serveur DHCP est faite au nom du contrôleur de domaine qui dispose des privilèges de modification sur l’ensemble des enregistrements ADIDNS.
Pour résumer, lorsqu’un serveur Windows DHCP est hébergé sur un contrôleur de domaine (avec la configuration par défaut), l’attaque présentée par David permet à un attaquant non authentifié de modifier l’ensemble des enregistrements DNS du domaine. Ainsi, un attaquant pourrait réaliser du « DNS Spoofing » afin de réaliser des attaques « Man-in-the-Middle » (relai NTLM par exemple) ou encore pour bloquer l’accès à des serveurs critiques.
Deux solutions sont proposées par David :
- Configuration de la sécurité « Name Protection » sur le serveur DNS du domaine ;
- Modification des identifiants utilisés par le serveur DHCP lors des communications avec le serveur DNS.
Cependant, d’après David, ces protections sont insuffisantes et peuvent être contournées.
Plus d’informations sont disponibles au sein de l’article de blog suivant : https://www.akamai.com/blog/security-research/spoofing-dns-by-abusing-dhcp
