McAfee Enterprise ATR descubre vulnerabilidades en la bomba de infusión B. Braun de uso mundial


Visión general

Como parte de nuestro objetivo continuo de proporcionar productos más seguros para empresas y consumidores, en McAfee Advanced Threat Research (ATR) investigamos recientemente el Bomba de gran volumen B. Braun Infusomat Space junto con B. Braun Estación Espacial, que están diseñados para su uso en instalaciones médicas tanto para adultos como pediátricas. Esta investigación se realizó con el apoyo de Culinda – líder de confianza en el ámbito de la ciberseguridad médica. A través de esta asociación, nuestra investigación nos llevó a descubrir cinco vulnerabilidades no reportadas previamente en el sistema médico que incluyen:

  1. CVE-2021-33886 – Uso de cadena de formato controlada externamente (CVSS 7.7)
  2. CVE-2021-33885 – Verificación insuficiente de la autenticidad de los datos (CVSS 9.7)
  3. CVE-2021-33882 – Falta autenticación para función crítica (CVSS 8.2)
  4. CVE ‑ 2021‑33883 – Transmisión de texto sin cifrar de información sensible (CVSS 7.1)
  5. CVE-2021-33884 – Carga sin restricciones de archivos con tipo peligroso (CVSS 5.8)

Juntas, un actor malintencionado podría utilizar estas vulnerabilidades para modificar la configuración de una bomba mientras la bomba está en modo de espera, lo que da como resultado que se administre una dosis inesperada de medicamento a un paciente en su próximo uso, todo sin autenticación.

Según la política de divulgación de vulnerabilidades de McAfee, informamos nuestros hallazgos iniciales a B. Braun el 11 de enero de 2021. Poco después, respondieron y comenzaron un diálogo continuo con ATR mientras trabajaban para adoptar las mitigaciones que describimos en nuestro informe de divulgación.

El objetivo de este documento es brindar una descripción general y algunos detalles técnicos de la cadena de ataque más crítica, además de abordar los desafíos únicos que enfrenta la industria médica. Para obtener una breve descripción general, consulte nuestro blog de resumen aquí.

Tabla de contenido

Fondo

La parte más importante de cualquier evaluación de producto es una sólida comprensión del propósito y función del producto bajo prueba. Sin esto, es demasiado fácil que la investigación produzca resultados poco significativos. Por lo tanto, para esta investigación, primero es importante responder a estas sencillas preguntas. ¿Qué son las bombas de infusión? ¿Qué investigación de seguridad ya se ha realizado?

¿Qué son las bombas de infusión?

Para comenzar con lo básico utilizando un recurso confiable: fda.gov dice: "Una bomba de infusión es un dispositivo médico que administra líquidos, como nutrientes y medicamentos, al cuerpo de un paciente en cantidades controladas". La FDA continúa explicando que normalmente los utiliza un "usuario capacitado que programa la velocidad y la duración". Las bombas de infusión pueden ser simples, administrando un solo medicamento intravenoso (IV) en el hogar, o complejas, administrando múltiples medicamentos simultáneamente en el entorno de la UCI. Desde la década de 1960 hasta el 2000, las bombas de infusión eran en su mayoría dispositivos electromecánicos con algunos componentes electrónicos integrados, pero el cambio de siglo produjo dispositivos "más inteligentes" con mejores mecanismos de seguridad y la posibilidad de programarlos, lo que abrió lentamente la puerta a los desafíos de seguridad de la información. Referencia cruzada del producto específico que hemos elegido mirar, el Bomba de gran volumen Infusomat® Space® (Figura 1), vemos que esta bomba está diseñada solo para un entorno médico y no está diseñada para un usuario doméstico. Las bombas de infusión existen principalmente para eliminar la necesidad de realizar una infusión manual, que requiere la conversión de la dosis en gotas por minuto y el recuento visual de las gotas para establecer una velocidad que requiere mucho tiempo y no es confiable. Se estima que hay más 200 millones Las infusiones intravenosas administradas a nivel mundial cada año, y las ventas de bombas intravenosas en los EE. UU. En 2020 fueron de $ 13.5 mil millones. Claramente, las bombas de infusión han consolidado su lugar en el mundo médico.

Figura 1: Bomba Infusomat B. Braun

¿Qué investigación de seguridad ya se ha realizado?

Dado que las bombas de infusión son una parte tan importante del campo médico y existen varios tipos diferentes, es razonable esperar que nuestro equipo no sea el primero en preguntar por su seguridad. Como era de esperar, ha habido muchos proyectos de investigación diferentes sobre bombas de infusión a lo largo de los años. Quizás la investigación más conocida se presentó en 2018 en Blackhat por Billy Rios y Johnathan Butts. La parte de la bomba de infusión de su investigación se centró en las bombas de insulina de Medtronic. Descubrieron que podían dosificar de forma remota a un paciente con insulina adicional debido al tráfico de texto sin cifrar y la capacidad de emitir un ataque de repetición. Incluso antes, en 2015 Se publicó una investigación sobre la bomba de infusión Hospira Symbiq que muestra que era posible modificar los archivos de la biblioteca de medicamentos y aumentar los límites de dosis a través de “operaciones imprevistas”, aunque se requería autenticación.

Por supuesto, para nuestro propósito, la pregunta más importante sigue siendo: ¿se ha realizado alguna investigación previa en nuestro dispositivo específico? Inicialmente la respuesta fue no; sin embargo, durante nuestro proyecto de investigación, un estudio muy amplio, ManiMed, fue lanzado bajo los auspicios de las autoridades alemanas para examinar la seguridad de los dispositivos médicos conectados a la red producidos o en uso en su país. Esto incluyó la investigación realizada en la bomba B. Braun Infusomat. Este es un trabajo fantástico que cubre muchos dispositivos conectados a la red. Haremos referencia a este estudio y hablaremos sobre sus hallazgos cuando sea apropiado a lo largo de este documento, ya que además exploramos nuestras mejoras a esta investigación y demostramos un nuevo ataque que anteriormente se consideraba imposible.

