Noticias y Alertas
Header

Y la seguridad en la SALUD? (#3)

junio 6th, 2017 | Posted by kwelladm in Publicaciones | Salud

Prácticamente todos los productos de los fabricantes contaban con algún tipo de bug de seguridad; los principales culpables eran librerías de terceros usadas en el código fuente de los dispositivos, que no habían sido actualizadas a la última versión. Aunque los bugs se encuentren y se solucionen, no sirve de mucho si los fabricantes siguen reutilizando el mismo código de siempre por comodidad.

En el caso de que el firmware de los dispositivos se pueda actualizar, las contraseñas suelen venir en el propio código (una de las peores prácticas de programación); por lo que es fácil introducir firmware falso que cambie la manera en la que funciona el marcapasos.

Esas no son las únicas prácticas peligrosas; más llamativo aún es que, cuando estos marcapasos se conectan con dispositivos de monitorización, no es necesario introducir ninguna contraseña.

Así que cualquiera puede acceder al marcapasos en cuanto obtenga una conexión; de hecho, no existe ningún sistema de autenticación con los servidores de las compañías para asegurarse de que el dispositivo al que se va a conectar es genuino.

No solo eso, sino que la comunicación no está cifrada; así que es muy fácil, obtener los datos que se retransmiten desde el marcapasos hasta los sistemas de monitorización. Algunos de estos sistemas incluyen puertos USB; por los que es posible introducir malware que se ejecutará sin ningún tipo de obstáculo.

Los investigadores han decidido censurar su propio trabajo para evitar que pueda usarse con fines malignos. Los nombres de los fabricantes y de los dispositivos no aparecen; y algunos detalles de los bugs han sido borrados, al menos hasta que sean arreglados por las compañías. Teniendo en cuenta la magnitud de estos errores, es poco probable que esto ocurra de la noche a la mañana.

Para terminar de entender cómo se trabaja sobre un marcapasos desde la programación, adjuntamos el siguiente informe:

How do Pacemaker Programmers Work?

Of all the components in pacemaker systems, pacemaker programmers provide the most insight into how pacemaker systems actually work.  In total, we examined seven different pacemaker programmers from four different manufacturers.  Six pacemaker programmer utilized unencrypted IDE hard drives.  One pacemaker programmer utilized an unencrypted PCMICA flash drive.  We saw a variety of operating systems such as the familiar Windows XP, Real Time Operating Systems (RTOS) like MonteVista, old operating systems like DOS, we even encountered one programmer using OS2!

All of the programmers we examined booted directly into the programming software without first requiring any type of login or password.  Pacemaker programmers do not authenticate to pacemaker devices.  Any pacemaker programmer can program any pacemaker from that specific vendor.  This is true for all programmers we examined.  Proximity is the primary criteria for pacemaker programming.  This is an area where is appears that patient care has influenced the cybersecurity posture of the pacemaker programmer.  While older pacemaker programmers only utilize a close proximity “telemetry wand”, newer programmers from all vendors utilize longer range RF communications in addition to the close proximity telemetry wand.  Our research focused on programmers that supported the use RF communications.  By intended design, all the pacemaker programmers we examined first required the use of a telemetry wand in order to communicate with the pacemaker.  This is the intended design; situations where devices can communicate with a pacemaker without first requiring a telemetry wand is more complicated and will be addressed in a later post.  In all implementations we observed, the telemetry wand would retrieve a token from the pacemaker device itself.  In some cases, the token is the device serial number/ID.  In one case, the token value retrieved from the pacemaker device was a static AES key.  This token value is then used to derive a session value/key and communications is passed from the telemetry wand to longer range, higher bandwidth radio signal.  The method/algorithms used to derive the session token/key values is different amongst different manufacturers.

These session token generation algorithms are stored within the programmer logic and software.  Once a proper session is established, the programmer can perform a variety of functions over radio, including the alteration of therapy.  This is by-design and is the case for all pacemaker programmers we examined.  Obviously, compromise of a pacemaker programmer is a serious matter.  The by-design capabilities of pacemaker programmers is significant and compromise of a pacemaker programmer would result in situations where alteration of therapy is possible.

The software implementation of pacemaker programmers shows an area where cross-pollination between vendors has likely already occurred.  All of the modern programmers we examined use a core application to initialize the programmer hardware and interfaces.  Communications to pacemakers is done through “apps”.  Each pacemaker device model has its own app on the programmer.  The app contains the specific commands supported by that specific pacemaker.  The pacemaker app also contains the telemetry structure used to retrieve data, program, and reprogram the pacemaker device.  Most of the implementations we observed allowed programmers to both update pacemaker therapy settings and pacemaker firmware.  We did not observe any cryptographically signed pacemaker firmware.  Given pacemaker firmware are not cryptographically signed, it would be possible update the pacemaker device with a custom firmware.  Once interaction with a pacemaker is complete, the pacemaker app passes control back to the main application and the main application will await an another inductive telemetry wand action.

 
Steps for RF Programming

(1)   Pacemaker programmer system starts the main application (no password required)

(2)   A close proximity telemetry wand is used to interrogate a pacemaker

(3)   The pacemaker device provides a token and identifying information

(4)   The pacemaker token and identifying data is received by the main application

(5)   The main application launches the pacemaker app for the identified pacemaker

(6)   The pacemaker programmer switches to RF communications

Pacemaker programmers represent a significant part of the pacemaker ecosystem.  From a security research perspective, access to programmers can be extremely helpful in understanding how pacemaker systems work.  In the next part, we’ll talk about the home monitoring systems and how they work.

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

Deja un comentario