Seguridad web en aplicaciones DICOM Viewers

En estos últimos meses, hemos continuado investigando acerca de diferentes componentes dentro de los servidores PACS, comentados ya en posts anteriores (PACS y DICOM: Una “radiografía” a las debilidades y fugas de información en sistemas médicos y PacsOne Server “All bugs in One” en la gestión de imágenes radiológicas). Hemos llevado a cabo un análisis general y aleatorio de varios clientes DICOM de tipo web (DICOM Web Viewer) de diferentes fabricantes y proyectos que podemos encontrar en internet en la actualidad, ya sea a través de sus aplicaciones demos o a partir de sus instaladores (versiones free o trial).

Como se imaginan, los clientes DICOM desarrollados como aplicaciones web, permiten que algún médico o paciente pueda visualizar las imágenes de una radiografía o datos de estudios realizados desde cualquier dispositivo tecnológico (computadora, móvil, etc.), gestionando con ello información sensible tanto para empresas que los implementan como para los clientes. Lamentablemente, muchas de estas aplicaciones arrastran problemas de seguridad en su código y ponen en riesgo la información de los clientes (pacientes) o la infraestructura en sí misma.

OWASP Top 10 vs DICOM Web Viewers

Sin ser éste un análisis de código fuente al detalle de estas aplicaciones, quisimos establecer una introducción al estado actual de estas aplicaciones web en referencia al OWASP Top 10, ya que hemos evaluado de manera superficial varias aplicaciones aleatoriamente, obteniendo así los resultados generales expresados en la siguiente matriz:

Categoría en OWASP	Aplica
A1 – Injection	ü
A2 – Broken Authentication & Session Management	ü
A3 – Cross Site Scripting (XSS)	ü
A4 – Broken Access Control	ü
A5 – Security Misconfiguration	ü
A6 – Sensitive Data Exposure	ü
A7 – Insufficient Attack Protection	ü
A8 – Cross Site Request Forgery	ü
A9 – Using Components with Known Vulnerabilities	ü
A10 – Unprotected APIs	ü

De la mera observación, podemos deducir que en las aplicaciones revisadas todas las categorías de riesgo fueron encontradas, al menos, en una oportunidad dentro de la investigación (muestreo de 12 aplicaciones famosas en el ámbito). A fin de evidenciar lo mencionado, presentamos a continuación un caso (prueba de concepto), de los diferentes hallazgos que hemos recogido durante nuestro breve análisis.

Caso A1 [Ataque de Inyección SQL permite lista información de todos los pacientes]

Caso A3 [Falta de Validación permite ataques XSS Reflejado]

Caso A5 [Falta de Hardening expone información técnica]

Caso A10 [Falta de validación en WebServices “APIs” permite Ataque Inyección SQL]

Lamentablemente, en términos generales, varios de los fabricantes de este tipo de aplicaciones no parecen poseer procedimientos que garanticen el desarrollo seguro de las mismas, basado en las múltiples vulnerabilidades web encontradas y desconocen que en su mayoría pudieran tener gran impacto tanto en la empresa que la implemente como en sus clientes.

Desde ElevenPaths intentamos colaborar con las distintas industrias en mejorar sus plataformas tecnológicas, acercándoles estudios, conocimiento, tecnologías y soluciones basadas en servicios, pero nos queda claro que nos falta un camino muy largo por recorrer a todos. Cada vez que nos proponemos mirar una tecnología diferente, uno puede sentir que ha retrocedido algunos años en cuanto a los controles de seguridad existentes, sin embargo, esos problemas siempre estuvieron allí, no retrocedimos, sólo que hasta este momento no nos habíamos preocupado por mirarlo, y eso nos puede afectar directamente a todos…

Carlos Ávila

Chief Security Ambassador

carlos.avila@global.11paths.com

@badboy_nt

#CodeTalks4Devs: MicroLatch, construyendo Latch en la palma de tu manoInvestigando los discos duros de Bin Laden: malware, contraseñas, warez y metadatos (I)