Motivación del proyecto

Si consideramos la sección de Antecedentes antes, se hace evidente que todavía hay una gran cantidad de investigación crítica por realizar en este espacio. Las bombas de infusión son un área prominente y en continuo desarrollo dentro del espacio de los dispositivos médicos, donde la investigación previa solo ha arañado la superficie. Debido al impacto crítico potencial y al estado de la seguridad de los dispositivos médicos, muchos proyectos anteriores no necesitaban profundizar mucho para encontrar problemas o inquietudes de seguridad. La industria de las bombas de infusión tiene numerosos dispositivos que no se han investigado públicamente en absoluto, y aún más que solo recibieron un análisis superficial de la comunidad de seguridad de la información. Por estas razones, decidimos echar un vistazo en profundidad a uno de los mayores proveedores de bombas de infusión, B. Braun, y centrarnos específicamente en uno de sus dispositivos utilizados en todo el mundo para analizarlo a una profundidad nunca antes vista. Al abordar todos los aspectos de esta bomba, queríamos responder a la pregunta básica: en un escenario realista, aprovechando las vulnerabilidades de seguridad originales, ¿podría un atacante malintencionado afectar la vida humana?

Descripción del sistema

Para este proyecto de investigación, nuestro sistema constaba de tres componentes principales: una bomba de gran volumen B. Braun Infusomat modelo 871305U (la bomba de infusión real), una SpaceStation modelo 8713142U (una estación de acoplamiento con capacidad para 4 bombas) y un componente de software llamado versión SpaceCom 012U000050. Estos modelos y el software correspondiente para el sistema B. Braun Infusomat se lanzaron en 2017. En industrias como la electrónica de consumo, esto se consideraría obsoleto y, por lo tanto, menos relevante para la investigación. Sin embargo, como se discutió anteriormente, en el campo de la medicina, este simplemente no es el caso. Dado que los dispositivos más antiguos todavía se utilizan ampliamente y quizás se desarrollaron originalmente con un menor énfasis en la seguridad, aumenta la importancia de investigarlos. Para la debida diligencia, consultamos y confirmamos con nuestros socios de la industria que este modelo específico todavía se estaba utilizando activamente en los sistemas hospitalarios de todo el país.

SpaceCom es un sistema Linux integrado que puede funcionar con la bomba desde su paquete de batería inteligente o desde el interior de la SpaceStation. Sin embargo, cuando la bomba se conecta a la SpaceStation, la SpaceCom de la bomba se desactiva. Realizamos la mayor parte de nuestra investigación con la bomba conectada a la SpaceStation, ya que descubrimos que este era el caso de uso más común. Si una SpaceStation se vio comprometida, podría afectar potencialmente a varias bombas a la vez. SpaceCom actúa como el módulo de comunicación externo para el sistema y está separado de las operaciones internas de la bomba, independientemente de dónde esté funcionando.

Si consideramos la bomba conectada a la SpaceStation como un sistema, tiene tres sistemas operativos separados que se ejecutan en tres conjuntos de chips distintos. SpaceCom que se ejecuta en SpaceStation ejecuta una versión estándar de Linux en un chipset PowerPC. El módulo WIFI para SpaceStation también ejecuta una versión estándar de Linux en un chipset ARM y se comunica a través de un bus PCI con SpaceCom. Por último, la bomba ejecuta su propio sistema operativo en tiempo real (RTOS) personalizado y firmware en un microcontrolador M32C. Se utiliza un microcontrolador adicional para monitorear el microcontrolador M32C, pero esto va más allá del alcance de nuestra investigación. Debido a este diseño modular y aislado, el módulo de comunicación Spacecom y la bomba necesitan una ruta dedicada para intercambiar datos. Esto se resuelve a través de un bus CAN, compartido en toda la SpaceStation, donde permite que las bombas y los accesorios se comuniquen entre sí. Esto es en lo que SpaceCom y cualquier bomba acoplada a la Estación Espacial confían para su intercambio. Un diagrama de arquitectura a continuación ayuda a demostrar la disposición y el diseño del sistema cuando hay una bomba en la estación de acoplamiento.

Figura 2: Arquitectura del sistema

Funciones y componentes de software de SpaceCom

SpaceCom contiene muchas piezas diferentes de software y aplicaciones patentados para respaldar las muchas funciones del ecosistema más grande de instalaciones médicas y de B. Braun. Nuestro equipo dedicó tiempo a analizar cada uno de ellos con gran detalle; sin embargo, para el propósito de este documento, solo tocaremos los componentes clave que son importantes para los hallazgos más críticos que se mencionan en el resumen de apertura.

Una función importante de SpaceCom es poder actualizar la biblioteca de fármacos y la configuración de la bomba almacenada en la bomba. La biblioteca de medicamentos contiene información como la sala y el departamento, una lista de medicamentos preconfigurados con sus concentraciones predeterminadas, mensajes de información que se imprimirán en la pantalla cuando se seleccionen y, lo que es más importante, límites suaves y estrictos para evitar errores de medicación. Uno de los mayores puntos de venta de las bombas de infusión inteligentes es su capacidad para prevenir la dosificación incorrecta de medicamentos, lo que se logra en parte a través de los límites de la biblioteca de medicamentos. Otro riesgo que la farmacoteca ayuda a mitigar es el error humano. Al tener las dosis y longitudes de infusión más comunes preprogramadas en la bomba, elimina los errores asociados con los cálculos de velocidad y el recuento de gotas mencionado anteriormente, asociados con la terapia de infusión manual.

