Introduction
Intrinsec était présent cette année pour la 9ème édition de la BruCON, une conférence de sécurité basée à Gand, en Belgique, et se déroulant sur 2 jours (du 5 au 6 octobre 2017).
Outre un grand nombre de présentations et d’ateliers sur le thème de la sécurité et des ICS (Industrial Control Systems), un étage complet était dédié au retro-gaming :
Nous avons souhaité détailler dans cet article les conférences et ateliers qui nous ont le plus marqués, l’intégralité des supports de conférence étant accessible sur le site officiel, ainsi que les vidéos disponibles sur YouTube.
Encore merci à toutes les personnes ayant permis que cet évènement soit une réussite.
The First Cyber Short – Lessons learned on the way to Wall Street
Introduction
Justine Bone, chercheuse en sécurité et PDG de MedSEC, nous a présenté lors de cette keynote une solution novatrice et contestée de cybersécurité de marché (market-based cybersecurity) dont l’idée principale est de se concentrer sur la sécurité du produit et non pas la sécurité de l’entreprise.
Cybersecurity: A spotty history
Comme le rappelle Justine, bien que de grands efforts sont faits côté IT afin d’améliorer le niveau de sécurité, la paranoïa et le manque de confiance de la part des clients et des entreprises en dehors du domaine subsistent. En revanche, les incidents de sécurité devenant de plus en plus communs et médiatisés, les utilisateurs commencent à se poser des questions et à s’intéresser au sujet. Enfin, l’impact financier commence à se faire sentir, notamment sur les cours de bourse des entreprises touchées, de façon durable.
Hackers are inventors and risk takers
Justine a ensuite présenté son constat vis-à-vis de l’industrie de la cybersécurité qui, selon elle, suit la plupart du temps un chemin de pensée directeur (directional thinking), que les chercheurs en sécurité suivent sans se poser de question. Or ce procédé n’est plus efficace. D’un côté, la défense a prouvé par son histoire son inefficacité, et de l’autre l’attaque commence à manquer de motivation, et devient de plus en plus chère.
L’industrie de la sécurité a besoin de faire preuve d’innovation, celle-ci pouvant être représentée par la formule suivante :
Innovation = creativity + value
The fallout of « responsible » disclosure
Le principe de « responsible disclosure », initialement introduit par Microsoft au début des années 2000, a ensuite été présenté et critiqué.
En effet, les grandes entreprises ont mis en place des conditions restrictives et ont défini un contexte leur permettant de maitriser complètement le processus de remontée de vulnérabilités, diminuant ainsi son impact et sa portée, ainsi que les revenus dégagés par les chercheurs en sécurité. Avec l’arrivée des bug bounties, ce principe a été rebaptisé en « coordinated disclosure » sans pour autant en changer son fonctionnement.
Meet the customers: investors
L’idée ici est de se concentrer sur les investisseurs « activistes », pouvant être des traders, des banquiers, des avocats, ou encore des experts en sécurité, et dont l’activité principale est de s’intéresser en détail à l’entreprise, afin d’en comprendre ses forces et ses faiblesses.
Mis en avant par Justine, les « short sellers » font partie de ces « activistes » et vont chercher à vendre des parts de l’entreprise ciblée qu’ils ne détiennent pas (qu’on leur a par exemple prêtées), avant que le cours ne tombe, pour enfin racheter ces parts une fois les prix au plus bas. La manœuvre est risquée (le cours d’une action pouvant monter indéfiniment, comme la perte potentielle par définition), et légale puisqu’elle ne repose pas sur des informations internes à l’entreprise (délit d’initié), mais très lucrative, comme le souligne Justine Bone.
Cybersecurity as contributing research
Elle a ensuite détaillée la marche à suivre et les pièges à éviter pour se lancer dans ce domaine.
Dans un premier temps, les POC (Proof of Concept) d’une vulnérabilité ne sont pas suffisants. Il faut en effet, générer des exploits qui sont répétables et fiables.
Ensuite, toutes les vulnérabilités ne se valent pas : les vulnérabilités liées au matériel étant préférées aux vulnérabilités liées au micrologiciel et enfin au logiciel.
Non-technical aspects
Tout sera fait pour discréditer les résultats des recherches et une attention particulière sera portée à l’historique du chercheur ayant divulgué la faille de sécurité.
La communication est ici un aspect critique : il faut en effet documenter et démontrer le fonctionnement de la vulnérabilité de façon claire et concise afin d’éviter toute déformation de la part de l’entreprise ciblée.
Enfin, même si toutes les précautions ont été prises, il est possible que l’échange ne se fasse pas, les avocats pouvant bloquer le processus ou l’entreprise n’étant pas en mesure de corriger la vulnérabilité (très fréquent pour les failles de type « hardware »).
Conclusion
Enfin, Justine Bone a conclu sa présentation, en soulignant que le « cyber short » est l’innovation dont notre marché a besoin, et pouvant être une solution alternative aux classiques « responsible » et « coordinated disclosure ».
Source
Detecting malware even when it is encrypted – Machine Learning for network HTTPS analysis
František Střasák- Sebastian Garcia
Introduction
Aujourd’hui, la moitié du trafic web global est chiffrée, et un tiers (10 % à 40 %) du trafic généré par les logiciels malveillants est également chiffré.
Le problème avec le chiffrement, c’est qu’il interfère avec l’efficacité des techniques classiques de détection de malwares.
Une des solutions classiques est de réaliser de l’inspection HTTPS afin de pouvoir déchiffrer le trafic et ainsi analyser celui-ci avant de le chiffrer de nouveau (Man-In-the-Middle). Dans ce cas, on peut donc utiliser les outils classiques d’analyse, mais cette solution pose plusieurs problèmes :
- un coût élevé (ressources machines, nécessité de mettre des processus en place) ;
- existence d’un risque sur la confidentialité des échanges.
Une autre solution est de ne pas déchiffrer le trafic et de se baser uniquement sur les caractéristiques du trafic chiffré.
Le but des travaux de recherche
Des travaux de recherche ont donc été menés par František Střasák afin de détecter du trafic HTTPS généré par des logiciels malveillants avec un taux de faux-positifs bas et un taux de détection haut.
Définition du jeu de données
Pour ce faire, quatre sous-ensembles de données composées de trafic provenant de malwares et d’applications légitimes ont été utilisés :
- CTU-13 dataset – public (composé de trafic légitime et malveillant)
- MCFP dataset – public (composé de trafic légitime et malveillant)
- Own normal dataset – public (composé de trafic légitime relatif à 3 jours d’accès à des sites classiques appartenant au top 100 Alexa)
- Normal CTU dataset – almost public (composé de trafic légitime réalisé par 22 personnes du département de FEE CTU)
Méthode et outil
Les chercheurs sont partis de fichiers pcap et les ont analysés avec l’outil Bro afin de générer les fichiers de logs suivants :
- conn.log : Connexions TCP/UDP/ICMP
- ssl.log : handshakes SSL/TLS, chemin du certificat, algorithmes de chiffrement…
- x509.log : informations relatives au certificat x509 (serial number, common name, validité…)
Analyse des fichiers
Les fichiers de logs étant interconnectés, il est possible de mettre en place un système de référence et de numérotation comme illustré par le schéma ci-dessous :
En s’appuyant sur différentes métriques et constantes, il est possible de calculer différents ratios et relations entre les connexions SSL (durées des connexions, temps entre les connexions, différences de durées, etc.), ainsi que sur les informations relatives aux certificats (moyennes sur la longueur des chemins de certificats, écart type sur la longueur des chemins de certificat, ratio entre les « common name » (CN) et les entrées DNS).
Algorithmes de machine learning
Un ensemble de données a été créé à partir de toutes ces unités de connexion SSL (ssl-connect-units), et les algorithmes d’apprentissage (« machine learning ») suivants ont été utilisés contre cet ensemble de données :
- XGBoost
- Random forest
- Neural network
- SVM
Experiments
La première étape a été de découper l’ensemble en N sous-jeux de données afin qu’ils ne contiennent qu’un seul exemple de données venant d’un logiciel malveillant. Pour chaque sous-ensemble de jeu de données, les actions suivantes ont été réalisées :
- découpage du sous-ensemble en données de test et données d’entrainement ;
- validation croisée avec les données d’entrainement ;
- entrainement sur les données d’entrainement et test sur les données de test ;
Suite aux différents tests, il a été possible de mesurer les résultats suivants :
- Expérience 1 (répartition normale / malware : 50% / 50% pour l’entrainement et pour les tests)
- XDGBoost -> Précision de 92%
- Random Forest -> Précision de 90%
- Expérience 2 (répartition normale / malware : 40% / 60% pour l’entrainement, 3% / 97% pour les tests)
- XDGBoost -> Accuracy 92,45 %
- Random Forest -> Accuracy 95,65
Un grand nombre d’expériences a été mené pour trouver les bons paramètres et déterminer ceux ayant un impact sur le taux de détection :
- durée de validité du certificat
- validité du certificat
- durée de la connexion
- nombre de domaines dans le certificat
- la version de SSL/TLS utilisée
- la périodicité des connexions
Conclusion
Pour conclure sa présentation, František Střasák a indiqué qu’il restait encore de nombreux critères à analyser et que les taux de faux positifs étaient encore trop élevés. Cependant, l’aboutissement de ces recherches pourrait permettre de détecter l’activité de malwares sans jamais déchiffrer le trafic et donc sans compromettre la confidentialité ni l’intégrité des échanges.
Sources
Knock Knock … Who’s there? Admin admin and get in! – An overview of the CMS brute forcing malware landscape
Introduction
Anna Shirrokova, analyste des menaces cognitives chez Cisco, a présenté en trois parties les logiciels malveillants ciblant les CMS au moyen d’attaques de type force brute :
- Historique des campagnes
- Analyse du fonctionnement d’un malware
- Méthodes de détection
Historique des campagnes
Les recherches menées permettent de retracer la chronologie suivante :
- 2009 : Première constatation d’une attaque de force brute distribuée ;
- 2013 : FortDisco réalisait des attaques par force brute des CMS WordPress et permettait aussi la redirection ainsi que l’usage d’exploit kits (Blackhole, Styx…) ;
- 2014 : Mayhem, contenait 6 modules de force brute (FTP, CMS).
- 2015 : Aethra ciblait des entreprises basées en Italie exposant des interfaces d’administration WordPress utilisant des identifiants par défaut. LizardSec a scanné pour se faire un botnet.
- 2015 : Troldesh opérait comme un rançongiciel puis, une fois les données chiffrées, réalisait des attaques par force brute sur divers CMS ;
- 2017 : Stantinko se comportait comme un adware et renfermait un module de force brute.
Anna a ensuite expliqué que ces logiciels malveillants embarquaient des modules de force brute, car ceux-ci sont simples à mettre en place, automatisables et très efficaces.
Analyse de Sathurbot
Une présentation en détail du malware modulaire Sathurbot a ensuite été réalisée.
Celui-ci comporte les modules suivants :
- backdoor
- downloader
- web crawler
- brute forcer
Le vecteur d’infection constaté est le téléchargement d’un exécutable pour l’accès aux fichiers de téléchargement de type torrents.
Une fois implanté, Sathurbot récupère la liste des sites à cibler via des recherches sur des moteurs comme Google, Bing, ou Yandex.
Un listing des WordPress est ensuite réalisé à partir de la liste précédente en tentant un accès à la page « wp-login.php ».
Une attaque par force brute via le script PHP « xmlrpc.php » est alors réalisée afin de tenter plusieurs tentatives d’authentification en une seule requête.
Une analyse des communications avec les serveurs CnC a ensuite été menée afin de récupérer les différents noms de domaine utilisés lors des différentes campagnes.
Détection
Plusieurs techniques peuvent être employées afin de détecter ce type de logiciel malveillant :
- Utilisation d’un IDS : ce n’est pas la meilleure solution, car celle-ci génère beaucoup de faux positifs ;
- Mise en place d’un SIEM : cette solution permet par exemple de repérer les machines qui se connectent à une multitude de sites différents dans un laps de temps réduit.
- Analyse comportementale
Conclusion
Anna a conclu par dire que ce type de logiciel malveillant était globalement facile à détecter, mais que les CMS étaient toujours victimes de ce type d’attaque bien que les méthodologies employées soient les mêmes au sein des différents malwares.
Sources
Evading Microsoft ATA for Active Directory Domination
Nikhil Mittal | https://github.com/samratashok
Introduction
Nikhil Mittal nous a présenté la plateforme de Microsoft, ATA (Advanced Threat Analytics), permettant de détecter des attaques en analysant le trafic et les évènements Windows.
Détections – Ce que ATA détecte
ATA est généralement placé en mirroring des contrôleurs de domaine (DC) et est capable de détecter plusieurs artefacts au cours des phases d’attaque suivantes :
- Reconnaissance
- Énumération de session SMB
- Énumération de comptes
- Énumération des contrôleurs de domaine
- Compromission d’identifiants
- attaque par force brute
- Déplacement latéral
- Pass-the-hash
- Pass-the-ticket
- Overpass-the-hash
- Prise de contrôle du domaine
- Golden Tickets
- Requêtes de réplication malveillantes (DCsync)
Contourner ATA
Phase de reconnaissance
Après nous avoir présenté les différents types de détection, Nikhil nous a indiqué comment les contourner. Un des premiers points logiques est de réaliser les phases de reconnaissance en interne de manière intelligente. En particulier, durant la phase d’énumération, si le DC n’est pas directement interrogé, l’activité associée ne sera pas détectée par ATA.
Ci-dessous, un exemple de commandes PowerView pour la récupération des sessions :
Get-NetComputer ou GetNetSession -ComputerName
Même chose pour l’outil UserHunter :
Invoke-UserHunter -ComputerFile
Overpass-the-hash
Pour éviter toute détection lors de la réalisation d’un mouvement latéral via la technique dite « Overpass-the-hash », il suffit de spécifier les clés AES récupérées en mémoire et utilisées par le protocole Kerberos :
Invoke-Mimikatz -Command '"sekurlsa::pth /user:<privservice> /domain:<domaine> /aes256:<condensat_aes256> /ntlm:ntlm /aes128:<condensat_aes18>"'
Golden Ticket
Une fois que la technique précédente réussit, il est possible de créer des tickets pour les administrateurs du domaine. L’étape suivante est donc de générer un Golden Ticket.
Par défaut, cette manipulation des tickets Kerberos est détectée à cause du processus de downgrade appliqué au chiffrement.
Là encore, si on utilise les condensats de type de l’algorithme AES (aes256 et aes128), ATA ne détecte plus cette attaque :
Invoke-Mimikatz -Command '"kerberos::golden /User:<privservice> /domain:<domaine> /sid:<SID> /aes256:<condensat_aes256_du_compte_krbtgt> /id:500 /groups:513 /ptt"'
Toutefois, la version 1.8 d’ATA détecte les tickets ayant une durée de vie très grande.
Il suffit donc de créer des Golden Tickets avec une durée de vie limitée à chaque fois qu’on en a besoin. Il ne faut pas oublier que c’est le condensat récupéré qui représente ici la persistance sur le domaine compromis, et non pas le Golden Ticket généré.
Petit rappel : il est recommandé de ne pas oublier de purger les tickets de la mémoire lorsque la mission est finie.
Éviter ATA
Si on ne peut pas contourner ATA, le mieux reste tout simplement de l’éviter. Plusieurs attaques n’ont pas besoin de dialoguer avec le DC et ne permettent pas de dérouler l’intégralité d’un scénario de compromission. En revanche, celles-ci suffisent à illustrer des risques importants pour le client audité.
Actuellement, ATA ne détecte pas l’exécution de commandes via PSRemoting, DCOM ou encore le détournement de DLL.
Les attaques de type Silver Ticket (pas de communications avec le DC) ou Kerberoast ne sont également pas détectées pour le moment, car les communications avec le DC sont légitimes et inexistantes ou relativement restreintes.
Limitations
ATA présente plusieurs limitations, au-delà des attaques détectées ou non. Le trafic chiffré (LDAPS, IPSEC ESP) ne peut par exemple pas être analysé, ainsi que les nouvelles techniques d’attaques non documentées, ATA nécessitant une signature particulière pour permettre les détections futures. Si l’attaque ne présente pas techniquement de particularité, ATA ne la détectera pas.
Attaque envers les installations d’ATA
Jusqu’à la version 1.8, l’analyse des bannières HTTP permettait de détecter les installations d’ATA. Depuis la version 1.8, il est également possible de détecter ATA via le certificat SSL généré (Subject: ATACenter).
De plus, tous les utilisateurs ou groupes ajoutés aux admins locaux du serveur hébergeant ATA ont les droits admin sur la console d’ATA. C’est d’autant plus grave vu qu’ATA est conçu pour détecter des mouvements latéraux !
Enfin, une base de données mongoDB étant utilisée, celle-ci est en écoute sur l’interface locale et accessible sans authentification. Cependant, aucune alerte n’est remontée lors de l’accès à celle-ci. Une solution simple à implémenter afin de simplement cacher toutes les alertes dans l’interface est la modification du paramètre « IsVisible » à « false » sur la collection « SuspiciousActivities » dans la base de données.
Il ne faut pas oublier qu’ATA n’est qu’un composant, n’ayant pas pour vocation de remplacer les bonnes pratiques classiques d’administration (limiter le nombre d’admins de domaine, ne les utiliser que pour se connecter aux DCs, etc.)
Comment protéger ATA
Afin de protéger ATA, il est conseillé de ne pas l’héberger sur un serveur appartenant au domaine qu’il supervise. La protection de la base de données va sans doute être implémentée dans une future version.
Conclusion
De manière générale, pour un attaquant, plusieurs bonnes pratiques peuvent être adoptées pour éviter ATA :
- Ne pas chercher à tout prix à devenir Admin de domaine sans comprendre l’infrastructure du SI du client ainsi que les éventuelles protections en place ;
- Réduire au maximum les communications avec les contrôleurs de domaine. Par exemple, il est inutile de générer un Golden Ticket ou d’utiliser une Skeleton key si cette action n’illustre pas de risques supplémentaires pour le client ;
- Rester concentré sur le but de la mission. Si ATA n’est pas contournable, autant éviter de s’y confronter.
Sources
How to Build Efficient Security Awareness Programs (that don’t suck)
Contact : https://keybase.io/sapran | Mindmap http://xmind.net/m/raQ4
Introduction
Dans cette présentation, Volodymyr Styran, nous a exposé sa méthode de sensibilisation basée sur l’idée qu’il faut responsabiliser les collaborateurs.
Les outils pour sensibiliser
La peur
La peur est la clé de la survie de l’humanité, elle nous permet de faire face aux menaces. Cependant, nous avons besoin qu’on nous dise de quoi avoir peur. Un usage raisonné permet d’aider à apprendre des nouvelles situations, et des rappels réguliers sont nécessaires afin d’adopter des habitudes saines.
Les motivations (incentives)
Dans le milieu professionnel, la motivation des collaborateurs repose sur les caractéristiques suivantes :
- Esprit de compétition : être en avance sur les autres
- Sentiment d’appartenance : être reconnu comme membre d’un groupe afin de transformer le collaborateur en « Corporate Awareness Evangelist »
Les habitudes
Les points suivants sont nécessaires afin d’instaurer les habitudes à suivre :
- Déclencheur
- Routine
- Récompense
- Repeat 🙂
Une illustration de ce schéma de pensée peut être le suivant : si je m’ennuie, je vais manger un cookie, mon taux de sucre augmente et donc je me sens mieux.
Construction d’une attaque
Enfin, Volodymyr Styran a conclu sa présentation en détaillant les techniques permettant de construire une attaque efficace :
Type d'attaque + Principe d'influence + Contexte de sécurité = Panique
Sources
How hackers changed the security industry
Introduction
Weld Pond, PDG de Veracode nous a partagé son retour d’expérience de plus de 20 ans sur la communauté des Hackers et le domaine de la sécurité informatique.
Historique
Avant les hackers, les développeurs étaient parfaits, les implémentations étaient parfaites, les administrateurs étaient parfaits, les utilisateurs étaient parfaits.
Dans ce monde parfait, tous les incidents de sécurité passaient par le CERT, seule entité en charge de contacter le fournisseur pour remonter un bug ou une vulnérabilité dans un produit. Créé en réponse au ver « Morris », exploitant deux vulnérabilités connues dans sendmail, celui-ci ne partageait aucune information avec l’extérieur. Les hackers se sont donc organisés pour rassembler des ressources.
Les conférences de sécurité, telle que la DefCON née au début des années 90, sont ensuite apparues pour partager des ressources et rencontrer d’autres hackers de la communauté.
Les tests d’intrusion sont ensuite devenus plus communs, puis des programmes bug bounty publics ont vu leur apparition grâce à des entreprises comme Facebook ou encore Google.
Weld Pond rappel enfin qu’aujourd’hui, les états se font passer pour des hackers criminels ce qui prouve que dorénavant les hackers sont devenus des « insiders ».
Conclusion
Weld a conclu sa présentation en indiquant que pour lui, tous les acteurs devraient avoir des notions de sécurité, et celles-ci ne doivent pas être un processus à part, mais doivent être intégrées dans les processus internes de développement. Nous devons faire monter en compétences des collaborateurs sur la sécurité pour en faire des « évangélistes » capables de repérer quand quelque chose ne va pas et réagir en conséquence.
Il s’est enfin adressé à la nouvelle génération en lui demandant de continuer à faire du bruit et à faire bousculer les codes afin que cette dynamique lancée dans les années 90 continue sur sa lancée.
Sources
See no evil, hear no evil – Hacking invisibly and silently with light and sound
Introduction
Cette présentation de Matt Wixey, consultant sécurité chez PwC UK, portait sur la façon dont le son et la lumière peuvent être utilisés pour envoyer des commandes ou exfiltrer de l’information à distance, et s’articulait autour de trois parties principales :
-
-
- Part 1 : Jumping air-gaps
- Part 2 : Surveillance and counter-surveillance
- Part 3 : Bantz
-
Part 1 : Jumping air gaps
Une des premières technologies présentées par Matt est la technologie LiFi permettant la transmission de données via l’émission de lumière. Pour contourner un air-gap, toutes les recherches actuelles supposent la compromission initiale d’une des machines de type air gaps ou un accès physique à celles-ci. D’autres solutions ont également été explorées comme la chaleur, l’accoustique ou encore les fréquences radio afin d’exfiltrer des données. Le schéma de compromission proposé par Matt est le suivant : créer un logiciel malveillant capable d’exécuter des commandes à travers l’API du ALS (Ambient Light Sensor) habituellement présent sur les portables. Le problème restant l’exfiltration des données.
Une des idées est d’utiliser un laser pour envoyer les commandes via un QRcode affiché très rapidement et capté par la caméra de l’attaquant pour exfiltrer les données. Une autre idée est d’utiliser la carte son de la machine cible pour extraire les données par ultrasons (18-19 kHz) inaudibles par la plupart des personnes, et d’utiliser le micro pour recevoir les commandes. Enfin, il est aussi possible d’insérer des images dans un signal audio, qu’il est possible de mixer avec un autre fichier audio.
Pour se prémunir de ce type d’attaque, il est recommandé de supprimer ou désactiver l’ALS et d’utiliser des filtres d’écran.
Part 2 : Surveillance and counter-surveillance
Plusieurs POC (Proof of Concept) ont été présentés par Matt afin de réaliser de la surveillance de personnes.
Un premier scénario est la surveillance d’une conversation en cours dans une salle fermée, et ayant une fenêtre donnant accès sur l’extérieur. Il est alors possible d’utiliser un microphone laser en direction de la fenêtre afin de récupérer les ondes infrarouges générées par les vibrations émises sur la fenêtre, les convertir en courant électrique afin d’identifier les différences de voltage et ainsi reconstruire le signal sonore.
Une autre démonstration a été l’utilisation d’un RTL-SDR afin de sniffer, analyser et cloner les signaux infrarouges afin de désactiver à distance des détecteurs de mouvements. Matt a alors présenté son PoC baptisé « Drone to clone to pwn », qui comme son nom l’indique est un drone sur lequel l’ensemble du dispositif de désactivation a été installé. Les drones ne générant pas assez d’ondes infrarouges (dégagement de chaleur), ceux-ci ne sont alors pas détectés :
Part 3: Bantz
Enfin, Matt nous propose un petit tour d’horizon des usages « dérangeants » des technologies.
De tous les systèmes présentés, nous retiendrons :
- le logiciel de « speech jamming » nous faisant entendre nos paroles en décalé, rendant le simple fait de parler très difficile ;
- « Kill More Gillmore » permettant d’éteindre la télévision en cas de diffusion de la série Gillmore girls ;
- la passoire convertie en casque couvert d’émetteurs pour perturber les capteurs d’altitudes des drones.
Sources :
XFLTReaT: a new dimension in tunneling
Balaza Bucsay nous a présenté son outil/framework open source de tunneling. L’outil est modulaire, multiclient et orienté objet. Il dispose d’une fonctionnalité de « check » permettant de vérifier d’une seule commande les différents canaux d’exfiltration possibles sur un réseau donné. De multiples protocoles sont déjà supportés : TCP, UDP, ICMP, DNS, etc.
En réalité, l’outil utilise deux canaux de communications pour chaque tunnel :
-
-
- un pour la transmission des données;
- un pour l’envoi des messages de contrôle.
L’outil est disponible ici : https://github.com/earthquake/XFLTReaT/
-
Sources
DYODE: Do Your Own DiodE
Arnaud Soullié nous a présenté le projet DYODE sur lequel il travaille depuis maintenant plus d’un an. Il s’agit de développer une diode réseau à bas coût. Une diode réseau est un composant permettant de transmettre des données à sens unique. Ce type de composant est principalement utilisé pour opérer de la remontée d’information depuis les ICS (Industrial Control System) et peut coûter aux alentours de 15 000 € pour des solutions de chez Thales ou Waterfall. L’expérience montre que le réseau ICS est presque toujours connecté au réseau CORP ou à Internet, d’où l’intérêt de ce type de composant, mais de nombreux cas d’usage ne méritent pas l’investissement, d’où l’idée d’une solution DIY (Do It Yourself).
La solution fait usage de deux convertisseurs cuivre-optique ainsi que de deux Raspberry PI comme compteurs pour permettre de faire passer du TCP dans une connexion à sens unique. Le transfert se repose sur une solution maison en python basée sur des sockets UDP.
Fonctionnalités développées :
- transfert de fichiers
- Modbus
- partage d’écran (basé sur la fonction de transfert de fichiers)
La première solution coûtait autour de 380 €. Pour réduire le coût et atteindre la cible de 200 €, plusieurs changements ont été envisagés ou mis en œuvre. Les convertisseurs Ethernet-FO ont été remplacés par une connexion série et un photocoupleur (2 €). Les Raspberry Pi3 pourraient également être remplacés par des Raspberry PI Zero. Au final, le coût à été réduit à 80 €.
Tout le projet est open source : code et hardware (PCB, plan 3D pour le boîtier)
Arnaud Soullié a également rappelé que des données peuvent également avoir besoin de redescendre depuis le réseau corporate vers le réseau ICS dans certains cas, la diode réseau n’est donc pas une « silver bullet ».
Limites de la solution
- Performances
- encore relativement lentes
- Haute latence (notamment sur le transfert de fichier)
- Sensible aux attaques de type « Side channels »
- Les attaques de type TEMPEST n’ont pas été prises en compte dans le projet
- Il est toutefois possible de réduire les fuites EM avec une cage de Faraday
- Renforcement de la gateway
- Les gateways (Rapsberry Pi) n’ont pas été renforcées pour le moment.
Roadmap du projet
- contrôle d’intégrité sur Modbus ;
- mise en place d’un Heartbeat ;
- amélioration du contrôle d’intégrité sur le transfert de fichiers ;
- développement du support d’autres protocoles (SMTP, FTP, Syslog, CIFS, etc.)
GitHub du projet : http://github.com/wavestone-cdt/dyode
