Fuites de données et de secrets : ce qui est déjà sorti

L'image mentale de la fuite de données, c'est un attaquant qui franchit un périmètre. En pratique, l'écrasante majorité de ce qu'un attaquant trouve sur une organisation a été publié par quelqu'un de l'intérieur, légitimement, et simplement laissé à découvert.

Un développeur committe un fichier de configuration contenant une clé active. Une équipe publie une collection d'API pour la partager avec un partenaire. Une sauvegarde est déposée « le temps d'un instant » dans un répertoire accessible depuis le web. Un espace de stockage est créé avec les permissions par défaut. Personne n'a été négligent d'une manière qui paraissait négligente sur le moment.

Deux conséquences en découlent, et les deux sont inconfortables.

• Il n'y a rien à détecter. Aucune intrusion n'a eu lieu, donc aucune alerte ne se déclenche et vos journaux ne montrent rien d'anormal. Les fuites se trouvent en regardant vers l'extérieur, pas en surveillant l'intérieur.
• La publication est de fait irréversible. Le code public est cloné, les moteurs de recherche mettent en cache, les archives capturent. Supprimer l'original ne rétracte pas les copies.

C'est pourquoi le traitement d'une fuite s'organise autour de la révocation, et non du retrait. On ne dépublie pas un secret. On peut seulement le rendre sans valeur.

Clés d'API, mots de passe de bases de données, jetons cloud et clés privées atterrissent en permanence dans des dépôts publics, et ils sont moissonnés dans les minutes qui suivent leur publication. Des scanners automatiques surveillent en continu les flux de commits publics. Le délai entre la publication d'une clé et son utilisation se compte en minutes, pas en jours, et c'est ce qui rend l'ordre de réaction ci-dessous si important.

Supprimer le fichier ne suffit pas C'est l'erreur la plus fréquente et la plus coûteuse. Retirer un secret dans un nouveau commit le laisse parfaitement lisible dans l'historique du dépôt, et chaque clone réalisé entre-temps le conserve définitivement.

L'ordre qui fonctionne réellement :

• Révoquez et renouvelez le secret d'abord. Avant le nettoyage, avant le post-mortem, avant d'en parler à qui que ce soit. Une clé révoquée est inoffensive partout où elle s'est déjà propagée, et vous ne savez pas où.
• Purgez-le ensuite de l'historique avec git filter-repo ou BFG Repo-Cleaner, en acceptant que les clones existants le détiennent toujours.
• Ajoutez enfin un scan de secrets en pré-commit, avec gitleaks ou trufflehog, pour que le suivant soit attrapé avant publication plutôt qu'après. ReconScope passe trufflehog sur votre code public exactement pour cette raison.

Au-delà des dépôts git Les collections d'API publiques, les espaces de travail partagés sur les plateformes de collaboration et les projets publics sur les forges embarquent régulièrement des clés, des jetons et des URL internes qui n'étaient pas destinés au partage. On les relit bien moins souvent que du code, parce qu'on les classe mentalement comme de la documentation. Les workspaces Postman et les projets GitLab publics sont les deux cas qui ressortent le plus. Tout ce qui est publié sous votre marque mérite la même vigilance qu'un dépôt.

Les secrets côté front-end Une clé codée en dur dans du JavaScript client est lisible par chaque visiteur. Aucune obfuscation n'y change quoi que ce soit : le navigateur doit pouvoir la lire, donc n'importe qui le peut. Elle doit être révoquée et déplacée côté serveur, pas mieux dissimulée.

C'est la catégorie qui a le plus progressé, et celle sur laquelle les organisations n'ont le plus souvent aucune visibilité.

Un infostealer est un logiciel malveillant qui s'exécute sur un poste individuel, celui d'un collaborateur, d'un prestataire, parfois d'un client, et qui exfiltre tout ce que contient le navigateur : mots de passe enregistrés, cookies de session, données de remplissage automatique, profils VPN. Le butin est empaqueté et vendu sur des marchés criminels, trié par les domaines auxquels il donne accès. Votre domaine est la clé de tri.

Ce sont les cookies de session qui rendent cela dangereux, et c'est la partie que la plupart des gens ratent. Un mot de passe volé est mis en échec par l'authentification multifacteur. Un cookie de session volé, non. Il représente une session qui a déjà passé l'authentification : le rejouer passe donc devant le MFA sans s'arrêter. Vos journaux affichent un utilisateur normal et authentifié.

La machine infectée est fréquemment hors de votre contrôle, un portable personnel utilisé en télétravail, le poste d'un prestataire, si bien que votre protection des terminaux ne la voit jamais. En pratique, le premier signal est l'apparition de votre domaine dans un lot d'identifiants fuités, ce qui explique pourquoi vérifier n'est pas optionnel.

