Les 8 et 9 octobre derniers s’est tenue la BruCON à Gand, en Belgique. Durant ces deux jours, la 7èmeédition de cette conférence annuelle de sécurité a rassemblé plus de 500 personnes en provenance d’Europe, des États-Unis ou encore d’Inde. Cette année encore, la BruCON offrait plusieurs activités dans les –magnifiques- locaux de l’Université de Gand :
- les conférences ;
- les ateliers ;
- l’ICS Village.
Retrouvez également un compte-rendu de notre workshop sur la sécurité des SI industriels dans l'article dédié : Pentesting ICS 101
Nous vous proposons un compte rendu des conférences auxquelles nous avons assisté. Les conférences ont toutes été filmées et sont consultables sur la chaîne YouTube de la BruCON : https://www.youtube.com/user/brucontalks. Vous pouvez également retrouver les slides des conférences et workshops en ligne : http://files.brucon.org/2015/.
Nightmares of a pentester (Chris Nickerson)
Au cours de cette première conférence, Chris Nickerson souhaite nous présenter les moyens de faire faire des cauchemars à un pentester et donc par extension un attaquant !
Étant pentester lui-même, Chris a basé sa présentation sur son vécu, en recensant les mécanismes de sécurité qui ralentissent réellement les avancés d’un attaquant. Il a prodigué ses conseils sous forme de règles, que voici.
- Règle #1 : « Ne pas parler aux étrangers ». Pour y parvenir, il recommande de bloquer les scans de ports, les échecs répétés d’authentification (attaque par force brute), les User-Agents d’outils connus de reconnaissance. Chris préconise également de se contraindre à déployer les équipements de type IPS en coupure et en mode bloquant, et de ne pas se contenter du mode surveillance.
- Règle #2 : « Considérer son LAN comme hostile ». Il nous préconise de segmenter les réseaux, de surveiller le trafic réseau (netflow, proxy HTTPS), de bloquant les scans de port internes et d’alerter lors d’un changement de configuration d’un équipement.
- Règle #3 : « Maîtriser les postes de travail ». Pour cela, Chris préconise de mettre en place des listes blanches de logiciels, de scanner les postes à la recherche de vulnérabilités, d’empêchant leur exploitation à l’aide d’outils comme Windows EMET.
- Règle #4 : « Les serveurs ont une mission précise ». Pour cela, en éliminant tout outil bureautique (adobe, office, etc.), en durcissant les OS, en mettant en place des alertes lors d’échec de connexion (SIEM).
- Règle #5 : « Se tenir prêt ». Afin d’être capable de réagir en cas d’incident, Chris décrit quelques mesures à prendre : créer un plan de réponse à incident dans lequel des acteurs sont identifiés, construire des arbres de décisions, réitérer les pentestsrégulièrement, utiliser des outils de capitalisation de connaissances et de réponse à incidents (RITR).
Chris Nickerson illustre parfaitement ce que la sécurité ne doit pas être.
Advanced Wi-Fi attacks using commodity hardware (Mathy Vanhoef)
Lors de cette deuxième conférence, Mathy Vanhoef a souhaité nous démontrer qu’il était possible, avec du matériel très abordable (une quinzaine de dollars) de brouiller les communications Wi-Fi. Il a rappelé que ce genre de matériel coûte habituellement quelques milliers d’euros, ce qui restreint la clientèle à des attaquants motivés.
Matthy nous a resitué le postulat sur lequel repose le Wi-Fi : chaque station se comporte de manière juste. Or, si une station ne respecte pas ce postulat, elle peut arriver par exemple à élever son débit. Pour cela, la station choisit d’ignorer les silences imposés par la norme (SIFS, AIFS, Backoff) et choisit d’émettre continuellement dès lors que le canal est libre. Elle peut alors transmettre plus longtemps et donc augmenter son débit. Matthy nous a donné les résultats de son étude : il est parvenu à faire passer son débit d’upload de 14 à 37 Mb/s.
Comportement égoïste : ignorer les silences (SIFS, AIFSN et Backoff) pour augmenter son débit.
Dans la deuxième partie de son exposé, il nous a expliqué qu’en émettant un message composé de données aléatoires continuellement dans le canal, cela condamnerait toutes les autres stations connectées au silence. En effet, ces dernières attendront que le canal soit à nouveau libre pour émettre, ce qui n’arrivera jamais. Il nous proposa alors une démonstration en direct.
Wireshark à l’appui, Matthy nous a fait constater qu’un important trafic était observable sur le réseau Wi-Fi de la conférence. Lorsqu’il démarra son brouilleur, il fît remarquer que l’analyseur réseau n’affichait plus aucun nouveau paquet, devant les applaudissements de l’audience.
Dans sa dernière démonstration, le présentateur a souhaité nous démontrer que faire mieux était possible ! En modifiant le code de son PoC, il a fait en sorte d’écouter le début de chaque trame, jusqu’aux champs contenant les adresses MAC. Connaissant l’expéditeur et le destinataire, on peut alors décider de brouiller ou non la suite de la trame, par comparaison avec l’adresse MAC de sa victime. Ce faisant, Matthy obtient alors un brouilleur sélectif pour quelques dollars !
Matthy a conclu sa présentation en soulignant les faibles moyens nécessaires à ce genre d’attaques, pour une efficacité atteignant un rayon de 80 mètres, voire 100 mètres avec un amplificateur.
OSXCollector: Automated forensic evidence collection & analysis for OS X (Kuba Sendor)
Dans ce troisième talk, Kuba Sendor nous a présenté un outil open-source qu’il a construit avec son équipe, pour répondre au manque d’application de forensics sur OSX. OSXCollector permet, après la compromission d’un Mac, de collecter un ensemble d’éléments nécessaires au forensics, tels que les logs, l’historique de navigation, les fichiers et de les consolider dans un fichier json. Tous ces éléments sont corrélés à l’aide des timestamps.
Il nous a ensuite décrit une autre composante de l’outil : Output Filter. Ce dernier permet d’intégrer à ce fichier json, des données pertinentes issues de nombreuses sources de Threat Intelligence : réputation des domaines, liste noire de fichiers, VirusTotal, ShadowServer, etc.
L’outil OSXCollector est disponible sur GitHub.
The .11 Veil, Camouflage & Covert!!! /*Invisible Wifi, Revealed */ (Rushikesh Nandedkar & Amrita Iyer)
Lors de ce talk, Rushikesh Nandedkar et Amrita Iyer ont décrit comment ils étaient parvenus à réaliser des communications en Wi-Fi, sans que les stations connectées au même réseau puissent s’en apercevoir.
Pour ce faire, ils ont modifié légèrement les drivers d’une carte Wi-Fi pour être en mesure de transmettre des données, dans certains champs des beacons par exemple. D’autres trames sont intéressantes pour cacher des données, comme : TPC-Request, PS-Poll.
En conclusion, les deux présentateurs nous indiquent qu’en utilisant 2 stations avec des drivers modifiés, il est parfaitement possible de communiquer sans se faire détecter des autres stations. Cette technique pourrait être utilisée pour camoufler l’exfiltration de données.
Levelling Up Security @ Riot Games (Mark Hillick)
Mark Hillick est responsable de l’équipe sécurité Europe chez Riot Games, la société éditrice du jeu League of Legends. C’est donc dans un contexte gamer-oriented qu’il évolue, lui conférant plusieurs crédos : sécurité, agilité et qualité.
Mark nous a expliqué comment lui et son équipe étaient passés de la réactivité (rôle de pompiers) à la proactivité. Pour faire comprendre les enjeux de la sécurité à tous, il a instauré l’organisation annuelle d’une semaine de la sécurité, dans le but de sensibiliser un plus grand nombre d’utilisateurs. Au-delà de cela, il a décrit comment il est parvenu à renforcer la sécurité, en créant une équipe de réponse à incident, en organisant des exercices (blue teamet red team), en formant les développeurs.
Le présentateur a fini sa présentation en déclarant que malgré tous ces efforts, avec 15 ingénieurs seulement, toutes les vulnérabilités ne pouvaient pas éliminées. C’est pourquoi, pour montrer de la reconnaissance envers les personnes remontant de nouvelles vulnérabilités, un programme de bug bounty a vu le jour.
KEYNOTE : Looking Forward Finding the right balance for InfoSec (Dave Kennedy)
Dave Kennedy, fondateur de TrustedSec, nous a présenté sa vision de la sécurité informatique. Selon lui, le hacking est de plus en plus populaire (grâce par exemple à l’excellente série Mr. Robot) et en même temps de plus en plus simple (le malware utilisé chez Sony Pictures n’était pas d’une grande complexité). Pour appuyer ses propos, il nous a montré en direct comme il était simple et rapide de copier un site web, en y injectant un malware, grâce à SET (Social Engineering Toolkit), l’un des outils développés par TrustedSec. Une fois sur cette parfaite copie du site dont elle a l’habitude, la victime est infectée par le malware qui donne accès à un shell à distance à l’attaquant.
Le présentateur regrette que bien trop souvent, par manque de ressources, les technologies de sécurité sont simplement empilées sans grande cohérence et sans qu’il y ait des talents pour les exploiter pleinement et les améliorer après leur mise en place.
David prend l’exemple les solutions de sandboxing, qui peuvent selon lui toutes être contournées avec 3 lignes de codes, qu’il affiche à l’écran :
import multiprocessing
if mutliprocessing.cpu_count() <2
exit()
Selon lui, on croit à tort que l’automatisation de la sécurité (scans, supervision, etc.) est une solution, mais il pense au contraire qu’elle n’est pas viable. Pour Dave, il faut des talents pour faire de la sécurité : s’obliger à appliquer les bonnes idées qui sont connues (rendre aléatoire les comptes administrateurs locaux, désactiver l’utilisation de PowerShell pour les utilisateurs, mettre en place EMET, etc) mais aussi innover.
David a conclu sa présentation sur une note positive, en déclarant que jamais l’on n’a été autant sensibilisé à la sécurité et qu’on s’améliorait tous les jours.
cve-search : A free software to collect, search and analyse common vulnerabilities and exposures in software (Alexandre Delaunoy and Pieter-Jan Moreels)
Dans ce talk, Alexandre Delaunoy and Pieter-Jan Moreels nous ont présenté l’outil qu’ils ont développé pour faciliter la recherche des CVE : cve-search.
Cet outil permet d’agréger plusieurs sources de CVE (NIST, Microsoft) localement, afin d’en faciliter la recherche et d’en améliorer la vitesse, le tout grâce à une interface web. Une démonstration de l’outil est disponible en ligne : https://cve.circl.lu/.
Dans les prochains mois, le but des deux développeurs est d’ajouter d’autres sources de publication de CVE, afin d’agrandir la base de données de vulnérabilités disponibles.
Unified DNS View to Track Threats (Dhia Mahjoub & Thomas Mathew)
Dhia Mahjoub et Thomas Mathew, deux chercheurs en sécurité pour OpenDNS, ont présenté les résultats intéressants de leurs analyses du trafic DNS à la recherche de menaces. Le trafic DNS analysé est constitué de plus de 70 milliards de requêtes DNS, représentant des téraoctets de données par jours, et autant d’informations à exploiter.
Pour mener à bien leurs travaux, ils se sont intéressés aux enregistrements DNS dont l’adresse IP était modifiée beaucoup plus fréquemment que la normale, aux domaines à très mauvaise réputation, etc. Les chercheurs ont ainsi pu de détecter les noms de domaines créés avec un DGA (Domain Generation Algorithm), grâce aux informations ne peuvent être masquées lors de la création (timestamp, zone géographique).
Un DGA est un algorithme utilisé par les malwares, pour créer une liste de centaines de noms de domaine à partir d’une seed (souvent la date du jour). Ainsi, le malware interroge chaque jour de nouveaux noms DNS, sans que son code ait à être à modifié. Le blocage de l’ensemble de ces noms de domaines devient alors extrêmement complexe, puisque de nouveaux apparaissent chaque jour.
Pour identifier ces enregistrements DNS malveillants, les chercheurs ont réalisé des statistiques sur l’ensemble des requêtes observées, à la recherche de pics très francs et sans précédent. Cela peut être le marqueur d’une attaque. Mais cette technique amenait certains faux positifs et donnait un volume de résultat trop important.
![]()
Représentation du nombre de requêtes en fonction du temps.
Pour affiner leurs recherches, ils ont fait appel à d’autres techniques, par exemple l’analyse de la répartition du type de requêtes DNS (A, TXT, SPF, MX), afin de qualifier un enregistrement et un domaine.
Après tous ces traitements, les chercheurs ont été capables d’associer à chaque enregistrement malveillant, l’activité pour laquelle il était utilisé : SPAM, GDA, Browlock (ransomware), distribution de logiciels malveillants, phishing, etc.
Desired state: compromised (Ryan Kazanciyan & Matt Hastings)
Ryan Kazanciyan et Matt Hastings nous ont présenté dans ce talk, comment la fonctionnalité « Desired State Configuration » de PowerShell pouvait être utilisée par un attaquant à des fins de persistance. Cette fonctionnalité permet de gérer facilement des configurations et de s’assurer qu’un état souhaité du système d’exploitation est maintenu dans le temps. Plus concrètement, cette fonctionnalité permet par exemple de vérifier qu’un service est exécuté, d’exécuter un script, de créer un utilisateur, de gérer le registre, etc., le tout périodiquement.
Pour cela, la fonctionnalité s’appuie sur un fichier de configuration .MOF, où est défini l’ensemble des actions à réaliser, les exécutables à déployer, etc. Ce fichier est ensuite déposé sur un serveur IIS, configuré spécifiquement pour la distribution aux autres postes de travail ou serveurs.
Pour illustrer leurs propos, les présentateurs ont décrit un scénario d’attaque utilisant DSC. L’attaquant souhaite installer un malware contenant une backdoor sur un poste de travail et s’assurer qu’il y reste le plus longtemps possible. La blue team de l’entreprise attaquée détecte le malware et le nettoie rapidement. Quinze minutes plus tard (c’est la période par défaut de vérification de configuration), DSC détecte que le malware n’est plus présent et le redépose immédiatement, permettant à l’attaquant de prolonger la durée de son attaque.
Le code de la preuve de concept est disponible sur Github : https://github.com/matthastings/DSCompromised
Shims For The Win: Case study and investigative techniques for hijacked Application Compatibility Infrastructure (William Ballenthin, FireEye & Jonathan Tomczak, Mandiant)
Les deux présentateurs ont animé la dernière conférence de l’édition 2015 de la BruCON, en présentant une technologie de Microsoft qui pourrait être utilisée à mauvais escient : les shims. Cette technologie a été créée pour assurer la compatibilité d’anciennes applications lors des mises à jour vers une version plus récente de Windows.
Techniquement, avant qu’une application se lance, Windows vérifie si un shim y est associé. Si c’est le cas, l’OS lance le shim, puis l’application. Parmi les fonctionnalités disponibles, on notera certaines d’entre elles qui pourraient être exploitées par des attaquants :
Nom du shim | Description |
DisableWindowsDefender | Désactive Windows Defender pour les applications de Sécurité qui ne fonctionne pas avec Windows Defender. |
CorrectFilePaths | Redirige les chemins du système de fichiers. |
LoadLibraryRedirectFlag | Change le dossier de chargement des DLL. |
NoSignatureCheck | Ne vérifie pas la signature de l’exécutable. |
RelaunchElevated | S’assure qu’un fichier exécutable est lancé en tant qu’admin |
VirtualRegistry | Met fin à un exécutable immédiatement. |
Quelques exemples de shims et leur rôle.
Pour illustrer leurs propos, William et Jonathan nous ont cité quelques exemples de scénarios d’attaque :
- [PoC] Utilisation du shim CorrectFilePathpour changer dynamiquement le chemin d’exécution d’un exécutable. On pourra ainsi exécuter un logiciel malveillant, en lieu et place d’une exécutable légitime.
- [Vu dans la nature] Une campagne de phishinga conduit à un dropper, qui a installé un shim. Ce dernier ciblait l’application Opéra et insérait à la volée du shellcode en mémoire.
- [Vu dans la nature] Injection DLL grâce à elogger.dll, à chaque exécution de svchost.exe (très fréquente).
Les présentateurs ont conclu sur la difficulté de détecter ces comportements dans le SI. De plus, l’architecture des fichiers .sdb (contenant les shims) n’est pas documentée, obligeant à la retro-ingénierie pour construire des règles de détection. Ils restent persuadés que cette technologie va constituer un vecteur d’attaque dans le futur.
En définitive, nous n’avons pas pu présenter toutes les conférences et tous les ateliers, mais nous pensons vous avoir donné un panorama représentatif de la BruCON 2015. Rendez-vous l’année prochaine, pour la prochaine édition !
Alexandre LUKAT
