Un deuxième fournisseur polonais de logiciels médicaux a été touché en quelques semaines. Les attaquants ont utilisé une faille d'injection SQL pour voler des données de patients chez Medyc, une plateforme vendue par QBUSoft aux cabinets médicaux et aux cliniques. La fuite de données Medyc en Pologne exposant des numéros PESEL fait suite à un incident bien plus important en août, et ensemble, ils montrent l'ampleur du risque qui pèse sur les fournisseurs derrière les logiciels de clinique, et non sur les patients dont ils détiennent les dossiers.

Les détails ci-dessous proviennent d'un reportage de Help Net Security. Certaines parties du résumé original étaient tronquées, donc cet article s'en tient à ce qui a été confirmé.

Ce qui a été volé chez Medyc

Medyc est une plateforme que les cabinets médicaux et les cliniques utilisent pour gérer l'enregistrement des patients, les dossiers et les ordonnances. Selon le rapport, des pirates ont volé des données de patients chez le fournisseur en exploitant une vulnérabilité d'injection SQL.

Le reportage indique que les informations volées comprennent des coordonnées et des numéros PESEL, les numéros d'identification nationaux utilisés en Pologne. L'ampleur complète du vol chez Medyc, y compris le nombre de patients concernés, n'était pas disponible dans l'extrait fourni, nous n'allons donc pas avancer de chiffre.

Les numéros PESEL sont importants car ils constituent un identifiant durable. Contrairement à un mot de passe, une personne ne peut pas facilement en changer. Lorsqu'il est associé à un nom et à des coordonnées, il peut être utilisé pour rendre les tentatives d'usurpation d'identité plus convaincantes.

Comment la fuite MyDr a préparé le terrain

L'incident Medyc ne s'est pas produit isolément. En août, des attaquants ont volé les données de près de 19 millions de personnes chez MyDr, une entreprise basée à Varsovie dont le logiciel est utilisé par environ 12 000 établissements de santé. La base de données divulguée contenait également des numéros PESEL.

C'est cette échelle qui est importante. Un seul fournisseur desservant des milliers d'établissements détient les dossiers d'une grande partie de la population d'un pays en un seul endroit. Lorsque ce fournisseur est compromis, chaque clinique qui en dépend est affectée en même temps, et les patients ignorent souvent quel logiciel utilise le cabinet de leur médecin.

Le cas Medyc ajoute un deuxième point de données. Deux fournisseurs différents, deux fuites, et les deux impliquent le même type d'identifiants sensibles. Ce schéma suggère que les attaquants considèrent les fournisseurs de logiciels médicaux comme des cibles efficaces, puisqu'une seule intrusion réussie peut rapporter les dossiers de nombreuses cliniques.

Pourquoi l'injection SQL continue de frapper les fournisseurs de santé

L'injection SQL est l'une des vulnérabilités web les plus anciennes et les mieux comprises. Elle se produit lorsqu'une application transmet une entrée fournie par l'utilisateur dans une requête de base de données sans séparer correctement les données des commandes. Un attaquant peut alors concocter une entrée qui modifie la requête et amène la base de données à renvoyer des informations qu'elle ne devrait pas.

Le correctif est bien connu : requêtes paramétrées, validation des entrées, comptes de base de données à privilèges minimaux et tests réguliers. Pourtant, la faille continue d'apparaître, en particulier dans les logiciels qui se sont développés au fil de nombreuses années ou qui gèrent de nombreuses intégrations. Les plateformes de santé correspondent souvent à cette description, puisqu'elles traitent les formulaires d'enregistrement, les ordonnances et les recherches de dossiers via des composants exposés au web.

La même classe de vulnérabilité apparaît bien au-delà de la médecine. Notre couverture des attaquants exploitant une injection SQL zero-day non corrigée dans GeoServer montre comment un type de faille peut être utilisé contre des plateformes très différentes. La leçon est constante : lorsqu'une application exposée à Internet communique avec une base de données, les requêtes non sécurisées constituent un risque sérieux.

Ce que cela signifie pour vous

Si vous êtes un patient en Pologne, vous ne pouvez probablement pas savoir si votre clinique utilise Medyc, MyDr ou un autre système. C'est là le problème central. Vos données se trouvent chez un tiers que vous n'avez pas choisi, et vos propres habitudes de sécurité ont peu d'influence sur la façon dont ce tiers écrit son code.

Un VPN chiffre le trafic entre votre appareil et un serveur. Il ne protège pas une base de données qu'un fournisseur stocke et qu'un attaquant atteint via une faille dans l'application même du fournisseur. Il en va de même pour le chiffrement des appareils et les mots de passe forts : ils sont utiles, mais ils n'arrêtent pas une fuite côté fournisseur.

Ce que vous pouvez faire, c'est réduire les dégâts si vos informations sont utilisées à mauvais escient :

  • Traitez avec méfiance les appels, SMS ou e-mails inattendus qui mentionnent votre santé, vos ordonnances ou votre PESEL, même s'ils semblent connaître des détails personnels.
  • Ne partagez pas votre PESEL ou vos informations médicales lors d'un contact non sollicité. Contactez la clinique via un numéro que vous recherchez vous-même.
  • Surveillez les avis officiels de votre clinique ou des autorités de régulation concernant l'implication éventuelle de vos données.
  • Utilisez des mots de passe forts et uniques et l'authentification à deux facteurs sur vos comptes e-mail et financiers, car ce sont des cibles courantes après les fuites de données d'identité.
  • Vérifiez vos relevés financiers et de crédit à la recherche d'activités que vous ne reconnaissez pas.

Points clés à retenir

La fuite de données Medyc en Pologne exposant des numéros PESEL, survenant après la fuite MyDr touchant près de 19 millions de personnes, montre que les fournisseurs concentrés de logiciels de santé sont des points de défaillance uniques. Les outils personnels comme un VPN valent la peine d'être utilisés pour la navigation privée, mais ils ne peuvent pas corriger une faille à l'intérieur de la base de données d'un fournisseur. La responsabilité en incombe aux fournisseurs, qui doivent corriger des problèmes de base comme l'injection SQL, et aux autorités de régulation qui les supervisent.

Pour les lecteurs, l'étape pratique est la vigilance face à l'usurpation d'identité et à l'hameçonnage qui utilisent des identifiants divulgués. Pour voir comment le même type de faille est exploité ailleurs, lisez notre rapport sur l'injection SQL zero-day dans GeoServer.