Pourquoi les CTF créent des compétences offensives réutilisables
Éditorial
Les concours de hacking éthique forment efficacement, mais produisent aussi des compétences offensives dont l'usage échappe aux organisateurs après la compétition.
Pourquoi les CTF créent des compétences offensives réutilisables
Section intitulée « Pourquoi les CTF créent des compétences offensives réutilisables »Les CTF (Capture The Flag), concours où il faut retrouver une preuve cachée dans un environnement vulnérable, accélèrent réellement l’apprentissage de la sécurité offensive. Le compromis est brutal : on gagne des praticiens capables de comprendre les failles, on accepte de ne plus contrôler ce qu’ils feront de cette capacité hors de l’arène.
→ Lire l’explication complète de la marmotte
Le compromis des CTF : former vite, contrôler presque rien
Section intitulée « Le compromis des CTF : former vite, contrôler presque rien »Un CTF fournit trois choses qu’une formation théorique produit mal : un objectif concret, un retour immédiat et le droit à l’erreur sur une cible autorisée. Une élévation de privilèges, c’est-à-dire le passage abusif d’un compte limité à un compte administrateur, cesse d’être une ligne dans un rapport et devient une chaîne causale observable : mauvaise permission, secret exposé, service mal configuré, contrôle contourné.
Cette pédagogie est excellente parce qu’elle force à raisonner sur des systèmes réels. Les participants croisent des journaux, des configurations, des protocoles réseau, des mécanismes d’authentification et des dépendances logicielles. Une erreur de validation d’entrée peut mener à une exécution de commande, puis à la récupération d’un jeton d’accès, puis à l’accès à un service voisin. La sécurité ne se découpe pas proprement en chapitres, malgré les slides qui le prétendent avec un aplomb admirable.
Mais la compétence n’est pas liée à l’intention de l’organisateur. Savoir identifier une injection SQL, c’est-à-dire une requête de base de données modifiée par une entrée mal contrôlée, sert autant à vérifier une application autorisée qu’à attaquer une cible non autorisée. Le cadre légal de la compétition borne l’action pendant l’épreuve. Il ne borne ni la mémoire, ni les scripts écrits, ni les réflexes acquis après.
La position défendue ici est donc nette : organiser et soutenir les CTF, oui, mais jamais comme unique dispositif de formation ou de recrutement. Leur valeur est maximale lorsqu’ils sont intégrés à un parcours qui enseigne explicitement l’autorisation, la réduction du risque et la remédiation. Sans ce second volet, le CTF forme des explorateurs de défauts. Pas nécessairement des défenseurs.
Cette limite vaut aussi pour les badges, classements et profils publics. Un score mesure la capacité à résoudre les problèmes choisis par l’épreuve, sous les contraintes de l’épreuve. Il ne mesure ni la qualité d’un rapport de risque, ni la prudence face à un système de production, ni la capacité à refuser une demande illégitime. Le tableau des scores reste un tableau des scores, pas un détecteur de maturité.
Surface d’attaque : de l’environnement de jeu à la réutilisation hostile
Section intitulée « Surface d’attaque : de l’environnement de jeu à la réutilisation hostile »Le premier risque est technique : un laboratoire insuffisamment isolé devient une cible de rebond. Une machine de CTF ne doit disposer d’aucune route vers le réseau d’administration, les environnements de développement, les dépôts de code ou les services d’identité. Le cloisonnement réseau doit être vérifiable par des règles de pare-feu et des tests de connectivité, pas seulement dessiné dans un diagramme au feutre.
Une plateforme exposée sur Internet doit séparer au minimum quatre zones : le frontal web, les services de compétition, les cibles vulnérables et l’administration. Les cibles doivent être éphémères, réinitialisées après chaque session ou instance, et privées par participant lorsque le scénario autorise la persistance. Partager une même cible entre concurrents crée des interférences pédagogiques et des fuites de solutions. Pire, cela apprend à exploiter le travail des autres, compétence certes répandue dans certains cercles, mais rarement celle recherchée.
Le second risque est informationnel. Des challenges inspirés d’applications internes, de configurations réelles ou d’incidents connus peuvent révéler une topologie, des conventions de nommage, une pile logicielle ou une faiblesse encore présente. Anonymiser des noms ne suffit pas si les versions, les chemins de fichiers et les messages d’erreur permettent une ré-identification. Un scénario doit être synthétique ou fondé sur une vulnérabilité déjà corrigée et publiquement documentée.
Le troisième risque concerne les artefacts publiés. Les solutions détaillées, appelées parfois write-ups, transmettent des chaînes d’exploitation reproductibles. Elles restent utiles pour apprendre, mais une solution ne doit jamais contenir de secret réel, d’adresse exploitable, de liste de comptes, de clé privée ou de procédure applicable telle quelle à une infrastructure identifiable. La frontière est simple : expliquer une classe de faille et sa correction est formateur ; documenter le chemin d’accès vers une cible existante ne l’est pas.
Les équipes qui hébergent elles-mêmes une plateforme doivent traiter les comptes participants comme non fiables. Authentification distincte de l’annuaire interne, jetons à durée courte, absence de fédération vers les ressources d’entreprise : le raccordement direct à l’IAM (Identity and Access Management), système de gestion des identités et des accès, transforme un jeu en pivot potentiel. La page sur les identités et leurs frontières rappelle pourquoi l’authentification n’équivaut jamais à une autorisation générale.
Prérequis d’une plateforme CTF réellement confinée
Section intitulée « Prérequis d’une plateforme CTF réellement confinée »L’infrastructure requiert un hyperviseur ou un orchestrateur de conteneurs capable d’imposer des frontières réseau et des limites de ressources. Un conteneur n’est pas une frontière de sécurité suffisante lorsqu’il partage un noyau avec l’hôte. Pour les scénarios exécutant du code fourni par les participants, privilégier une machine virtuelle par instance ou un bac à sable renforcé, avec virtualisation matérielle activée et images immuables.
Chaque instance doit recevoir des identifiants et des marqueurs uniques. Réutiliser le même drapeau, la chaîne secrète validant une réussite, permet le partage immédiat de réponse sans résoudre le challenge. Générer le drapeau à partir d’un secret côté serveur et d’un identifiant d’instance évite ce défaut, à condition que le secret de dérivation reste hors de la cible. Le mettre dans une variable d’environnement de conteneur revient à cacher la clé sous le paillasson, mais avec Kubernetes écrit dessus.
Les journaux doivent couvrir les créations d’instances, les authentifications, les accès d’administration, les flux sortants refusés et les réinitialisations. Ces événements servent à détecter un abus de plateforme, mais aussi à rejouer un incident. Une conservation minimale de 90 jours est raisonnable pour une plateforme exposée, sous réserve des contraintes internes de protection des données. Les journaux ne doivent contenir ni mots de passe ni jetons bruts.
La supervision doit alerter sur trois signaux : consommation anormale de processeur ou de mémoire, flux sortants vers Internet et tentatives répétées vers le plan d’administration. Le minage clandestin reste une hypothèse banale dès qu’un environnement de calcul gratuit est accessible. Aucun concours n’immunise contre l’économie très terre à terre du processeur volé.
Enfin, les sauvegardes ne doivent conserver que les éléments nécessaires : configurations versionnées, définitions de challenges, résultats et journaux nécessaires à l’enquête. Sauvegarder les instances compromises n’apporte généralement rien, sauf à archiver des charges malveillantes et des secrets accidentellement déposés. La reprise doit reconstruire depuis une image approuvée, jamais restaurer aveuglément un système de jeu compromis.
Exemple reproductible : vérifier l’absence de secrets dans un challenge
Section intitulée « Exemple reproductible : vérifier l’absence de secrets dans un challenge »Avant publication, analyser l’arborescence du challenge dans une image ou un dépôt isolé. Cette vérification ne remplace pas une revue humaine, mais elle bloque des erreurs grossières : clés privées, jetons d’accès, fichiers d’environnement ou configurations copiées depuis un poste de travail.
# Exécuter depuis la racine d'un challenge destiné à être publié.# La commande cherche des secrets fréquents sans envoyer de contenu à l'extérieur.grep -RInE \ --exclude-dir=.git \ --exclude='*.min.js' \ --exclude='package-lock.json' \ '(BEGIN (RSA |EC )?PRIVATE KEY|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|password[[:space:]]*=[[:space:]]*[^[:space:]]+)' \ .
# Vérifier aussi les fichiers qui ne devraient jamais accompagner le challenge.find . -type f \( -name '.env' -o -name '*.pem' -o -name '*.p12' -o -name 'id_rsa' \) -printUn résultat doit bloquer la publication jusqu’à qualification. Un faux positif est une minute de revue. Une clé divulguée impose une rotation, une recherche d’usage et parfois une enquête. Le calcul est peu poétique, mais il est vite fait.
Les secrets de démonstration doivent être générés pour le challenge, limités à son environnement et révoqués à sa destruction. Un secret n’est pas inoffensif parce qu’il porte le mot demo. Les attaquants lisent aussi les commentaires, avec une patience que les systèmes de gestion de tickets n’ont jamais eue.
Du challenge à la défense : imposer la remédiation
Section intitulée « Du challenge à la défense : imposer la remédiation »La formation doit exiger une restitution défensive pour chaque exercice significatif. Après l’exploitation, documenter la condition initiale, la preuve observée, le correctif, le contrôle compensatoire et le test de non-régression. Une vulnérabilité sans correctif associé transforme l’apprentissage en collection de tours de passe-passe.
Le bon format est un rapport court et contraint. Il doit distinguer la cause racine d’un symptôme : désactiver un message d’erreur ne corrige pas une injection ; filtrer une adresse IP ne corrige pas une authentification cassée ; changer un mot de passe ne répare pas une fuite de secret dans l’historique Git. La gestion des menaces gagne en qualité dès lors que l’exploitation est reliée à un chemin d’attaque, puis à un contrôle mesurable.
Les organisateurs doivent aussi publier des règles d’engagement explicites : périmètre, méthodes interdites, interdiction de viser des tiers, canaux de signalement et conséquences en cas de sortie de périmètre. Ces règles ne neutralisent pas une compétence acquise. Elles donnent en revanche une base d’exclusion, de journalisation et d’intervention quand un comportement franchit la limite.
Le recrutement ou l’évaluation ne doit jamais se limiter au classement. Demander une analyse de remédiation, une modélisation de menace ou une revue d’architecture révèle davantage la capacité à protéger. Une personne capable d’expliquer pourquoi un contrôle échoue vaut plus qu’une personne qui récite une commande mémorisée. Les commandes changent. Les mécanismes et les dépendances restent, avec une ténacité presque administrative.
Ce que les CTF ne garantissent pas
Section intitulée « Ce que les CTF ne garantissent pas »Un CTF ne garantit ni l’éthique, ni la légalité des actes futurs, ni la capacité à intervenir en production. Il ne garantit pas non plus la maîtrise de la disponibilité, de la confidentialité des données personnelles, de la gestion de crise ou de l’impact métier. Une cible de concours est conçue pour tomber. Un système de production doit continuer à fonctionner pendant qu’on cherche pourquoi il brûle.
Il ne faut donc pas confondre compétence offensive et autorisation de tester. Toute intervention sur un système réel requiert un périmètre écrit, des créneaux, des contacts d’escalade, des limites de charge et une procédure d’arrêt. Sans cela, même une vérification techniquement bénigne peut produire une indisponibilité, contaminer des preuves ou déclencher des mécanismes de défense.
La réponse architecturale n’est pas d’éviter les CTF. Ce serait abandonner un outil de formation puissant parce qu’il peut être mal employé, raisonnement qui finirait aussi par interdire les tournevis. La réponse consiste à les enclaver, à supprimer toute donnée réelle, à former à la remédiation et à évaluer la responsabilité opérationnelle au même niveau que l’exploitation.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans cible éphémère et privée par participant, un concurrent peut laisser sur l’instance partagée un binaire modifié, une page piégée ou un service d’écoute qui vise les outils et navigateurs des participants suivants : le poste de l’apprenant devient la cible, hors de tout périmètre surveillé par la plateforme. Sans filtrage des flux sortants, une instance compromise peut lancer balayages et tentatives de connexion vers des tiers ; ceux-ci voient alors l’adresse de la plateforme comme source. Les plaintes pour abus et l’inscription de cette plage d’adresses sur des listes de blocage touchent aussi les services légitimes qui partagent la même sortie réseau. Sans journal des créations d’instances, aucune de ces actions ne peut ensuite être rattachée à un compte.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un concours de hacking éthique donne aux participants un système volontairement vulnérable et une preuve à retrouver. Pour réussir, ils observent les fichiers, les programmes, les comptes et les échanges entre machines. Ils cherchent une erreur de configuration, un mot de passe exposé ou une fonction mal protégée. Quand ils trouvent un accès, ils montrent qu’ils peuvent atteindre une zone qui ne devait pas être accessible.
Cette pratique apprend vite parce que le résultat est visible. Mais le savoir acquis reste disponible après le concours. Une personne peut réutiliser les mêmes méthodes contre un système qui ne lui appartient pas. L’organisateur ne peut pas supprimer cette connaissance ni contrôler tous les usages futurs.
La plateforme doit donc limiter les dégâts possibles pendant le concours. Les systèmes de jeu doivent être séparés des réseaux internes, des comptes réels et des données réelles. Chaque participant doit recevoir un espace isolé, surveillé et régulièrement remis à zéro. Les accès doivent expirer, les activités inhabituelles doivent être détectées, et les sauvegardes doivent permettre de reconstruire le service depuis un état propre.
Après chaque exercice, il faut aussi apprendre à corriger la faille trouvée et vérifier que le correctif fonctionne. Sans cette étape, le concours entraîne surtout à entrer. Avec elle, il entraîne aussi à empêcher une nouvelle entrée.
À lire aussi
- Pourquoi les primes de bug bounty stagnent-ellesAnalyse des primes de bug bounty qui stagnent malgré l'inflation et la complexité croissante des systèmes, et du pouvoir capté par les plateformes intermédiaires.
- Bug bounty gouvernemental et immunité pénalePourquoi les programmes gouvernementaux de recherche de vulnérabilités créent une tension entre l'immunité annoncée et le droit pénal applicable hors périmètre.
- Sécuriser les bases de données managées cloudSécuriser RDS, Cloud SQL et les bases managées contre les accès réseau exposés, les secrets applicatifs mal gérés et les instantanés partagés publiquement.
- Laisser une équipe se tromper sans casser la productionLaisser une équipe se tromper est un risque pédagogique à encadrer par des limites techniques, des données contrôlées et une exploitation préparée.
Pages voisines
La citent
Pourquoi les CTF créent des compétences offensives réutilisables
Elle cite