Une modification triviale dans l'URL des pièces jointes adressées par l'assurance maladie permettait d'accéder à des courriers adressés à d'autres assurés. Après avoir alerté l'ANSSI en urgence, nous avons contacté Ameli, qui a corrigé la faille. Cherchant à le vérifier, nous avons alors découvert une seconde fuite de données...

Un lecteur de Next INpact nous a alerté fin novembre au sujet d'une faille de sécurité affectant la messagerie d'ameli.fr, le portail de Caisse nationale de l'Assurance Maladie (CNAM).

Refroidi par l'affaire Bluetouff, qui avait été condamné pour piratage informatique après avoir découvert des fichiers de l’Agence nationale de sécurité sanitaire de l’alimentation, de l’environnement et du travail (ANSES) dans des répertoires non protégés, il n'osait pas contacter Ameli pour leur notifier la brèche.

Le mode opératoire ? Simplissime : il suffisait de modifier le numéro identifiant les fichiers PDF adressés en pièce jointe pour accéder à des courriers adressés à d'autres assurés.

S'il n'était pas possible de cibler un individu en particulier, nous n'en avons pas moins pu, de la sorte, accéder aux noms, prénoms, adresses, n° de sécurité sociale, demandes de documents et de renseignements, attestations de prise en charge ou de refus de soin (au motif que « le bénéficiaire du soin s'est déplacé sur le territoire suisse pour se faire soigner »), parfois accompagnées de pièces jointes (arrêt de travail, notamment) de plusieurs autres assurés.

Faute de pouvoir trouver un moyen de contacter en urgence l'assurance-maladie en plein week-end, nous avons profité de la disposition introduite par la loi pour une République numérique en 2016 pour alerter l'ANSSI de cette vulnérabilité, sans (trop) risquer d'être accusé d'avoir compromis Ameli.

Pas d'impunité pénale

Son article 47 avait en effet modifié le code de la défense pour y préciser qu'« une personne de bonne foi qui transmet à la seule autorité nationale de sécurité des systèmes d’information une information sur l’existence d’une vulnérabilité concernant la sécurité d’un système de traitement automatisé de données » ne saurait être dénoncée au procureur de la République.

Ainsi, plus exactement, cette disposition empêche l'ANSSI d'avoir à dénoncer automatiquement les faits de piratage informatique – ou d'atteintes à un système de traitement automatisé de données (ou STAD), dans le jargon – mais sans introduire d'immunité pénale (voir Signalements des failles : à l’ANSSI, pas de raz-de-marée après la loi Lemaire).

Dit autrement, le chercheur qui viendrait à sonner à la porte de l'agence pourrait toujours être attaqué par le propriétaire du système faillible, quand bien même celui-ci serait en délicatesse sur le terrain du RGPD et sa sacro-sainte obligation de sécurité (voir Le RGPD expliqué ligne par ligne (articles 1 à 23)).

En l'espèce, la politique de protection des données personnelles de la CNAM précise bien que « des politiques de protection des systèmes d’information (PSSI) sont mises en œuvre. Toutes les précautions utiles sont prises pour assurer la sécurité et la confidentialité de vos données personnelles, notamment pour empêcher leur perte, altération, destruction ou utilisation par des tiers non autorisés ».

Nous aurions aimé en savoir plus

Le lundi suivant, le service de presse d'Ameli, que nous avions contacté dans la foulée, accusait réception de notre alerte et précisait qu'il reviendrait vers nous « dès que possible ». L'après-midi, la faille était encore exploitable.

Nous voulions en savoir plus sur l'historique de cette faille de sécurité, si elle avait été exploitée, mais également pourquoi et comment une faille aussi triviale avait pu être possible, ce qui avait été entrepris pour la colmater, et éviter qu'un tel incident ne se reproduise, si l'incident avait été déclaré à la CNIL, et de quand datait le dernier audit de sécurité.

