Liens vers les comptes-rendus des autres jours :
A first glance at the U2F protocol (Florian Maury et Mickaël Bergem)
La présentation vise à comparer le protocole U2F avec les autres solutions à double facteur et d’en tirer les avantages/inconvénients.
U2F est un protocole d’authentification forte (2 facteurs) visant à répondre aux problèmes posés par l’authentification avec des identifiants faibles, mais aussi des attaques de type phishing avec rejeu dans les protocoles à deux facteurs utilisant un SMS comme second facteur.
Spécifié par l’alliance FIDO, son point fort est la simplicité d’utilisation. En effet, une simple clef USB permet d’utiliser le token (créé grâce à de la cryptographie asymétrique) pour l’authentification, ceci avec une action minime de l’utilisateur (ce dernier n’a qu’à appuyer sur une touche).
Bien que ce protocole apporte de nombreuses mesures de sécurité à faible coût pour l’utilisateur, il n’est que très peu déployé aujourd’hui. De plus, il n’est pas parfait (il reste sensible aux attaques de type SLOTH).
How to not break LTE crypto (Benoit Michau et Christophe Devine)
La présentation s’intéresse aux vulnérabilités au sein des modems cellulaires et des contournements de procédures de sécurité LTE. Pour évaluer les implémentations de la norme LTE au sein de différents équipements (incluant des modems Qualcom, Mediatek et Samsung), une infrastructure composée d’une antenne-relai (Ettus USRP et Amarisoft eNodeB), d’un cœur de réseau en Python (corenet) et de plusieurs smartphones sous Android a été construite.
Après quelques rappels sur la cinématique d’une connexion LTE (identification, envoi des capacités de connexion, authentification mutuelle avec le cœur de réseau en utilisant un secret présent dans la carte SIM, établissement d’un canal sécurisé via le protocole NAS puis via RRC), des exemples de vulnérabilités sont fournis :
- Un modem testé accepte un contrôle d’intégrité nul (EIA0-RRC). Cette configuration permet de faire de l’interception de données lors des reconnexions du mobile sur une fausse antenne relais (établissement d’un nouveau canal RRC sans chiffrement et sans contrôle d’intégrité);
- Certains modems peuvent transmettre d’autres informations que leur IMSI/TMSI alors que le protocole NAS n’est pas activé.
Des vulnérabilités ont été identifiées dans l’ensemble des modems testés. Si les fabricants peuvent corriger rapidement les vulnérabilités, le déploiement des correctifs jusqu’aux abonnés reste laborieux : mise à disposition des patchs aux fabricants des mobiles, puis distribution aux opérateurs mobiles… L’orateur conclut en indiquant que la transparence des différents constructeurs est insuffisante.
Méthodologie d’extraction de signatures issues des signaux AIS (Erwan Alincourt et Pierre-Michel Ricordel)
Cette conférence s’intéresse à AIS (Automatic Identification System) : système radio de balises de localisation pour les bateaux. Ce système a été construit dans les années 2000 sans aucune préoccupation de sécurité.
Après un rappel sur les différents types de transpondeurs (navires commerciaux, de plaisance, récepteurs simples, balises de détresse…), les orateurs présentent des utilisations détournées possibles d’AIS : falsifications d’identité, falsifications de position, coupures volontaires du système, détournement des capacités d’administration (par ex. pour modifier une fréquence d’utilisation à distance d’un transpondeur à l’insu de l’utilisateur et conduire à un déni de service), injection de données falsifiée (appels au secours, ajout arbitraire de bateaux…), etc.
La plateforme utilisée pour les tests utilise du matériel abordable et grand public. De plus, les spécifications du protocole sont publiques. Partant du principe que la couche logique ne peut apporter aucune garantie de sécurité, les orateurs se sont intéressés à la couche physique pour tenter de détecter des anomalies (fausses positions envoyées, usurpations d’identité…). Deux caractéristiques peuvent notamment être utilisées :
- La puissance du signal peut être confrontée à la distance présumée du bateau
- La forme des signaux radio d’un émetteur AIS peut être analysée et comparée aux signaux précédemment reçus
Comparaisons et attaques sur le protocole HTTP2 (Georges Bossert)
Georges Bossert nous a présenté un état de l’art du protocole HTTP 2.0. Son prédécesseur, le protocole SPDY développé par Google a été déployé sur quelques sites à partir de 2009. Le principal objectif de SPDY est de réduire significativement la latence lors d’une navigation web. Pour y parvenir, plusieurs fonctionnalités ont été mises en place :
- Nombre illimité de flux concurrents sur une connexion TCP
- Priorisation des requêtes
- Compression des en-têtes
- Le client n’est pas systématiquement l’initiateur lors de l’échange de données (machine à état stateful)
En novembre 2012, le protocole HTTP 2.0 fait son apparition et apporte quelques améliorations par rapport à SPDY :
- Le SSL n’est pas obligatoire pour pouvoir l’utiliser (SPDY nécessite un flux authentifié)
- L’algorithme de compression est plus rapide
- La priorisation est mieux gérée
A l’heure actuelle, la plupart des sites absorbant un gros trafic utilisent la version 2.0 de HTTP (Google, Facebook, Twitter,…). Concernant les navigateurs, une mise à jour est nécessaire pour utiliser ce nouveau protocole. Mais s’il a été mis à jour il y a moins de 3 ans, la compatibilité est assurée. Enfin, les serveurs disposent aussi d’une version compatible HTTP 2.0.
Même si l’implémentation théorique se doit d’être identique pour chaque serveur web, des différences peuvent être constatées en pratique. Ces différences peuvent être exploitées pour identifier le serveur distant. A titre d’exemple, les quatre principaux serveurs web (Apache, Nginx, H20 et Tomcat) peuvent être fingerprintés en quelques requêtes.
Évolution des techniques d’attaques de circuits intégrés (Olivier Thomas)
Les puces sont aujourd’hui partout : dans les cartes bleues, dans les titres de transport, dans des clés de voiture, dans les passeports, dans des pacemakers… L’orateur présente les trois grands types d’attaques que l’on peut mener sur ces puces :
- Attaques non-invasives : il s’agit de tester une puce en utilisant tout ce qui l’entoure (bus, alimentation, horloge…)
- Attaques semi-invasives : la puce peut être ouverte et analysée, mais ne peut pas être modifiée physiquement (injection de fautes avec des lasers, attaques électromagnétiques)
- Attaques invasives : La « Rolls-Royce » selon l’orateur, car tout est permis (modification physique de la puce notamment)
Après quelques rappels sur les circuits imprimés, les transistors, les attaques « Side Channel » et les attaques optiques, l’orateur focalise sa présentation sur les attaques invasives, attaques qui – selon l’orateur – sont possibles sur l’ensemble des puces du marché. La première étape est le « deprocessing » de la puce, processus complexe durant lequel des images de chaque couche de la puce sont réalisées (par ex. via des processus chimiques/physiques ou en utilisant du plasma). Ensuite, les images de chaque couche peuvent être analysées : lecture de la ROM, de la mémoire Flash, reconstitution des portes logiques de la puce.
A la question « Où en êtes-vous vis-à-vis des puces récentes ? », l’orateur répond « on est très proche » et « on en parlera éventuellement en privé ».
App vs Wild (Stéphane Duverger)
Parfois un système se doit d’être opérationnel même si il s’exécute dans un environnement hostile (noyau malveillant suite à une compromission par exemple). Afin d’adresser cette problématique, Stéphane Duverger nous a présenté un outil développé par ses soins.
Les contraintes sont les suivantes :
- L’environnement dans lequel s’exécute l’application est non-maintenu et vérolé
- Aucune modification ne doit être effectuée sur l’application
- Aucune connaissance de l’OS n’est nécessaire (l’outil doit fonctionner sur la plupart des architectures)
Le but est de garantir l’intégrité et la confidentialité du code de l’application. Les données ne sont pas ici considérées comme sensibles.
La solution proposée réside dans la virtualisation. Un micro-hyperviseur de type bare-metal (ramooflax) héberge le système d’exploitation qui exécutera l’application à protéger. Le principe est d’utiliser une suite d’applications chiffrées, qui seront déchiffrées à la volée par l’hyperviseur et allouées dans des zones mémoires cloisonnées.
Toutefois, un binaire polymorphique (un code modifiant ses instructions à la volée) ou lancé par un JIT-Compiler ne peuvent pas être utilisés ici.
Winbagility : Débogage furtif et introspection de machine virtuelle (Nicolas Couffin)
L’analyse dynamique d’un code s’exécutant en mode noyau (drivers) nécessite la mise en place d’un environnement adapté. En effet, le driver s’exécute dans une machine virtuelle qui est contrôlée par un debugger présent sur la machine hôte. Cependant, cette méthode a plusieurs inconvénients :
- Elle modifie le comportement du système cible (démarrage en mode /DEBUG)
- Elle peut provoquer un échec lors de la vérification d’intégrité de code
- Elle peut générer des BSOD si la protection PatchGuard est activée
L’objectif est ici d’analyser un code de manière dynamique avec PatchGuard activé et sans modifier le système cible. Pour y parvenir, le debuggeur sera attaché un niveau en dessous, c’est-à-dire à l’hyperviseur. Des HyperBreakoints ont été développés pour l’occasion afin de mettre en pause l’hyperviseur. Les détails de l’implémentation sont expliqués plus en détail dans les slides.
Au niveau des performances, l’exécution des instructions en mode debug est suffisamment rapide pour que cette méthode soit une solide alternative à l’analyse traditionnelle.
Déverrouillage d’Android en simulant un clavier/souris (Antoine Cervoise)
Aujourd’hui, les attaques pour déverrouiller un Android sont nombreuses, notamment sur les anciennes versions du système. La présentation se concentre sur les façons de déverrouiller le téléphone en utilisant une solution peu coûteuse connectée sur le port USB OTG (qui permet de brancher un clavier ou une souris).
La solution (à base d’Arduino, et de Rasberry PI) utilise une attaque de type force brute sur l’authentification (code PIN, schéma, mot de passe).
En conclusion, cette présentation présente une façon peu chère et automatisée pour déverrouiller un Android sans attaquer le téléphone physiquement et sans implémenter d’attaques complexes.
The Metabrik Platform: Rapid Development of Reusable Security Tools (Patrice Auffret)
Metabrik est une plateforme permettant le développement rapide d’outils. Reposant sur un shell de type UNIX, un langage (basé sur du PERL), et plus de 200 « briks ».
Ces « briks » regroupent un ensemble de fonctionnalités, parfois se reposant sur les outils standards qui sont des références dans leurs domaines, auxquels on peut ajouter des fonctionnalités manquantes.
Le but de cette plateforme est de centraliser les scripts (afin de les réutiliser), d’automatiser tout en lignes de commandes et de rendre une syntaxe normalisée qui rend la compréhension plus rapide, mais aussi plus facilement mémorisable.
DYODE : Do Your Own DiodE, Une diode open source à moins de 200€ pour réseaux industriels (Arnaud SOULLIE et Ary Kokos)
Le but de cette présentation est de montrer qu’il est possible de fabriquer une diode réseau pour un prix abordable. Pour rappel, une diode réseau est une passerelle qui autorise l’acheminement d’informations uniquement dans un sens. Cette propriété de sécurité est assurée physiquement par l’utilisation de convertisseurs cuivre-optique et le branchement d’un seul (sur deux) câbles optiques TX -> RX. L’utilisation du protocole TCP n’est donc pas possible à travers une diode, seul le protocole UDP permettant un transfert de données à sens unique.
Ce projet a été pensé suite à divers retours d’industriels : le prix de cet équipement peut rebuter un grand nombre de sociétés. Pour un prix aux alentours de 200 €, le projet DYODE permet de créer un canal unidirectionnel et propose à l’heure actuelle trois fonctionnalités :
- Transfert de fichiers plats
- Transfert de données Modbus
- Partage d’écran sans interaction
Plusieurs limitations sont cependant présentes, une vitesse de transfert faible (quelques Mo/s) et une haute disponibilité non garantie (utilisation de composants non durcis.)
Rumps
Pour finir en beauté cette journée, on termine sur les fameux « Rumps » qui font la force du SSTIC. Dans le désordre, on trouvera par exemple :
- Pourquoi l’image sur le vidéoprojecteur est floue dans l’amphithéâtre
- Quelques chiffres et anecdotes sur la billetterie
- Des hacks Twitter pour gagner des super cadeaux ou des followers
- Un bruteforce sur des UID Mifare avec un Proxmark pour tromper les distributeurs de bière de certains bars
- Un nouvel exemple d’attaque sur un disque dur chiffré
- La création d’un script permettant d’ajouter l’ensemble des antivirus du marché à la table WMI « AntiVirusProduct » de Windows (sans les installer) et des conséquences : certains codes malveillants ne se lancent plus
Comme chaque année, la journée se termine par le fameux Social Event qui s’est déroulé à la Halle Martenot de Rennes. On notera pour cette itération la badgeuse qui « insulte » aléatoirement les participants lors des entrées/sorties et un important dispositif de CRS sur la place (événements extérieurs à la conférence).
