Attaques sur les protocoles de santé
DICOM

En préambule de cet article, et pour une meilleure compréhension, il est vivement conseillé de lire l’article précédent sur le DICOM, de sa description à son utilisation. Dans les précédentes publications sur HL7 et DICOM, il a été constaté que le chiffrement des flux n’était pas systématique lors de la mise en place de ces services. Un certain nombre de risques avaient été évoqués dans l’article sur HL7, mais il avait été choisi de ne pas s’étendre sur ce sujet lors de la description de DICOM. Pour cause, cette partie se penchera sur les risques que représentent les flux ouverts DICOM et les différentes actions malveillantes possibles sur ces interfaces sans aucune authentification.

La réplication de tout ou partie des éléments démontrés dans cet article est répréhensible et pourrait avoir des conséquences extrêmement graves. N’effectuez jamais ces actions sur un réseau non autorisé ou que vous ne maîtrisez pas. 

Lors des recherches effectuées pour cet article, il a été constaté qu’environ 5 300 serveurs DICOM disposent d’une interface exposée sur le web, selon Shodan . La majeure partie de ces serveurs se trouvent aux États-Unis, avec 1400 dans ce pays, pour 118 en France.

Les risques liés à l’exposition de ces machines peuvent paraître abstraits. Il faut considérer que chacun de ces serveurs peut potentiellement contenir des informations personnelles sur les patients, lesquelles sont stockées sur ces systèmes exposés.  Pour mieux appréhender les tenants et les aboutissants de ce genre d’attaques potentielles, il est nécessaire de recréer une infrastructure similaire.

Pour ce faire, inutile de passer par la case achat de matériel d’acquisition, il suffit de répliquer un PACS avec son visionneur d’image.

Création d’une instance de test

Il existe de multiples répertoires GitHub permettant l’installation rapide d’un serveur PACS et de son visionneur d’image DICOM. Le plus intéressant pour réaliser ce test est le projet OHIF with Orthanc car il permet de mettre rapidement en place une infrastructure conteneurisée sans solliciter trop de ressources.

Comme l’indique le nom du projet, le serveur PACS choisi est Orthanc. Développé et maintenu par l’université de médecine de Louvain, Orthanc est très largement utilisé dans le monde entier. La visualisation, quant à elle est assurée par l’applicatif OHIF, créé par le Massachusett’s General Hospital.

Afin d’alimenter la base d’examens, des images DICOM anonymisées et disponibles en open source ont été utilisées.

Voici ce qui peut être maintenant visualisé dans la WebUI  OHIF :

Des visuels de radiographie sont disponibles comme suit :

Concernant la partie Orthanc, voici un visuel de la recherche d’image DICOM disponible sur l’applicatif.

Attaque par extraction 

Dans la configuration nominale disponible sur le github, le serveur Orthanc ne peut pas échanger d’informations avec d’autres entités que le visualiseur. Comme explicité dans l’article précédent, les modalités DICOM doivent nécessairement échanger avec le serveur pour remplir leur rôle.

Afin de recréer un scénario de compromission au plus proche de la réalité, les étapes suivantes seront suivies :

• Phase initiale de découverte des interfaces DICOM
• Bruteforce des AE titles. Un AE Title (Application Entity Title) est un identifiant au format string, une chaine de caractère, utilisé dans les communications DICOM afin d’identifier de manière distincte une application ou un dispositif (comme un scanner, une station de travail, ou un serveur PACS) sur un réseau. Cette partie permettra d’être plus discret lors de l’énumération
• Enumération des données et extraction des objets DICOM (radio) du PACS

Cette démonstration aboutira par une attaque sur les fichiers DICOM et une évaluation des risques associés.

Avant de décrire les différentes phases du scénario opérationnel, quelques rappels sont nécessaires. Les attaques ne seront pas effectuées en exploitant des failles dans les applicatifs Orthanc ou OHIF.

Précédemment, pour accéder aux différents panneaux présents dans les captures d’écrans, des identifiants ont été utilisés, ce qui ne sera pas le cas lors de l’attaque. L’objectif de cette démonstration est de répliquer des actions malveillantes qu’un tiers pourrait réaliser en ligne pour accéder et/ou pour modifier des données dans le but de nuire à un patient ou de revendre ses données. Un des objectifs connexes à cette démonstration est de permettre la création de règles de détection réseau.