El RTOS de la bomba contiene una base de datos de más de 1500 pares clave / valor utilizados durante el funcionamiento. Estos datos constan de todo, desde el estado de los componentes actuales, la vida útil de la batería, la velocidad del motor, las alarmas y los valores utilizados para la calibración del tubo. Como tal, estos datos se considerarían extremadamente sensibles en el contexto del funcionamiento de la bomba y no están destinados a tener interacción directa con el usuario, ni se presentan al usuario. Un subconjunto de las claves se puede modificar indirectamente a través de un software de servicio dedicado por técnicos certificados.

Para interactuar con la biblioteca de fármacos y la configuración de la bomba en la bomba de SpaceCom, se utiliza un binario exclusivo llamado PCS. El binario de PCS usa el canon binario para interactuar con el bus CAN para enviar comandos al sistema de la bomba para leer y escribir valores basados ​​en la biblioteca de medicamentos o la configuración de la bomba que se le proporcionó. La interfaz principal para realizar esta tarea es a través de un protocolo de red TCP patentado, que de forma predeterminada se envía a través del puerto 1500. Este protocolo no está autenticado ni encriptado y confiamos mucho en estas debilidades para nuestra investigación y ataques. Además, esto resultó en la presentación de CVE-2021-33882 y CVE ‑ 2021‑33883 como se indica en la descripción general anterior.

Detalles del escenario de ataque crítico

Metas

¿Cuál podría ser el objetivo de un atacante malintencionado? Hablando de manera realista, se ha demostrado que la mayoría de los ataques tienen motivaciones económicas. Al traducir esto a nuestra bomba de infusión, la pregunta es: ¿Por qué pagarían grandes sumas de dinero los ejecutivos médicos, sin dudarlo? Si miramos los eventos recientes, en mayo de 2021, Colonial Pipeline piratas informáticos pagados 4,4 millones de dólares para que su oleoducto vuelva a funcionar debido a los ataques de ransomware. Los ataques a los entornos de atención médica están aumentando con el FBI estimando un ciberataque con ransomware "Ryuk" recaudó 61 millones de dólares durante un período de 21 meses en 2018 y 2019. Los ataques ahora muestran un potencial de daño para el paciente con uno ejemplo a partir del 28 de octubreth, 2020. La Red de Salud de la Universidad de Vermont fue parte de un ataque coordinado más grande contra múltiples servicios de salud de EE. UU. Que resultó en la pérdida completa de su sistema de registros médicos electrónicos durante semanas. Los resultados del ataque basado en ransomware provocaron que el 75% de los pacientes de quimioterapia activa fueran rechazados, el cambio de ruta de las ambulancias y retrasos en las pruebas y el tratamiento. Teniendo en cuenta que las bombas intravenosas apoyan directamente la vida humana en algunos casos, es fácil sugerir que un atacante podría exigir cualquier monto de “rescate” aprovechando las amenazas para pacientes reales. Por lo tanto, para lograr esto, un atacante necesitaría controlar el funcionamiento de la bomba.

Esta tarea es más fácil de decir que de hacer cuando se considera el diseño de la bomba como se describe anteriormente. El tradicional "rootear" en el componente de red (SpaceCom) resulta ineficaz. Para realizar cambios en la bomba en sí, un atacante debe interactuar con el RTOS de la bomba, que no está conectado a la red. En esta sección proporcionamos un resumen de cómo pudimos lograr este objetivo mediante el uso de los cinco CVE informados.

Acceso inicial

Aunque obtener acceso de root en SpaceCom no nos proporcionará todo lo que necesitamos para lograr el objetivo final, sigue siendo el primer paso. Durante nuestro reconocimiento y enumeración del sistema, descubrimos una interfaz remota escuchando en https: // ipaddress / rpc. Esta interfaz estaba conectada a un fuente abierta servicio denominado "json-dbus-bridge". Como se describe en GitHub, este servicio “es una aplicación fast-cgi que brinda acceso a D-Bus. Acepta llamadas JSON-RPC y las traduce a llamadas D-Bus. Cualquier respuesta se convierte de nuevo a JSON y se envía al cliente ". Esto despertó nuestro interés, ya que el acceso externo al subsistema D-Bus podría proporcionarnos acceso a la comunicación interna, que puede tener un nivel de seguridad diferente al de las redes externas típicas.

Al realizar cualquier tipo de investigación de vulnerabilidades, valoración o evaluación de la seguridad del producto, es fundamental no olvidar buscar problemas existentes en componentes de terceros. Esto es aún más importante ya que estamos trabajando en un software lanzado en 2017. Mientras recorríamos las páginas de GitHub en busca de json-dbus-bridge, notamos una vulnerabilidad de cadena de formato que era parcheado en 2015. Por supuesto, tuvimos que probar si la versión que encontramos tenía la vulnerabilidad existente.

Figura 3: Prueba de vulnerabilidad de cadenas de formato

Las pruebas de la Figura 3 confirmaron la existencia de la vulnerabilidad de picadura de formato. Si bien esta vulnerabilidad de cadena de formato se descubrió públicamente en 2015 en el código json-dbus-bridge, la actualización nunca se incluyó en el software de B. Braun y, por lo tanto, cumplió la condición para una divulgación de vulnerabilidad de día cero específica del proveedor. Esto fue archivado como CVE-2021-33886 y fue nuestro primer descubrimiento informado a B. Braun. Durante las próximas semanas pudimos aprovechar esta vulnerabilidad y crear un exploit funcional para ganar www acceso de shell de nivel de usuario al dispositivo. Debido al impacto potencial en los dispositivos no parcheados, no se han incluido los detalles técnicos exactos de nuestro exploit.

Escalada de privilegios

Aunque el acceso del usuario es el primer paso, se necesitará acceso de root para interactuar con el bus CAN para comunicarse con la bomba real. Un buen objetivo y un proceso conocido para la escalada de privilegios es encontrar un binario propiedad de root con el bit setuid habilitado. No pudimos encontrar uno listo para usar; sin embargo, la interfaz web tiene una opción para realizar copias de seguridad y exportar la configuración que se basa en tarring una carpeta que contiene un puñado de archivos y encriptarla con AES usando una contraseña proporcionada por el usuario. El archivo de copia de seguridad se puede descargar para restaurar posteriormente la configuración. Al restaurar esta copia de seguridad, root es el usuario que realiza deshacer de tal manera que los permisos de archivo se conservan del archivo tar proporcionado. Por lo tanto, si podemos alterar el archivo, podríamos crear un escenario de escalada de privilegios.

