SecurityInsider
Le blog des experts sécurité Wavestone

Compte-Rendu de la conférence BruCON 2017




Wavestone était présent à l’édition 2017 de la conférence BruCON où Arnaud SOULLIE et Alexandrine TORRENTS de la practice Cybersecurity & Digital Trust ont présenté un workshop sur la sécurité des systèmes industriels. Arnaud SOULLIE a également présenté la nouvelle version du projet DYODE (https://www.youtube.com/watch?v=JjqPOesXje4). 
Nous vous proposons ci-dessous un compte-rendu d’une sélection de talks, les vidéos étant déjà disponibles sur YouTube (https://www.youtube.com/channel/UCqwMU1l90lf9BLersW6eAHw).
Nous tenons à remercier les organisateurs pour leur accueil chaleureux, l’ambiance conviviale et l’esprit de communauté qui ont régné durant cette conférence.


Justine Bone - The cyber short - A market solution for product safety and corporate governance


À travers cette Keynote, la CEO de MedSec a montré le besoin d’innovation en matière de cybersécurité en présentant une nouvelle opportunité : les marchés publics. En effet, ils représentent une nouvelle façon de :
  • Tenir les entreprises responsables de la sécurité de leur produit
  • Financer la recherche de vulnérabilités

Et si les incidents de cybersécurité pouvaient avoir un impact sur la valeur des actions en bourse ? Justine a présenté quelques exemples encore peu significatifs comme Verizon/Yahoo et Equifax mais la situation pourrait évoluer dans les années à venir. 
Les nouveaux clients de la cybersécurité seraient donc les investisseurs, et en particuliers les investisseurs activistes qui ont énormément d’expérience et font d’importants travaux de recherches avant chaque transaction. Ces investisseurs commencent à s’intéresser aux aspects technologiques et notamment aux vulnérabilités pouvant impacter les produits et donc les actions.
La cybersécurité pourrait donc être un nouveau vecteur de recherche. En revanche, la recherche en cybersécurité est assez différente de la recherche de manière générale :
  • Les recherches sont souvent ultra secrètes, alors que les recherches en cybersécurité sont souvent open source
  • Les recherches sont souvent divulguées à la fin des transactions alors qu’en cybersécurité, de nombreux accords de confidentialité sont signés entre les chercheurs et les fabricants

La recherche en cybersécurité doit donc évoluer et notamment fournir des exploits fiables et industrialisables. De plus, l’intégrité des recherches doit pouvoir être vérifiée.
En revanche, la découverte d’une vulnérabilité critique n’engendrera pas forcément une chute sur les marchés publics. En effet, de nombreux autres facteurs doivent être pris en compte. Par exemple, une vulnérabilité sur un composant matériel, nécessitant un rappel des produits aura certainement plus d’impact qu’une vulnérabilité sur un firmware ou un logiciel. 
Ce qu’il faut retenir de cette présentation est que la cybersécurité peut éduquer le marché et influencer l’attitude d’une entreprise. En revanche, il va falloir attendre encore un peu avant que les comités de direction soient véritablement sensibilisés. 
Bien que très intéressante, cette keynote prend des hypothèses qui sont actuellement loin d’être avérées dans tous les secteurs :
  • Le caractère vulnérable d’un produit va engendrer une chute des ventes, donc une baisse de revenus pour la société qui la commercialise
  • La vulnérabilité d’un produit ou d’une gamme de produit pourrait avoir un impact global sur la société qui la commercialise
  • Les consommateurs se tourneront moins vers un produit vulnérable ; actuellement le caractère novateur d’un produit semble plus important à leurs yeux que son niveau de sécurité



František Střasák – Detecting malware even when it is encrypted - Machine learning for network HTTPS analysis


L’étude de František part d’un constat simple. Plus de 50% du trafic web global est chiffré. En ce qui concerne les malwares, entre 10 et 40% du trafic est chiffré. Le chiffrement rend inefficaces les techniques classiques de détection et l’inspection TLS coute cher, est contraignant et ne respecte pas le principe de vie privée. 
Il existe donc un besoin de découvrir de nouvelles méthodes de détection de malware, sans déchiffrer les communications. L’objectif de l’étude présentée dans ce talk est donc de détecter des malwares sur du trafic HTTPS sans le déchiffrer et en assurant une importante précision, présentant de faibles taux de faux négatifs et faux positifs. 
Le jeu de données utilisé pour ces tests était composé de 163 captures de trafic (certaines légitimes et d’autres générés sur des postes infectés par un malware). 
Plusieurs informations sur ces captures peuvent être récupérées grâce aux fichiers de logs : conn.log, ssl.log et x509.log. Plusieurs agrégats SSL (adresse IP source, adresse IP de destination, port de destination, protocole) ont été listés à partir de ces logs et les analyses ont été effectuées sur un certain nombre de caractéristiques, parmi lesquelles :
  • Le nombre d’agrégats SSL
  • La durée moyenne / l’écart-type des connexions
  • Le nombre moyen de paquets
  • Le ratio de connexions établies / non établies
  • Le ratio des versions TLS / SSL
  • Le nombre moyen de certificats SSL différents
  • La durée moyenne de validité du certificat
  • Etc.

Deux jeux de test ont été menés en séparant des données d’apprentissage et des données de tests. 
  • Le premier jeu de test contenait 50% de trafic malware et 50% de trafic normal à la fois pour la phase d’apprentissage et la phase de tests
  • Le second jeu de test contenait 40% de trafic malware et 60% de trafic normal pour l’apprentissage et 3% de trafic malware et 97% de trafic normal pour la phase de test

Les résultats des deux jeux de tests sont assez similaires et montrent une précision de 90% et 95% respectivement. Les taux de faux positifs et faux négatifs restent assez importants (7% et 10%). 
Avec cette étude, František a identifié les critères les plus caractéristiques pour la détection de malware :


Les résultats sont plutôt satisfaisants mais doivent néanmoins être améliorés. Le but initial n’a donc pas été totalement atteint. De plus, les malwares tentent de ressembler de plus en plus à du trafic normal et ces nouvelles méthodes risquent d’être de plus en plus difficiles à utiliser. 


Anna Shirokova – Knock Knock… Who’s there? admin admin and get in! An overview of the CMS brute-forcing malware landscape


Anna Shirokova a tout d’abord présenté un panorama des malwares effectuant des attaques de type brute force sur les CMS tels que WordPress
  • 2009 : première attaque de brute force distribué sur WordPress
  • 2013 : FortDisco
  • 2014 : Mayhem ainsi qu’une vulnérabilité dans l’un des plug-ins les plus utilisés
  • 2015 : Aethra, CMS Catcher et Troldesh (un ransomware)
  • 2017 : Stantinko

Elle est ensuite revenue sur le malware Sathurbot apparu en 2013. Sathurbut est un botnet modulaire contenant notamment une backdoor, un module de téléchargement, un indexeur web ainsi qu’un module de brute force. Ce botnet permet donc d’indexer des pages sur des moteurs de recherches tels que Bing, Google et Yandex, d’identifier des WordPress et ensuite de les bruteforcer en tentant des combinaisons non standards d’identifiants. Plusieurs mots de passe peuvent même être testés sur un même site. 
Anna a également parlé rapidement de détection, en mentionnant les IDS, les SIEM ainsi que les analyses comportementales. 
Pour terminer, ce qu’il faut retenir des attaques de brute force de CMS :
  • Elles sont encore réussies à cause des mots de passe faibles utilisés en revanche le taux de réussite est difficile à calculer
  • Très peu de recherches sont orientées sur ce type d’attaque



Nikhil Mittal – Evading Microsoft ATA for AD domination


Nikhil Mittal a pu tester la plateforme Microsoft Advanced Threat Analytics (ATA). Cette plateforme permet de détecter un certain nombre d’attaques en analysant le trafic vers les contrôleurs de domaine, les événements SIEM et les logs
Les tests ont été réalisés sur la version 1.8 de Lightweight ATA gateway installé sur un contrôleur de domaine Windows Server 2012 R2. 
Microsoft ATA permet en particulier de détecter les attaques suivantes :


En revanche, la présentation de Nikhil montre qu’il est possible de contourner ces contrôles dans la plupart des cas. 
En effet, en termes de reconnaissance, seules les requêtes envoyées au contrôleur de domaine sont détectées. La solution pour contourner ATA est donc de requêter l’AD de manière intelligente, sans énumérer le DC. De plus, le scan de SPN (Service Principal Name) n’est pas détecté et des outils comme PowerView peuvent être utilisés pour de tels scans
Par ailleurs, les attaques comme overpass-the-hash sont détectées car le niveau de sécurité du chiffrement est abaissé et l’implémentation utilise un protocole non standard. Pour contourner ATA, il faut donc utiliser le niveau de chiffrement habituel, soit des clés AES. Cette évasion permet donc de créer des tickets pour les administrateurs de domaine. 
La même méthode peut être utilisée pour contourner la détection des golden tickets. De plus, la création d’un golden ticket pour un utilisateur non-existant n’est pas détectée !
Depuis la version 1.8 d’ATA, il est possible de détecter l’utilisation de ticket dont la période de validité a expiré. Il faut donc être vigilant en utilisant de tels tickets. La règle principale à ne pas oublier : si on ne peut pas contourner ATA, il faut mieux l’éviter. 
De plus, plusieurs autres attaques ne sont pas détectées par ATA :
  • L’exécution de commande en utilisant PowerShell Remoting, DCOM ou DLL Hijack
  • Silver ticket puisqu’il n’y a pas de communication avec le DC
  • Kerberoast puisque le peu de communications avec le DC sont normales 

ATA a également quelques limitations :
  • Impossibilité d’analyser du trafic chiffré
  • Manque de signatures pour certaines attaques

Par ailleurs, la console ATA elle-même peut être attaquée :
  • Identification possible jusqu’à la version 1.7
  • Identification du certificat SSL par défaut sur les machines Linux notamment 
  • Accès par défaut à la console d’administration pour le groupe local ATA
  • Absence d’authentification sur la base de données locale MongoDB

Il serait donc possible de porter atteinte à la base de données et d’empêcher le déclenchement des alertes
Ces résultats sont cohérents avec ceux obtenus en interne par Wavestone sur nos maquettes. Le produit continue à gagner en maturité, et il faut souligner que la licence est comprise dans les licences EMS, détenues par de nombreux clients grands comptes. 


Sander Demeester – Secure channels: Building real world crypto systems


La présentation de Sander Demeester était plutôt un cours théorique sur les bases de la cryptographie. Il a commencé par définir un canal sécurisé et présenté les trois notions principales : confidentialité, intégrité et authenticité
Il a ensuite présenté les étapes de construction d’un canal sécurisé :
  • Le protocole authentifié de génération de clé, respectant la propriété de Pefect Forward Secrecy
    • La création de la clé (Diffie-Hellman)
    • Le transport de la clé (RSA)
  • La phase de dérivation de la clé
  • L’utilisation des clés dérivés pour la protection des communications, avec notamment le chiffrement par bloc (CTR, CBC, etc.)

Enfin, il a présenté des exemples de la vie réelle :
  • TLSv1.3 avec le « record protocol » : tous les messages sont protégés avec les schémas AEAD  (Authenticated Encryption with Associated Data) et sont donc chiffrés et authentifiés 
  • SSHv2 qui utilise une architecture à plusieurs niveaux ainsi que le protocole « binary packet » 



Gregory Pickett – Open Source Security Orchestration


Les développements de Gregory Pickett sont partis d’une question : tous mes serveurs utilisent Fail2Ban pour se protéger, mais est-il possible de partager les « Jails » entre ces différents serveurs ?
Il souhaitait trouver un moyen de faire communiquer les serveurs entre eux afin de partager leurs connaissances, sans faire intervenir un système tiers, comme un SOC par exemple. 
Il a donc créé le protocole ANP : Adaptive Network Protocol. Ce protocole permet de :
  • Partager les événements entre systèmes sous un même format
  • Stocker les événements localement 
  • Faire en sorte que les systèmes utilisent les événements partagés 
    • Fail2Ban
    • Modsecurity
    • Iptables

Concrètement, il est possible d’envoyer des messages afin d’ajouter / de retirer un événement redouté. 
Le partage permet d’obtenir une visibilité accrue et d’être proactif. En effet, les systèmes peuvent se protéger eux-mêmes.
Le protocole a encore besoin d’améliorations, notamment l’ajout d’interfaces et l’ajout de types de messages. Cependant, il peut faire la différence et notamment faire en sorte que l’attaque soit arrêtée, en utilisant peu de ressources humaines. 


Arnaud Soullié / Alexandrine Torrents – Pentesting ICS 101

Cette année, Wavestone animait un workshop à la BruCON, sur le thème de la sécurité des SI industriels. Cet atelier s’est déroulé de 13h30 à 17h30 le vendredi, avec une vingtaine de personnes.
Le même workshop mais sur une durée de 2h avait déjà été animé il y a deux ans à la BruCON et avait fait l’objet d’un article sur Security Insider : http://www.securityinsider-wavestone.com/2015/10/brucon-0x07-pentesting-ics-101.html



La différence principale par rapport au workshop de 2015 est l’ajout d’un atelier de programmation des automates Schneider TM221 avec le logiciel SoMachine Basic. 
Le workshop était découpé ainsi :
  • Présentation des SI industriels
  • Présentation des principales familles de vulnérabilités affectant les SI industriels
  • Présentation des principaux protocoles industriels et programmation d’un automate
  • Présentation des outils de test d’intrusion sur les automates Schneider et Siemens
  • Capture the flag sur la maquette
Merci à tous les participants qui ont bien joué le jeu et ont réussi à capturer le drapeau ! 


Alexandrine TORRENTS

Aucun commentaire:

Enregistrer un commentaire