Quatre jours plus tard, le service de presse d'ameli nous répondait laconiquement que « la situation que vous avez bien voulu nous signaler avait bien été identifiée par nos équipes de sécurité et corrigée depuis, pour bloquer toute récupération aléatoire de correspondance depuis l’espace personnel du compte ameli. Nous avons également veillé à informer la Cnil à ce sujet ».

Pour autant, et « afin de protéger les dispositions que nous prenons pour assurer la sécurité des données personnelles, vous comprendrez que nous ne pouvons divulguer aucune information concernant les modalités de nos audits de sécurité, tant sur leur périmètre que sur leur périodicité ».

Une deuxième fuite de données, découverte dans la foulée

Désormais, les URL modifiées renvoient à une page d'erreur intitulée « Visualisation de fichier » précisant « Service indisponible », page que Google avait archivée le mercredi précédent à 2 h du matin. Il ne nous a pas été possible de savoir ni depuis quand la faille existait, ni quand elle avait été corrigée.

Ce faisant, cherchant à vérifier quelles autres pages étaient archivées par Google, nous avons découvert une dizaine d'autres pages personnalisées de confirmation d'inscription affichant les noms et prénoms d'assurés. 

S'il est quelque peu étonnant de voir de telles pages archivées par Google, elles ne permettaient pas d'obtenir d'autres données personnelles, contrairement à la première faille. La plus vieille page avait été archivée le 15 septembre, la plus récente ce dimanche 8 décembre, et donc après que le premier problème ait été corrigé. 

Et sans que l'on comprenne pourquoi Google n'aurait archivé que 11 pages seulement, sinon que le fichier robots.txt, censé préciser aux robots ce qu'il est permis (ou interdit) d'indexer, n'existait pas et affichait un gros (et gras) « Action Interdite », Ameli laissant donc n'importe quel robot indexer n'importe quelle page.

De nouveau contactée, la CNAM nous répond, une semaine plus tard, que les deux problèmes « sont bien d’origine et de nature différentes. Concernant la seconde, son impact est moindre, dans la mesure où l’indexation des pages ainsi affichées ne permet pas l’accès à des courriers d’un tiers. Nous avons réalisé les correctifs nécessaires et demandé à Google la suppression des pages qui avaient été ainsi référencées ».

Pour autant, et une semaine après l'avoir alertée à ce sujet, il était toujours possible de consulter les pages en question via le cache de Google, mais aussi et surtout directement sur ameli.fr. Et nous avons également découvert que certaines d'entre-elles avaient depuis été réarchivées par Google, la dernière l'ayant été le dimanche 15 décembre, veille de la réponse d'Ameli.

En l'espèce, le fichier robots.txt n'avait toujours pas été corrigé, ce dimanche 15 décembre, et continuait d'afficher « Action interdite ». Il n'a été modifié que ce lundi 16, pour n'autoriser les crawlers des moteurs à n'indexer que la seule « page requise, soit page d’accueil au compte ameli, et uniquement celle-ci », nous répond l'assurance maladie.

La CNAM précise que « nos services juridiques ont bien demandé à Google la suppression des liens de confirmation d’ouverture/fermeture de comptes ainsi archivés, demande qui n’a pas encore abouti et que nous continuons de suivre auprès des services de Google. Par ailleurs, il nous reste une amélioration à apporter au niveau du processus de validation des emails des assurés qui créent un compte personnel sur Ameli pour éviter que ces quelques indexations ne se reproduisent : ce sera fait courant janvier. Cependant, il convient de souligner que les quelques liens ainsi référencés ne permettent pas d’accéder aux espaces personnels des assurés ; en effet, en cliquant sur les deux liens présents dans l’email de confirmation, ils renvoient vers la page d’accueil et nécessitent de nouveau, la saisie des identifiants et des mots de passe des assurés sociaux concernés ». 

« Nous continuerons de tout mettre en œuvre pour protéger la sécurité des données de nos différents publics (assurés, professionnels de santé et employeurs) », conclut l'assurance maladie, sans expliquer cela dit ce pourquoi le problème avait ainsi pu perdurer plusieurs mois.