Réagir - Forcez la réinitialisation des mots de passe concernés, et invalidez les sessions actives. Une réinitialisation qui laisse les sessions vivantes ne corrige rien, puisque c'est le cookie qui a été volé. - Activez le MFA partout, en sachant qu'il neutralise les mots de passe volés et non les sessions volées. - Isolez et réinstallez la machine compromise. Nettoyer une infection par infostealer sur place n'est pas fiable. - Surveillez en continu. De nouveaux lots apparaissent constamment : un contrôle ponctuel ne renseigne que sur un instant, et sur rien d'autre.

Les moteurs de recherche indexent bien plus que prévu : dumps de bases, sauvegardes, fichiers de configuration, journaux, portails d'administration, documents internes. N'importe qui peut les trouver avec une requête ciblée, une technique qu'on appelle généralement le dorking, et cela ne demande aucune compétence. Les requêtes circulent dans des listes publiques.

Voici ce qui prend les gens de court. Retirer un fichier de votre serveur ne le retire pas de l'index. La copie en cache reste disponible jusqu'au rafraîchissement de l'index, et une archive peut en conserver un exemplaire indéfiniment.

L'ordre compte donc :

• Supprimez ou restreignez le contenu de votre côté.
• Demandez explicitement le retrait de l'index, via l'outil Suppressions de la Search Console. Attendre un rafraîchissement naturel peut prendre des semaines.
• Renouvelez tous les secrets que le fichier contenait, en partant du principe qu'il a été lu. Vous ne pouvez pas prouver le contraire, et le renouvellement coûte moins cher que l'hypothèse inverse si elle est fausse.

Les archives du web Des services d'archivage capturent les pages au fil du temps. Un fichier de configuration, un export ou une sauvegarde exposés une seule après-midi il y a trois ans peuvent rester récupérables aujourd'hui, longtemps après que toute trace en a quitté vos serveurs. Les URL historiques méritent d'être passées en revue précisément parce qu'elles documentent ce qui a été exposé, et parce que personne ne les audite jamais.

Un espace de stockage laissé en lecture publique est l'un des constats les plus rentables qui soient, à cause de ce que ces espaces contiennent typiquement : sauvegardes, exports de bases, dépôts d'utilisateurs, factures, pièces jointes.

Ce qui les rend particulièrement exposés, c'est que leurs noms se devinent. Ils suivent la marque — societe-backup, societe-assets, societe-prod — l'attaquant n'a donc pas à découvrir le nom : il génère des candidats et les teste.

Réagir Confirmez d'abord que l'espace vous appartient, puis bloquez l'accès public au niveau du compte plutôt qu'objet par objet — c'est ce qui prévient aussi la prochaine erreur de configuration, et pas seulement celle-ci. Passez en revue ce qui a été exposé, et renouvelez tout identifiant ou clé qui s'y trouvait. Un espace contenant une sauvegarde contient très souvent un fichier de configuration, et ce fichier contient très souvent un mot de passe.

Celle-ci est plus discrète que les autres, et elle ne concerne pas des secrets. Chaque document publié — PDF, tableur, présentation — transporte des métadonnées : noms d'auteurs, identifiants internes, versions de logiciels, parfois chemins de fichiers internes et noms d'imprimantes ou de serveurs.

Rien de tout cela n'est une vulnérabilité en soi. Mis bout à bout, sur quelques dizaines de documents publics, l'ensemble produit quelque chose de précieux pour un attaquant : une liste de vrais noms de collaborateurs, la convention de nommage des comptes, et les logiciels utilisés. C'est la matière première d'un phishing ciblé crédible, et d'attaques par mot de passe contre un format d'identifiant connu.

Le correctif est procédural plutôt que technique : nettoyez les métadonnées avant publication, et faites de cet assainissement une étape du processus de publication plutôt qu'une vigilance au cas par cas.

L'ordre compte davantage que la vitesse, et se tromper d'ordre gaspille les seules heures qui comptent.

• Révoquez d'abord. Avant d'enquêter, avant de nettoyer, avant d'informer qui que ce soit. Un identifiant exposé n'est dangereux que tant qu'il reste valide, et la révocation est en général l'action la plus rapide dont vous disposez.
• Partez du principe qu'il a été lu. Ne passez pas de temps à établir si quelqu'un l'a vu : on ne prouve pas une absence, et cette hypothèse ne vous coûte qu'un renouvellement que vous devriez faire de toute façon.
• Retirez ensuite, en sachant que le retrait est incomplet. Supprimez le fichier, purgez l'historique, demandez la désindexation. Considérez cela comme une limitation de la propagation, non comme une annulation de la fuite.
• Cherchez comment cela a été publié. Une fuite est le symptôme d'un processus : une étape de relecture absente, une permission par défaut, un poste non surveillé. Corriger le cas sans corriger le processus garantit la récidive.
• Examinez vos obligations légales. Si des données personnelles sont concernées, des obligations de notification RGPD peuvent s'appliquer, avec un délai de 72 heures pour notifier l'autorité de contrôle. Établissez-le tôt, pas une fois le travail technique terminé.