(Este post ha sido elaborado por Joan Balbastre y Jesús Galvez con la colaboración de Maite Moreno en su redacción).
En el pasado SummerCon, celebrado este verano, la comunidad se hacía eco de la investigación sobre vulnerabilidades en algunos productos clínicos para la inyección de medicamentos, llevada a cabo por el investigador Billy Rios, y centrada en la línea de productos fabricada por Hospira, la cual tiene mas de 400.000 bombas distribuidas por hospitales de todo el mundo.
Tras sus primeras investigaciones, Ríos descubrió que un atacante de forma remota podría alterar el funcionamiento de estas bombas de inyección, siendo capaz de administrar dosis letales de fármacos. Una de las vulnerabilidades indica que el software encargado de almacenar los umbrales para la administración segura de las dosis (“biblioteca de medicamentos”) podía ser manipulado para cargar nuevos umbrales debido a la inexistencia de autenticación para su acceso. Esto provocaría que, aunque por un error humano en la inserción de valores se sobrepasara el nivel de la dosis suministrada (o se quedara corto), no le saltaría ninguna alerta al personal clínico.
Ilustración 1: FIG.1 Ilustra un dispositivo médico; FIG.2 Proceso de instalación de una actualización.
La alarma mundial ante el riesgo de que se pudiera acceder de forma remota a estas bombas de inyección de pacientes y alterar las dosis que pudieran dañar e incluso llevarlo a la muerte crecía y no sin razones, ya que Ríos insistía en que era viable que un atacante cambiara el firmware de estas bombas de forma remota y variara las dosis de los medicamentos. Tan solo era necesario acceso a la red hospitalaria a la que está conectado el dispositivo médico.
El software desarrollado por Hospira que actúa como servidor encargado de enviar las actualizaciones de la biblioteca de medicamentos es MedNet, actualizaciones que son procesadas por el módulo de comunicaciones de cada dispositivo que se encuentra a la escucha. Ríos descubrió que MedNet podría ser utilizado para llevar a cabo cambios en la configuración y firmware del dispositivo, además de para poder instalar malware o usar publicaciones no autorizadas de librerías de medicamentos ya que dichas “bibliotecas” no requieren autentificación ni llevan una firma digital. Al estar el módulo de comunicaciones de la bomba conectado a la red del hospital de forma inalámbrica, cualquiera con acceso a la WiFi podría realizar este ataque.
Hospira niega la existencia de dicha vulnerabilidad escudándose en que el módulo de comunicaciones está separado físicamente de la placa de circuitos haciendo, según ellos, imposible este ataque. Ríos explica que esto es indiferente, ya que ambos circuitos se encuentran comunicados a través de un puerto serial, que actúa como puente entre ambos.
Los dispositivos afectados fueron los PCA3,PCA5 LifeCare, los de la línea Symbiq y el modelo Plum A+. Se sospecha que los modelos Plum A+3, Sapphire y Sapphire Plus podrían ser también vulnerables.
Si nos servimos de los manuales de servicio de los modelos comprometidos podemos corroborar los siguiente:
“El módulo de conectividad (CE) está alimentado por la placa de circuitos (PWA) de la unidad de microcontrolador (MCU), empleando la tensión del motor como fuente de energía (VMOT). La alimentación de la CE está controlada por la señal POWER CE OFF* que se encarga de conectar y desconectar la unidad.”
Es decir, existe conexión entre las unidades del microcontrolador y de conectividad, por lo menos en cuanto a tensión de alimentación se refiere.
“El microcontrolador está dotado de dos interfaces, una para el módulo de comunicaciones y otra para el acceso por código de barras. Pueden ser operadas independientemente entre ellas y los otros procesos del microcontrolador. Tiene también un tercer puerto serie para la interfaz de periféricos (SPI) que se emplea para conectar el reloj en tiempo real (RTC) al conversor analógico/digital (ADC).”
En otras palabras, aquí es donde encontramos el puerto serie que une la MCU con el CE.
Además encontramos que se detalla el funcionamiento de la conectividad inalámbrica del dispositivo y, lo que es más importante, como la memoria flash del circuito del microcontrolador se programa a través del puerto serie RS-232 que comunica la MCU con el módulo de comunicaciones.
Observando los diagramas electrónicos contenidos en el manual técnico corroboramos todo lo antes mencionado:
Ilustración 2: Detalle del circuito impreso de la unidad de microcontrolador. En rojo, la carga de los puertos serie.
Ilustración 3: Detalle del puerto serie de la placa de circuito impreso de la unidad del microcontrolador, que conecta con el módulo de comunicaciones.
Con lo cual se reafirma todo lo que Ríos comentaba en sus declaraciones.
Finalmente, la FDA, organismo que regula la tecnología clínica publicó una alerta solo para los modelos PCA3 y PCA5 y el ICS-CERT publicaba un informe sobre las distintas vulnerabilidades que afectaban al producto PCA5 y anteriores:
-
Stack-based buffer overflow (CVE-2015-3955).
-
Autorización inadecuada (CVE-2015-3459).
-
Verificación insuficiente de autenticidad de datos(CVE-2014-5406).
-
Uso de contraseñas escritas en código (CVE-2015-1011).
-
Información sensible almacenada en texto claro (CVE-2015-1012).
-
Error en la gestión de claves (CVE-2015-3957).
-
Uso de una versión de software vulnerable (AppWeb V.1.0.2).
-
Consumo de recursos no controlado (CVE-2015-3958).
Además de una serie de recomendaciones a seguir mientras no se liberaba un nuevo software que solucionara estos problemas.
Hasta ahora no parece que hayan evidencias reales de intentos de ataques a este tipo de dispositivos médicos con el objetivo de dañar a una persona…pero puesto que las posibilidades existen la pregunta que os lanzamos es:
¿Están realmente protegidos ante ataques cibernéticos los dispositivos médicos? ¿Qué opináis?
