Qui a récupéré les clés : détecter le vol de clés dans les logs applicatifs
Le défi
Un point de terminaison de debug a été laissé exposé et il sert du matériel de clé privée. Dans vos logs applicatifs, la plupart du trafic est constitué de pages normales, mais une IP frappe sans cesse /debug/keys et /.well-known/private-keys en obtenant un 200 à chaque fois - elle télécharge discrètement les secrets. Filtrez les chemins suspects, trouvez la source unique qui récupère le matériel de clé, et soumettez son IP.
Ce que tu vas apprendre
- Filtrer un log d'accès par chemin pour isoler les endpoints sensibles
- Comprendre qu'un 200 sur un chemin de secrets signifie que la donnée a été servie
- Utiliser la colonne user-agent pour distinguer un script d'un navigateur
- Repérer une collecte systématique de clés depuis une seule source
- Attribuer l'exfiltration de secrets à une IP unique
Compétences testées
Prérequis
- Compréhension des chemins HTTP et des codes de statut
- Connaissance du fait que les clés privées sont du matériel secret
- Familiarité avec les chaînes user-agent
Comment ça marche
Des secrets sont exposés lorsqu'un endpoint de debug ou de diagnostic destiné à un usage interne reste accessible en production. Des chemins comme /debug/keys et /.well-known/private-keys peuvent servir du matériel de clé privée brut, et quiconque les trouve peut simplement le télécharger. Dans les logs, le vol ne semble pas violent : ce n'est qu'une série de requêtes GET réussies. La compétence consiste donc à savoir quels chemins ne devraient jamais être servis et à repérer qui les sollicite.
Filtrez sur path:/debug et path:/.well-known et une seule source, 198.51.100.31, explique tout. Elle demande /debug/keys aux formats pem et jwk, /.well-known/private-keys, et /debug/config, encore et encore, chaque requête retournant 200. Le code de statut est la preuve : un 200 signifie que le serveur a réellement renvoyé le matériel de clé, pas un 403 ni un 404. Deux autres signaux confirment l'intention : aucun utilisateur légitime ne visite ces chemins, et l'ua de la requête est python-requests, un client scripté, tandis que chaque IP bénigne utilise un véritable agent de navigateur pour charger les pages de l'application.
C'est une défaillance récurrente dans le monde réel : une route de debug oubliée expose des clés de signature ou des clés privées TLS, et un attaquant scripte une boucle pour les récupérer. La preuve dans les logs est la combinaison d'un chemin jamais public, d'un 200 répété, d'une seule source, et d'un user-agent automatisé.
Erreurs fréquentes
- Considérer un 200 comme anodin. Sur un chemin de secrets, un
200est le pire des cas : cela signifie que la clé a été servie. Le succès est ici l'alarme. - Se contenter de compter les requêtes. Plusieurs IP sont actives, mais une seule est active sur les chemins de debug et de clés privées.
- Ignorer le user-agent. L'agent
python-requestsface aux navigateurs est un indice fort que cette source est un script, pas une personne. - Soumettre le chemin au lieu de l'IP. La question demande qui récupère les clés : l'adresse de la source unique.
Comment s'en protéger
Les secrets exposés sont d'abord un problème de configuration et de code, mais la détection sur le log d'accès permet de repérer une collecte active. Traitez tout accès à un chemin de secrets comme un incident.
- N'exposez jamais d'endpoints de debug, de diagnostic ou servant des clés en production : supprimez-les ou protégez-les par une authentification forte et un réseau interne.
- Alertez sur toute requête vers des chemins qui servent des secrets (
/debug,/.well-known/private-keys), en particulier celles renvoyant un200. - Faites tourner tout matériel de clé qui était accessible, et considérez que tout ce qui a été servi avec un
200est compromis. - Bloquez ou limitez le débit des clients automatisés qui martèlent les chemins sensibles, et examinez les user-agents non-navigateurs.