PACS y DICOM: Una “radiografía” a las debilidades y fugas de información en sistemas médicos

martes, 30 de mayo de 2017

En el mundo de la conectividad de los dispositivos médicos y su instrumentación, existen una amplia variedad de iniciativas, protocolos, estándares y fabricantes que trabajan arduamente en intentar alcanzar una integración neutral para este tipo de sistemas y dispositivos.


Imagen 1: Ejemplo de sistema médico

Claro está que aquellos que trabajamos en la comunidad de la seguridad, vemos con gran preocupación que el auge que siguen tomado estas tecnologías no implique considerar desde el diseño, conceptos como el desarrollo seguro.

Dentro de la gran variedad de sistemas, en esta oportunidad queremos enfocarnos en los sistemas PACS (Picture Archiving and Communication System), cuya arquitectura típica podemos observar en la imagen 2. En dicha imagen podemos observar que existe un componente principal llamado servidor PACS, el cuál es un sistema encargado del almacenamiento digital, de la transmisión y de la descarga de imágenes radiológicas. Estos sistemas se componen de software y hardware, que se comunican directamente con las denominadas modalidades (“Modality”); y es a través de estas, que se obtienen las imágenes. Las imágenes son transferidas hacia el visor PACS (software cliente para visualización y emisión de informes radiológicos), las cuales pueden ser tanto estaciones de trabajo o dispositivos móviles (con sus respectivas vulnerabilidades por mala gestión de los mismos).


Imagen 2: Ejemplo de arquitectura típica PACS

Dentro de este tipo de arquitecturas, el protocolo DICOM (Digital Imaging and Communications in Medicine) juega un papel relevante ya que es el llamado formato universal para el intercambio de imágenes médicas digitales. El mismo es responsable de toda la comunicación con las modalidades del área de imágenes (cada una de las técnicas/equipos para la obtención de imágenes: Tac, Resonancia Magnética, Ecografía). Además de la comunicación con otros servidores PACS y estaciones de trabajo DICOM.

Las inadecuadas prácticas de desarrollo, configuración o implementación, como en cualquier ámbito, provocan fallos de seguridad muy variados, pero en este caso nos preocupan aquellos donde principalmente podría revelarse información como los datos personales de los pacientes, tipo de enfermedades, hospitales visitados e información de sus doctores, entre otros…


Imagen 3: DCOM

Haciendo unas simples búsquedas en Shodan por los puertos 104 o 11112 de DICOM más comunes o directamente alguna palabra clave como se muestra a continuación, es posible tener una idea de qué tan expuestos se encuentran estos sistemas:


Imagen 4: Búsqueda en Shodan Server de DCOM, top de búsquedas.



Imagen 5: Búsquedas en Shodan Server de DCOM, Argentina.



Imagen 6: Búsqueda en SHodan Serber de DCOM, Ecuador.



Imagen 7: Búsqueda en Shodan Server de DCOM, Chile.


Encontrar sistemas expuestos podría no representar un problema para muchos, pero innegablemente existe un riesgo de seguridad sobre el cual deberíamos preocuparnos, porque existen vulnerabilidades provocadas por las malas implementaciones que evidencian fugas de información tales como la que podemos ver en las siguientes imágenes, donde haciendo uso de un Viewer PACS (en este caso utilizamos el de RADIANT) es posible consultar remotamente (sin autenticación) información de pacientes, exámenes radiológicos (información o imágenes), incluso con la posibilidad de estar expuestos a la manipulación de esta información a través de algún otro fallo.


Imagen 8: Información accedida con el Viewer PAC de un sistema expuesto.


Claramente, este tipo de servicios podrían estar expuestos a la explotación de algún otro tipo de vulnerabilidad critica o de mayor impacto, permitiendo, por ejemplo, tomar control de una red hospitalaria. Existen varios posibles vectores de ataque que un potencial atacante podría aprovechar, como por ejemplo: 
  • Passwords Hardcodeados (ejemplo: CVE-2013-7442 GE Centricity PACS)
  • Trafico inseguro
  • Firmware de dispositivos (Modality)
  • APIs de PACS (RESTFul)
  • Fallos en el desarrollo de Software Clientes Viewer PACS (Escritorio, Web, Apps) 



Aplicación Web de GE para Radiología (acceso a reportes e imágenes desde PACS)

Tenemos que tomar en consideración que no solo existen este tipo de dispositivos o sistemas de salud, son muchos más, y de no tomar en cuenta las consideraciones necesarias de seguridad, se podrían presentar los mismos riesgos a los cuales se enfrentan en la actualidad cualquier infraestructura tecnológica.


Si desean conocer un poco más, no dejen de analizar la información disponible en: 
  • OFFIS (Institute for Information Technology) – DICOM Toolkits, Librerías, Software, Demos

  • Sitio que ejecuta un servidor DICOM genérico para uso público de pruebas