Bruteforce des AE Titles

Reconnaissance préalable au bruteforce 

Dans cette phase des tests, l’objectif est de récupérer le plus d’information possible sur le service ouvert afin d’identifier les moyens nécessaires pour réaliser la suite de l’attaque. Pour ce faire, le script NSE Dicom-ping est utilisé afin d’interroger l’interface. Pour cette phase, des modifications de la librairie NSE ont été nécessaires pour gérer certaines erreurs sur les paquets DICOM.

Le retour de la commande NSE est le suivant :

Dans cette première capture, la sortie du script permet de valider que le serveur attaqué dispose bien d’un port DICOM. De plus, grâce à l’indication “Called AET check enabled”, l’attaquant a la capacité de déduire qu’une énumération des AE-Title est possible.

A l’aide de Wireshark, il est possible d’analyser le trafic et d’examiner la requête envoyée et reçue par nos machines :

Dans cette deuxième capture de l’analyseur Wireshark, la présence du terme “reject” permet d’’identifier un élément important. Pas n’importe quel AE-Title ne sera accepté pour initier un échange avec le serveur PACS. Ces informations sont importantes car elles permettent de réaliser plusieurs déductions logiques corroborées par la capture réseau et le retour de commande NSE.

Dans un premier temps et pour échanger avec le serveur PACS, il sera nécessaire de trouver le nom (AE Title) d’un dispositif autorisé à échanger avec le serveur PACS. La vérification des noms de dispositif n’est pas installer/configurer par défaut sur tous les serveurs PACS. Lorsque cette identification est mise en place, elle signifie que les exploitants connaissent leur réseau DICOM. Cela ne constitue pas un élément de sécurité car tout passe en clair et il est très facile d’usurper un AE Title. En revanche, cela peut ralentir l’attaquant ou le pousser à changer de stratégie.

Bruteforce des AET 

L’étape suivante consiste à l’énumération des AE-titles utilisables pour initier une connexion avec le serveur PACS. Pour ce faire, une liste prédéfinie de noms de machines, basée sur une étude de serveurs open-source présents sur le marché, a été établie. Quelques noms communs ont également été ajoutés à cette liste.

Malgré les éléments présents dans la capture d’écran relative à Nmap,  un AE Title correspondant à celui attendu par le serveur Orthanc a bien été identifié. Pour des protocoles très spécifiques, l’usage de Wireshark est recommandé pour s’assurer de la fiabilité des résultats obtenus par des outils automatisés.

Une fois l’identification d’un l’AE-Title valide, il reste à créer le code permettant de réaliser l’énumération. La librairie Pynetdicom est utilisée à cet effet.

Pour démontrer la capacité de récupération des éléments sensibles par l’attaquant, les données seront sélectionnées directement sur le serveur PACS. Plusieurs radiographies seront utilisées afin de mesurer l’exhaustivité de l’énumération.

Enumération de la base de données du serveur PACS

Pour des raisons de clarté et afin d’éviter une série de captures d’écran, seuls les noms génériques des premières radiographies seront présentés :

Voici une partie des données récupérées par le script développé pour réaliser l’énumération.

Pour être plus agnostique sur le type de commande et de service class utilisé pour récupérer les données ci-dessus, la capture suivante reprend toute la séquence de cet échange :

Une fois l’énumération réalisée, l’attaquant dispose de toutes les informations nécessaires à la manipulation des fichiers DICOM. Dès lors, il est aisé pour lui d’extraire les fichiers. Cette extraction sera possible grâce à la récupération d’identifiant unique pour chaque objet DICOM énuméré. Une fois ces identifiants en main, l’attaquant sera en mesure de requêter le serveur PACS afin de récupérer (C-Get) et de stocker (C-Store) les images.

Ci-dessous, un exemple d’extraction des données réalisée sur le lab de test :

Pour résumer les différentes phases d’attaques décrites dans cet article, voici un schéma récapitulatif des échanges/du processus :

L’attaque dans le monde réel

A travers les actions décrites dans cet article, il est pertinent de s’interroger sur la vraisemblance de ce type d’attaque.

Depuis quelques années, un nouveau mode opératoire apparait chez les acteurs ransomware. En effet, certains acteurs délaissent le chiffrement des données pour se concentrer uniquement sur le vol de données et l’extorsion. En d’autres termes, les attaquants extraient les données et menacent de les publier si une rançon n’est pas versée.