Para usar esto en nuestro beneficio, necesitamos incrustar un binario en el archivo de respaldo propiedad de root con el bit "setuid" establecido para que podamos usarlo para elevar los privilegios. Irónicamente, el código responsable de la importación / exportación de configuraciones ya está haciendo la mayor parte del trabajo por nosotros. El binario "configExport" ubicado en el sistema de archivos es un contenedor para llamar a setuid / setgid (y desinfectar las entradas) que luego llama a execve en el script "/configExport/configExport.sh". Podemos usar un editor hexadecimal para cambiar qué script está ejecutando el binario "configExport" y reemplazar "configExport.sh" con un script controlado por el atacante, mientras también parcheamos la desinfección de entrada. En su lugar, podríamos haber compilado nuestro propio binario, pero este enfoque nos ahorra un par de horas de diversión de compilación cruzada de PPC.

Mientras trabajábamos en este componente de nuestra cadena de ataque, los investigadores que trabajaban en el proyecto ManiMed, en coordinación con B. Braun, publicaron un reporte que incluyó este hallazgo, que figura como CVE-2020-16238 en el sitio web de B. Braun. Como se describe en la sección 4.6.2.2 de su informe, "Una vulnerabilidad de carga de archivos arbitrarios autenticada combinada con un enlace simbólico no validado y escaladas de privilegios locales permite a los atacantes ejecutar comandos como usuario root". Felicitamos a los investigadores de ManiMed por descubrir también esta vulnerabilidad y practicar la divulgación responsable.

Sistemas de cruce

El verdadero trabajo comienza una vez que se obtiene el acceso de root. El desafío es cómo afectar el cambio en el RTOS de la bomba con acceso de root en el módulo de comunicación de SpaceCom. Un enfoque común sería continuar buscando vulnerabilidades en el RTOS de la bomba que llevarían a la ejecución de código dentro de su sistema. Este método plantea muchos desafíos durante las pruebas de caja negra y podría dañar nuestro número limitado de dispositivos de prueba.

Otro enfoque que hemos aprovechado en proyectos anteriores es secuestrar la funcionalidad estándar del dispositivo para promover el ataque. Esto puede ser más manejable, pero primero requiere una comprensión profunda de cómo funciona el dispositivo y el resultado deseado. Esto también prueba la defensa del dispositivo en profundidad y puede resultar muy difícil dependiendo de las medidas de seguridad implementadas. En nuestro caso, esto forzaría la pregunta de qué tan bien protegida está el área que rodea la comunicación entre la bomba y SpaceCom.

Como se mencionó en la sección de descripción del sistema anterior, el binario PCS es responsable de comunicarse con el sistema de la bomba para dos operaciones críticas: actualizar la biblioteca de medicamentos y actualizar la configuración de la bomba. Estas son funciones clave que probablemente serían de interés para un atacante. Hay varios enfoques diferentes que podría adoptar un atacante para interactuar con estas operaciones clave, especialmente dado el acceso de root. Teniendo en cuenta las diversas alternativas, optamos por aprovechar nuestro acceso raíz en SpaceCom para inyectar código en la memoria de PCS y utilizar funciones y objetos existentes para comunicarnos con el sistema interno de la bomba.

Nuestro camino elegido requería una comprensión profunda de las estructuras de datos y las funciones utilizadas para facilitar esta comunicación. La clave es encontrar el lugar perfecto en una pila de llamadas de operación más grande donde podamos modificar o inyectar los datos que queramos, mientras seguimos utilizando funciones de nivel inferior para evitar la necesidad de crear innecesariamente objetos y datos desde cero. Para ilustrar este punto, considere si queremos enviar una señal simple para apagar la bomba desde el espacio de memoria de PCS. El hecho de que todos los datos enviados desde SpaceCom al RTOS de la bomba se realiza a través de mensajes CAN, con acceso de root significaba que podíamos enviar mensajes CAN directamente en el bus CAN. Esto requeriría un amplio conocimiento y desglose de la estructura del mensaje CAN, ya que el protocolo subyacente está diseñado por B. Braun y tendría que someterse a ingeniería inversa. Aunque es posible, es muy difícil, especialmente con el campo de marco de datos de CAN que carece de especificaciones estrictas. Dentro de PCS hay una cadena de llamadas que construye este mensaje. Si tuviéramos que inyectar y utilizar funciones muy bajas en la cadena de llamadas, como el trySend función que envía un mensaje CAN (como se ve en la figura 4), necesitaríamos entender todos sus argumentos y el formato de datos que usa. Básicamente, tendríamos el mismo problema que antes.

Figura 4: función trySend

Si buscamos más arriba en la pila de llamadas una función que realiza la operación que nos interesa, apagando el dispositivo, podemos dejar que el resto de la cadena de llamadas haga el trabajo pesado por nosotros. Observe que en la Figura 5 a continuación hay una función solo para este propósito, que solo requiere que se pase un parámetro.

Figura 5: switchOffDevice

Aprovechando este concepto, podemos usar las funciones dentro de PCS de una manera similar a una API para realizar operaciones de lectura y escritura en la base de datos de la bomba y forzar un cambio.

Comprensión de los datos críticos

Si queremos enviar y escribir datos como la biblioteca de medicamentos y la configuración de la bomba, primero debemos comprender el formato de los datos, cómo se procesan y las medidas de seguridad implementadas que deben tenerse en cuenta. Nuestro equipo pasó mucho tiempo revirtiendo tanto la biblioteca de fármacos como los datos de configuración de la bomba. Una parte de la configuración de la bomba se conoce como calibración y datos desechables. Ambos se pueden modificar a través de nuestra cadena de ataque; sin embargo, para este artículo solo tocaremos el más crítico de los dos, la calibración y los datos desechables.

