SSTIC 2017 - J3
(edit: wrap-up J3 en anglais sur le blog de @xme)
Réutilisez vos scripts d’audit avec PacketWeaver — Florian Maury,Sébastien Mainand
cpu_rec.py, un outil statistique pour la reconnaissance d’architectures binaires exotiques — Louis Granboulan
On peut enrichir la reconnaissance d’architectures en ajoutant des blobs binaires dans le corpus de référence.
Le Machine Learning confronté aux contraintes opérationnelles des systèmes de détection — Anaël Bonneton,Antoine Husson
Le machine learning est souvent vendu comme une solution miracle par les fabricants de solutions de sécurité, et pour les experts sécurité, c’est souvent du bullshit. L’objectif des orateurs et de démontrer qu’utilisé intelligemment, le machine-learning peut être utile. Pour l’apprentissage, il faut un gros corpus labélisé gentil/méchant fabriqué par des experts pour le donner en entrée à un algo d’apprentissage qui va générer un classificateur capable de discriminer entre goodware et badware.
Le classificateur peut être tuné pour régler un seuil de détection.
Pour que le ML fonctionne, il faut transformer les fichiers à analyser en un vecteur de features numérique, et à partir de ce vecteur, l’algorithme d’apprentissage va générer le classificateur.
Bon, c’est pas le tout d’avoir un jeu de donnés bien labellisé (humour !), il faut aussi qu’il soit représentatif du trafic ou des fichiers à analyser, sinon on se retrouve avec un biais d’apprentissage, et le modèle appris n’est pas adapté à la réalité.
NIDS : À la recherche du méchant perdu — Eric Leblond
Suricata est un IDS sous licence GPL dont le code appartiens à une fondation: l’OISF. Invité à un exercice OTAN, l’orateur était dans une Yellow Team chargée de prévenir la Red Team de leur détection ou non. Du coup pour visualiser la détection de la propagation des attaquants il a associé la localisation des alertes avec l’architecture du réseau. Suricata produit des alertes format JSON prêt à mâcher. L’IDS remonte parfois beaucoup trop d’alertes, et difficile alors de mapper les alertes à la topologie réseau. On se retrouve avec un nuage de bouts de graph non-orientés pas très lisible. Du coup l’orateur à corrigé la sortie JSON de Suricata pour pouvoir dire dans la signature si la source ou la destination est la cible de l’attaque, permettatn de reconstruire des graphs orientés à partir des alertes.
Deploying TLS 1.3: the great, the good and the bad: Improving the encrypted web, one round-trip at a time — Filippo Valsorda
TLS est présent partout, et sécurise nos échanges entre serveur web & navigateur, serveurs mails, etc… L’orateur nous fait un rappel sur le fonctionnement de TLS 1.2. TLS 1.2 nécessite 4 échanges entre le client et le serveur pour établir la clef de session, et du coup ça bouffe pas mal de data sur les réseaux mobiles. TLS 1.3 représente un grand bond en avant sur le protocole. L’établissement de la session se fait en 2 échanges, réponse HTTP inclue. La communication deviens immédiatement chiffrée après le server hello. Bon, bien sûr, le client doit deviner quel algorithme crypto va être accepté par le serveur, si jamais ça rate, le client doit refaire la négociation. TLS 1.3 supporte la reprise du contexte cryptographique pour économiser la négociation de clef de session. Le problème avec ce système, c’est que ça pête la forward secrecy (Confidentialité persistante). Du coup si la clefs est compromise plus tard, on peut péter tout l’historique des com. 0-RTT est une autre optimisation du temps de réponse, mais pour fonctionner, il repose sur une clefs pré-partagée. Du coup, pour assurer une nouvelle forward-secrecy dans TLS 1.3, une nouvelle clefs est balancée par le serveur dans sa réponse pour les échanges suivants. Comment faire quand le client doit envoyer de la data avec le server hello, comme dans le cadre d’un POST. Pour ce faire, le serveur web attend l’établissement du hello et du secure channel avant de calculer la réponse du POST. Du coup, pour éviter tout merdoiement avec 0-RTT, il faut que l’API fournisse ce qu’il faut pour que le client puisse décider quand envoyer des données avec le hello ou pas. Du coup la sécurité dépend de la bonne utilisation du 0-RTT par l’application.
Petit soucis avec les requêtes GET qui peuvent foirer à la transmission avec 0-RTT, reçue par le serveur, mais dont le client n’a pas reçu la confirmation parce-qu’il à subit une déconnexion. Du coup c’est galère pour les Reverse-proxy comme chez cloudflare, ou il faut mettre de coté les informations jusqu’a la re-connexion TLS de l’utilisateur. Du coup c’est galère pour les API dont les réponses à des requêtes GET changent à chaque fois.
Il y a eu des échanges très houleux ou certains fournisseurs de solutions de sécurité voulaient des mécanismes de déchiffrement « out of bound » (comprendre hors-ligne ou après-coup) des sessions TLS, ce qui est juste une attaque directe de la sécurité de TLS. Et coté protocoles de sécurité: il a fallu dégager de TLS 1.3 toute les features à problème, et algo crypto pourris qui ont généré une palanquée de vulnérabilités ces dernières années.
Pour éviter les attaques par downgrade, le serveur doit explicitement dire dans son message de réponse DOWNGRD, message signé par sa clef privée, et indiquant qu’il faut causer TLS 1.2.
Pour améliorer la sécurité du protocole TLS, l’ensemble de la spec du protocole à été créé de façon à être prouvable afin d’éviter des erreurs dans le design du protocole. Une lecture suggérée par l’orateur sur l’impact des interceptions https sur la sécurité.
Subscribers remote geolocation and tracking using 4G VoLTE enabled Android phone — Olivier Le Moal,Patrick Ventuzelo,Thomas Coudray
Le protocole VoLTE est un proto permettant de passer des communications voix sur le carrier data du réseau téléphonique mobile. Le réseau mobile est découpé en 3 zones, la partie accès radio, la partie GSM pour gérer la voix en 2G/3G, et la partie data 3G/4G autrement appellé LTE (long term evolution). Donc si l’appel fait 4G VoLTE vers 2G/3G c’est du « VoLTE to Legacy », sinon c’est du VoLTE de bout en bout. L’avantage de VoLTE c’est d’éviter au téléphone de basculer vers la 3G pour le coup de fil et donc de dégrader la bande passante radio disponible. Pour faire de la VoLSTE, il faut un OS compatible, avec le baseband qui va bien, et l’opérateur avec l’infra adaptée. Sous Android, faut faire une config custom pour pouvoir jouer avec la VoLTE. Du coup avec un téléphone rooté, on peut voir deux interfaces de com réseau, une pour la data, et une pour la VoLTE.
La communication voix se base sur du signaling façon SIP, et du SDT pour les éléments de config des codec voix & vidéo. Du coup on peut faire plein de conneries avec ces protocoles, genre spoofer le caller-id. Quand on regarde les échanges entre deux téléphones sur deux opérateurs différents, on constate des différences entre les headers envoyés par l’un et reçu par l’autre. Du coup on peut se demander ce que fout la gateway IMS au milieu… Du coup les orateurs ont joué avec les headers, nottament en ajoutant un header custom, ou en manipant le header user-agent des téléphones. Du coup c’est envisageable de se faire un chat avec des INVITE qui ne sont que des initation d’appels non-facturés. Dans d’autres headers VoLTE, le téléphone leak son IMEI qui associé au user-agent permet d’identifier précisément le hardware associé. Autre info leaké dans les headers: les identifiants des bornes auquel le téléphone est appairé, ce qui permet de géolocaliser silencieusement le téléphone.
DroneJack: Kiss your drones goodbye ! — Guillaume Fournier,Pascal Cotret,Paul Audren De Kerdrel,Valérie Viet Triem Tong
DroneJack est un projet de protection de zone contre les drones Wifi. Les principales solutions existantes concistent à identifier et localiser les drones, brouiller les drones, utiliser des aigles pour les intercepter, Sniper en electromag le drone… DroneJack se base de l’idée de skyjack en considérant que le drone est un AP wifi volant. L’objectif du projet est de protéger une zone contre une nuée de drones et ça en continu, sans interrompre la détection.
DroneJack est une infra d’attaque de drone wifi entièrement customisable. Pour détecter le drone, l’@mac et quelques carractéristiques wifi permettent un fingerprinting passif. Avec des raspy disposés un peu partout sur la zone protégée, on peut trianguler la position du drone en fonction de la puissance du signal. Pour bloquer le drone, on peut le de-auth à coup de paquets de de-synchro. Si le wifi n’est pas chiffré ou cassable, on peut faire un take-over sur le drone, lui envoyer des ordres de retour à la maison, d’arrêt d’urgence. On peut aussi récupérer les donnés vidéo & GPS du drone. Certains drones embarquent une interface Web qui permet le pilotage du drone. Si on peut récupérer les coordonnées GPS de décollage du drone on peut aller ceuillir le pilote attendra son bien.
Ingénierie inverse d’une brosse à dents connectée — Axelle Apvrille
L’oratrice travaille chez fortinet, et analyse des malwares pour smartphones & objets connectés. Pourquoi une brosse à dent: parceque c’est drôle, et difficile à reverser. Il s’agit d’une brosse à dent fournie par une assurance dentaire et associée à un jeu vidéo sur smartphone pour inciter les gens à se brosser les dents. Plus on se brosse les dents, plus on marque de points sur l’appli. Ne pouvant se procurer une 2nde brosse, il n’a pas été possible à l’oratrice d’en faire la rétro hardware. Elle à donc procédé à l’analyse à partir du code source de l’application et d’un dongle bluetooth low energy.
Pour causer à la brosse, il faut trouver son addresse, en suite il faut se baser sur des captures réseau pour identifier les commands qu’on peut envoyer à la télécomande. Le code de l’appli mobile aide beaucoup à comprendre les fonctionnalités & paquets associés.
L’oratrice à donc tout claqué dans un script python permettant d’usurper l’application mobile et de contrôler là brosse à dent. Inversement on peut usurper la brosse à dent via un dongle BLE et envoyer de fausses informations à l’application.
Il n’y a aucun mécanisme d’authentification, tout passe en clair, Le seul évènement chiffré c’est le temps de brossage… avec une clef en dur dans l’appli mobile. (probablement « protégé » pour éviter la fraude au brossage…). Autre chose: le profil de l’utilisateur, son score, etc… sont stocké sur les serveurs de l’assurance dentaire. Après avoir trouvé une vulnérabilité qui semblerais critique, l’assureur à fermé le compte de test. L’intérêt d’une telle attaque, c’est que plus vous vous brossez les dents, moins cher vous payez votre assurance. Autre problème, la BDD des utilisateurs n’était pas protégée. Maintenant faut avoir une brosse à dent pour y accéder…
Conférence de clôture : Retour technique de l’incident de TV5Monde — ANSSI
Rare sont les victimes d’un incident de sécurité qui ne veulent pas en témoigner. TV5 à le mérite d’en parler, ce n’est pas le cas de tout le monde.
TV5 Monde avait cessé la diffusion de ses 20 chaines thématiques dans le monde, ainsi que le deface de leur chaine twitter, facebook, et la perte d’accès aux mails. Des commandes d’effacement de firmware d’équipements de production ont été lancé volontairement par les attaquant pour démolir l’appareil de production. Dans les premières 48h, il a fallu établir une liste de points de contacts techniques pour réparer le SI. Il a fallu réfléchir à la collecte de traces, et la recherche de bombes logiques laissés par l’attaquant. Les auditeurs ANSSI ont apporté une vision technique du SI parfois meilleure que la victime. Les auditeurs ont rapidement identifié un compte rajouté à l’AD avec des connections RDP associés. Ils ont retrouvé un « connectback.dll » lancé par rundll32 avec en paramètres une ip et un port. L’ouverture de TV5 monde et son soutien aux investigateurs numériques à facilité leur travail et a grandement amélioré la qualité de leur collecte.
Les objectifs lors de l’analyse & remédiation sont différents pour chaque partenaire, en fonction de ses centres d’intérêt. Dans la chronologie on retrouve les classique d’une APT excepté le sabotage qui lui est plutôt rare. L’attaquant à pris pied sur un serveur de collecte de contenu multi-média, outil de travail essentiel des journalistes. Un compte par défaut sur le serveur à permis sa prise de contrôle. Cette machine n’a servi à rien à l’attaquant, puisque cette machine n’était pas interconnecté numériquement avec l’infra de TV5.
L’attaquant à en suite utilisé un vpn d’admin d’un sous-traitant pour se connecter à TV5. Il a en suite pu découvrir des serveurs contrôlant les caméras. Il a en suite utilisé un autre compte d’un autre prestataire pour créer un compte admin sur l’AD. Sur la messagerie et le Wiki interne, l’attaquant va récupérer de la documentation sur le fonctionnement du SI avec des comptes associés et le fonctionnement du matériel. En suite l’attaquant prépare des machines de rebond avec des outils d’attaques dont un RAT jamais utilisé pour créé une fausse piste. Ses machines sont en suite équipés d’un programme de « connect-back » pour se passer du VPN. Le facebook et le site web se font défacer, puis l’attaquant va rentrer des commandes pour mettre en carafe les switchs et les routeurs.
Dernière action de l’attaquant: la suppression de la vm de messagerie sur leur serveur de virtualisation. TV5 réagis à la compromission en coupant l’accès à internet de la chaîne.
En parallèle de l’analyse forensic, il a fallu que les auditeurs identifient l’ensemble de l’infra de la victime, avec les éventuels connexions internet sauvages, puis mettre au point une solution temporaire pour permettre aux journalistes de travailler en mode dégrader. S’assurer qu’il ne restait pas de bombes logiques résiduelles. La découverte du métier de la victime fut riche et impressionnante pour les auditeurs. Il fallait aller vite pour cartographier les applications dépendantes de l’AD et l’impact de sa refonte sur le fonctionnement du SI. Autre difficultés, les auditeurs était devenus l’attraction des journalistes qui cherchaient à obtenir un maximum d’informations sur ce qui se passait forçant les auditeurs à se cacher des caméras.
Pour permettre aux journalistes de travailler, les auditeurs ont mis en place des sas et une bulle filtrée sans clef usb, avec des SAS de transfert pour alimenter les filers en vidéos neuves. Les conditions de travail sont devenus très très dures, des vacances ont été annulés, les victimes se sont senties traumatisés et craignaient un retour des attaquant.
La cartographie réseau est un moyen d’appui à l’audit garantissant son exhaustivité. L’externalisation implique une perte de connaissance qui a rendu problématique la réponse sur incident. Lors d’un incident de sécurité, les prestataires prendrons des décisions pour continuer leur prestation et non pour la sécurité du client. La connaissance du SI est clef pour une bonne défense et une bonne remédiation.
Collecter les journaux, les augmenter, mettre en place des séquestres. Comprendre le réseau, ses constituants, et mettre en oeuvre une stratégie de cloisonnement et de filtrage pour assurer une diffusion sûre. Les auditeurs ont découvert une connexion internet sauvage avec un pare-feu alternatif permettant à l’infogérence de venir réparer une éventuelle boulette sur le vpn principal. Associé à ça, un ensemble de comptes d’administration du prestataire avec des accès privilégiés au réseau du client/victime.
Une fois la stratégie de remédiation établie, on migre progressivement les postes sur AD tout neuf, avec un cloisonnement adapté, jusqu’à isoler totalement l’infra de production vidéo. La petite taille de TV5 Monde à facilité la mise en oeuvre de cette stratégie, ce n’est pas forcément aussi évident sur de plus grosses structures. La sécurisation d’un AD, ça nécessite de bien comprendre un sacré paquet de notions de fonctionnement, ça ne s’improvise pas, et si c’est mal fait ça peut laisser des trous de sécurité béants.
S’en suit une stratégie de durcissement que je vous invite à regarder sur la vidéo bientôt mise à disposition sur le site du SSTIC.
