- L’auteur, instructeur de plongée et ingénieur plateforme, a découvert une grave vulnérabilité de sécurité dans le portail membres d’un assureur de plongée
- Le portail utilisait des ID utilisateur séquentiels et le même mot de passe par défaut, permettant à n’importe qui d’accéder aux données personnelles d’autres membres avec une simple combinaison
- Il a signalé le problème simultanément au CSIRT Malta et à l’organisation concernée, mais au lieu de le remercier, l’organisation a averti d’un risque de responsabilité pénale par l’intermédiaire de son représentant juridique
- L’auteur a refusé de signer un engagement de confidentialité (NDA) et a proposé à la place une déclaration corrigée confirmant uniquement la suppression des données, mais l’organisation a de nouveau proféré des menaces en invoquant un risque de diffamation
- L’affaire met en lumière l’importance d’une procédure de divulgation responsable des vulnérabilités et la réalité des menaces juridiques qui dissuadent de protéger les chercheurs
Découverte de la vulnérabilité
- Lors d’un voyage de plongée sur l’île Cocos, au Costa Rica, l’auteur a découvert un défaut structurel dans le portail membres d’un assureur de plongée
- Lorsqu’un instructeur enregistrait un élève, le système générait un ID numérique séquentiel et un mot de passe par défaut inchangé
- Comme de nombreux utilisateurs ne modifiaient pas leur mot de passe, il était possible d’accéder à l’intégralité des données personnelles d’autres membres (nom, adresse, date de naissance, coordonnées, etc.)
- Aucune mesure de sécurité de base comme l’obligation de changer le mot de passe, la limitation des connexions ou la MFA n’était en place
- Certains comptes contenaient aussi les informations de mineurs (14 ans)
- L’auteur a vérifié le problème avec un accès minimal, puis a immédiatement cessé toute action, et toutes les données collectées ont été supprimées définitivement
Vérification et preuve
- Il a essayé avec Python
requests, mais en raison d’une structure de session complexe, la vérification a été faite via une automatisation du navigateur avec Selenium
- Il suffisait de saisir l’ID utilisateur et le mot de passe par défaut pour se connecter
- Le script d’automatisation est publié comme exemple de code non fonctionnel, et tous les identifiants réels ont été supprimés
- Les exemples de sortie incluaient l’ensemble des données de profil, comme le nom, l’e-mail, l’adresse et la date de naissance
- Ce processus a également confirmé que plusieurs comptes de mineurs étaient exposés de la même manière
Procédure de divulgation de la vulnérabilité
- La vulnérabilité a été officiellement signalée le 28 avril 2025, avec un délai de grâce de 30 jours pour corriger le problème
- Un e-mail a été envoyé simultanément au CSIRT Malta et à l’organisation concernée
- Le rapport incluait un résumé du problème, un risque potentiel de violation du GDPR, des captures d’écran et un lien PoC chiffré
- Il demandait un accusé de réception sous 7 jours et une correction sous 30 jours
- Il s’agissait d’une procédure standard conforme à la politique nationale de divulgation des vulnérabilités (NCVDP)
Réponse de l’organisation
- Deux jours plus tard, la réponse est venue non pas de l’équipe IT, mais d’un avocat chargé de la protection des données (cabinet juridique du DPO)
- Le message mentionnait la réinitialisation des mots de passe et l’introduction de la 2FA, mais reprochait d’avoir d’abord informé un organisme public
- Il avertissait que les actes de l’auteur pourraient constituer une infraction au regard du code pénal maltais, avec une possible responsabilité juridique
- L’organisation a exigé la signature d’une déclaration de confidentialité, ainsi que la remise d’une copie du passeport, avec une échéance de signature le jour même
- La déclaration incluait une clause stipulant que « le contenu de cette déclaration restera confidentiel », ce qui revenait de fait à une NDA (accord de confidentialité)
- Ensuite, les demandes répétées de signature se sont poursuivies sous des intitulés comme « rappel amical » ou « notification urgente »
Refus et réponse du chercheur
- L’auteur a refusé de signer une clause de confidentialité et a proposé à la place une déclaration révisée confirmant uniquement la suppression des données
- Il a précisé que l’information transmise au CSIRT Malta faisait partie de la procédure officielle et que l’analyse après divulgation relevait des pratiques standard du secteur de la sécurité
- L’organisation a cité l’article 337E du code pénal (computer misuse), avertissant que même des actes commis à l’étranger pourraient être considérés comme des infractions à Malte
- Elle a également indiqué que toute mention du nom de l’organisation sur un blog ou lors d’une conférence pourrait entraîner une action en diffamation et en réparation du préjudice
- La vulnérabilité a désormais été corrigée, et la réinitialisation des mots de passe par défaut ainsi que l’introduction de la 2FA sont en cours
- Cependant, il n’est pas confirmé si les victimes ont été notifiées, conformément aux articles 33 et 34 du GDPR
Transfert de responsabilité et violation du GDPR
- L’organisation a soutenu que « changer le mot de passe relève de la responsabilité de l’utilisateur »
- Or, selon l’article 5(1)(f) et l’article 24(1) du GDPR, le responsable du traitement doit mettre en place des mesures techniques et organisationnelles appropriées
- Des mots de passe par défaut identiques et des ID séquentiels constituent clairement des mesures de sécurité inadaptées
Un schéma récurrent
- Il existe toujours un effet dissuasif (Chilling Effect) où les chercheurs en sécurité qui divulguent une vulnérabilité de manière responsable se heurtent à des menaces juridiques
- La réponse juridique détériore au contraire la réputation, et le problème n’est pas la vulnérabilité elle-même, mais la manière dont l’organisation réagit
La bonne procédure de réponse
- Accuser réception du signalement et corriger le problème
- Remercier le chercheur
- Mettre en place une politique de CVD (Coordinated Vulnerability Disclosure)
- Notifier les utilisateurs concernés, en particulier pour protéger les mineurs
- Ne pas imposer le silence via une NDA
Conseils pour les organisations et les chercheurs
- Les organisations devraient mettre en place une procédure de divulgation claire, par exemple avec security.txt, et remercier les chercheurs
- Les chercheurs devraient impliquer le CSIRT national, conserver tous les échanges, supprimer les données puis refuser toute clause de confidentialité
- La directive NIS2 encourage la divulgation responsable des vulnérabilités au sein de l’UE
- Même en 2026, la réalité demeure qu’un simple signalement de vulnérabilité peut encore déboucher sur des menaces juridiques
Aucun commentaire pour le moment.