Depuis l’année dernière, mon université organise chaque année un Capture-the-Flag, et cette fois-ci, je fais partie des organisateurs de l’événement.

Dans un CTF, nous simulons un réseau volontairement vulnérable que l’on pourrait trouver dans une entreprise ou à la maison.
Les joueurs doivent rechercher et aller aussi loin que possible pour trouver des fragments de texte appelés « flags » qui rapportent tous des points. L’équipe qui a le plus de points à la fin gagne.

J’ai participé à l’édition précédente, qui était plutôt sympa, mais qui souffrait de quelques problèmes : le parcours était très linéaire, donc être bloqué à un moment donné signifiait un arrêt total de la progression jusqu’à ce que le problème soit résolu. Nous avons bien commencé l’événement et étions en tête, mais nous sommes restés bloqués sur un drapeau concernant le base64 imbriqué. Nous avons compris ce qu’il fallait faire avec le base64, mais nous n’avons pas compris qu’une des étapes était le drapeau lui-même. Toutes les autres équipes ont reçu des indices pour nous rattraper, et nous avons perdu notre avantage de manière très frustrante.

Nous avons donc voulu créer la meilleure version possible pour la prochaine édition : pas de drapeau aléatoire bizarre comme le base64 imbriqué, pas d’indice gratuit, pas de chemin linéaire qui vous bloquerait complètement.

J’ai réfléchi aux drapeaux possibles à partir de ce jour-là et je les ai notés quelque part. Quand j’avais une idée, je l’ajoutais à la liste. À la fin de notre premier semestre, nous nous sommes retrouvés avec une liste d’environ 90 idées, toutes plus ou moins tordues. Avec toute la classe, nous avons décidé de faire une « liste hiérarchique » de toutes nos idées, en les classant de « nous en avons absolument besoin » à « comment sont-ils censés penser à ça dans toute leur vie ».

Nous avions des drapeaux pour différentes plateformes : Windows, Linux et Android. Nous savions que ce n’était pas très courant dans ce type de CTF d’avoir Windows ou Android, nous avons donc pensé que cela nous permettrait de tester leurs capacités de recherche au lieu de spammer des scripts préparés et d’acquérir de nouvelles connaissances.

Certains drapeaux concernaient le démarrage à distance d’un ordinateur via Wake-on-Lan, d’autres concernaient une simple élévation de privilèges via un DirtyCow, un Log4Shell sur un serveur Minecraft, une IA qui vous mettait au défi de lui dire un drapeau, coller un faux autocollant « recyclage » sur leur écran avec un drapeau dessus… Nous avions tellement de diverses idées que nous n’avons pas pu toutes les mettre en œuvre, car l’événement ne durait que 7 heures.

Nous avons décidé de diviser les drapeaux en deux catégories : les principaux et les bonus. Les principaux coûtent plus cher, sont visibles sur le site web de validation des drapeaux et peuvent faire l’objet d’indices payants. Les bonus sont invisibles et ne peuvent donc pas faire l’objet d’indices, mais ils rapportent des points supplémentaires. Ils sont faciles à manquer.

Lors de l’événement, les équipes ont commencé avec une clé USB contenant différentes copies d’un VPN qui leur donnait accès à une copie différente du réseau sur lequel elles allaient jouer. Nous avons également ajouté une brève introduction à la
recherche d’une URL Tor et à l’accès à un serveur HTTP, IRC et FTP via Tor. Je ne savais même pas que Tor faisait autre chose que HTTP avant, mais il prend en charge tous les protocoles TCP (et je considère même que déployer un site web Tor est beaucoup plus facile qu’un site web normal). De plus, nous avons caché une deuxième partition corrompue sur la clé USB avec un drapeau bonus, une équipe l’a presque trouvée, mais s’est dit « eh, personne ne cacherait ça ici ». Si seulement vous saviez…

Les drapeaux devaient être implémentés sur Virtual Machine sur notre CyberRange, notre machine de virtualisation. Comme nous n’y avions pas accès au début de l’année, nous nous sommes entraînés un peu sur l’équivalent open source : GNS3. C’est un très bon outil, plus spécialisé dans les réseaux. Importer QEMU VM à l’intérieur n’était pas si facile, mais c’était un substitut parfait.

Une fois que nous avons eu accès à la véritable machine de virtualisation, nous avons réalisé que l’interface utilisateur n’était pas la plus facile à utiliser pour notre événement. Cependant, la machine présentait de sérieux problèmes, comme l’impossibilité d’utiliser des « portes » pour se connecter à Internet en raison de certificats expirés, ou la création d’une VM qui bloquait toute la machine. La documentation en ligne est quasi inexistante, car il s’agit d’un appareil de niche. Nous avons essayé de contacter le support technique, mais la communication n’était pas toujours simple, et cela nécessitait souvent d’utiliser l’interface CLI de la machine qui était cassée et ne pouvait pas se connecter à la machine.

