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 pentests ré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 team
et 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 CorrectFilePath pour 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 phishing a 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
Aucun commentaire:
Enregistrer un commentaire