Cette année encore, XMCO était partenaire de la conférence Black Hat Europe. Voici notre retour sur cette édition 2017, qui se déroulait au centre de conférences ExCel London, à Londres.
Au vu du nombre impressionnant de présentations (à minima 4 en parallèle), nous ne décrirons ici que les six présentations nous ayant le plus marqués au cours de ces deux jours de briefing. Les autres conférences auxquelles nous avons pu assister seront disponibles dans le prochain numéro de l’ActuSécu.
How To Rob A Bank Over The Phone – Lessons Learned And Real Audio From An Actual Social Engineering Engagement, par Joshua Crumbaugh
Dans une présentation originale basée sur des extraits audio d’une mission et sur le retour d’expérience de cette même mission, Joshua Crumbaugh présente un vecteur d’attaque toujours sous-estimé, l’homme. Ce spécialiste du social engineering est aussi le fondateur de la société PeopleSec, qui se spécialise dans les missions de RedTeam et de Social Engineering. Il a usé de ses talents pour compromettre des data centers des plus grandes sociétés américaines, pour accéder à des coffres bancaires, ou encore à des zones interdites au sein de casinos.
En introduction, l’expert explique que les victimes de Social Engineering ne devraient pas être renvoyées (comme c’est souvent le cas), mais le management devrait être remis en cause. En effet, sans prévention minimale ou sans formation préalable, n’importe qui pourrait être piégé lors d’une mission.
La mission présentée par Joshua visait une banque américaine. Seul un des vice-présidents de cette banque était au courant qu’un test de pénétration était prévu pour ce jour. C’est précisément ce vice-président qui a été visé.
En préparant sa mission en amont, Joshua a découvert que la banque utilisait un petit fournisseur d’accès Internet pour ses emails. Ce fournisseur avait la réputation d’être assez instable. Il a donc appelé la banque en se faisant passer pour un technicien travaillant pour le FAI, prétextant travailler à une amélioration du service fourni.
Le vice-président de la banque ne détectant pas directement la supercherie a volontairement proposé son aide et la mission a suivi son cours. Le consultant a ainsi pu faire télécharger des scripts sur les serveurs de la banque visée, et les faire exécuter par sa cible. Lorsque l’exécution des scripts a échoué, il est resté dans son rôle et a réussi à faire télécharger un nouveau script à sa victime. Il parviendra à ses fins en compromettant le SI de la banque.
Au cours de cette présentation, Joshua Crumbaugh distillait des informations cruciales liées à son métier. Parmi celles-ci, il explique que la reconnaissance est une partie essentielle de la mission. Avoir un prétexte pour appeler une personne, une histoire crédible qui puisse être corroborée est un atout essentiel. Un autre point important appuyé était de ne jamais sortir du rôle que l’on s’est créé pour la mission. À moins d’être démasqué ou arrêté par la police, le chercheur reste toujours dans le rôle qu’il a créé pour tirer le maximum de sa mission.
L’expert a aussi créé une règle qu’il appelle « Mon patron ». Dès qu’il doit demander à sa victime d’effectuer une action, il prétend que c’est « mon patron » qui lui impose de le faire. Ce faisant, il crée une situation de « nous contre le reste du monde ». Ce faisant, la victime compatit avec l’attaquant, et propose généralement d’elle même « d’aider » pour faire avancer les choses.
Il ne s’agit là que de quelques exemples, la présentation complète regorgeant d’astuces du même acabit, que tout consultant effectuant des missions de Social Engineering ou de phishing devrait connaitre.
Blueborne – A New Class Of Airborne Attacks That Can Remotely Compromise Any Linux/IOT Device, par Ben Seri & Gregory Vishnepolsky
Ben Seri et Gregory Vishnepolsky, deux chercheurs en sécurité chez ARMIS sont venus présenter leurs travaux ciblant le Bluetooth et la vulnérabilité BlueBorne, dévoilée quelques semaines plus tôt. En ciblant la pile Bluetooth, ils s’attaquent à une technologie souvent perçue comme marginale et n’ayant jamais été complètement auditée. Pourtant le Bluetooth est une porte d’entrée à des attaques “sans-fil” qui peuvent avoir des conséquences importantes. En effet, les capacités de cette technologie permettent entre autres de répliquer les attaques et de les propager à tous les périphériques alentour. Les vulnérabilités découvertes et leur exploitation n’impliquaient aucune interaction avec un utilisateur, relevant encore le niveau de criticité.
Les recherches ont mené à la découverte de 8 vulnérabilités, dont 4 considérées comme critiques permettant de prendre le contrôle à distance le système ciblé. Cela représente plus de 5 milliards de périphériques susceptibles d’être attaqués. Dûe à la variété des vulnérabilités découvertes, tous les systèmes sont affectés (Android, Windows, Linux et iOS). En effet, les vulnérabilités ne sont pas intrinsèquement liées au protocole Bluetooth, mais à son implémentation sur les systèmes. Les deux speakers expliquent que les spécifications du Bluetooth font 2822 pages et que la plupart sont très difficiles à comprendre.
Poursuivant leur présentation, Ben et Gregory ont expliqué qu’à partir du moment où le Bluetooth était activé sur un système, celui-ci était toujours à l’écoute de connexions entrantes, bien que normalement impossible à découvrir pour d’autres systèmes. Un attaquant distant pouvait alors profiter de ce fonctionnement pour y accéder malgré l’absence de visibilité. Cela est rendu possible par la diffusion des fragments d’adresses MAC qui sont transmis par le Bluetooth. Un attaquant peut écouter les communications réseau et découvrir suffisamment d’information pour être en mesure de retrouver une adresse complète.
Par la suite, la présentation s’est orientée vers une explication plus technique des composants vulnérables et des stratégies d’exploitation utilisées pour arriver à des codes d’exploitation fonctionnels. Ici encore il a été noté que des défauts dans l’implémentation de mécanismes de sécurité (absence de KASLR, de Stack Canaries, etc.) permettaient de faciliter l’exploitation des vulnérabilités découvertes.
Pour illustrer leur propos et les vulnérabilités présentées, les deux chercheurs se sont attaqués à deux produits ayant eu un grand succès commercial cette année. Une montre Samsung Gear S3 et un Amazon Écho ont été pris pour cible et compromis, à distance et sans la moindre interaction utilisateur. Lors d’une démonstration technique, ils ont été en mesure de répliquer leur attaque sur d’autres périphériques, illustrant la capacité pour un attaquant de rebondir de périphérique en périphérique pour propager son attaque.
Breaking Bad: Stealing Patient Data Through Medical Devices, par Saurabh Harit
Saurabh Harit, chercheur en sécurité chez Spirent SecurityLabs est revenu lors de sa présentation sur la sécurité du matériel médical connecté à Internet.
Dans la mouvance de l’IoT, de plus en plus de périphériques médicaux, professionnels ou grand public, sont connectés à Internet. Tensiomètres, cardiofréquencemètres, pèse-personnes, et même des médicaments connectés passent maintenant par Internet afin de centraliser leurs données et les associer à leurs utilisateurs.
Il y a du positif indéniable à ces avancées technologiques dans le domaine de la médecine. Le chercheur évoque notamment la possibilité pour un docteur de suivre en temps réel un patient, d’adapter ses soins, d’être alerté en cas de problème vital, etc. Tout cela à distance, permettant par la même occasion d’alléger la charge de travail sur le personnel médical. Il y a aussi la possibilité de centraliser une grosse quantité de données médicales pouvant être utilisée pour faire avancer la recherche.
À l’opposé, il y a malheureusement aussi des points négatifs. Parmi eux, l’interopérabilité compliquée, notamment due au très grand nombre de périphériques existants, ayant le même objectif, mais produits par des fabricants différents. La question de la légitimité d’un périphérique médical sur un réseau se pose aussi; comment s’assurer qu’un cardiofréquencemètre appartient bien à l’utilisateur associé ? Le plus gros point négatif restant évidemment la maintenance, et la difficulté majeure que représentent les mises à jour de sécurité de ce genre de périphériques (mettre à jour un pace maker n’est pas des plus trivial).
Une analyse du marché noir de la donnée sur Internet a permis de mettre en lumière que les données médicales étaient de plus en plus ciblées. Leur valeur à la revente est aujourd’hui supérieure à la valeur des données financières classiques (Numéro de carte de crédit, documents bancaires, etc.). De plus, de par le peu de sécurisation du matériel médical, le taux de compromission est en constante augmentation alors que le taux de détection reste très faible.
Saurabh Harit a donc choisi de porter ses recherches sur deux périphériques médicaux et de présenter les vulnérabilités découvertes. La première portait sur un stylo numérique connecté dédié aux médecins. Lors de l’écriture d’une ordonnance, l’information était directement envoyée à la pharmacie afin de que la commande soit préparée.
En s’attaquant au service Windows du périphérique, le chercheur a réussi à élever ses privilèges, puis à accéder à des fichiers de configuration qu’il a pu déchiffrer (car chiffrés par un algorithme « fait maison »). Il a ainsi retrouvé des identifiants d’une base de données et l’adresse de cette base sur Internet. En se connectant à cette base, il a découvert l’ensemble des données médicales (identité, âge, sexe, numéro de sécurité sociale, chambre d’hôpital, etc.) des patients des utilisateurs du stylo numérique.
Pour sa deuxième recherche, le consultant a visé une pompe intraveineuse. En utilisant un PDA, il a pu communiquer via le port infrarouge de la pompe et y envoyer une configuration modifiée. Il a par la suite pu analyser les échanges réseau effectués lors de la prise de commande sur la pompe. Cette analyse lui a permis de recréer en partie la structure du protocole de communication, et d’envoyer des commandes arbitraires à la pompe à distance.
Security Through Distrusting, par Joanna Rutkwoska
Pour la keynote d’ouverture du second jour, Joanna Rutkwoska aborde les problématiques liées à la confiance entre les différents périphériques d’un appareil, à travers 8 cas d’étude dont seul le premier sera abordé ici : le cas des microphones des téléphones mobiles / smartphones.
Les microphones des smartphones sont toujours connectés (il n’est que rarement possible de les désactiver). Ils peuvent donc être utilisés à l’insu de l’utilisateur afin d’écouter les bruits ambiants de l’appareil, d’écouter des conversations ou encore de capturer phoniquement les frappes clavier réalisées par l’utilisateur.
La solution ? Retirer les micros du téléphone et utiliser un périphérique externe activable à la demande (p. ex. un casque Bluetooth).
Red Team Techniques For Evading, Bypassing, And Disabling Ms Advanced Threat Protection And Advanced Threat Analytics, par Chris Thompson
Chris Thompson fait partie de l’équipe IBM X-Force Red (tests d’intrusion en mode « RedTeam »). Il nous présente un état des lieux des techniques d’évasion en environnement Microsoft, plus particulièrement lorsque les solutions Windows Defender ATP (Advanced Threat Protection) et Microsoft Advanced Threat Analytics sont mises en place.
Ainsi, ATP bloquera l’exécution de scripts Powershell malveillants, et ce même s’ils sont obfusqués. En revanche, des scripts JavaScript/VBScripts obfusqués et ne faisant pas appel aux API Kernerl32 (tel que CACTUSTORCH) pourront s’exécuter impunément.
Les appels à la console WMI permettront également de contourner les protections apportées par ATP, tout du moins jusqu’à la prochaine mise à jour majeure du logiciel prévue pour le printemps 2018.
Microsoft ATA lèvera quant à lui des alertes de sécurité lorsqu’un évènement suspect sera détecté auprès d’un contrôleur de domaine Active Directory. Ainsi, ATA lèvera des alertes pour des attaques telles que « Pass-the-Hash », « Golden Ticket », « Over-Pass-The-Hash » (dans certaines conditions), ou encore lors de la réalisation d’attaques de bruteforce, d’énumération des utilisateurs du domaine (via la commande « net user /domain » par exemple) ou de la modification de certains groupes du domaine (Administrateur du Domaine, Administrateurs, etc.).
En revanche, un certain nombre d’attaques n’impliquant pas les contrôleurs de domaine ne seront pas détectées (p. ex. énumération des utilisateurs du domaine via le protocole SMB en ciblant l’ensemble des systèmes du domaine, à l’exception des contrôleurs de domaine). De même, les modifications de groupes du domaine autre que ceux spécifiés par Microsoft ne lèveront pas d’alertes (p. ex. modification d’un groupe héritant du groupe « Administrateurs du Domaine »).
Une liste plus complète des attaques détectées et non détectées est présentée au sein des slides.
Key Reinstallation Attacks: Breaking The WPA2 Protocol, par Mathy Vanhoef
C’est à travers une présentation très didactique que Mathy Vanhoef nous présente les résultats de ses travaux de recherche à l’encontre du protocole Wifi WPA2 : la fameuse attaque KRACK (Key Reinstallation Attack) qui a récemment défrayé la chronique.
Il rappelle dans un premier temps les spécificités du 4-way handshake utilisé lors de l’authentification auprès d’un point d’accès Wifi WPA2, puis présente l’attaque. Celle-ci nécessite la réalisation d’une attaque Man in the Middle sur le canaux Wifi : il faut répliquer le point d’accès sur un canal différent du point d’accès attaqué afin d’être en mesure de bloquer la transmission de certains paquets (le blocage effectif est assuré par le fait que le point d’accès pirate et le point d’accès légitime soient sur des canaux Wifi différents.).
Lors du 4-way handshake, l’attaquant bloque la transmission du message 4 du handshake (client vers le point d’accès). Ce message précède l’installation de la clé de session (PTK) par le client et le point d’accès. Le point d’accès ne recevant pas ce message, il renvoie au client le message 3. Le client renvoie alors le message 4 au point d’accès, sauf que cette fois-ci le message est chiffré avec la clé PTK précédemment installée. Puis, conformément au protocole, le client réinstalle la même clé PTK, ce qui remet à zéro le nonce (number used once).
A ce stade, l’attaquant dispose des éléments suivants : le message 4 en clair et le message 4 chiffré avec la PTK et le premier nonce. Ces deux éléments permettent à l’attaquant de retrouver le keystream utilisé pour le chiffrement, et in fine de déchiffrer le prochain paquet envoyé par le client (puisque celui-ci utilisera un nonce déjà utilisé).
Cette attaque permet finalement à l’attaquant de déchiffrer des trames envoyées par le client ou de rejouer des trames envoyées vers le client.
Par la suite, Mathy procède à la démystification de l’attaque et des idées fausses circulent sur la toile depuis la publication de l’attaque.
- Il suffit de mettre à jour le client ou le point d’accès : faux ! Les deux types de périphériques sont bien vulnérables à l’attaque.
- Il faut être près du réseau attaqué et de la victime : faux ! L’utilisation d’une antenne performante permet de mener l’attaque à distance.
- Il faut être connecté au réseau (i.e. connaître la passphrase WPA2) : faux !
- Aucune donnée intéressante n’est transmise immédiatement après le handshake : faux ! Il suffit de réaliser une attaque de déauthentification afin de provoquer un nouveau 4-way handshake alors que des connexions TCP sont établies par le client.
- Mener une attaque MitM sur les canaux Wifi est difficile : faux ! Il suffit d’utiliser les messages d’annonces de modification de canal (Channel Switch Announcement).
- L’attaque est d’une complexité élevée : vrai ! Toutefois, les scripts permettant l’attaque n’ont besoin d’être écrits qu’une seule fois.
- L’utilisation d’AES-CCMP permet de se protéger de l’attaque : faux ! Il est toujours possible de déchiffrer et rejouer des trames lorsque AES-CCMP est utilisé.
- Les réseaux d’entreprise (802.1x) ne sont pas affectés : faux ! Le 4-way handshake intervient également lors de l’authentification auprès des réseaux d’entreprises.
Enfin, Mathy conclut par le fait que la preuve formelle d’un algorithme ne permet pas d’en garantir la robustesse. Le 4-way handshake et le protocole de chiffrement utilisé après son élaboration ont été prouvés robustes, il n’existe par contre aucune preuve formelle liant les deux. En outre, un modèle abstrait est presque toujours différent d’une implémentation de code concrète. Comme disait Einstein : « En théorie, la théorie et la pratique sont identiques. En pratique, elles diffèrent »
Nous attendons avec impatience la prochaine édition de cette conférence de qualité. En attendant, rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette dernière !