Los datos de calibración y desechables generalmente se ven en forma de archivos que se encuentran en SpaceCom. En un nivel más granular, son una colección de pares clave / valor que deben leerse o escribirse en la base de datos de la bomba. Cada archivo también puede ser una gran cantidad de datos que se encuentran en la memoria flash de la bomba. La ubicación física de cada clave dentro de este blob está codificada en la bomba y, a veces, en PCS. Esta representación es relevante cuando se trata de calcular varios CRC que operan en bloques de datos en lugar de pares de claves. Estas sumas de verificación se utilizan en gran medida en toda la infraestructura de la bomba con datos críticos para garantizar la integridad de los datos. Esto sirve para garantizar la seguridad de los pacientes al garantizar que los datos no puedan modificarse o corromperse accidentalmente. La Figura 6 muestra un ejemplo de datos desechables contenidos en archivos en SpaceCom.

Figura 6: Datos desechables

Observar los nombres de las variables dentro del archivo de datos desechables y el código relevante en el firmware de la bomba nos llevó a un par clave / valor que especifica el "volumen de cabeza" del tubo, que se puede ver en la figura anterior. Después de un análisis extenso, determinamos que el "volumen de la cabeza" es el parámetro que dicta la cantidad de medicamento que se administra al paciente por ciclo. Determinamos que si se cambiaba este valor, podría ser potencialmente dañino. Detallamos este análisis en la sección "Consideración única para el pirateo de bombas de infusión" a continuación.

Con un par clave / valor objetivo en mente, el siguiente paso sería comprender cómo calcular los CRC. Dado que el sistema verifica constantemente la integridad de los datos, si un atacante quisiera modificar cualquier valor, también necesitaría modificar los CRC que validan los datos modificados. A través de la ingeniería inversa, determinamos que el CRC era una implementación personalizada de un CRC16, donde el valor inicial es 0xFFFF y se basa en una tabla polinomial codificada. Pudimos extraer este algoritmo y escribir scripts de Python personalizados para calcular el CRC necesario para los datos desechables.

Con una comprensión básica de los datos operativos críticos y la capacidad de calcular los CRC, podemos aprovechar el binario PCS, en forma de API, para enviar comandos a la bomba para modificar estos datos. Esto es válido tanto para la biblioteca de fármacos como para los datos de configuración de la bomba. Aunque los CRC son excelentes para verificar la integridad, no brindan seguridad ni nivel de confianza del lugar de donde provienen los datos. Esta falta de verificación de origen es lo que llevó a la presentación de CVE-2021-33885.

Cadena de ataque final

Si revisamos nuestra cadena de ataque, podemos obtener acceso a nivel de usuario al dispositivo sin autenticación o autorización. Luego, podemos escalar nuestros privilegios a root y aprovechar la funcionalidad existente del binario PCS para realizar modificaciones en los datos desechables de la bomba. Conceptualmente, el proceso está completo; sin embargo, podemos hacer algunas tareas de limpieza adicionales para que nuestra cadena de ataque sea un poco más realista y eficiente.

Dado que el protocolo propietario para el binario PCS no está autenticado, existen ciertas opciones de configuración que pueden modificarse para que un atacante facilite aún más su trabajo. Una de estas opciones de configuración le dice a la bomba de qué servidor es "confiable" para recibir datos operativos (como la biblioteca de medicamentos). Un atacante puede enviar un comando a SpaceCom que borra la configuración actual del servidor de confianza y la reescribe en un servidor controlado por el atacante. Esto no es necesario para este ataque cuando se aprovecha la cadena de formato y la ruta de escalada de privilegios descrita anteriormente; sin embargo, proporciona métodos alternativos y simplifica el proceso de ataque.

Por último, la bomba tiene una notificación audible y visual cuando se ha modificado alguna configuración o información de medicamentos en la bomba. Una vez más, con el espíritu de un ataque realista, un atacante malintencionado querrá ser lo más sigiloso posible. Para lograr esto, valió la pena determinar un método para borrar estas notificaciones. Este proceso resultó ser tan simple como reiniciar la bomba después de que se completaron nuestras modificaciones. La operación de reinicio ocurre en cuestión de segundos, por lo que al usar esta técnica, todas las alertas al usuario final se borraron rápidamente. El proceso de ataque completo se puede ver resumido en el diagrama a continuación.

Figura 7: Cadena de ataque completa

Requisitos previos del ataque

Aunque esta cadena de ataque presenta un método completo para modificar los datos críticos de la bomba, es importante reconocer las condiciones necesarias para que este ataque tenga éxito. Estas bombas están diseñadas para conectarse en red a una red interna local. Por lo tanto, en condiciones normales de funcionamiento, un atacante debería haber encontrado un método para obtener acceso a la red local. ¿Podría este ataque tener lugar a través de Internet? Técnicamente hablando, sí; sin embargo, es muy poco probable que se vea una configuración en la que una bomba esté conectada directamente a Internet.

Además de estar en la red local, la bomba tiene medidas de seguridad para garantizar que no se produzcan modificaciones mientras la bomba está en funcionamiento. Por lo que descubrimos durante nuestra investigación, si la bomba está administrando medicamentos de forma activa, ignora cualquier solicitud en el bus CAN para modificar la biblioteca o los datos de configuración. Esto significa que el ataque solo puede tener éxito cuando una bomba está inactiva o en modo de espera entre infusiones.

Impacto

