Vous êtes dans : Accueil > Tribunes libres >

Ça n’arrive pas qu’aux autres : retour sur quelques incidents de sécurité insolites

Charles Blanc-Rolin , MARDI 08 DéCEMBRE 2020

Le but de ce billet n’est absolument pas d’accabler les victimes de ces incidents, ni leurs prestataires, même si l’on pourrait dans certains cas attendre un peu mieux de leur part… mais de nous faire réfléchir sur nos pratiques, nos croyances et les contrôles que nous pourrions mettre en place pour nous assurer que nos prestataires sont à la hauteur de nos espérances.

Ces dernières semaines, j’ai eu connaissance de quelques anecdotes plutôt insolites que j’ai pu lire, entendre ou tout simplement que l’on m’a rapporté. On peut sourire derrière son masque, mais attention, n’oublions pas que ça n’arrive pas qu’aux autres !

Le premier incident a fait un peu de bruit dans la presse la semaine dernière, et pour cause ! Plus d’1,7 téraoctet de données seraient restés en accès libre sur Internet via un serveur ELK (ElasticSearch, Logstash, Kibana) mal configuré, d’après un article original publié par Cybernews [1]. La gigantesque fuite de données en question concerne une plateforme française de distribution de médicaments. Parmi les données exposées, on pouvait apparemment trouver l’état des stocks de certains entrepôts, les médicaments livrés, leurs quantités, quand et à quelles pharmacies (officines et pui), de quoi donner des idées à des personnes mal intentionnées... des données à caractère à personnel sur les clients, des statistiques sur la consommation de médicaments… que du bonheur…
Pour rappel, la CNIL qui pourrait bien s’intéresser à cet incident, a d’ailleurs récemment rappelé quatre bonnes pratiques concernant la mise en place et l’utilisation de la solution ELK [2].

Le second incident a été conté récemment par Vladimir KOLLA dans la célèbre « minute fail » de l’excellent podcast No Limit Secu [3]. L’incident de sécurité en question, s’est déroulé chez un hébergeur de données de santé (HDS) et s’est propagé chez un client, qui est à la demande de l’audit. L’auditeur arrivé sur place échange avec le responsable des sauvegardes, et lui demande :

« Quelles mesures de sécurité mettez-vous en place en tant qu’hébergeur HDS ? »
Réponse : « C’est quoi HDS ? »

Deuxième question :
« Les sauvegardes sont-elles chiffrées ? »
Réponse : « Oui elles sont chiffrées en HTTPS. »

Pour rappel, HTTPS indique le chiffrement d’un flux Web et en rien le chiffrement d’un fichier de sauvegarde. Bilan, le prestataire n’avait aucune idée des mesures de sécurité de base à mettre en place.

Gardons toujours à l’esprit qu’une certification ou un label quel qu’il soit ne peut être garant d’une sécurité absolue. Rappelez-vous, début juillet alors que des POCs permettant d’exploiter la vulnérabilité CVE-2020-5902 affectant les solutions F5 BIG-IP fleurissaient sur le Web, il était possible de s’immiscer dans les SI de deux hébergeurs certifiés HDS dont un disposait également de la qualification SecNumCloud de l’ANSSI par le biais d’interfaces d’administration vulnérables exposées sur Internet [4].

Troisième incident qui m’a été raconté, un établissement voit plusieurs de ses machines (serveurs et postes clients) « monter dans les tours » (charge CPU à 100%). Après investigation, accompagné notamment par la cellule ACSS [5], l’établissement découvre qu’il est victime d’un crypto miner qui a pu être déployé par le biais de l’accès VPN d’un prestataire qui avait été compromis. Un cas malheureusement assez classique, qui nous rappelle l’importance de la mise en place d’une authentification multi facteurs, d’un bastion ou d’une solution de PAM, quand on peut se le permettre.

Quatrième et dernier incident, j’ai gardé le meilleur pour la fin. Un ami qui travaille lui aussi dans le secteur de la santé me dit, « tu veux rire ». L’opérateur télécoms lui fournissant un réseau privatisé MPLS permettant d’interconnecter ses différents sites semble s’être emmêlé les crayons et a raccordé son réseau MPLS avec celui d’un autre de ses clients… Il est tout de même important de noter que c’est l’établissement de santé qui a été le seul à détecter cet incident. Je crois que nous pouvons lui tirer notre chapeau ! Après avoir observé un nouveau flux vidéo apparu dans sa solution de supervision, il lance les investigations. Pensant tomber sur une caméra de vidéo protection d’un des sites, il tente une connexion sur l’interface Web de la caméra alors inconnue, qui était protégée par un couple identifiant / mot de passe admin / admin et se retrouve à visionner… un champs de course ! Un incident pas banal qui rappelle bien l’intérêt d’une supervision maîtrisée et la véracité de l’adage : la confiance n’exclue pas le contrôle…

Source : https://cybernews.com/security/french-pharmaceuticals-distribution-platform-leaking-1-7-tb-confidential-data/. 

[1] https://cybernews.com/security/french-pharmaceuticals-distribution-platform-leaking-1-7-tb-confidential-data/

[2] https://www.cnil.fr/fr/moteur-de-recherche-et-danalyse-elasticsearch-4-bonnes-pratiques-securite

[3] https://www.nolimitsecu.fr/interview-renaud-feil/

[4] https://www.dsih.fr/article/3842/cve-2020-5902-ou-comment-s-immiscer-au-coeur-du-si-via-une-breche-dans-les-solutions-f5-big-ip.html

[5] https://cyberveille-sante.gouv.fr/

#sécurité#cnil#HDS