Seguiremos pendiente de cómo evolucionan tanto los dispositivos como los sistemas médicos para traerles nuevas entradas acerca de ellos. De igual manera los invitamos a compartir información acerca de estos sistemas en nuestra comunidad.

Carlos Ávila
Chief Security Ambassador

Nuevo informe: Una aproximación práctica al Certificate Transparency

lunes, 29 de mayo de 2017

Desde hace algún tiempo, Mozilla, Microsoft y Google han apostado a la masificación del uso de la criptografía. Las diferentes medidas de seguridad aplicadas apuntan a mejorar el cifrado del tráfico de red: deshabilitar en los navegadores la utilización de protocolos antiguos como MD5, RC4, SHA-1, RSA de 512 y 1024 bits y habilitar otros, como TLS v1.1 y v1.2.

Con la intención de solucionar la problemática inherente al uso de TLS, en noviembre de 2016 Google anunció en el marco del "CA/Browser Forum" (organización que reúne a todas las CAs y desarrolladores de navegadores del mercado) que a partir de octubre de 2017 haría obligatoria la Transparencia de Certificados Digitales (Certificate Transparency o CT) en su navegador Chrome.

Ejemplo de bloqueo por Certificate Transparency nativo en Chrome

Descubre 11 tecnologías de ElevenPaths en esta sopa de letras y llévate 111 euros

viernes, 26 de mayo de 2017



ACTUALIZACIÓN: el juego ya ha concluido, nos pondremos en contacto con el ganador y publicaremos la solución.
¡gracias por participar!

¿Quieres ganar 111 euros en un cheque regalo para Amazon?

Encuentra 11 de nuestras tecnologías en esta sopa de letras y sé el primero en 
comunicarnos tu solución detallada a innovationlab@11paths.com
Puede que no sea mala idea seguirnos en @elevenpaths y a través del hashtag #11PathsGame




g l f l   f c b k e v c f   c b a c   h z c w k   a p c j c b   r z c   n c b g e l y l f a c   c j   c e   l m c ñ c n l f p k   d l ñ p l   e l   n c f c ñ d l   c e   j z o c f k   n c   e c a f l b   ñ k f f c b g k j n p c j a c   l   e l   g k b p ñ p k j   n c   e l   e c a f l   c j   e l   g l e l m f l   o l b   k j ñ c.   c e   l m c ñ c n l f p k   c b   ñ p f ñ z e l f.



Innovación y laboratorio
www.elevenpaths.com

Ya solo queda un año para la aplicación del nuevo reglamento europeo de protección de datos. ¿Estás preparado?

jueves, 25 de mayo de 2017


El nuevo Reglamento Europeo de Protección de Datos (RGPD), el cambio más importante en la regulación de la privacidad en los últimos veinte años, entró en vigor en mayo del año pasado, y será de obligado cumplimiento en toda la UE a partir del 25 de mayo de 2018. Hasta esta fecha, permanece vigente la Ley Orgánica de Protección de Datos (LOPD). Un año puede parecer mucho tiempo, pero puesto que el proceso de adecuación es complejo, no conviene esperar al último momento, más sabiendo el riesgo de recibir una multa por parte del regulador. 

El laboratorio de malware avanzado de ElevenPaths

miércoles, 24 de mayo de 2017

El escenario actual está evolucionando hacia un nuevo contexto de amenazas avanzadas que la industria está tratando de contener mediante la implementación de diferentes tipos de soluciones. Desde ElevenPaths, se ha realizado un completo análisis a las 17 principales tecnologías del mercado, diseñadas para luchar contra este tipo de amenazas y focalizadas en el endpoint. Con el objetivo de tener una visión clara e independiente de los diferentes enfoques que los fabricantes han utilizado, se ha desarrollado una metodología propia que no sólo toma como base los parámetros más puramente técnicos, sino que también ha tenido en cuenta variables que permiten incluir las necesidades y perspectiva de los administradores y usuarios finales de la tecnología. Esta metodología se basa en seis grandes categorías:

  • Despliegue de la solución considerando principalmente las variables relativas a tipos de sistemas operativos para los que existe soporte, complejidad de despliegue y consumo de recursos.
  • Capacidades de prevención y bloqueo para identificar amenazas antes de que estas sean ejecutadas, prestando especial atención al número de falsos positivos obtenidos.
  • Una vez que las amenazas no se han detenido en una fase inicial de prevención, se evalúan las capacidades de detección para aportar datos sobre la calidad y cantidad de los modelados de amenazas que incorporan las soluciones.
  • Una vez que las amenazas se han materializado en el sistema se evalúan las capacidades de respuesta, referido principalmente a las capacidades de remediación y contención de la amenaza.
  • En una fase de postincidente se examinan las características forenses, que nos aportarán tanto cantidad como calidad de la información relacionadas con el incidente.
  • De forma paralela a los estados de las amenazas, se observan las capacidades de los datos relativos a análisis e inteligencia, los cuales aportan capacidades relativas a proporcionar información de contexto asociada a la amenaza, las tácticas utilizadas y al actor involucrado en la misma.