Los requisitos previos para este ataque son mínimos y no suficientes para mitigar la amenaza general. En el mundo actual, existe una amplia gama de métodos documentados y utilizados para que los atacantes obtengan acceso a las redes locales. Si también consideramos que los hospitales o las instalaciones médicas son generalmente lugares públicos con pocas o ninguna barrera de entrada, es fácil ver cómo alguien malintencionado puede pasar desapercibido y obtener acceso a la red. Las bombas tampoco siempre administran activamente la mediación. Incluso en los hospitales más concurridos hay tiempo de inactividad entre pacientes o momentos en los que las bombas simplemente no están en uso.

Con la capacidad de modificar los datos desechables y de configuración de la bomba, existe una amplia gama de posibilidades por las que un atacante podría optar por tener un impacto. Un atacante podría simplemente poner el dispositivo en un estado inutilizable o escribir mensajes arbitrarios en la pantalla. Elegimos centrarnos en los datos desechables, específicamente en el par clave / valor etiquetado como "TUBE_HEADVOLUME_A", ya que determinamos que demostraría el mayor impacto, causando daño a un paciente. En el siguiente video, verá primero la bomba en funcionamiento normal. Después de demostrar que el sistema funciona según lo previsto, modificamos la configuración de forma remota utilizando la cadena de ataque explicada anteriormente y luego ilustramos su efecto en la bomba al administrar medicamentos.

Manifestación

(incrustar) https://www.youtube.com/watch?v=N8SFxH-jNRw (/ incrustar)

Consideraciones únicas para el pirateo de bombas de infusión

Una característica interesante de este proyecto es que su impacto y consecuencias están intrínsecamente arraigados en el mundo físico. Donde los ataques de software comunes terminan con la capacidad de obtener acceso de root o privilegios de kernel, en este proyecto, la forma en que el personal médico usa el dispositivo y cómo puede afectar la seguridad del paciente es crucial para el resultado. Las próximas secciones se centrarán en varios aspectos del proyecto que caen bajo este paraguas.

Por qué modificamos TUBE_HEADVOLUME

Como se describió anteriormente, nuestro ataque se basa en modificar los datos desechables que gobiernan la forma en que se usa la bomba para administrar la medicación. Pero, ¿por qué y cómo decidimos investigar esto? Un efecto secundario interesante de que la bomba se construya para ser segura es que la mayoría de las entradas y salidas que recibe del bus CAN se verifican ampliamente contra el acceso fuera de rango. Desde la perspectiva de un atacante que ya ha comprometido SpaceCom, este suele ser el objetivo principal de los errores de corrupción de la memoria. Difundir y emular la arquitectura M32C es costoso en términos de trabajo inicial, por lo que, en cambio, comenzamos a buscar un camino de menor resistencia y buscamos puntos ciegos en el diseño seguro.

En nuestro caso, queríamos poder afectar la cantidad de medicamento que se dispensa, preferiblemente sin tener nada en la pantalla, ya que eso indicaría un mal funcionamiento o anomalía. Nuestro plan original era manipular la biblioteca de medicamentos del dispositivo, pero resulta que los datos que pudiéramos alterar se mostrarían en la pantalla, lo que podría generar preocupación ya que el personal médico verifica el medicamento recetado y califica con el pedido antes e inmediatamente después de iniciar el tratamiento. infusión. Esto no sería ideal para un atacante, así que seguimos investigando. Los otros archivos que pudimos modificar fueron los datos de calibración y los datos desechables. Estos archivos son interesantes ya que describen parámetros internos; el de calibración especifica los parámetros físicos del dispositivo en sí, mientras que el desechable es para los específicos de la tubería que pasa por la bomba. Cualquiera que esté familiarizado con las herramientas de precisión sabe lo importante que es una buena calibración. Si la calibración está desactivada, dará lugar a operaciones o resultados incorrectos. Desde un punto de vista operativo, esto tiene sentido, pero desde la perspectiva de un atacante, esto tiene una gran probabilidad de ajustarse al proyecto de ley para el ataque que teníamos en mente: modificar un valor interno para que la bomba piense que está dispensando la cantidad correcta de fármaco, mientras actually incorrect in its calculations.

Looking at the variable names inside the disposable file and relevant code in the pump firmware led us to one that specifies the “head volume” of the tube. From our understanding, each time the pump pumps, it compresses the IV tubing thereby pushing a small quantity of drug towards the patient. Overall, there are many physical parameters that would govern this volume –the internal tube diameter, the length of the compressed region, how much the tube is being compressed, etc.—but in the end, it seemed that all these values were summed up in one variable. Cutting this value in half would make the pump believe it is pushing half the actual amount, and therefore would have to pump twice as fast to deliver it. We tried our hypothesis, and by doing so, the amount of drug dispensed doubled while the pump assumed everything was normal.

Operations in Hospitals and Consequences of Over-Infusing Drugs

Now that we have an idea of what happens to the device when we alter its internal configuration, we can consider how this could play out in the real world. As mentioned previously, medical staff are expected to be extra-careful when using these devices, ensuring the numbers match the doctor’s order. In the United States, both the Centers for Medicare and Medicaid Services (CMS) and the American Society of Clinical Oncology require standard of practice be followed with high risk or hazardous infusions like blood or chemotherapy. This standard requires two appropriately trained people (usually nurses), one who will be infusing the medication, and the other to verify the order and configuration prior to administration. Looking internationally, we were also  able to find this same protocol in use at an Irish hospital. It confirms the attention to detail and the requirement to double-check each value is correct. However, another document describing the adoption of a smart pump system in a Swedish hospital hints at concerns (p. 47) that invalid drug protocols might be followed if a nurse picked the wrong default settings on the pump. These documents are anecdotal, but the overall feeling is that strong checks are in place. Under pressure or with multiple infusions, mistakes can be made, which smart pumps should prevent.

One of our industry partners, Shaun Nordeck, M.D. is an Interventional Radiology Resident Physician at a Level 1 Trauma Center and prior, served as an Army Medic and Allied Health Professional. Leaning on more than 20 years in the medical field. Dr. Nordeck states “A high-pressure environment such as the ICU may be at increased risk for infusion errors since these critical and often medically complex patients have multiple infusions which are being adjusted frequently. Errors, however, are not limited to the ICU and may just as easily occur in the inpatient ward or outpatient settings. Essentially with each increase in variable (patient complexity or acuity, number of medications, rate changes, nurse to patient ratio, etc.) there is an increased risk for error.”