Il est également possible de revendre les données médicales associées aux objets DICOM présents sur les serveurs PACS.

Cette démonstration démontre toutes les phases relatives à ce genre d’attaque. Dans un monde où les actes cyber malveillants se multiplient et se diversifient, il ne serait pas surprenant de voir ce type d’action faire la une des médias dans les années à venir.

Les parties précédentes de cet article ont mis en exergue les attaques relatives au protocole DICOM. Dans cette partie, il s’agira de décrire, au travers d’une preuve de concept, la modification des fichiers DICOM afin de les rendre exécutables dans un environnement Windows. Il est important de noter que l’architecture déployée dans le cadre de la partie laboratoire ne permet pas de réaliser les manipulations décrites dans le GIT de ce POC.

Pour résumer, l’attaque sur les fichiers consiste à injecter un portable exécutable Windows dans un fichier DICOM en utilisant les fichiers polyglottes. Les fichiers polyglottes sont des fichiers interprétables dans plusieurs langages. Ici, le but est de réaliser un fichier suivant ce modèle :

Dans cette capture de l’article relatif à cette preuve de concept, il est facile de comprendre comment le fichier DICOM a été modifié. A noter que ce genre d’action est effectué pour les systèmes Windows mais peut être porté sur les bases Linux/OSX. Malgré la complexité de ce POC, cette technique permettrait de réaliser des attaques par supply chain. En effet, si une radio est réalisée dans un cabinet de radiologie puis transmise à un établissement hospitalier, le fichier corrompu deviendrait un vecteur de propagation de virus. La partie la plus complexe dans ce scénario reste l’exécution du fichier à distance. Il faudra en effet modifier le fichier pour le rendre exécutable sur le système cible.

Après avoir décrit des attaques utilisant les fichiers et les échanges réseaux DICOM, il convient d’examiner comment réaliser une détection efficace de ces attaques.

Lorsque l’on parle de détection réseau, on évoque le monitoring des échanges entre un serveur PACS et un terminal de travail ou un appareil d’acquisition. Plusieurs méthodes peuvent être utilisées à cet effet.

La principale consiste en l’utilisation de techniques de détection comportementales. Des exemples concrets seraient :

• Une machine qui n’émet jamais de DICOM et qui se met à échanger soudainement dans ce protocole ;
• Un nombre important de tentatives infructueuses d’appairage ;
• D’autres comportements inhabituels et différents de l’exploitation quotidienne du réseau.

Ces indices peuvent mener à la détection de tentative d’intrusion.

Concernant les fichiers DICOM, plusieurs techniques de détection peuvent également être mises en place au niveau du réseau. L’une d’entres elles consiste en la reconstruction du fichier et en son analyse. Un fichier polyglotte peut ne pas être exécuté lors d’un téléchargement, mais le sera lors de son ouverture par l’utilisateur. Cela pourrait laisser le temps à un EDR (Endpoint Detection and Response) ou à un NDR (Network Detection and Response) d’analyser l’élément et de détecter une anomalie dans le fichier qui contiendra un fichier exécutable et une image DICOM.

Dans cette série d’articles sur le domaine de la santé, plusieurs sujets ont été abordés. Du panorama des menaces aux attaques, ce coup de projecteur sur le domaine de la santé a permis de montrer que ce monde où l’humain et la machine fonctionnent parfois en symbiose est complexe à sécuriser. Au-delà du risque cyber, il est crucial de prendre en compte l’impact potentiel sur la vie humaine d’une attaque sur un appareil biomédical ou sur le système global des établissements de santé.

La double compétence autrefois requise pour réaliser des attaques complexes utilisant des réseaux IT/OT n’est plus totalement d’actualité. En effet, l’essor des IA permet à des attaquants moins expérimentés de réaliser des actions malveillantes contre des systèmes critiques en utilisant de vieux protocoles sans capacité de sécurisation. Cette tendance conduira inévitablement à la multiplication des actions malveillantes et à l’augmentation de la surface d’attaques. Des connaissances considérées comme trop complexes à acquérir, deviennent plus facilement accessibles et utilisables, pour le meilleur et pour le pire.

Auteurs : Purple Team et 0xSeeker