J’ai donc décidé de procéder à une ingénierie inverse. Cela a été un peu stressant, car cela s’est produit juste avant l’événement, mais c’est peut-être l’expérience qui m’a le plus appris pendant toute ma scolarité à l’université : virtualisation, routage, VLAN, certificats, postgres, tout ce qu’un administrateur système peut aimer. Cela a fini par fonctionner, et nous avons pu réparer la machine de plus en plus rapidement à chaque fois.

Nous voulions également une identité visuelle et une histoire qui donnerait un avantage considérable à ceux qui essaieraient de la comprendre. Nous avons créé un logo ressemblant au Golden Gate Bridge de San Francisco et avons décidé que l’histoire porterait sur une mafia en pleine expansion à San Francisco qui tenterait de vendre sa cryptomonnaie. La police sponsoriserait alors les joueurs pour les traquer. Étant en France, l’événement aurait lieu vers une heure du matin à San Francisco, lorsque les membres de l’organisation seraient endormis.

Nous avons eu l’idée de diffuser l’événement en streaming sur Twitch à un moment donné, mais cela aurait nécessité trop d’autorisations de la part de tout le monde, et un seul refus aurait signifié la censure en direct de plusieurs heures d’images, soit environ 7 heures d’événement.

L’idée a été abandonnée, mais nous avons tout de même pu obtenir les écrans de certains joueurs pour voir comment ils s’en sortaient grâce à FFmpeg et un serveur OSSRS.
J’ai acheté des câbles haut de gamme pour pouvoir supporter le trafic, et j’étais ravi du résultat.

L’un d’entre nous s’est vu confier la tâche de préparer la musique et de l’orchestrer avec OBS. Nous avons utilisé de nombreux jeux vidéo et morceaux de musique, car ils ne contiennent souvent pas de paroles et ont généralement un rythme régulier, sans être trop forts ni trop faibles à certains moments. Certaines personnes ont trouvé que le volume était un peu trop élevé lors de l’événement, mais il a fait du bon travail, et les scènes OBS qu’il a préparées avec des comptes à rebours et un léger effet de glitch étaient absolument parfaites.

Les derniers jours avant l’événement, nous avons préparé la salle : quelques caméras mal fixées au mur, quelques routeurs Wi-Fi et câbles Ethernet pour que tout le monde puisse jouer, des ordinateurs préinstallés avec Kali et les logiciels nécessaires déjà disponibles, la table pour toutes les équipes inscrites, le moniteur avec nos scènes OBS. Ce n’était pas facile avec le peu de temps dont nous disposions, mais nous avons fini par obtenir un résultat parfait.

Le CyberRange est tombé en panne quelques jours avant l’événement. Nous avons accidentellement sélectionné un câble réservé sur l’interface utilisateur pour accéder à notre réseau modèle, mais cela a modifié son VLAN interne et ce port a été utilisé virtuellement pour connecter le logiciel de virtualisation interne. (Les câbles réservés ne devraient pas pouvoir être sélectionnés pour cet usage, cela éviterait ce genre d’incident.) Nous étions très stressés et sommes retournés faire de l’ingénierie inverse, et un ami a trouvé une solution pour réparer le VLAN, ce qui a sauvé tout l’événement.

Rassurés et prêts, nous avons pu commencer l’événement à l’heure. Les participants étaient censés entrer dans la salle quelques minutes avant la fin de notre compte à rebours, mais ils sont restés dehors pour discuter avec de vieux amis qu’ils venaient de retrouver, alors que nous étions censés présenter l’histoire. Nous avons failli oublier d’expliquer l’histoire, mais tout s’est bien passé (merci d’envoyer des e-mails indiquant que l’événement commence au moins 30 minutes avant l’heure réelle pour la prochaine édition).

Tout a fonctionné presque sans accroc pendant toute la durée de l’événement, à l’exception de quelques problèmes mineurs, comme l’une des machines Android qui est tombée en panne et a refusé toute connexion à ADB, et la machine Windows dont la protection contre les attaques par force brute n’avait pas été désactivée, empêchant une équipe d’y accéder.

Au final, tout le monde était satisfait et a appris de nouvelles choses grâce à cet événement, même les joueurs les plus expérimentés qui participaient souvent à des CTF.