As a measure of safety, it is important to keep in mind that one can visually count the number of drops to verify the infusion rate (there’s even an optional module to do it automatically). However, depending on the parameters, a minor change of speed (e.g., halved or doubled) might not be immediately obvious but could still be deleterious. Dr. Nordeck further stated that “something as routine as correcting a person’s high blood sugar or sodium level too quickly can cause the brain to swell or damage the nerves which can lead to permanent disability or even death.” The FDA’s MAUDE database keeps track of adverse events involving medical devices and can be used to see what type of problems actually occurred in the field. Certain drugs are particularly potent, in which case the speed at which they are delivered matters. En esto instance, an over-sedation at 4 times the intended rate led to the death of a patient a few hours after the incident occurred. Under-dosing can also be problematic as the required medication does not reach the patient in the appropriate quantity. These examples highlight that a pump not delivering the correct amount of drug occurs in the field and may remain unnoticed for multiple hours, which can lead to injury or death.

Common Pitfalls

Let’s now take a step back and consider some generic shortcomings that became apparent while looking at the infusion pump ecosystem. We believe these problems are not specific to a brand or a product but rather may be found across the entire medical field. This is because throughout the years, this vertical has only received a limited amount of attention from both malicious actors and the cybersecurity industry.  With the increased rate of cyber threats and the constant additions of new smart devices in private networks, new attack surfaces are being exposed and the hardening of many systems may turn into low hanging fruits for the ones lagging. The slower life cycle of smart medical devices means that best security practices and mitigations take longer to be adopted and deployed in the field. Awareness of this may help healthcare organizations, and their supporting IT administration have a more critical eye on the technology deployed in their environments while medical device vendors should remain vigilant of their “legacy” technologies and continually reassess the risk profile associated with legacy products in the current cybersecurity landscape.

Patching is Costly

Consumer products, both hardware and software are often nimbler than their counterparts in the medical industry. Your web-browser or operating system on your personal computer will auto-update immediately after a patch is released which come on a regular basis. This is radically different for medical devices which are often directly linked to patient safety and therefore need to undergo a more rigorous vetting process before applying updates. This often leads to the need to immobilize devices during updates, perform follow up tests and recalibrations. It is often very expensive and challenging for medical facilities to update products, resulting in deployed devices with firmware that is several years old. Because of this, “table stakes” security measures may never be fully adopted, and corresponding vulnerabilities may have a larger impact than in other industries.

Designed for Safety Rather than Security

When looking at the general architecture of the pump, it is obvious that it was designed with safety in mind. For instance, it relies on an application processor for the main processing but also has a control processor that makes sure nothing unexpected occurs by monitoring sensors output along with other components. Everything is CRC checked multiple times to flag memory corruption and every range is bounds-checked. All of this suggests that the design was intended to mitigate hardware and software faults, data accidentally being corrupted over the wire, and the flash module degrading which aligns with a high priority on safety.

However, it looks like preventing malicious intent was not given as much attention during the design process. Sometimes the difference between safety and security might be a little blurry. Preventing accidental memory corruption and out of bounds access due to faulty hardware will also make exploitation harder, yet an attacker will always attempt to escape these mitigations. Along the same lines, logic bugs that would be extremely unlikely to occur by chance might be the “keys to the kingdom” for an attacker. Internal audits and offensive security exercises can highlight the attacker mindset and bring valuable insights as how to harden existing safeguards to protect against intentional threats.

Everything is Trusted

When looking at how the pump and its communication module handles communication and file handling, we observed that critical files are not signed (CVE-2021-33885), most of the data exchanges are done in plain-text (CVE-2021-33883), and there is an overall lack of authentication (CVE-2021-33882) for the proprietary protocols being used. There are a few password-protected areas for user facing systems, but not as many for the behind-the-scenes internal systems. This might be because a login page on a website is an “obvious” necessity, along with having a proper authentication mechanism for FTP and SSH, while ad-hoc protocols designed more customized uses are not as obvious. There is also an evolving landscape at play and its related threat assessment; the risk of an unauthorized person tampering with a configuration file (calibration data, drug library, etc.) is fairly low if it also requires dedicated software and physical access to the device. However, if suddenly the device becomes network-connected, the attack surface is extended and the original assumptions may not be refreshed. Defense-in-depth would dictate that in any case, important files should not be easy to tamper with. However, security vs functionality comes with legitimate compromises and when it comes to embedded devices, limited resources and usability also need to be factored into the equation.

CAN gets Connected to WIFI

Originally, the CAN bus was reserved for communication between trusted components such as a Servicing PC used for maintenance or for connecting multiples devices within an older model of the Space Station that did not have SpaceCom built in. The latter would come as an optional module that could be plugged into the Space Station to offer external connectivity. Hence, the CAN bus was used for “internal” communication between trusted components and an external module, the SpaceCom, could be added for data reporting over the network. Over the following decade, technology improved and miniaturized to the point where everything got merged, so that even a battery module could provide WIFI connectivity and the SpaceCom functionalities. This opened new possibilities, such as having the built-in SpaceCom module provide similar capabilities as the servicing PC. From a user perspective this is great as it simplifies operations, but from a security perspective, this created a situation where a “trusted” internal network suddenly became bridged to an external network that could even be accessed wirelessly. What might have been an acceptable risk, where only a few proprietary devices with physical access could perform privileged operations, became much more questionable when a WIFI-connected Linux device started to offer the same capabilities.

This kind of problem has been faced by nearly every industry vertical that evolved from reliance on trusted physical networks which suddenly got connected to the internet or other untrusted networks. Smart connected devices are a double-edged sword: in the same way they offer greater flexibility and synergy between systems, they can also lead to emergent security issues that need to be considered holistically.

