C’est un lecteur qui nous a avertis de la brèche. Des billets électroniques SNCF se sont retrouvés référencés sur les moteurs de recherche. L’alerte, passée d’abord par une plateforme de l’ANSSI, n’est toujours pas expliquée mais a suscité déjà plusieurs mises à niveau techniques.

Avec une requête spécialement formée dans les moteurs de recherche, il était possible de retrouver des dizaines de billets électroniques de clients SNCF. Embêtant puisque ces données personnelles permettent de savoir qui s’est déplacé, où et quand, avec l’aide du réseau ferré ! 

Fin février, un lecteur, Adrien Jeanneau, avait d’abord utilisé les bons soins de la plateforme de signalement de l’ANSSI. Et pour cause, on peut désormais plus facilement signaler à l’Agence nationale pour la sécurité de systèmes d’information la présence de failles de sécurité. La loi Lemaire a en effet évincé les rigueurs de l’article 40 du Code de procédure pénale, lequel oblige normalement les autorités à signaler à la justice l’identité de ceux qui auraient possiblement commis un délit (informatique ou non). De toute évidence, difficile d’esquisser ici le début d’une quelconque responsabilité du découvreur : celui-ci s’est contenté d’utiliser un moteur de recherche, en injectant des variables glanées dans les URL menant vers des e-billets.

L'alerte ANSSI, une réunion de crise à la SNCF

« Nous tenons à vous rappeler qu'aucune contrainte légale n'oblige la victime d'une vulnérabilité à corriger son site » s’était hasardée à lui répondre l’ANSSI, avant de préciser qu'évidemment son signalement avait été remonté au responsable du traitement. Et quel responsable... La SNCF est un « opérateur d’importance vitale » (OIV) astreint à des contraintes fortes depuis la loi de programmation militaire.

Dans la foulée, début mars, une réunion de crise est organisée dans les hautes sphères de la Société nationale des chemins de fer français. « Après analyse, les équipes sécurité de SNCF groupe et de SNCF Mobilité ont effectivement constaté que les moteurs de recherche référençaient quelques dizaines d’URL permettant d’accéder à certains PDF des e-billets ou justificatifs de voyage de certains clients » nous a confirmé la direction de l’entreprise, avant de relativiser, les pieds sur la pédale de frein : « quelques dizaines sur 15 000 en moyenne émis par jour ». 

Une fuite inexpliquée, la faute aux tiers ?

Si en l'état, il est donc imprudent de parler d’hémorragie, la SNCF ajoute malgré tout que « ces URL sont envoyées par mail aux personnes concernées, elles sont personnelles et n’ont pas vocation à être référencées par les moteurs de recherche ». Il y a cependant un caillou dans le ballast : « nos recherches ainsi que celles menées par notre réseau de Threat Intelligence externe n’ont pas permis de trouver la source et l’explication de ce référencement ». 

Les équipes techniques ont eu beau chercher dans leurs infrastructures, elles ont aujourd’hui la quasi-certitude que la fuite viendrait d’ailleurs. « L’explication la plus probable, avancent-elles sur la pointe des pieds, est que certains clients ont stocké cette URL personnelle sur des réseaux sociaux, des sites privées, barres d’outils, etc. qui ont permis aux moteurs de recherche d’indexer cette ressource ». 

La SNCF met du plâtre sur une jambe de bois

Sans connaître la cause officielle de cette fuite, la SNCF a pris des mesures d'urgence pour supprimer l'indexation sauvage en jouant dans un premier temps avec les variables du fichier Robots.txt. Placé à la racine d'un site, ce fichier permet d'exclure les contenus - ici des e-billets - de tout risque de référencement. « Ces paramètres permettent de bloquer l’exploration et l’indexation de l’URL par les moteurs de recherche. Le 2 mars, [ils] ont été installés en production. Nous ne devrions plus retrouver de nouvelles URL sur les moteurs de recherche, les anciennes restant par contre encore en cache ».

Cette mise en cache est une véritable photocopie du web réalisée par les moteurs. En toute logique, elle a été purgée cette semaine, par le simple écoulement du temps. C'est ce que nous avons constaté aujourd'hui.

« Nous avons aussi entrepris de sécuriser davantage le flux de cette application, ajoute la SNCF. Là encore, « cela prendra un moment, le temps que les e-billets associés aux URL déjà émises en HTTP soient consommés. Ils ont en effet une durée de visibilité qui peut aller jusqu’à deux mois entre l’achat et l’utilisation ». Il faut déduire de ces éléments que la SNCF compte (enfin) passer ces pages en HTTPS pour mieux sécuriser ces données sensibles... Même si cela ne change rien à leur accessibilité directe. Toutes ces rustines contraignent certes les moteurs à ne pas référencer ces pages, mais sans chantier plus ambitieux, elles restent accessibles à l'internaute lambda, sans contrôle d'accès.

Dans le compte rendu qu’elle nous a adressé, la société tient malgré tout à « rappeler l’importance qu’elle accorde à la protection des données personnelles de ses clients et de ses agents. Un réseau d’acteurs, au service de la sécurité SI, est en charge de mettre en œuvre les mesures adaptées à la protection de ces données, que ce soit dans le cadre de nouveaux projets ou en réaction lors d’incident ».