Liens vers les compte-rendus des autres jours :
- SSTIC 2017 – jour 1
- SSTIC 2017 – jour 2
- SSTIC 2017 – jour 3
PacketWeaver
Les agents de l’ANSSI Florian Maury et Sébastien Mainand, du laboratoire sécurité des réseaux et des protocoles, nous ont présenté leur outil PacketWeaver qui répond à un besoin récurrent de leurs prestations d’audit niveau réseau. En effet, ils sont souvent amenés, sur les solutions qu’ils auditent, à capturer du trafic (via du MITM) de manière sélective pour l’observer et le manipuler avant de le réinjecter sur le réseau.
Ce processus est facilement réalisable avec du spoofing ARP, des règles de filtrage iptables puis des scripts Scapy (ou autre). Cependant, la mise en place de cet environnement est une action répétitive, peu intéressante, sensible aux erreurs et peu générique (adresses en dur).
Ils ont donc développé un outil qui organise et facilite ces étapes et qui permet ensuite d’enchaîner les traitements au travers des blocs reliés par des pipes de communication.
L’outil est développé en Python et propose une interface console similaire à Metasploit.
Parmi les fonctionnalités, nous avons pu observer la possibilité de lancer un scan ping sur un réseau ou bien de créer un serveur ou proxy DNS avec les adresses que nous souhaitons. Les blocs peuvent avoir plusieurs entrées et sorties. Par exemple, il est facile d’implémenter un flux avec un serveur TLS connecté à un script de modification de notre choix et renvoyé via un client TLS.
Dans le futur, les auteurs prévoient de fournir plus de scripts, de s’en servir pour des exercices de formation et de fournir des jeux de tests d’équipements.
Vidéo : https://www.sstic.org/2017/presentation/pw/
cpu_rec.py
Louis Granboulan, de la société Airbus, nous a présenté son outil cpu_rec.py. Lors de son travail, notamment d’audit, il est amené à désassembler des programmes, or il est indispensable d’en connaître l’architecture pour interpréter correctement les octets en opcodes et instructions. Cela n’est pas forcément évident quand nous ne sommes pas en présence de simples fichiers ELF, COFF (PE) ou Mach-O, mais d’extraits bruts de firmwares ou de captures mémoires. L’outil est capable de reconnaître actuellement 72 architectures qui sortent évidemment des classiques Intel ou ARM.
En résumé, l’outil fonctionne à base de statistiques, calculées préalablement sur un corpus de programmes d’une architecture connue, pour calculer ensuite les similitudes avec le code binaire à analyser.
Louis nous a alors détaillé les stratégies testées (machine learning, chaînes de Markov avec fenêtre glissante, etc.).
Il est à noter que son outil peut fonctionner de manière autonome ou bien en tant que module pour le programme binwalk afin de l’appliquer facilement à un firmware ou image disque.
Article et vidéo : https://www.sstic.org/2017/presentation/cpu_rec/
Le Machine Learning confronté aux contraintes opérationnelles des systèmes de détection
Anaël Bonneton et Antoine Husson de l’ANSSI et de l’INRIA ont présenté le sujet en vogue du Machine Learning appliqué à la sécurité informatique et plus précisément à la détection d’intrusion.
Ils ont remarqué que les systèmes actuels sont basés sur des signatures construites par des experts, dont le but est de minimiser les faux-positifs mais qui en contrepartie gèrent mal les variations et se heurtent aux attaques nouvelles. Le milieu est donc en recherche de solutions nouvelles dont le Machine Learning, et plus largement l’Intelligence Artificielle, font partie. Ils ont noté que, dans l’état actuel, les experts sécurité sont sceptiques sur la qualité et facilité de compréhension des résultats tandis que les services marketing annoncent de grandes promesses.
Les orateurs ont présenté les bases de ce domaine de l’apprentissage supervisé. Nous partons d’une entrée que l’on souhaite analyser (dans leur exemple, des fichiers PDF). Il faut d’abord la transformer en vecteur numérique (liste de nombres) pour pouvoir être interprétée par un classifieur. Ce dernier va retourner un score (que l’on souhaite ici refléter le caractère malveillant du fichier PDF), que l’on va comparer à un seuil afin de prendre une décision binaire (malveillant ou non). Dans le cadre d’une détection, ce score peut servir à prioriser les alertes et à régler finement le seuil entre faux-positifs et faux-négatifs.
Pour la phase d’apprentissage, un expert va déterminer un moyen de transformer l’entrée en vecteur de nombres à partir de caractéristiques (plusieurs pistes ont été données : le nombre de pages ou d’images, la présence et la valeur de la date de dernière modification…), choisir l’algorithme du classifieur puis construire un jeu de données labellisées (malveillant ou bénin ?). Le classifieur qu’ils ont retenu, à base de modèle linéaire, sait découvrir tout seul quelles sont les caractéristiques discriminantes et qui influent, positivement ou négativement, sur le score final et dans quelle mesure (poids).
Afin de valider le modèle, la solution classique consiste à utiliser 90 % du jeu de données labellisées pour entraîner l’algorithme, et en conserver 10 % pour le tester et en valider l’efficacité. Ils ont aussi évoqué les problèmes qui peuvent apparaître quand le modèle est surentraîné sur un jeu de données spécifiques au point d’être peu efficace sur d’autres.
Leur outil SecuML est générique et permet de voir les coefficients découverts lors de l’apprentissage pour chaque caractéristique, les scores calculés pour chaque sur les fichiers de test et les scores de faux-positifs et détection obtenus sur le sous-jeu de contrôle en fonction du seuil retenu.
Article et vidéo : https://www.sstic.org/2017/presentation/le_machine_learning_confront_aux_contraintes_oprationnelles_des_systmes_de_dtection/
NIDS : À la recherche du méchant perdu
Eric Leblond, de Stamus Networks, a effectué une présentation au sujet de l’IDS réseau Suricata auquel il contribue.
Il a participé à un exercice de cyberdéfense organisé par l’OTAN au sein de la yellow team, en charge d’indiquer à la red team (les attaquants) le niveau de discrétion de leurs attaques contre la blue team (les défenseurs). Il a alors eu l’idée de construire un graphe de progression des attaquants dans le système d’information cible à partir des alertes remontées par les IDS. Pour chaque alerte il avait donc besoin de savoir qui était l’attaquant et la cible.
Naïvement il est envisagé que l’adresse IP source d’une alerte correspond à l’attaquant, tandis que l’adresse IP destination correspond à la victime. Cependant, les alertes peuvent aussi venir d’un flux sortant : par exemple, quand un serveur Web retourne beaucoup d’erreurs HTTP 403, l’IP source est celle du serveur, mais l’attaquant correspond à l’IP destination.
L’orateur a donc proposé d’ajouter aux règles des informations pour retourner dans les alertes les valeurs correctes pour la Source et la Target permettant de construire un graphe orienté de relations représentant le chemin de l’attaquant de victime en victime.
L’auteur a implémenté dans Suricata et Prelude les modifications nécessaires, mais il reste maintenant à convertir et enrichir les nombreuses règles de détection existantes.
Diapositives, article et vidéo : https://www.sstic.org/2017/presentation/signature_ids_update/
Deploying TLS 1.3: the great, the good and the bad: Improving the encrypted web, one round-trip at a time
Filippo Valsorda de la société Cloudflare a été invité pour nous présenter la dernière version du protocole de communication chiffrée TLS 1.3.
Il a commencé sa présentation en avertissant que malgré le numéro de version mineur, TLS 1.3 apportait des modifications majeures (« big jump ») contrairement à ses prédécesseurs TLS 1.0, 1.1 et 1.2. Le numéro de version a d’ailleurs donné lieu à de nombreux échanges sur la liste de diffusion du groupe de travail.
Le sujet majeur était celui du nombre de RTT (acronyme générateur de nombreuses blagues sur Twitter) lors des établissements de connexions TLS. Un RTT correspond à un Round-Trip Time, à savoir le temps d’un aller-retour entre le client et le serveur (soit deux paquets). Ces allers-retours, indispensables pour vérifier et négocier les conditions de chiffrement, génèrent une surcharge et de la latence par rapport à une connexion simple en clair et il est donc souhaitable de les minimiser.
En comparaison avec TLS 1.2 qui en nécessitait deux, la dernière version 1.3 ne nécessite plus qu’un RTT pour établir une connexion TLS à partir de zéro. En effet, des messages (Client/Server Hello et Finished) qui étaient auparavant envoyés successivement sont maintenant présents dans les mêmes paquets, faisant gagner plusieurs centaines de millisecondes.
Il a ensuite rappelé que la plupart des établissements de connexions TLS se font de manière plus succincte en réutilisant les paramètres négociés dans un précédent échange selon le mécanisme de Resumption. Au lieu de 1 RTT il est désormais possible de descendre à 0 RTT en concaténant le contenu utile (ex : requête ou réponse HTTP) aux messages d’établissement de connexion TLS.
Au-delà des impacts sur la Foward Secrecy qui ont été pris en compte et gérés, Filipo a expliqué qu’un attaquant serait désormais capable de rejouer un message chiffré capturé, sans avoir besoin de le décrypter, ce qui peut avoir des conséquences sérieuses (imaginons par exemple une requête HTTP qui sert à déclencher un virement bancaire). Les programmes clients sont les mieux placés pour savoir quels sont les messages dangereux en cas de rejeu, c’est-à-dire ceux qui déclenchent des actions. En HTTP par exemple, une requête GET n’est censée servir qu’à récupérer du contenu, sans le modifier (requête dite « idempotent« ), un navigateur pourrait donc utiliser le mécanisme 0-RTT pour celles-ci, cependant cette convention n’est pas respectée par toutes les applications il y a donc un risque. Il a décrit la politique de Cloudflare à ce sujet : accepter les requêtes GET en 0-RTT seulement quand aucun paramètre n’est passé (il ne s’agit que d’une heuristique, imaginons par exemple une requête GET /product/123/delete), ce test étant combiné à une détection du framework utilisé.
Filippo a ensuite décrit dans TLS 1.3 ce qui avait été retiré (RC4, 3DES, MD5, SHA1, AES-CBC, compression, renégociation… annulant les fameuses attaques qui les exploitaient), réduit (beaucoup moins de choix concernant les suites de chiffrement et les courbes elliptiques) et ajouté (signature de l’intégralité de l’échange d’établissement de la connexion et protection contre les downgrades malveillants).
Il a ensuite conclu sur l’état actuel du déploiement, côté client et serveur, en évoquant le cas de certains proxys qui ne supportaient pas bien ce protocole et bloquaient les connexions.
Article de blog qui reprend la présentation : https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
Vidéo : https://www.sstic.org/2017/presentation/2017_invite_2/
Subscribers remote geolocation and tracking using 4G VoLTE enabled Android phone
Olivier Le Moal, Patrick Ventuzelo et Thomas Coudray de la société P1 Security nous ont présenté les défauts de sécurité du nouveau protocole de communication VoLTE déployé par les opérateurs de téléphonie mobile. Ce protocole implémente la Voice over LTE, à la manière de la VoIP mais au-dessus des protocoles de données existants des opérateurs. Ce protocole propose une meilleure qualité du son, un appel plus rapide et la possibilité de téléphoner via des bornes VoWiFi.
VoLTE réutilise les protocoles existants de VoIP : SIP pour la signalisation, SDP pour la négociation des paramètres de codec et RTP pour le flux audio avec des codecs récents adaptés (ex : AMR). Grâce à leur infrastructure de test, constituée de deux téléphones Android rootés et connectés chez deux opérateurs différents, ils ont pu observer (via des captures réseau classiques) les messages échangés et notamment comparer ce qui est envoyé d’un côté puis reçu de l’autre. En effet les opérateurs ont ajouté des équipements dédiés : serveurs et proxys SIP, passerelles pour l’audio…
Les orateurs ont notamment découvert que dans les messages SIP INVITE, il était facile d’usurper le numéro d’appelant (caller ID spoofing) sans que l’opérateur ne l’empêche. Au-delà de la conséquence évidente pour la personne qui reçoit l’appel, ils ont évoqué la possibilité d’injecter de faux appels dans les systèmes judiciaires d’interception et traçabilité. De manière plus anecdotique, les interlocuteurs peuvent échanger des messages en injectant leurs données dans les entêtes SIP, sans traçabilité ni facturation. D’après les orateurs, les fabricants sont au courant et travaillent sur le sujet.
Ils ont également observé que le message « 183 session progress », retourné par le téléphone appelé suite au message INVITE, divulguait de nombreuses informations sensibles dont l’IMEI (qui indique la version exacte du téléphone et facilite donc l’exploitation précise de vulnérabilités le cas échéant, exemple : Stagefright), ainsi que l’identifiant de la borne qui permet de localiser le téléphone. Ces informations peuvent être obtenues gratuitement, et de manière silencieuse pour la victime car l’échange peut être interrompu à ce moment, avant le déclenchement de la sonnerie.
Enfin ils ont conclu en expliquant que, contrairement aux audits télécom classiques dont ils sont coutumiers, l’exploitation de vulnérabilités VoLTE est simplifiée par l’absence de prérequis difficiles d’accès : ici nul besoin d’être physiquement présent dans le réseau de l’opérateur ou d’avoir à sa disposition du matériel spécifique.
DroneJack
Guillaume Fournier, étudiant à CentraleSupélec, nous a présenté le projet DroneJack qu’il a créé avec un autre étudiant, visant à protéger des zones physiques contre le survol par des drones.
Leur solution se différencie de l’existant (brouillage, aigles…) par sa sélectivité et son efficacité sur des nuages de drones. Elle fonctionne contre les drones Wi-Fi en pilotant plusieurs bornes Wi-Fi dans la zone à protéger pour bien la couvrir et permettre des localisations par triangulation.
S’agissant de drones Wi-Fi, les développeurs de DroneJack réutilisent les outils (suite Aircrack) et techniques existantes sur ces réseaux. Les drones utilisant des réseaux protégés sont soumis à des attaques de dé-authentification, et ceux dont le réseau est ouvert sont rejoints par l’outil pour ensuite mener des attaques sur l’interface de pilotage (API) ou sur le système d’exploitation.
L’assistance s’est néanmoins posé plusieurs questions concernant l’efficacité du dispositif, la facilité d’échapper à la détection en changeant l’adresse MAC du drone (certains fabricants ont leurs propres préfixes OUI donc facilement identifiables) et concernant le risque d’attaque contre des réseaux Wi-Fi légitimes. Enfin, la question de la légalité d’une telle attaque sur les drones a également été soulevée mais n’a reçu aucune réponse concrète.
Article et vidéo : https://www.sstic.org/2017/presentation/dronejack/
Ingénierie inverse d’une brosse à dents connectée
Axelle Apvrille, de Fortinet, s’est intéressée à une brosse à dent connectée distribuée par une assurance dentaire américaine. Devant la difficulté de s’en procurer plusieurs exemplaires, elle a exclu le vecteur d’attaque physique (démontage de son unique exemplaire) et s’est donc attaquée aux applications iOS et Android ainsi qu’à la connectivité Bluetooth Low Energy utilisée pour communiquer avec l’application sur le smartphone de l’utilisateur.
Elle a démontré qu’aucun mécanisme de sécurité proposé par Bluetooth LE (authentification et chiffrement) n’avait été activé, rendant facile la communication avec la brosse pour découvrir quelles sont les interfaces et services exposés. En complétant ces informations avec l’analyse des applications mobiles, elle a été capable de créer un script pour requêter des informations de la brosse (sa couleur, la vitesse de rotation du moteur, etc.) et même d’interagir avec (déclenchement du moteur à la vitesse voulue).
Elle a également remarqué que la brosse utilisait toujours la même adresse MAC (au lieu d’utiliser la fonctionnalité LE privacy), et qu’elle émettait en permanence même quand elle était éteinte et pouvait donc servir à tracer une personne qui se déplace avec (par exemple dans sa valise).
Côté serveur, elle a découvert plusieurs vulnérabilités permettant d’accéder aux photos de profil d’autres utilisateurs ou bien de changer son score aux mini-jeux afin de potentiellement tricher pour obtenir des remises sur le coût de l’assurance.
De manière générale, elle a décrit les échanges compliqués qu’elle a eus avec le fabricant, qui semble être la société d’assurance, lors de la notification des vulnérabilités (fermeture de son compte support puis de son compte utilisateur).
Article et vidéo : https://www.sstic.org/2017/presentation/ingnierie_inverse_dune_brosse__dents_connecte/
Conférence de clôture : Retour technique de l’incident de TV5Monde
L’ANSSI est intervenue par l’intermédiaire de deux agents (qui ont souhaité rester anonymes) pour décrire dans le détail l’attaque menée en 2015 contre la chaine de télévision TV5 Monde.
Cette présentation était très intéressante et dense en contenu, nous vous recommandons donc fortement de visionner la vidéo originale ou de lire l’article écrit par le journaliste du Monde, Martin Untersinger (qui était intervenu le jour précédent, voir notre résumé à ce sujet).
Pour un auditeur sécurité, les vulnérabilités exploitées par l’attaquant ne sont pas surprenantes :
- défauts de filtrage : en entrée du réseau depuis Internet, via les interconnexions avec les fournisseurs et diffuseurs de flux, et en interne (« réseau plat ») ;
- mots de passe triviaux ou par défaut ;
- présence de mots de passe dans un wiki interne.
Dans l’ensemble, les auditeurs de l’ANSSI ont noté que le niveau de sécurité était faible, mais dans la moyenne de leur expérience.
Il est intéressant de noter que TV5 Monde faisait appel à plusieurs prestataires informatiques : l’attaquant a ainsi exploité l’accès VPN de l’un d’entre eux pour accéder au réseau interne, puis utilisé les identifiants d’un autre pour passer administrateur du domaine Windows. L’orateur a donc rappelé les risques liés à l’externalisation de l’administration de son système d’information, notamment au niveau de la perte de connaissance et de la difficulté d’intervention en cas d’incident. En effet, une fois l’intervention de réaction sur incident déclenchée, il leur a par exemple été difficile d’obtenir une cartographie précise et à jour du réseau et des systèmes.
Après avoir présenté les premières actions entreprises afin d’arrêter l’attaque, les orateurs ont décrit les étapes de remédiation. Ces étapes comprenaient plusieurs phases d’audits exhaustifs de l’existant (notamment de l’architecture réseau et du domaine Active Directory) puis de reconstruction à chaud du domaine (via des scripts développés spécifiquement pour contrôler la réplication, le tout entrecoupé de pauses pour permettre la réalisation des journaux télévisés sans risque).
Afin de créer un environnement Active Directory cible renforcé, ils se sont inspirés des recommandations d’administration en silo présentées en première journée (établissement d’un modèle de délégation avec trois zones avec des niveaux de criticité différents) :
- rouge pour les contrôleurs de domaine, serveurs de virtualisation (ESX), comptes et postes de travail d’administration, afin de constituer un cœur sain imprenable ;
- jaune pour les serveurs métier et comptes de service ;
- vert pour les utilisateurs simples, les postes de travail, les imprimantes, etc.
Vidéo : https://www.sstic.org/2017/presentation/2017_cloture/
— Clément Notin
Toujours aussi captivant, merci !