Vous êtes dans : Accueil > Tribunes libres >

Def Con 2018 : le chercheur Douglas McKee récupère et modifie les constantes vitales d’un patient

Charles Blanc-Rolin, MARDI 21 AOûT 2018

La Def Con figure parmi les conférences les plus incontournables dans le domaine de la sécurité numérique. Pour sa 26ème édition à Las Vegas qui s’est déroulée du 9 au 12 août, la sécurité des dispositifs médicaux faisaient partie, une fois encore des sujets phares de l’évènement.  

Douglas McKee, chercheur en sécurité chez McAfee, s’est lancé dans l’aventure de la rétro-ingénierie d’un protocole de communication réseau spécifique au secteur de la santé, le protocole RWHAT. Pour cela, il s’est rendu sur eBay, et a investi dans un moniteur patient et une console de surveillance centralisée, comme nous pouvons en trouver dans nos services de réanimation ou de soins continus par exemple. Première surprise pour le chercheur, malgré le fait que ces dispositifs soient toujours très présents dans les hôpitaux, la console utilise un système d’exploitation obsolète : Windows XP Embedded. Jusque là, rien qui ne fera lever le sourcil d’un RSSI santé.

Il a alors commencé par jouer le cobaye, avant de céder sa place à un simulateur ECG, afin d’étudier les échanges réseau entre le moniteur et la console de surveillance centralisée.

doug_mckee

En analysant les échanges à l’aide de l’analyseur de trames Wireshark, et en décortiquant quelques binaires présents sur la console de surveillance, il a pu établir plusieurs constats.

Premiers constat, les deux appareils communiquent « en clair » via UDP [1]. L’absence de chiffrement dans ce protocole baptisé RWHAT, expose les données relatives aux patients sur le réseau.
Il est donc possible pour toute personne connectée à ce même réseau, de voir passer grâce à une simple analyse de trames, des informations sensibles telles que le nomprénomdate de naissanceet numéro de chambre du patient, ainsi que ses constantes vitales.

wireshark_name

Autre constat étonnant, les deux appareils n’ont pas besoin d’être configurés pour dialoguer l’un avec l’autre, à partir du moment où ils sont connectés à un même réseau, ils sont capables de communiquer.
Pour arriver à cette conclusion, le chercheur s’est appuyé sur le broadcast [2] effectué par chaque appareil connecté au réseau en l’absence l’autre.
Pour résumer simplement, la console qui écoutent sur le port 7000 / UDP, interroge toutes les 10 secondes l’ensemble du réseau à la recherche de moniteurs susceptibles de lui parler sur ce même port, et de son côté, le moniteur envoi les informations relatives au patient sur le port 7000 / UDP à l’ensemble du réseau. Excellente idée non ? C’est un peu comme si pour engager la conversation avec le médecin, l’infirmière criait toutes les 10 secondes dans tout l’hôpital : « le patient Bernard Dupont, né le 17 jullet 1972, à la chambre 154 a 16 de tension et un rythme cardiaque de 140 bpm » en espérant qu’un médecin se manifeste en disant, je prend !

Malgré l’utilisation du protocole UDP, Douglas McKee a constaté l’établissement d’une connexion entre les deux appareils assez ressemblante à celle qui peut se produire lors de l’utilisation de TCP, le fameux three-way handshake [3].

handshake 

D’après ses différentes analyses, c’est la console qui va déterminer le port qui va être utilisé pour la communication.

Parti de ces constats, il a donc réalisé un script permettant de forger des paquets avec l’outil Scapy[4], émulant un rythme cardiaque de 80 bpm, placé sur un Raspberry pi connecté au réseau en lieu et place du moniteur patient. Il a ainsi pu faire croire à la console de surveillance centralisée qu’un moniteur avec un patient sous surveillance était connecté au réseau.

emmulation

Pour aller plus loin et démontrer qu’il était possible de modifier les constantes patients perçues par la console en temps réel, Douglas McKee a réalisé son attaque via une machine Kali connectée au réseau depuis laquelle il a commencé par « paralyser » le moniteur avec une attaque de type ARP spoofing [5]. Il a fait croire au moniteur que sa machine Kali avait la même adresse IP que la console de surveillance centralisée, créant ainsi un « pseudo » conflit d’adresse IP pour le moniteur.

ip_conflict

Le moniteur neutralisé, il a ensuite pu émettre des paquets, toujours grâce à Scapy, diffusant les constantes souhaitées, passant ainsi le rythme cardiaque affiché sur la centrale de 30 bpm à 180 bpm.

Alors que le rythme cardiaque enregistré par le moniteur était de 80 bpm.

false_value

Cette brillante démonstration nous rappelle une fois encore, l’extrême vulnérabilité des dispositifs médicaux connectés et l’intérêt de les placer dans des réseaux cloisonnés et si possible « surveillés ». Elle nous rappelle également les risques vitaux pour le patient, car ici, au-delà du risque de perte de confidentialité, c’est la vie du patient qui peut se retrouver menacée, avec un mauvais diagnostic, une mauvaise médication ou encore le non déclenchement d’alarmes sur les constantes vitales, le tout pouvant entraîner le décès du patient.

N’oublions jamais qu’avec les dispositifs médicaux, à l’autre bout du câble, c’est le patient qui est connecté !


[1] https://fr.wikipedia.org/wiki/User_Datagram_Protocol

[2] https://fr.wikipedia.org/wiki/Télédiffusion 

[3] https://fr.wikipedia.org/wiki/Three-way_handshake

[4] https://fr.wikipedia.org/wiki/Scapy -  https://scapy.net/ 

[5] https://fr.wikipedia.org/wiki/ARP_poisoning

Pour approfondir : https://securingtomorrow.mcafee.com/mcafee-labs/80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals/

#sécurité#dispositifs médicaux#numérique#patient##medical