RETEX du CERT-FR sur les violations de données applicatives

Christophe Renard et David Quesada, du CERT-FR, présentent dans NoLimitSecu le retour d'expérience que leur équipe a tiré des piratages d'applications traités en 2025, ces fuites de données ensuite publiées, vendues ou utilisées pour de l'extorsion. Identifiants volés par des infostealers, comptes ordinaires utilisés pour aspirer des milliers de fiches, bases exposées sur Internet : face à ces attaques peu sophistiquées, ils détaillent dix mesures testées chez les victimes, applicables souvent sans réécrire l'application.

Des fuites de données sans attaque sophistiquée

Christophe Renard et David Quesada, du bureau Appui à la reprise de contrôle du CERT-FR, rattaché à l’Agence nationale de la sécurité des systèmes d’information (ANSSI), présentent aux contributeurs de NoLimitSecu le retour d’expérience (RETEX) que le CERT-FR a publié sur les violations de données applicatives. Leur bureau aide les victimes de piratage à mettre les attaquants dehors et à reprendre le contrôle de leur système d’information. Le document est né des cas traités en 2025 : des applications web souvent anciennes, piratées, dont les données ont ensuite été publiées, vendues ou utilisées pour de l’extorsion. Les invités expliquent d’abord le terme de violation, repris du RGPD par la CNIL, plus large que le vol puisqu’il couvre la copie, la modification ou l’indisponibilité des données. Sur environ 200 incidents suivis de près, ils constatent que l’essentiel des compromissions s’est fait sans moyens techniques sophistiqués : réutilisation d’identifiants volés par des infostealers, parfois sur l’ordinateur familial ou sur un poste professionnel prêté aux enfants, bases de données ou stockages exposés directement sur Internet. Les comptes détournés sont rarement des comptes d’administrateurs, plutôt ceux d’employés autorisés à consulter quelques dizaines de fiches et dont l’accès a servi à en aspirer des dizaines de milliers.

Leur message : on peut réduire fortement le risque sans réécrire l’application, souvent en reconfigurant l’existant.

Dix mesures, testées chez les victimes

Les invités passent en revue les dix mesures du document, chacune illustrée par des exemples de configuration et de code. Il s’agit de formaliser une politique de gestion des données, de limiter les accès des utilisateurs, y compris en volume, de réduire l’exposition (rendre une application inaccessible entre 22 heures et 6 heures quand personne ne l’utilise, géofiltrage), d’aller au-delà du couple identifiant et mot de passe, de sécuriser l’environnement d’hébergement par une segmentation en bulle autour de chaque application, de tracer les actions des utilisateurs, de superviser les journaux, de déclencher des réactions automatiques en cas d’anomalie, de vérifier la sécurité dans la durée et, pour les administrations, d’appliquer l’homologation. Le débat porte sur les limites de l’authentification forte quand les infostealers volent les cookies de session, sur les mécanismes de protection du cookie apparus dans Chrome et leurs questions de vie privée, sur les adresses IP perdues entre les équipements frontaux et sur le retour en grâce du pare-feu applicatif. Les invités insistent : « chaque mesure indépendamment est insuffisante », c’est leur combinaison qui force l’attaquant à se montrer.

Les exemples sont surtout tirés d’infrastructures sur site, faute de cas dans le cloud, mais les principes valent pour les deux.

Pour aller plus loin

• RETEX du CERT-FR sur les violations de données applicatives
• Site du CERT-FR
• Christophe Renard sur LinkedIn
• David Quesada sur LinkedIn
• Page de l’épisode sur NoLimitSecu

Les références de l’épisode

• CERT-FR : centre gouvernemental de réponse aux incidents, auteur du document présenté.
• Bureau Appui à la reprise de contrôle : équipe des deux invités, qui accompagne la remédiation après un piratage.
• RGPD et CNIL : origine de la notion de violation de données reprise dans le titre du document.
• EBIOS RM : méthode d’analyse de risque évoquée à propos de la politique de gestion des données.
• Référentiel général de sécurité : cadre que la dixième mesure demande d’appliquer dans l’administration.

Au fil de l’épisode

• 00:00:16 : présentation des invités et du bureau Appui à la reprise de contrôle
• 00:01:25 : ce qu’est un RETEX du CERT-FR et l’origine du document
• 00:02:29 : pourquoi parler de violation plutôt que de vol de données
• 00:05:43 : environ 200 incidents en 2025 et des attaques peu sophistiquées
• 00:06:40 : infostealers et frontière brouillée entre poste personnel et poste professionnel
• 00:08:03 : des comptes ordinaires utilisés pour aspirer des milliers de fiches
• 00:10:08 : mesures 1 et 2, politique de gestion des données et limitation des accès
• 00:12:45 : mesure 3, réduire l’exposition dans le temps et dans l’espace
• 00:15:45 : mesure 4, dépasser le couple identifiant et mot de passe
• 00:17:54 : le vol des cookies de session et les moyens de les protéger
• 00:23:59 : mesure 5, sécuriser l’environnement d’hébergement
• 00:26:46 : mesure 6, tracer les actions des utilisateurs et les adresses IP perdues
• 00:34:32 : séparer les interfaces d’administration par sous-domaine
• 00:36:22 : mesure 8, réactions automatiques et alertes
• 00:39:50 : applications web, API et websockets
• 00:43:06 : pourquoi le document parle peu du cloud
• 00:45:15 : mesures 9 et 10, vérification dans la durée et homologation
• 00:47:05 : les schémas du document et le mot de la fin

FAQ

Qu’est-ce que le RETEX du CERT-FR sur les violations de données applicatives ?

C’est un retour d’expérience publié par le CERT-FR à partir des piratages d’applications traités en 2025. Selon Christophe Renard et David Quesada, il partage ce qui a été vu et mis en place chez les victimes, sans valeur normative : dix mesures de réduction du risque, avec des exemples de configuration et de code.

Comment les attaquants ont-ils volé des données dans les cas étudiés ?

D’après les invités, la plupart des compromissions n’ont demandé aucun moyen sophistiqué. Les attaquants ont surtout réutilisé des identifiants volés par des infostealers, souvent sur des ordinateurs personnels, ou profité de bases de données et de stockages exposés sur Internet. Ils ont ensuite consulté en masse des fiches avec le compte d’un simple employé.

Pourquoi l’authentification forte ne suffit-elle pas contre les infostealers ?

Parce qu’une fois l’authentification passée, l’application délivre un cookie de session, et les infostealers volent aussi ces cookies, expliquent les invités. Le document propose de lier le cookie à des paramètres du poste, comme l’adresse IP ou le navigateur, ou d’utiliser les mécanismes de protection du cookie apparus dans Chrome, qui demandent aussi des évolutions côté serveur.

Faut-il réécrire une application ancienne après une fuite de données ?

Pas forcément, répondent les invités. Dans la plupart des cas accompagnés, ils ont trouvé des solutions par l’architecture ou la configuration : pare-feu applicatif, serveur mandataire inverse, limitation des volumes consultés, fermeture hors des heures ouvrées. Ces mesures ne ramènent pas le risque à zéro mais se déploient vite et sans investissement lourd.