Ah, Las Vegas…
Comme chaque année, une délégation de SCRT s’est rendue dans la capitale du jeu pour participer à la conférence Defcon. Cette année toutefois, sept ingénieurs ont pris part à cette expédition :
- Une personne pour assister aux conférences
- Une personne pour participer en tant que conférencier (et au CTF)
- Le reste de l’équipe (6 personnes) pour participer au Capture The Flag
Après un week-end plutôt intense, voici un petit aperçu du CTF tel que nous l’avons vécu.
Capture The Flag
Le challenge Capture The Flag de Defcon est le plus prisé des concours de ce type. Son fonctionnement est un peu différent de concours comme Insomni’hack où il s’agit uniquement de résoudre des énigmes et épreuves techniques. Ici, chaque équipe se voit attribuer un serveur sur lequel plusieurs services sont disponibles. Chaque service renferme un “flag” qui doit être protégé et ce flag change toutes les cinq minutes. Chaque équipe possède les mêmes services et le but du jeu est multiple :
- Garder ses services fonctionnels durant tout le jeu, sous peine de perdre des points si le service ne répond plus
- Analyser les services afin de trouver les vulnérabilités qu’ils contiennent et :
- Corriger ces failles pour que les adversaires volent plus vos flags sinon, perte de points.
- Exploiter la vulnérabilité chez les adversaires afin de voler leurs flags, et ainsi gagner des points.
Comme on peut le voir, la tâche n’est pas de tout repos, et l’action est permanente, ne laissant que peu de répit à toute l’équipe.
Qualifications
Nous avons obtenu notre place en finale de justesse après avoir terminé en dix-septième place aux qualifications qui ont eu lieu un peu plus tôt dans l’année. Cette place nous a permis de nous retrouver parmi les vingt équipes qualifiées.
Une fois dans la salle, un bloc de tables était attribué à chaque équipe. Un unique câble permettait de se connecter au réseau du jeu, qui nous a permis de nous connecter à notre serveur. Cette année, le serveur fonctionnait sur une carte ODROID U3 (processeur ARM) avec une distribution Ubuntu. Les organisateurs ont laissé une heure aux équipes pour mettre en place leur stratégie avant d’ouvrir le réseau, et ainsi commencer les hostilités.
Epreuves
En début de jeu, seuls deux services étaient proposés aux équipes, puis les organisateurs ont progressivement ajouté de nouveaux services, augmentant le nombre de paramètres à prendre en compte au cours du jeu.
Une épreuve très originale se présentait sous cette forme :
Ce badge fonctionne avec un FPGA et possède un émetteur/récepteur radio. Il permet d’envoyer et de recevoir des messages aux autres équipes. Le processeur utilisé est un MSP430 modifié et une version du firmware est accessible pour analyse.
Au final, cinq services étaient disponibles. Certains d’entre eux ont été mis à jour plusieurs fois au cours du jeu, mais restaient sensiblement identiques tout en retirant on introduisant de nouvelles vulnérabilités.
La plupart des services étaient des binaires ARM – dynamique et statique – vulnérables à des corruptions mémoire, en particulier buffer overflows et Use-After-Free. Cette année nous retrouvions les services suivants:
- Un jeu de space trading (binaire x86 lancé par qemu)
- Un serveur Web
- Un serveur imap
- Un protocole binaire inventé par les organisateurs
Attaque
Comme les équipes n’ont pas d’accès root sur les serveurs de jeu, il n’y a pas de possibilité d’analyser le trafic réseau entrant. Les organisateurs ont bien entendu prévu une solution à ce problème et proposaient de télécharger le trafic réseau des cinq dernières minutes de jeu, et ce pour chaque équipe.
Une tactique de jeu que nous avons utilisé consistait à analyser le trafic réseau d’une attaque réussie, de récupérer l’exploit d’une autre équipe et ainsi de gagner du temps sur l’exploitation d’une vulnérabilité.
Toutefois il n’est pas possible de se contenter d’analyser et de rejouer les attaques des autres équipes: plusieurs vulnérabilités ne sont pas immédiatement rejouables et nécessitent une bonne compréhension du binaire affecté et du chemin d’exécution menant à la vulnérabilité. Il est donc nécessaire de consacrer beaucoup de resources sur le reverse-engineering des binaires afin de comprendre leur fonctionnement, trouver des vulnérabilités, les patcher puis les exploiter.
Défense
Le maintien du serveur est également une tâche difficile tant les attaques sont nombreuses et leur suivi difficile. Le maintien des services opérationnels est important puisqu’il influe directement sur le score. Dès lors, de nombreux scripts et outils d’analyse ont été mis en place pour que nous ayons un suivi presque continu sur de nombreux éléments du système, comme par exemple :
- les fichiers créés par les services
- les modifications des services en eux-même
- la limitation du temps d’exécution des services
Au cours du jeu, certaines failles ont permis aux équipes d’obtenir un shell sur les serveurs adverses. Dès lors, une partie du travail du sysadmin consiste a constamment surveiller les processus du serveur et de tuer les processus non désirables en attendant un patch de la vulnérabilité exploitée. Tâche rendue compliquée par la créativité de nos adversaires pour maintenir un accès à notre serveur. A titre d’exemple, nos scripts ont tué environ 1338 processus /bin/sh sur la journée de dimanche…
Conférence – “Playing with car firmware… or how to brick your car”
Cette année (et pour la deuxième année consécutive), nous avons également eu la chance d’être sélectionnés pour présenter un sujet lors de cette 22ème édition de Defcon.
De nos jours, les voitures ne sont plus purement mécaniques. Les véhicules actuels contiennent tous de nombreux composants électroniques (ECU) reliés entre eux grâce à un réseau (CAN BUS).
Les communications sur le réseau CAN Bus sont d’ailleurs quelque chose de normalisé grâce aux standards ISO-TP ou ISO 15765-2.
Ces différents ECU surveillent et contrôlent en permanence l’état du véhicule.
Plusieurs travaux de recherche ont d’ailleurs été présentés lors de la dernière édition de Defcon, on retiendra entre autres la démonstration assez impressionnante de Charlie Miller & Chris Valasek. Pour rappel, leurs recherches portaient sur les modèles Ford Escape (2010) et Toyota Prius (2010) et ils ont notamment expliqué comment ils avaient réussi à prendre le contrôle de la direction, de l’accélération, du freinage et d’autres fonctions importantes de ces véhicules. Les chercheurs ont même trouvé un moyen de réaliser des attaques persistantes en modifiant le firmware de l’ECU pour envoyer de mauvais signaux, même quand ils n’étaient plus physiquement connectés aux unités de contrôle.
La plupart des recherches faites jusqu’à présent ont principalement porté sur les interactions possibles avec les différents ECU du véhicule au travers du réseau CAN Bus et plus particulièrement au travers de la prise OBD2.
Je n’ai trouvé que peu de publications concernant les systèmes multimédia qui équipent la plupart des véhicules récents. Ces équipements se matérialisent généralement au travers d’un écran permettant de contrôler le GPS et diverses fonctionnalités du véhicule : Bluetooth, lecteur musique/MP3, lecteurs vidéo, carnet d’adresse, GPS.. mais aussi : climatisation, éclairage, verrouillage centralisé, position des sièges pour ne citer que quelques exemples…
Comme on peut s’en rendre compte ces équipements ont une interaction assez importante avec le véhicule et peuvent contrôler bien plus de choses que le simple volume de la musique.
Il semblerait même que certaines options du véhicule (wifi à bord, télévision…) soient présentes « par défaut » sur tous les véhicules équipés du GPS et qu’il s’agisse juste d’une activation électronique.
….c’est donc le fruit de mes recherches sur ce thème que j’ai eu la chance de présenter pour Defcon.
Utilisateurs codés en dur dans le véhicule, mots de passe “par défaut”, SSID, ranges IP internes du constructeur…. il semblerait bien que l’industrie automobile aient encore quelques progrès à faire dans le domaine de la sécurité…
Ce fut un véritable plaisir de présenter ce sujet à un salle enthousiaste … et, il faut l’avouer, assez impressionnante (tant par sa taille, que par les personnes qui étaient présentes)
Les slides de ma conférences seront très prochainement disponibles sur le site de la defcon (en attendant, si vous demandez gentiment, c’est avec plaisir que nous vous les fournirons)
Conclusions
Le CTF fut une vraie réussite, tant sur le système de jeu que sur l’organisation et le niveau très élevé de la compétition.
Defcon reste une “immense” conférence avec les avantages et les inconvénients que cela représente…. il faut être motivés pour faire la queue partout (pour obtenir son badge, pour essayer d’accéder aux salles des conférences, pour manger…) mais c’est une occasion unique de croiser et cotoyer de nombreux passionnés et professionnels de la sécurité informatique.
Nicolas,Paul, Adrien, Michael, Alain,Florian,Karim