(In)Seguridad en Aplicaciones Móviles PACS/DICOM

1 de marzo de 2018

Con frecuencia nos hacemos análisis médicos. Toda la información que se produce como resultado tras estas pruebas, es almacenada en alguna infraestructura tecnológica de una empresa o en la nube, para luego ser utilizada por el médico y realizar un diagnostico, o por el usuario (paciente) para revisarla desde la palma de su mano. Acerca de esto, hemos estado revisando en otras entradas, sistemas de almacenamiento y transmisión de información médica y radiológica (PACS) y hemos evidenciado cómo ciertas vulnerabilidades pondrían en riesgo la información médica y análisis radiológicos de los usuarios.

Aplicaciones móviles para comunicación con Servidores PACS

Además de los servidores y servicios publicados sobre los que ya hemos hablado anteriormente, hemos observado un crecimiento de aplicaciones móviles para que los usuarios consulten desde sus tables o sus smartphones los datos médicos personales. Por ello, hemos partido de la misma pregunta: ¿Podría estar esta información en riesgo por alguna falla de seguridad informática? Muchas de estas aplicaciones tienen comunicación directa con internet mediante dispositivos y sistemas de la infraestructura interna tecnológica de servicios médicos, un vector de ataque adicional para las mismas...

Descripciones mostradas en aplicaciones PACS/DICOM Mobile Viewer

En este análisis hemos seleccionado la última versión de 35 aplicaciones (iOS/Android) visores DICOM o de conexión hacia servidores PACS, que evidenciamos como los más conocidos y tienen mayor cantidad de descargas en Apple Store y Google Play. Dentro de este muestreo de aplicaciones nos enfocamos en analizar únicamente las aplicaciones móvil, ya que a pesar de que se descubrieron debilidades del lado del servidor ( backend), no han sido incluidas en este post.

Para esta revisión utilizamos un dispositivo Android ( rooteado), IPhone 5S (no jailbreak) y nuestra plataforma de análisis de seguridad continuo de aplicaciones móviles mASAPP.

En base a los controles de seguridad del Top 10 Mobile de OWASP se realizaron pruebas a nivel macro, que solo representan un análisis general de las pruebas exhaustivas que se podrían realizar a las aplicaciones móviles, pero que estaban fuera del alcance de este análisis.

Top 10 Mobile Risks OWASP

Como puede verse en la siguiente imagen, los resultados demostraron que para el desarrollo de este tipo de aplicaciones la seguridad no ha sido una prioridad.

Resumen General de Resultados

Almacenamiento inseguro y privacidad (M2)

En 18 aplicaciones Android hemos encontrado cuentas de correo electrónico de usuarios en la metadata de las apps e incluso cuentas de correo de los desarrolladores que han sido comprometidas en brechas de datos en servicios de internet.

Correo de desarrollador comprometido en una brecha de datos en servicios de Internet

Usuarios y contraseñas almenas en SQLite en texto plano, además de estructuras fácilmente legibles, nos denota otra mala práctica en cuanto almacenamiento local inseguro. En otros casos, nos encontramos con los passcode o pins como control de acceso en las aplicaciones, almacenados en archivos XML (XD).

Bases de Datos SQLite con estructuras que almacenan contraseñas en texto plano

Almacenamiento de Clave en Texto-Plan "PassCode" para acceder a la aplicación

Archivo de Certificado/Key Hardcodeado en App iOS

Comunicación, autenticación y cifrado (M3 – M4 – M5)

Diez de las aplicaciones analizadas establecen canales HTTP no cifrados, mientras una gran parte de aplicaciones usan comunicación HTTPS con certificados autofirmados y no verifican la autenticidad del certificado digital (por ej. Métodos Certificate Pinning). Esto facilitaría a un atacante generar ataques MiTM (Main-in-the-Middle).

Aplicación que alerta de Certificado Falso

Uso de Certificados Auto firmados

Uso de Canal HTTP para comunicación

Aplicaciones que tienen “opcional” el uso de HTTPS

Usando base64 para "cifrar" contraseñas

Vulnerabilidades por falta de validación de datos (M7)

Entre los principales hallazgos, seguimos encontrando vulnerabilidades de tipo Inyección SQL y XSS (Cross Site Scripting). En el caso particular de XSS, hemos encontrado esta vulnerabilidad en 11 aplicaciones dado que se encuentra activado en las “Webviews” para que puedan ejecutar código Javascript o a su vez agregar librerías HTML.

Vulnerabilidades de XSS que permite ataques a usuarios finales de la App

Otras de las malas prácticas que pudimos observar en esta categoría, es el uso o generación de funciones para ejecución de comandos desde la aplicación.

Ejecución de comandos desde la aplicación

Información sensible “Harcodeada” y ofuscación (M9)

Las 20 aplicaciones Android se pueden descargar y modificar de manera arbitraria. Se puede obtener de manera legible las clases de JAVA de las aplicaciones porque no mantienen ninguna característica de ofuscación de código (despersonalización) para dificultar el proceso de reversing.

Revisión de clases JAVA después del proceso de reversing

Archivos JKS & Google API Keys “hardcoded”

Esperamos que toda esta información sirva para ayudar a desarrolladores y que la industria continúe mejorando en aspectos de seguridad; ya que como vemos, al involucrar nuevas tecnologías a sectores “tradicionales”, también se pueden heredar malas prácticas que conllevan a mejorar y revisar nuevos vectores de buscan los atacantes.

Los investigadores y entusiastas de la ciberseguridad día a día buscamos fallos de seguridad en esta industria y creo que aún faltan muchos por explorar; sistemas de resultados de exámenes, registros médicos en la nube, más servicios radiológicos, dispositivos embebidos ( firmware) y componentes del sector de la salud que necesitan ser evaluados profundamente, ya que juegan un papel fundamental en la vida diaria de cada uno de nosotros.

Carlos Avila

Chief Security Ambassador

@badboy_nt

carlos.avila@global.11paths.com