Technical Debt

When developing custom protocols and ad-hoc systems it’s natural to incur technical debt. This is even more true when the life cycle of a device is many years and when it is complicated and expensive to deploy patches and upgrades, leading to a heterogeneous customer base and multiple hardware revisions to support. This can cause situations where more obscure features are not looked at for years and their ownership might be lost or perfunctory. An example of this is the format string vulnerability affecting the json-dbus module. Its usage is obscure, and it was forked from an open-source project many years ago. The original repository fixed bugs that were security bugs but were not flagged as such which led them to fly under the radar for multiple years. Likely, at the time it was forked, the code served its purpose and was never revisited afterwards, leaving the security bug unnoticed. The same can be said for custom-designed protocols and file formats. It may be difficult to evolve them in line with the improvement of best security practices while avoiding breaking “legacy” deployments. In this scenario, mitigations might be the way to go; making sure the systems are isolated, unnecessary features can be disabled and their privilege and access limited to what’s needed. Future-proofing a system is a difficult challenge. If anything, transparency on how the system functions and the components it relies on, coupled with regular audits (code source review or black box audit) can help prevent components from falling in the cracks where they’re not checked against best practices for many years.

Conclusión

This concludes a research project which took two senior researchers a significant amount of time to showcase a life-threatening risk of a medical device being taken over by a remote attacker. For the time being, ransomware attacks are a more likely threat in the medical sector, but eventually these networks will be hardened against this type of attacks and malicious actors will look for other lower-hanging fruits. Given the lifespan of medical devices and the difficulties surrounding their updates, it is important to start planning now for tomorrow’s threats. We hope this research will help bring awareness to an area that has been a blind spot for far too long. Dr. Nordeck affirms the importance of this research stating: “The ability to manipulate medical equipment in a way that is potentially harmful to patients, without end-user detection, is effectively weaponizing the device and something only previously conceived by Hollywood yet, McAfee’s ATR team has confirmed is plausible. Device manufactures clearly aim to produce safe and secure products as evidenced by built-in safeguards. However, flaws may exist which allow the device to succumb to a ransom attack or potentially cause harm. Therefore, manufactures should collaborate with security professionals to independently test their products to detect and correct potential threats and thereby preserve patient safety and device security.”

Performing regular security audits, making it easier for medical professionals to keep their devices up to date and offering solid mitigations when this is not possible should really be on every medical vendor’s list of priorities. Medical professionals, policy makers and even the general public should also hold accountable the medical vendors and have them clearly articulate the risk profile of the devices they sell and demand better ways to keep their device secure. We recognize even with this mindset and a holistic approach to security, there will always be flaws that cannot be predetermined. In these cases, vendors should encourage and even seek out industry partners, embrace responsible disclosure and communicate broadly with researchers, stakeholders and customers alike.

From a security research perspective, it is crucial to understand how a device works at a holistic system level, and how each component interacts with each other, which components they can talk to, and so on. For manufacturers, it is important to read between the lines; something may not be in a design document or in the specifications, but sometimes emergent properties will occur as a side-effect of other design decisions.

An offensive project like ours is really meant to highlight structural weaknesses and point out risks. Now, defensive work is necessary to address these concerns. For instance, manufacturers should leverage cheaper and more powerful microcontrollers to implement proper authentication mechanisms. However, it is even more important to study and address the challenges hospitals face when it comes to keeping their devices up to date. This should come as both technical solutions from the vendors and advocacy to promote secure practices and raise awareness on the underlying risks associated with critical devices having outdated software. The FDA tried to lead the way in 2018 with its CyberMed Safety (Expert) Analysis Board (CYMSAB), but so far little progress has been made. The work the German BSI did with the ManiMed project is also extremely encouraging. We see this as an area of cybersecurity with lots of potential and need for attention and look forward to the information security industry taking on this challenge to make this critical sector always more secure.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. As per McAfee’s vulnerability public disclosure policy, McAfee’s ATR team informed and worked directly with the B.Braun team. This partnership resulted in the vendor working towards effective mitigations of the vulnerabilities detailed in this blog. We strongly recommend any businesses using the B.Braun Infusomat devices to update as soon as possible in line with your patch policy and testing strategy.

CVE Details

CVE: CVE-2021-33882

CVSSv3 Rating: 6.8/8.2

CVSS String: AV:N/AC:H/PR:N/UI:N/ S:C/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Missing Authentication for Critical Function vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote attacker to reconfigure the device from an unknown source through lack of authentication on proprietary networking commands.

CVE: CVE-2021-33883

CVSSv3 Rating: 5.9/7.1

CVSS String: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Cleartext Transmission of Sensitive Information vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote attacker to obtain sensitive information by snooping the network traffic.  The exposed data includes critical values for the pumps internal configuration.

CVE: CVE-2021-33884

CVSSv3 Rating: 7.3/5.8

CVSS String: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L/CR:M/IR:M/AR:L/MAV:A

CVE Description: Unrestricted Upload of File with Dangerous Type vulnerability in BBraun SpaceCom2 prior to 012U000062 allows remote attackers to upload any files to the /tmp directory of the device through the webpage API.  This can result in critical files being overwritten.

CVE: CVE-2021-33885

CVSSv3 Rating: 10.0/9.7

CVSS String: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Insufficient Verification of Data Authenticity vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote unauthenticated attacker to send malicious data to the device which will be used in place of the correct data.  This results in execution through lack of cryptographic signatures on critical data sets

CVE: CVE-2021-33886

CVSSv3 Rating: 8.1/7.7

CVSS String: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N/RL:O/RC:C

CVE Description: Improper sanitization of input vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote unauthenticated attacker to gain user level command line access through passing a raw external string straight through to printf statements.  The attacker is required to be on the same network as the device.





Enlace a la noticia original