Une image DICOM « infectée » par du code malveillant, oui c’est possible !
23 avril 2019 - 10:58,
Tribune
- Charles Blanc-Rolin
Le 9 avril, le chercheur Markel Picado Ortiz (@D00RT_RM) [2] publiait sur Github un POC [3] démontrant qu’il était possible d’insérer un exécutable Windows dans un fichier d’image au format DICOM. Un article du 16 avril publié sur le blog de la société Cylera [4], laboratoire pour lequel il travaille, revient en détails sur ses travaux.
Il a tout d’abord tiré parti des 128 octets de préambule que contiennent les fichiers DICOM.
Certains vous diront qu’il s’agit d’une erreur de conception, le standard DICOM lui évoque une fonctionnalité. « It’s not a bug, it’s a feature ». Au delà de la plaisanterie, cette section de préambule a bien une utilité : rendre compatible un fichier DICOM avec une application multimédia, tel qu’une visionneuse d’images JPG et autres, qui n’est pas capable de lire nativement un fichier au format DICOM.
Le standard DICOM n’impose aucune exigence de structuration de cette zone, et peu importe ce qu’elle contient, elle n’altère en rien la lecture du fichier.
Markel Picado Ortiz en a donc profité pour insérer une entête d’exécutable Windows dans le préambule :
Puis, il a ensuite placé du code après les données relatives à l’image, dans ce fichier devenu « polyglotte ».
L’image reste lisible par n’importe quel lecteur DICOM :
Ici sous Windows
Ici sous Linux
Mais si l’extension du fichier est remplacée par « .exe », ou si le fichier, même avec son extension originale est lancé depuis une invite de commande, c’est l’exécutable Windows qui prend le dessus !
Même si le code contenu dans le fichier à la suite de l’image ne sera pas exécuté par le lecteur DICOM lui même, à moins d’une attaque très ciblée, avec la connaissance du lecteur utilisé par la victime et en exploitant une vulnérabilité de ce même lecteur (autant dire « quasi improbable »), de nombreux scénarios d’attaques restent facilement imaginables...
Dans une seconde partie du POC, Markel Picado Ortiz présente la possibilité de modifier automatiquement tous les fichiers DICOM qu’il trouve sur la machine, mais également sur des partages réseau SMB… dans le fonctionnement, cela nous rappelle bien des choses… imaginons que chaque fichier infecté soit capable d’en infecter d’autre, ce serait le pompon !
Même si le POC ne le montre pas, il est important de garder en tête que les informations relatives aux patients qui transitent « en clair » sur le réseau lors d’échanges sur le protocole DICOM, apparaissent également « en clair » dans les fichiers et peuvent donc être facilement modifiées. Lors de la réception de fichiers DICOM les modalités d’imagerie ou PACS n’effectuent aucune vérification de l’intégrité des fichiers via un calcul d’empreinte ou une signature numérique.
Le standard, dont la première version connue sous le nom de ACR-NEMA 300 est né 1985. Il aura fallut attendre 2018 pour qu’il intègre le chiffrement des communications via TLS. Il devrait se passer encore pas mal d’années avant que les constructeurs l’implémentent, et que nos établissements en disposent.
Quand on voit qu’aujourd’hui, l’un des plus important FAI français n’a toujours pas implémenté STARTLS sur sa messagerie, on peut aisément penser que d’ici vingt ans, des images DICOM pas plus sécurisées qu’aujourd’hui, continueront de transiter « en clair » sur les réseaux de nos SIH. D’où l’importante de continuer à bien les protéger...
[2] https://twitter.com/D00RT_RM
[4] https://labs.cylera.com/2019/04/16/pe-dicom-medical-malware/
