Carlos Ávila

Hace unos meses publiqué un artículo sobre la seguridad y la privacidad en el “Internet de la salud” en el que describía como es inimaginable la cantidad de aplicaciones y dispositivos que la industria de la medicina ha desplegado y serán, en un futuro no tan lejano, utilizados por todos nosotros. Como ha pasado en otras industrias, quizás esto es el camino natural que deben seguir las tecnologías y la industria médica, con el objetivo de mejorar los servicios y la calidad de vida de las personas. Con todos estos cambios, hoy nos acompaña un nuevo termino conocido como IoMT o “Internet of Medical Things” que, a través de tecnologías de IoT o “Internet of Things”, han llegado para quedarse. IoMT es como, a través de sensores incluidos en los dispositivos médicos tradicionales, y acompañados de otras tecnologías como el Big Data, se recopilan datos que, extraídos y analizados, ofrecen mejor servicio a los pacientes y a los profesionales de la salud. Aplicaciones móviles IoMT y funcionalidades Es conocido que los hospitales en el mundo cada día cuentan con más sistemas tecnológicos que involucran desde monitoreo remoto de pacientes, bombas de insulina, manejo de medicamentos, etc., todo esto conectado a la infraestructura tecnológica del hospital. La idea del IoMT es generar un ecosistema de salud interconectado con todos estos dispositivos y las plataformas tecnológicas, aquí es donde juegan un papel fundamental las aplicaciones móviles. Estas aplicaciones móviles desarrolladas para IoMT en mucho de los casos, ya sea directa o indirectamente, están gestionando aparatos y sistemas de la infraestructura hospitalaria, tanto en el interior de los hospitales como externamente. Estas ‘Apps’ comienzan a ejecutan acciones o tomar decisiones en base a datos, dentro de una infraestructura sanitaria porque permanecerán conectados con los relojes inteligentes, pulseras de pacientes, monitoreo de inhaladores de asma, sensores de urología, etc. Ciertos hallazgos en ‘Apps’ IoMT Hemos realizado la revisión unas pocas de estas aplicaciones móviles IoMT desde nuestras plataformas mASAPP (análisis de seguridad continuo de aplicaciones móviles), así como también con dispositivos físicos con una revisión muy superficial. Es importante mencionar que en cualquier industria, y la sanitaria no es una excepción, se deben continuamente buscar fallos, analizar su seguridad e implementar nuevos controles de seguridad, ya que la tecnología cambia rápidamente y, por ende, la forma de protegerla. En primer lugar, puedo destacar que existen aplicaciones que al momento de registrar un usuario permite usar contraseñas débiles y sin ningún control de fortaleza de las mismas. Además, un denominador común estas aplicaciones es que no se identificó la existencia de controles de 2FA. Imagen 1: No valida complejidad de claves en registro de usuarios (ej. “password”) Otro aspecto que llama la atención, es que encontramos estructuras fácilmente legibles entre archivos .plist, lo que nos denota una mala práctica en cuanto almacenamiento inseguro de estos datos o inadecuada revisión previo a subir las aplicaciones a las tiendas. I magen 2: Archivos con datos “hardcoded” en archivos .plist I magen 3: Archivos de certificados “hardcoded” en las apps Si bien las aplicaciones establecen canales de comunicación seguros (HTTPS) con sus backends, notamos que los desarrolladores muchas veces deshabilitan arbitrariamente características de seguridad que fortalecen los canales de comunicación desde el cliente (App). Esto solo es una muestra de las oportunidades para mejorar que tienen estas aplicaciones. De la misma manera, no olvidar que muchas de estas aplicaciones tienen comunicación directa a través de protocolos como Bluetooth o internet con los dispositivos IoMT o IoT, ampliando posibles vectores de ataque para los cibercriminales que debemos estar atentos a investigar y proteger. Retos y oportunidades para mejorar Con la puesta en marcha de dispositivos IoMT y sus aplicaciones en las diversas instalaciones en el mundo, nos presenta nuevos retos y vectores de ataque tanto para los propios administradores, fabricantes e investigadores de seguridad ya que seguramente se comenzarán a ver muchas más amenazas a las infraestructuras hospitalarias a través del ecosistema de estos dispositivos. Otros frentes para abordar están relacionados con la estandarización de estos dispositivos y los protocolos de comunicación, que son diversos y están implementados ya en entornos tecnológicos sanitarios. Como hemos visto con las aplicaciones móviles enfocadas a estos dispositivos, esto ya está en camino y su aumento será seguramente vertiginoso. Con lo cual, los retos de seguridad en la aplicabilidad de IoMT son desafiantes y deberíamos comenzar a prestarle atención como un potencial riesgo al cual los atacantes quieren sacarle la mayor ventaja.

Los servidores web son una de las principales vías de propagación de malware en internet. Estos son frecuentemente atacados buscando fallos de seguridad que permitan infectarlos, para que a su vez sirvan como agentes de propagación de malware, control de botnets y minado de criptomonedas entre otras actividades maliciosas. Para esto, uno de los movimientos realizados por los atacantes es cargar archivos infectados en los servidores para el despliegue de dichos códigos maliciosos entre los usuarios. En este articulo nos centramos en archivos (ofimática y pdf) que podrían estar infectados y alojados en servidores web comprometidos. Aquí es donde, a través de la herramienta FOCA (opensource), podemos utilizar el plugin de DIARIO para analizar si estos archivos contienen o no malware en macros embebidas y evitar así la propagación de dichos archivos en internet o a tus propios usuarios. DIARIO, cómo detectar malware protegiendo tu privacidad Pero ¿qué es DIARIO? DIARIO es un plataforma que incorpora Inteligencia Artificial entrenada específicamente para detectar malware que generalmente escapa a las soluciones tradicionales de antivirus y, para ello, realiza un proceso de análisis de los documentos sin necesidad de acceder al contenido de los mismos, algo fundamental en el caso de tratarse, efectivamente, de archivos de índole privada o sensible. A través de la herramienta FOCA (opensource), y tras hacer la búsqueda de los documentos en el servidor web, puedes usar DIARIO para analizar, de manera periódica, los archivos cargados en tus servidores web para conocer si contienen malware o no (a nivel de macros) para así poder ejecutar alguna acción de mitigación y control sobre este riesgo. La ejecución del análisis puede ser de manera individual como por todos los archivos ‘crawleados’ o encontrados por FOCA y sus métodos de búsqueda. Al final, también podrás obtener un resumen tabulado de los resultados. Lo cierto es que estos archivos no deberían ni siquiera llegar a estar en los servidores web, ya que deberían controlarse antes de que lleguen al servidor. Pero las técnicas se actualizan y mejoran por parte de los delincuentes así que, en caso de que quieras probar, tienes una herramienta más para analizar desde otra perspectiva tus documentos con la finalidad de defenderte de este tipo de amenazas.

Según statcounter, el sistema operativo de Apple, en concreto macOS (OSX anteriormente), tiene una cuota de mercado de alrededor del 17%, siendo el segundo sistema operativo de escritorio más utilizado. Esto conlleva un mercado atractivo donde los cibercriminales están constantemente investigando en busca de vulnerabilidades que puedan ser efectivamente explotadas. Asimismo, en la actualidad el uso de malware multiplataforma a través de nuevos lenguajes de programación facilitan un despliegue mucho mayor y un espectro de victimas más amplio. Este tipo de código malicioso está diseñado para atacar varios sistemas operativos, incluido macOS. Esto brindaría potenciales “herramientas” para el cibercrimen con el objetivo de sacar el mejor partido de ellas, obviamente de manera maliciosa. Por este motivo es importante estar atentos a ciertas consideraciones, más allá del sistema operativo para que, como usuario o administrador de IT, puedas fortalecer este tipo de sistemas. Si bien existen recomendaciones y buenas prácticas que deben seguirse para mantener el dispositivo y la información que se gestiona lo más seguros posibles, el enfoque de este articulo es compartir algunas herramientas de seguridad adicionales que puedas tener a mano mas allá del sistema operativo. Herramientas de seguridad para estar más protegido A continuación destaco algunas de las herramientas (open source y gratuitas) más destacadas para proteger tu sistema operativo: BlockBlock: monitoriza las ubicaciones más comunes utilizadas por el software malicioso para ganar persistencia y lanza alertas cada vez que se modifican con un nuevo archivo FSMonitor: es una aplicación que monitorea y permite visualizar, en un entrono grafico amigable, todos los cambios en el sistema de archivos KnockKnock: puedes identificar software instalado en el equipo que no es legítimo y potenciales malware instalados con persistencia en tu sistema LinkLiar: en casos particulares, con el fin de proteger tu privacidad, podrías necesitar cambiar tu MAC Address y este programa te lo permitiría de manera fácil Lynis: te permite realizar un diagnostico exhaustivo del sistema y medir el nivel de hardening del mismo. Es una herramienta muy completa OverSight: monitoriza la webcam y micrófono del sistema, alertando cada vez que cualquier proceso intenta acceder a ellos RansomWhere?: monitorea continuamente buscando archivos cifrados por procesos sospechosos, pudiendo detener el proceso que está ejecutando el ransomware e intenta minimizar consecuencias de infección dentro del sistema ReiKey: identificar malware monitorizando las acciones del usuario, principalmente en busca de keyloggers en el sistema Santa: desarrollada por Google, consiste en una extensión del kernel de macOS que monitorea ejecuciones (‘white/blacklisting’ de aplicaciones) Stronghold: sencillo programa que permite configurar fácilmente ajustes de seguridad de macOS desde el terminal TaskExplorer: permite ver todos los procesos que se están ejecutando en el equipo, incluido cualquier clase de malware que pueda existir. Además, se integra con VirusTotal Como mencionaba al inicio de este articulo, no olvides que el sistema operativo en sí mismo tiene varios controles de seguridad y privacidad que deberías conocer. Además, las herramientas cambian y lo importante es mantenerse actualizado desde las diversas fuentes que existen hoy entre repositorios, procedimientos de iniciativas, artículos técnicos especializados, videos y mucho más que pueden sumar a que tus dispositivos, o a tu infraestructura si eres una empresa, estén más protegidas de amenazas para los sistemas macOS. Cada vez más, los dispositivos de Apple en general son muy codiciados por el cibercrimen, por lo que deberías adoptar cada una de estas recomendaciones para no ser una victima mas de los atacantes en la red.

Para los científicos e investigadores la optimización del tiempo en un laboratorio en la actualidad juega un papel fundamental para procesar y emitir resultados. Existen aplicaciones que tienen capacidades especializadas para laboratorios de I+D, laboratorios de desarrollo y fabricación de procesos o laboratorios bioanalíticos. Este tipo de software en muchos casos es encargado del tratamiento de datos patológicos, procesos de fabricación, gestión de muestras, datos personales, resultados clínicos, procesos químicos, formulas de experimentos “secretos”, intercambio de datos electrónicos, etc. Con lo cual, este tipo de información es un atractivo para los ciberdelincuentes como en cualquier otra industria de hoy en día. Las plataformas LIMS (Laboratory Information Management System, por sus siglas en inglés), conocidas también como LIS, son un tipo de software diseñado para mejorar la productividad y la eficiencia de los laboratorios actuales. Estas aplicaciones permiten realizar un seguimiento de los datos asociados con muestras, experimentos, flujos de trabajo de los laboratorios e instrumentos. La arquitectura y despliegue de este tipo de plataformas está presente en varios modelos, entre los principales están ‘thick-client’ y ‘thin-client’, clientes que se ejecutan desde cualquier estación de trabajo, entornos web, aplicaciones móviles y los entornos Cloud y SaaS, que permiten a los usuarios de estos sistemas conectarse a los servidores donde se albergan las funcionalidades y los datos del core de LIMS. En este articulo haremos una aproximación al estado de la seguridad de las aplicaciones móviles que son parte de la plataforma integral de un LIMS proporcionadas por los fabricantes. Analizando aplicaciones móviles LIMS Hemos seleccionado la última versión de 24 aplicaciones (iOS/Android) donde los usuarios pueden interactuar con una arquitectura LIMS desplegada en una organización y ejecutar las tareas correspondientes. Dentro de este muestreo de aplicaciones nos enfocamos en analizar de manera general únicamente la aplicación móvil. Para esta revisión utilizamos un dispositivo Android (rooteado), iPhone (sin jailbreak) y nuestras plataformas mASAPP (análisis de seguridad continuo de aplicaciones móviles) y Tacyt (herramienta de ciberinteligencia de amenazas móviles). Los principales controles de seguridad del Top 10 Mobile de OWASP fueron considerados para esta revisión. Los mismos, que solo representan un vistazo general, de una cantidad de pruebas que en detalle y de manera exhaustiva se podrían realizar. Los resultados demostraron que, si bien se han implementados controles de seguridad para el desarrollo de este tipo de aplicaciones, se encontraron varias debilidades que deberían corregirse y sobre todo mantener la mejora continua en el proceso de desarrollo. Las vulnerabilidades encontradas conforme a los controles evaluados se encuentran en la siguiente matriz de resumen: Sumario general de resultados controles analizados (-) Característica que aplica solo en plataformas Android Debilidades encontradas A continuación, queremos destacar varias debilidades que encontramos en estructuras fácilmente legibles entre archivos XML, API Keys o de configuración, lo que denota una mala práctica en cuanto almacenamiento local inseguro. Imagen 1: Archivos de Certificados / Key Hardcoded Imagen 2: Archivos con API Keys Legibles Imagen 3: API Keys Hardcoded en código fuente Si bien una gran parte de estas aplicaciones establecen canales de comunicación seguros (HTTPS) con sus backends como muestra nuestro cuadro de resultados, siguen funcionando algunos canales HTTP no cifrados, aplicaciones sin verificar autenticidad de certificados, certificados autofirmados o aplicación de métodos para mejorar la seguridad en este aspecto. Imagen 4: Uso de canales HTTP (inseguros) hacia el backend Así mismo, entre las practicas inseguras de programación de aplicaciones, continuamos observando la falta de características de ofuscación de código (despersonalización) para dificultar el proceso de reversing, eliminar archivos obsoletos o de pruebas, no usar funciones o APIs deprecadas, no utilizar funciones de debug o logging en aplicaciones productivas o comentarios muy descriptivos en el código. Características que incluyen la mayoría de guías de practicas segura de desarrollo. Imagen 5: Revisión de clases luego de proceso de decompilar dlls Imagen 6: Archivos para test almacenados en la App Imagen 7: Uso inseguro para transmisión de credenciales (base64) Imagen 8: Funciones de debug/ logging utilizadas Conclusiones Las aplicaciones móviles han beneficiado al monitoreo y automatización de procesos de los laboratorios, donde se pueden destacar funcionalidades como ubicación y seguimiento de muestras, inventarios, integración con instrumentos y otras plataformas, optimización de flujos de trabajo y muchas más. Sin embargo, no debemos dejar de lado los desafíos asociados a los controles de seguridad que en este tipo de aplicaciones requieren una consideración cuidadosa por parte de los diseñadores de equipos, los desarrolladores de software y sistemas de control, así como una buena concienciación de los usuarios que las usan. Los negocios de las empresas de la llamada ‘bioeconomia’ y sus laboratorios del futuro se están enfrentando de los riesgos informáticos asociados a fallos de seguridad que puedan aprovechar los ciberdelicuentes para obtener réditos dentro de la industria del cibercrimen. En el otro lado de la moneda estamos los investigadores, las organizaciones, fabricantes y la comunidad que intentamos aportar seguridad a este “nuevo” ecosistema.

Seguramente a estas alturas muchos ya han aceptado los nuevos términos y políticas de privacidad sin saber en realidad de qué se trataba o el impacto en la privacidad de sus datos. Otros, incluso, han decidido pasarse a Telegram y empezar a abandonar el mensajero verde… ¿Por qué tanto ruido con esta nueva actualización de la política? Para explicarlo brevemente, con la aceptación de esta actualización de condiciones y política de privacidad (obligatoria a partir del 8 de febrero), permitirás que tus datos de WhatsApp se compartan con el resto de los servicios de Facebook, lo cual era opcional hace unos años atrás donde el usuario podía decidir directamente qué compartía y qué no entre las empresas de Facebook. Notificación de actualización de condiciones y política de privacidad de WhatsApp Los usuarios están hablando mucho de este tema tan controvertido, ya que si no aceptan esta actualización, no podrán continuar utilizando la aplicación. En estos últimos días se han escrito varios artículos sobre esto dando algunos detalles, por lo que decidimos enfocar esta entrada a cuáles son las alternativas que tenemos ante las manifiestas intenciones de Facebook sobre utilizar nuestros datos. Consideraciones sobre la aceptación de los nuevos términos y condiciones Nos interesa analizar qué sucederá con los usuarios que aceptaron estos nuevos términos por error y que hora quieren revocar esta aceptación, aunque esto implique que el 8 de febrero de este año deberán dejar de utilizar la plataforma si no están de acuerdo. ¿Podrán hacerlo? ¿Existe algún lugar donde se puede revocar esta aceptación? La respuesta es simplemente NO. De todos modos, nos planteamos verificar algunas acciones que podrían intentar ejecutar los usuarios para revertir está aceptación “inconsciente”, sobre todo tras de leer tantos artículos o mensajes en Twitter sobre el tema. Decidimos comenzar con la más obvia: buscar una opción en las configuraciones de la cuenta, claro que no hay tal opción. La segunda opción que pensamos fue más dura: eliminar el usuario para posteriormente crearlo nuevamente o incluso cargar otro usuario en la aplicación y ver si nos aparecía nuevamente el cartel de aceptación de la política. Sin embargo, al ejecutar WhatsApp, la aplicación toma la última actualización (versión 2.20.206.24) dando por aceptada la nueva política. Siendo más incisivos, la tercera opción que tiene el usuario es desinstalar la aplicación por completo y reinstalar todo con versiones anteriores desde la tienda oficial. Pero al realizar este procedimiento, verificamos que no es posible la instalación de una versión anterior ya que no se encuentra disponible como una alternativa de manera oficial (claro que, si ya contamos con el instalador de una versión previa descargado o lo descargamos de una tienda no oficial (lo cual no recomendamos), si podríamos instalar otra versión con la política previa). Otros detalles Es interesante también resaltar que para la comunidad europea, la nueva política de privacidad no aplica completamente (sic), generando una política exclusiva para los usuarios residentes en esta zona del mundo y esto es debido a la normativa GDPR, que impide, tanto a Facebook como a cualquier otra empresa, compartir los datos de sus usuarios con sus otras empresas o que se utilicen para diversos intereses sin la aprobación explicita y clara del usuario. Gracias a esto, los usuarios de WhatsApp en la comunidad europea tienen ganada por ahora esa batalla por su el control de su privacidad. En resumen, podemos decir que los usuarios de WhatsApp que ya aceptaron la política de privacidad sin leer o tener en cuenta lo que implicaba para el manejo de sus datos, solo tienen dos opciones: Eliminar la cuenta y dejar de utilizar este servicio de mensajería migrando a otro de los muchos servicios similares que han surgido en los últimos años. Para quienes opten por esta opción pueden seleccionar entre varios servicios que han tomado fuerza últimamente. Continuar con el uso de este servicio teniendo en cuenta que no es posible retractarse de la nueva política de privacidad y aceptando que sus datos van a ser compartidos entre todas las empresas de Facebook, para fines que según se indican en la política tienen como objetivo “operar, proporcionar, mejorar, entender, personalizar, respaldar y promocionar nuestros servicios”.

Hoy en día, las tecnologías para desarrollar software para web se multiplican de manera vertiginosa, al tiempo que introducen, en algunos casos, nuevas formas de ataque o ventajas inesperadas para los atacantes. Veamos qué es WebAssembly (WASM) y qué potenciales beneficios puede tener para los atacantes. Este relativamente nuevo estándar abierto (anunciado en 2015 pero comenzado a usarse en 2017) nos permite la ejecución de código binario, compilado con lenguajes como C, C++ o Rust en navegadores web modernos, con todas las nuevas funcionalidades y rendimiento que puede conllevar. Arquitectura general de Aplicación WebAssembly WASM no se creó como reemplazo de JavaScript, sino para complementarse. De hecho es el motor JavaScript quien se encarga de ejecutarlo. Este estándar disfruta de múltiples casos de uso, como indica su sitio web: desarrollo/ejecución de juegos, aplicaciones CAD, plataformas de simulación, contratos inteligentes (blockchain), entre otros. Si quieres echar un vistazo sobre cómo ejecutan un binario de un juego en WASM puedes ver esta web que emula la famosa Gameboy o cómo AutoCAD comienza a ejecutarse desde cualquier navegador. Así como las nuevas tecnologías y lenguajes de programación nos ofrecen múltiples mejoras, es cuestión de tiempo que los atacantes encuentren los vectores de ataque para usarlos en su propio beneficio, y las aplicaciones WebAssembly no son una excepción. Veamos, a través del ejemplo a continuación, cómo se podría compilar un simple código malicioso para simular un ciberataque de ingeniería social. Ejemplo de compilación y ejecución de WASM (PoC Fraude) Este tipo de ataque simulado se conoce como “estafa de servicio técnico”, donde un estafador se hace pasar por un técnico de una compañía de tecnología usando tácticas intimidatorias e ingeniería social para engañar a las personas y hacer que paguen por servicios de soporte innecesarios. Cuando la víctima llama al número de soporte técnico, los estafadores piden dinero para solucionar el problema o piden accesos para instalar software malicioso (backdoor) en el dispositivo de la víctima. Este hilo de Twitter de Sergio de los Santos es un buen ejemplo de la sofisticación alcanzada. Caso de estafa de servicio técnico En estos casos, el beneficio para el atacante sería la ofuscación del código a la hora del análisis, más velocidad, etc. De hecho, el código WASM compilado se ha usado ya para campañas de minado de bitcoins mediante la infección de navegadores a través de código malicioso en sitios comprometidos. Entre los casos más conocidos están los de Coinhive y Cryptonight. Ambos ataques (mediante JavaScript generado por WASM) aprovecharon el poder computacional para “minar” criptomonedas a través del navegador. De forma general, cuando navegamos por Internet podemos encontrarnos con sitios que han sido comprometidos por los estafadores comúnmente con código JavaScript puro o WASM y, a partir de aquí, si nuestros navegadores no tienen controles adecuados, se puede consumar el ataque. Si WebAssembly está siendo utilizado como apoyo para ataques de criptominado, es posible que los atacantes sigan sacando provecho desde otros frentes. Otras fórmulas de uso malintencionado de WASM son: Redirección a URLs maliciosas: existen campañas para infectar dispositivos mediante redirecciones maliciosas (a través de código WebAssembly) de sitios comprometidos a las mismas estafas de soporte técnico, minado de criptomonedas, etc. Keyloggers, registrar el pulsado de teclas para robar contraseñas y cualquier otra información confidencial de los visitantes de sitios web comprometidos, aprovechando que mediante WebAssembly se está generando código que evade las detecciones típicas de controles externos o de navegadores. Explotación de navegadores: explotar vulnerabilidades en el navegador casi siempre involucra JavaScript. Por lo tanto, WebAssembly puede desempeñar un papel importante en la explotación del navegador al ofuscar el código de explotación. Las tecnologías ofrecen muchas posibilidades, WebAssembly no es la excepción y podrían ser un aliado o un enemigo. Está muy claro que presenta muchas ventajas, pero puede proporcionar nuevas vías para explotar debilidades en diferentes casos. Si bien los desarrolladores se esfuerzan por integrar características de seguridad, nosotros como usuarios debemos tomar nuestras precauciones, teniendo actualizandos nuestros navegadores con complementos que bloqueen ejecución dinámica de JavaScript, como NoScript. Desde ElevenPaths hemos aportado herramientas como AMSIext para evitar ejecuciones no deseadas en los navegadores.

En el momento de escribir este artículo existen muchas empresas alrededor del mundo que están innovando, creando y mejorando diversas aplicaciones, robots y gadgets para monitorear nuestra salud. De hecho, muchas de éstas son ya una realidad y están siendo vendidas en el mercado de aplicaciones e implementadas en hospitales en el mundo. Todos estos relojes con sensores, chips insertados en nuestro cuerpo, teléfonos inteligentes y otros aparatos son fantásticos y almacenan un gran cantidad de datos de los usuarios pero, ¿están siendo protegidos? ¿Se usarán estos datos para emitir diagnósticos? ¿Qué pasa con la seguridad del software de estos dispositivos? ¿Qué nos deparan, por ejemplo, las cirugías realizadas por robots por control remoto? La digitalización de la industria sanitaria Se habla de innovación, digitalización y robotización en la industria de la salud y esto ha llevado al ser humano a realizar proyectos tan interesantes como el conocido DaVinci (el robot con el sistema quirúrgico más avanzado del mundo) u otros quizás menos conocidos como el microrobot llamado ViRob, destinado a limpiar y drenar “tuberías” del cuerpo como una necesidad en las operaciones. Pero si hablamos de dispositivos comunes y de accesibilidad para los usuarios, encontramos los audífonos para monitorear tu salud integral en tiempo real. En cuanto a aplicaciones móviles, vemos como mediante una fotografía realizada con el dispositivo móvil y el procesamiento avanzado de imágenes se podrían detectar ciertos tipos de cáncer en la piel. Tanto es así que el proyecto -GoogleLeNet de Google, originalmente diseñado para interpretar imágenes para coches inteligentes, viene trabajando ya en esto hace mucho tiempo. En la actualidad es imposible estar al día con tal cantidad de dispositivos por los que llega información y esto, para los médicos, no es una excepción. Un médico puede realizar diagnósticos a partir de su experiencia con varios pacientes, pero una computadora lo está haciendo en la actualidad basándose en datos y comparaciones de resultados que se obtuvieron de cientos o millones de casos similares. La salud es lo primero, siempre que sea segura Los datos que hoy en día son tratados por todos estos gadgets de la industria sanitaria necesitan ser confiables y seguros para poder emitir un diagnóstico fiable mediante una analítica. Por tanto, se deben proteger y probar los desarrollos de software que hacen que estos aparatos tecnológicos funcionen. La comunidad de la ciberseguridad, así como empresas de seguridad en general, han estado realizando investigaciones al respecto de este tema, donde han expuesto vectores de ataque y vulnerabilidades sobre este tipo de entornos. De igual manera, la FDA (US Food and Drug Administration) ha creado guías y realiza frecuentes llamamientos a los creadores de tecnologías médicas para que pongan énfasis en la seguridad de sus productos. La industria sanitaria, como muchas otras, depende en gran parte de la tecnología para conocer nuestro estado de salud. Probablemente, cada nuevo dispositivo que utilicemos compartirá de alguna manera datos con otras plataformas para la toma de decisiones por parte de los médicos. El "Internet de la salud" Así como el “Internet de las cosas” se refiere a interconectar varios dispositivos entre sí para que en muchos casos interactúen de manera automática, el “Internet de la salud” quizás permitirá que todos nuestros datos médicos estén conectados entre sí, de forma que a través de diversos sistemas puedan condensarse en un informe integral. Nos encontramos así en el momento en que todos estos datos se están almacenando en entornos que deberían tener un nivel de seguridad gestionado, evaluado y monitoreado frecuentemente, porque de ellos dependerá la toma de decisiones. Es realmente importante que nos involucraemos en esta problemática como comunidad y como usuarios. Además, es necesario que tanto los gobiernos como las entidades legales aseguren el buen empeño de todos los actores de esta industria de manera permanente mediante leyes y normativas. De esta manera conseguiremos mantener un nivel de seguridad adecuado que nos permita sentirnos un poco más tranquilos ante las ciberamenazas.

La industria del retail farmacéutico se ha visto obligada a moverse mucho mas rápido en esta carrera de la llamada "transformación digital", debido a la pandemia global que actualmente atraviesa la sociedad. Por tanto, las empresas farmacéuticas han tenido que utilizar aplicaciones que ya tenian desplegadas o desplegar aplicaciones rápidamente. Estas aplicaciones son las mismas que mueven su negocio para gestionar recetas y pedidos de medicamentos, descuentos, etc. y que hacen atractivo a los clientes el uso de sus servicios en esta época de alta demanda de medicamentos. Por otra parte, muchos gobiernos del mundo establecieron la cuarentena obligatoria, la cual hizo que las personas hiciesen mayor uso de los medios digitales para la compra de medicinas, alimentos y otros productos. Por ello, las aplicaciones móviles y la infraestructura que las soportan juegan un papel fundamental hoy en día, y lo más seguro es que incorporen a nuestro día a día más que nunca. ¿Qué implicaciones tiene esto? Todos los datos que se generan a través de los clientes son gestionados por tu dispositivo móvil y la infraestructura tecnológica (propia o de un tercero) de las empresas o cadenas farmacéuticas. Como es de suponer, estas aplicaciones podrían tener vulnerabilidades y suponer un riesgo para los datos de los clientes. Muchas de estas aplicaciones tienen comunicación directa con dispositivos y sistemas de la compañía que ejecutan procesos internos, creando un vector de ataque adicional para los cibercriminales que busquen este tipo de información. Imagen 1: Descripción y funcionalidades de las aplicaciones farmacéuticas En este análisis he seleccionado la última versión de 29 aplicaciones (iOS/Android) de compañías farmacéuticas en las que el usuario puede acceder a diversos servicios, entre los cuales destacan, principalmente, la compra online de fármacos y la gestión de recetas médicas. Las aplicaciones fueron seleccionadas de manera aleatoria en farmacéuticas de Sudamérica, España y Estados Unidos. Dentro de este muestreo de aplicaciones nos enfocamos en analizar únicamente la aplicación móvil, ya que si bien se descubrieron debilidades del lado del servidor (backend), éstas no fueron incluidas. Para esta revisión utilizamos un dispositivo Android (rooteado), un iPhone 5S (no jailbreak) y nuestras plataformas mASAPP (análisis de seguridad continuo de aplicaciones móviles) y Tacyt (herramienta de ciberinteligencia de amenazas móviles). Resultados del análisis Los controles de seguridad del Top 10 Mobile de OWASP realizaron pruebas a nivel general, las cuales sólo representan un vistazo general de la cantidad de pruebas que de manera exhaustiva que se podrían realizar a dichas aplicaciones móviles. En nuestro caso, los resultados demostraron que, si bien se implementaron controles de seguridad para el desarrollo de este tipo de aplicaciones, se encontraron varias debilidades que deberían corregirse y, sobre todo, mantener la mejora continua en el proceso de desarrollo. Las vulnerabilidades encontradas conforme a los controles evaluados se encuentran en la siguiente matriz de resumen: Sumario general de resultados controles analizados (-) Característica que aplica solo en plataformas Android En primer lugar, queremos destacar varias debilidades que encontramos en estructuras fácilmente legibles como archivos XML, API Keys o de configuración, lo que denota un almacenamiento local inseguro. Imagen 2: Archivos de Certificados/Key Hardcoded Imagen 3: Archivos con API Keys Hardcoded Legibles Si bien una gran parte de estas aplicaciones establecen canales de comunicación seguros (HTTPS) con sus backends, siguen funcionando algunos canales HTTP no cifrados, como muestra nuestro cuadro de resultados. También encontramos aplicaciones que no verifican la autenticidad de sus certificados o certificados autofirmados lo que muestran una necesidad de mejorar la seguridad en este aspecto. Imagen 4: Uso de Certificados Auto firmados Asimismo, entre otras prácticas inseguras de programación de aplicaciones, observamos la falta de características de ofuscación de código (despersonalización) para dificultar el proceso de reversing en casi todas las aplicaciones Android. Imagen 5: Revisión de clases java luego de proceso de reversing Imagen 6: Documentación y comentarios técnicos en detalle Un dato no menor en este análisis es que 5 de las aplicaciones fueron encontradas por Tacyt en markets no oficiales, en muchos casos desplegadas por usuarios que no eran necesariamente los dueños de la aplicación (a saber con qué fines). Imagen 7: Muestra de una aplicación encontrada en otro s markets no oficiales Conclusiones Creemos que estos hallazgos siguen siendo un aporte más en el avance hacia una mejor seguridad y esperamos que sirva para ayudar a los desarrolladores de aplicaciones del sector farmacéutico. En esta crisis sanitaria mundial se han producido muchos otros casos en los que las industrias han tenido que transformar muchos de sus servicios tradicionales en servicios digitales, pero de una forma abrupta, con los riesgos informáticos que ello conlleva. Gestionar la seguridad y privacidad de los datos los usuarios de las aplicaciones farmacéuticas es fundamental, ya que éstas almacenan datos privados de nuestra salud. Es importante que las empresas de este sector sean consientes de que los datos de sus clientes están expuestos a riesgos informáticos y de que, mediante controles apropiados y evaluaciones constantes, deberían protegerlos, manteniendo también a salvo su infraestructura tecnológica ante potenciales ciberamenazas.

En la actualidad, con la gran cantidad de amenazas informáticas, los equipos de investigación y analistas necesitan acceder de manera rápida a fuentes de datos que comiencen a dar pistas sobre el incidente que tienen bajo la lupa. En la década de los 90 eran muy pocas las plataformas o servicios de donde podías recolectar información tal como datos acerca de un dominio, hashes de malware, direcciones de phishing, datos de un email, identificación de botnets, etc. Varios de estos indicadores dentro de un ataque informático son conocidos hoy en día como IoCs. De hecho, en muchos casos tenías que desarrollar tus propios scripts para obtener dichos datos, armarte de honeypots para recolectar algunos o descargar los pocos datos que podías de servicios de terceros. Y por supuesto ni hablar de analizar dicha información: debías integrarla con tu equipo de desarrollo y realizar toda una travesía para obtener finalmente las funcionalidades deseadas. Esto era un proceso lento, rudimentario y poco escalable para las empresas, instituciones gubernamentales, fuerzas de la ley y equipos de seguridad. Con las interfaces APIs, todo cambió A medida que las industrias tecnológicas evolucionaron, las empresas comenzaron a hacer uso de las interfaces API. De igual manera, la gente de InfoSec evidenció una oportunidad para mejorar sus herramientas y plataformas que almacenaban datos de brechas de seguridad, IoCs, vulnerabilidades, etc. La cantidad de servicios y bases de datos que alojan información de seguridad es muy amplia, tanto pública como privada, por lo que suele estar dispersa y en algunos casos es volátil. Los equipos de SOCs, fuerzas de la ley, gobiernos, analistas y equipos de respuesta a incidentes necesitan monitorear, investigar, obtener y mantener estos datos lo mas rápido posible. Con esta perspectiva, hace poco escribíamos una entrada del blog contando una de nuestras recientes herramientas, TheTHE, que a partir de una interfaz muy simple y potente a la vez, se basa en la idea de que un dato de IoCs sea utilizado como disparador para que se ejecuten búsquedas (a través de sus plugins). De esta manera se puede ir descubriendo y consolidando toda la información posible de diversas fuentes. Para entenderlo mejor, veamos un caso de uso con uno de sus plugins. Imagen 1: API REST de servicio de DIARIO para análisis de malware en ofimática Caso de uso con DIARIO de 11Paths Teniendo un hash como un IoC durante un ataque a una organización, podríamos llevarlo a TheTHE y lanzar algún plugin, en este caso el de DIARIO, con el fin de consumir su API REST y determinar si contiene un malware embebido como macro. Imagen 2: Analizando hash mediante API REST a DIARIO De hecho, también es posible lanzar otro plugin simultáneamente para conocer la IP del servidor C2C, que se encuentra en el archivo con la macro, y revisar la reputación de la dirección IP. Así mantendremos cada dato de manera simple y sintetizada en una sola plataforma, pudiendo almacenarla y compartirla en nuestra red local, e incluso monitorear los cambios durante el tiempo que dure la investigación. Imagen 3: Lanzando plugin de Reputación de IP y otro de whois Sin embargo, éstos sólo son algunos escenarios que podríamos utilizar dentro un proceso de respuesta a incidentes o Threat Hunting, dado que la modularidad de TheTHE permite que cualquiera pueda desarrollar sus propios plugins dependiendo de sus necesidades. A continuación podemos ver un ejemplo de los archivos básicos y necesarios que se deberían desarrollar para poder generar un nuevo plugin y recibir los datos en el frontend de la aplicación. Pasos mínimos para generar un plugin Subtasks: [thethe/tasks/subtasks] generar un archivo ‘nombredeplugin.py’ (botscout.py) con toda la programación del mismo y básicamente deberemos devolver como resultado un objeto de tipo JSON de Python. Tasks: [thethe/tasks/tasks.py] invocar los métodos del anterior archivo creado de tu plugin (botscout.py) y luego método con las directrices como lo muestra en la siguiente imagen. Finalmente, [frontend/src/tempate/] crear una carpeta con el nombre del plugin (en este caso "botscout") y dentro de la misma generar un index.vue donde desarrollar nuestra parte del frontend en vueJS. Desde ElevenPaths creemos en la importancia de contribuir con diferentes organismos para el intercambio de información sobre amenazas, ya que el poder compartir información y herramientas OpenSource como TheTHE en base a experiencias propias incentiva a toda la comunidad a participar activamente en este tipo de iniciativas. Esperamos que esta herramienta ayude a analistas y equipos de Threat Hunting a agilizar sus investigaciones, de la misma manera que deseamos que las diversas experiencias que tenga cada uno nos ayuden a enriquecer esta plataforma.

Las aplicaciones creadas hoy en día para interoperabilidad en diferentes sistemas operativos, incluyendo Skype, Spotify, Signal, Slack, navegadores como Brave, editores de código como Visual Studio Code y muchos programas más, son usadas a diario por cada uno de nosotros y se basan en uno de los lenguajes más usados en la actualidad como es JavaScript. Además, se suman sus diferentes componentes a este stack, para su desarrollo y ejecución tanto en frontend como backend. Como decíamos el año pasado, este popular lenguaje cuenta con un sinnúmero de oportunidades para poder desplegar paquetes y aplicaciones para el un desarrollo de software web, pero no sólo eso, a esto también se suma que se han vuelto muy populares para el desarrollo de programas de escritorio independientemente del sistema operativo. Existen varios frameworks populares para el desarrollo de este tipo de aplicaciones, entre los cuales se destaca ElectronJS (como número uno y más usado), pero tenemos otros como NWJS, AppJS, Meteor y más. Arquitectura de Aplicación ElectronJS Al crear estas aplicaciones, como cualquier otra tecnología, los atacantes buscan formas de aprovecharse de estas “nuevas” implementaciones, que en muchos de los casos extienden fallos de diseño de los propios lenguajes o, al ser integradas con otros componentes, amplían los vectores de ataque, que en la actualidad pueden llegar a representar un riesgo para los datos de los usuarios. A través de la modificación de este tipo de aplicaciones y sin emitir ninguna alerta al usuario sobre dicho comportamiento, investigadores de seguridad han encontrado la forma de poder explotar debilidades que permitan introducir código arbitrario malicioso backdoor que ejecute acciones maliciosas en el equipo de la víctima (por ejemplo, capturar pulsaciones del teclado keylogger o habilitar la cámara del usuario, entre otras). De la misma manera, un consultor de seguridad puede hacer uso de estos mismos vectores de ataque dentro de una auditoría para revelar datos o hacer movimientos laterales en una red. De hecho, existen hoy en día varias herramientas de ataque, como por ejemplo beemka, que permiten sacar provecho de manera rápida de estas vulnerabilidades. Cómo proteger tus aplicaciones Aquí algunas de las referencias que podrían ayudar a asegurar este tipo de aplicaciones: Mantener tu aplicación sincronizada con la última versión del framework y componentes usados en tu desarrollo. Evaluar las dependencias usadas por tu aplicación. Analizar y conocer completamente el framework usado, esto incluye sus debilidades. Implementar prácticas de desarrollo seguro en tu proyecto. Esto sólo es un breve recordatorio para no descuidar las cosas básicas durante el desarrollo y despliegue de nuestras aplicaciones. En definitiva, los vectores a nuevas tecnologías o lenguajes migran, se actualizan, se mejoran y se diversifican, pero los riesgos siempre están presentes en todo el ciclo de vida del software, con lo cual siempre debes preguntarte ¿cuántas de las aplicaciones que uso podrían están poniendo en riesgo mis datos privados o están arriesgando la reputación de mis proyectos de desarrollo?

Con frecuencia viajamos hacia nuestros destinos preferidos y vemos cómo las ciudades se modernizan a partir del uso a tecnologías con el fin de agilizar procesos de pago, mejorar el transito y lograr que los usuarios ganen tiempo en sus rutinas diarias. Toda esta información es gestionada desde alguna infraestructura tecnológica para tomar decisiones, como verificación de pagos y saldos, apertura de telepeajes, acceso a lugares privados, etc. En otra serie de post hemos ido analizando aplicaciones móviles enfocadas en otro tipo de entornos, quizás un poco ‘inusuales’. Para escribir este articulo pensamos en realizar una revisión general a la seguridad de las aplicaciones móviles sobre telepeaje (Pay Toll o Electronic Toll Payment en inglés), y cuál seria el estado actual de seguridad de estas aplicaciones que nos ayudan a gestionar información y realizar transacciones desde nuestro coche. Imagen 1: Muestras de Aplicaciones Móviles para gestión de Telepeajes Imagen 1: Muestras de Aplicaciones Móviles para gestión de Telepeajes Hoy en día, muchas de estas aplicaciones tienen interacción con dispositivos de telemetría, RFID o comunicación directa desde internet con sistemas de la infraestructura tecnológica interna de las organizaciones, creando un vector de ataque adicional para las mismas, sumado a que los usuarios podrían utilizar aplicaciones inseguras para gestionar sus datos. En este análisis hemos seleccionado 41 aplicaciones (tanto de iOS como de Android) que percibimos como relevantes en base a su ranking, número de descargas en sus respectivos markets y características puntuales, todas ellas en su última versión, utilizando nuestra plataforma mASAPP de análisis de vulnerabilidades en aplicaciones. Dentro de este muestreo de aplicaciones nos enfocamos en analizar únicamente de manera general y no a nivel de detalles cada aplicación móvil, ya que si bien se descubrieron debilidades del lado del servidor (backend) no fueron incluidas. Analizando apps en Android e iOS 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 realizamos pruebas a nivel macro y los resultados nos permitieron observar que el desarrollo de este tipo de aplicaciones necesitan mejorar varios aspectos de seguridad. Imagen 2: Resumen General de Resultados En principio, ciertas evidencias de este análisis nos demuestra que las aplicaciones interactúan cada vez con servicios en la nube para almacenar la información, tipo firebase, y es así también que podemos encontrarnos con varias de estas aplicaciones exponiendo datos, como se muestra en la imagen 3. I magen 3: Firebase DB expuesta públicamente De la misma manera, encontramos estructuras fácilmente legibles entre archivos XML, API Keys o de configuración, lo que denota otra mala práctica en cuanto almacenamiento local inseguro. I magen 4: Archivos de Certificados/Key ‘Hardcoded’ I magen 5: Archivos con API Keys “hardcoded” Legibles Si bien una gran parte de estas aplicaciones establecen canales de comunicación seguros (HTTPS) con sus backends; como muestran nuestro cuadro de resultados, siguen funcionando algunos canales HTTP no cifrados, aplicaciones sin verificar autenticidad de certificados, certificados autofirmados, o aplicación de métodos para mejorar la seguridad en este aspecto. I magen 6: Uso de Certificados Auto firmados Entre las prácticas inseguras de programación de aplicaciones, se observan en este tipo de aplicaciones la falta de características de ofuscación de código (despersonalización) para dificultar el proceso de reversing. Imagen 7: Revisión de clases java luego de proceso de reversing Imagen 7: Revisión de clases java luego de proceso de reversing Un dato no menor dentro de los análisis que realizamos, es que hemos encontrado que varias de las aplicaciones analizadas son encontradas por nuestra plataforma Tacyt en markets no oficiales -en este caso 12 aplicaciones-, desplegadas por otros usuarios que no son necesariamente los dueños de la aplicación. Esperamos que este post sirva como aporte para que la industria y estos entornos continúen mejorando en aspectos de seguridad, ya que como vemos en tecnologías que son cada vez mas parte de nuestra rutina diaria, se presentan riesgos informáticos y nuevos vectores de ataque que los cibercriminales buscarán utilizar si no comenzamos a tenerlos en cuenta para su mejora y protección.

Los administradores de paquetes de software se extienden a través de los sistemas operativos como por ejemplo: apt, yum, Chocloatey, etc. Así como para los lenguajes de programación (Bundler, Composer, pip, RubyGems, etc.). La versatilidad que tienen estas porciones de código (packages) para implementarlos en nuestros proyectos de software tiene un potencial muy relevante a la hora de desarrollar aplicaciones de manera ágil, ya que al ser componentes previamente desarrollados permiten acelerar nuestro proyecto, mejorar funcionalidades y, de igual manera, compartir con la comunidad nuestro conocimiento. Pero... ¿qué pasa al vincular código de terceros en nuestros proyectos? Este cuestionamiento debería llevarnos a tomar en consideración varios aspectos como temas de compatibilidad, rendimiento... Pero sobre todo, aspectos de seguridad del código que estamos incluyendo, ya que en muchos casos es un "plug and play" en nuestros proyectos de software y no conocemos qué está haciendo exactamente dicha programación. Se conocen casos específicos de ataques a las famosas “gemas” del lenguaje de programación Ruby, en la actualidad muy utilizado en diferentes entornos. Estos ataques han sido detectados tanto por la comunidad de que da soporte al proyecto como por plataformas independientes. Pero es tal la cantidad de paquetes indexados (153.937 al generar este post) y desplegados, que el escenario se complica. Estadísticas de “Gems” Ruby en la actualidad. Fuente: https://rubygems.org/stats De igual manera otros lenguajes que operan bajo estos esquemas, han sido victimas por parte de los delincuentes informáticos para generar ataques dirigidos, en este caso investigadores de la Universidad de Hamburgo han ayudado a descubrir vectores de ataques en su tesis denominada “Typosquatting in Programming Language Package Managers”, donde evidencian cómo mediante técnicas “Typosquatting” pueden entregar paquetes de software falsos y ejecutar código remoto a través de los mismos. Si bien vemos cómo las “gemas” de Ruby sufren de este tipo de amenazas, es evidente que otros tipos de administradores de paquetes también han sido afectados por varios ataques, y como resultado los desarrolladores al usar dicho código en sus proyectos se ven afectados. Pero en el caso de Pip de Python, también se han conocido desde ataques de inyección de malware para controlar servidores hasta paquetes maliciosos para minar criptomonedas. Prueba de Concepto de ejecución de código “malicioso” en paquete Python Pip Si bien en este post particularmente nos hemos referido a dos administradores de paquetes (RubyGems y Pip), hay algunas medidas iniciales que podrían ayudar a minimizar el riesgo de algún tipo de ataque mediante este vector, entre las que podemos mencionar: Realiza análisis del código de cada paquete de software previo a incluirlo en tus proyectos. Utiliza parámetros para instalación de paquetes con el usuario local con privilegios mínimos. Pon atención al momento de instalar paquetes de software, especialmente cuando usas privilegios de administrador o root en tu sistema. Instale paquetes en modo de comprobación de hash utilizando los hashes que proveen los repositorios oficiales. Esto protegerá la integridad del paquete y garantizará que obtenga el paquete fiable. Verifique que este escrito el nombre del paquete correctamente. Puede haber paquetes maliciosos con un nombre similar donde los atacantes estén usando técnicas de “Typosquatting”. Debemos tener cuidado con los paquetes que utilizamos en nuestros proyectos desde el gran universo de administradores de paquetes y las tecnologías de programación en sí mismo, que si bien son de gran ayuda para la comunidad de desarrollo, en la actualidad los atacantes buscan diversos vectores para poder realizar acciones maliciosas dentro de nuestras infraestructuras tecnológicas.

En la actualidad, el sector de aseguradoras, como la mayoría de industrias, se suma a la transformación digital, brindando a través de la tecnología un salto relevante a nuevos y mejores servicios para sus clientes. Sin duda, las compañías de seguros siempre han buscado acercarse a sus agentes o corredores como forma de asegurar su lealtad o preferencia frente a otras compañías; así como a sus clientes finales para que ellos ser menos dependientes de los primeros. Las entidades de seguros pueden operar en uno o en múltiples servicios (hospitalarios, accidentes, automóvil, incendios, responsabilidad civil, etc.), con lo cual a día de hoy pueden desde una aplicación móvil algún usuario podría acceder a múltiples opciones como, por ejemplo, contratar un seguro medico, gestionar pólizas y reclamos, reportar siniestros, entre otros. Toda la información que se produce por los asegurados es gestionada por tu dispositivo móvil y alguna infraestructura tecnológica (propia o de tercero) de la empresa aseguradora, con lo cual, como en cualquier otro tipo de industrias estas aplicaciones podrían mantener vulnerabilidades que podrían en riesgo los datos de sus clientes. Muchas de estas aplicaciones tienen comunicación directa desde internet con dispositivos y sistemas a la interna de la compañía que ejecutan procesos internos, creando un vector de ataque adicional para los cibercriminales que intenten buscar este tipo de información. Funcionalidades de Aplicación de Compañía de Seguros Médicos En este análisis, he seleccionado la última versión de 58 aplicaciones (iOS/Android) de compañías aseguradores donde el usuario (agente, broker o empresas) accede a diversos servicios. Las aplicaciones fueron seleccionadas en base a fuentes de las compañías de ranking en Latinoamérica y en el mundo. Dentro de este muestreo de aplicaciones, nos enfocamos en analizar únicamente la aplicación móvil, ya que si bien se descubrieron debilidades del lado del servidor (backend) no fueron incluidas. Para esta revisión utilizamos un dispositivo Android (rooteado), IPhone 5S (no jailbreak) y nuestras plataformas mASAPP (análisis de seguridad continuo de aplicaciones móviles) y Tacyt (herramienta de ciberinteligencia de amenazas móviles). Los controles de seguridad del Top 10 Mobile de OWASP se realizaron pruebas a nivel general, las mismas que solo representan un vistazo general de una cantidad de pruebas en detalle y de manera exhaustiva que se podrían realizar a las aplicaciones móviles. Top 10 Mobile Risks OWASP Los resultados demostraron que, si bien se han implementados controles de seguridad para el desarrollo de este tipo de aplicaciones, se encontraron varias debilidades que deberían corregirse y sobre todo mantener la mejora continua en el proceso de desarrollo. Las vulnerabilidades encontradas conforme a los controles evaluados se encuentran en la siguiente matriz de resumen: Resumen general con resultados controles revisados Los datos y detalles técnicos donde se mencionan a la empresa dueña o detalles del desarrollador de la aplicación han sido censurados; sin embargo, iremos presentando hallazgos que hemos considerado muestreos relevantes de potenciales debilidades. Dichas vulnerabilidades podrían estar poniendo en riesgo los datos de los usuarios e inclusive la infraestructura con que interactúan y a continuación te contamos más detalles. Almacenamiento Inseguro y Privacidad (M2) En 21 aplicaciones de las 58 analizadas hemos encontramos datos a los que hemos catalogado como “privados o sensibles” en donde se pudieron obtener usuarios y contraseñas de acceso a servicios como APIs, archivos XML de configuraciones, archivos SQLite sin protección, entre otros. Los resultados se obtuvieron mediante el análisis estático de la aplicación y observando las aplicaciones en ejecución. Evidencias de Hardcode Claves en Texto-Plano (acceso API y uso de servicio web) Archivo de Certificados/Key “Hardcode” en App iOS Comunicación, Autenticación y Cifrado (M3 - M4 - M5) Doce de las aplicaciones 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), lo que facilitaría a un atacante generar ataques MiTM (Main-in-the-Middle). Uso de Certificados Auto firmados en Apps Evidencia de uso de canales HTTP (sin cifrar) en Apps para comunicación con Backends Vulnerabilidades por Desarrollo de Código Inseguro (M7) Entre los principales hallazgos de este tipo de vulnerabilidades seguimos encontrando malas practicas de desarrollo que exponen a el App a vulnerabilidades de tipo Inyección SQL y XSS (Cross Site Scripting) dado que se encuentra permitido el uso de Webviews (funcionalidad deprecada) para que puedan ejecutar código JavaScript o a su vez agregan librerías HTML. Uso de consultas concatenadas vulnerables potencialmente a SQL Injection Hardcode de clave secreta Otras de las malas prácticas que pudimos observar en esta categoría, es el uso indebido o generación de funciones para realizar debugging o logging de aplicaciones en producción. Este tipo de funciones deberían usarse exclusivamente en entornos de desarrollo. Uso de Funciones de debugging “Console” activadas en producción Información Sensible “Harcodeada” y Uso de Ofuscación (M9) En 22 aplicaciones Android de las 30 analizadas se pueden descargar y modificar de manera arbitraria, con lo cual se puede obtener de manera legible las clases de java de las aplicaciones ya que no mantienen ninguna característica de ofuscación de código (despersonalización) para dificultar el proceso de reversing. Revisión de clases java luego de proceso de reversing Archivos con API Keys legibles Desde nuestras investigaciones, generación de post y contenido, creemos que esto sigue siendo un aporte más y esperamos que 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, también se pueden heredar malas prácticas que conllevan a mejorar y revisar nuevos vectores de buscan los atacantes. Sin duda, gracias a los nuevos recursos digitales, las compañías de seguros tienen posibilidades de acceso, personalización y contacto; sin embargo, es importante que sean consientes que los datos de sus clientes estas expuestos a riesgos informáticos por lo cual mediante controles apropiados y evaluaciones constantes deberían protegerlos manteniendo a salvo también la su infraestructura tecnológica ante potenciales amenazas. Carlos Ávila Chief Security Ambassador carlos.avila@global.11paths.com @badboy_nt

En la actualidad, cuando se evalúa la seguridad de las empresas, por lo general, dentro de los vectores de ataque, está muy presente por parte de los auditores las tecnologías más actuales como: aplicaciones web, dispositivos de red, aplicaciones móviles, IoT (Internet of Things), VoIP, entre otros. En este artículo, no pretendemos hablar de esas tecnologías, sino más bien enfocarnos en algunas que han existido por mucho tiempo y siguen operando en muchas de las empresas. A las que estamos haciendo referencia es a los aplicativos conocidos como cliente/servidor o también con diferentes nombres –en inglés– como ‘Fat Client’, ‘Heavy Client’, ‘Rich Client’, ‘Thick Client’... Todas, por lo general, siguen una arquitectura cliente servidor. Estos aplicativos son desarrollados ‘in-house’ o por terceros e implementados por las empresas en las estaciones de trabajo de sus usuarios. Por ejemplo, una persona del área de contabilidad hace uso de un cliente instalado en su computador para realizar sus procesos contables que están en frecuente comunicación con el servidor central de este aplicativo. Hoy en día, en el camino de los procesos de pentesting o evaluaciones de seguridad (dependiendo del enfoque), los auditores se pueden encontrar con aplicativos clientes (instalados en el host del usuario) de tipo ejecutables (DotNet, Java, C, C++, etc.), Applets de java, swf de Flash. Estructura de Cliente/Servidor (Bypass Aplicativo Cliente) Comúnmente se menciona que cada aplicativo instalado en una computadora es un potencial vector de ataque. Aquí mencionamos algunos de estos vectores que podrían analizarse para encontrar debilidades que puedan ser explotadas por un tercero y usarlas para alguna finalidad maliciosa dentro de la red. Análisis de tráfico Decompilación del código Backend (webservices, APIs) DLL Hijacking Archivos de configuración Durante este año, mis compañeros de laboratorio han escrito una serie de post sobre protecciones de binarios, que sirven como punto de partida para el análisis y control de protección (por ejemplo, contra desbordamiento de buffer) al momento de la compilación del aplicativo. Es por esto, que para motivos de ilustración y que se pueda evidenciar el impacto que podría conllevar el que no hayan sido aplicado controles necesarios, a nivel de la infraestructura, y sobre todo prácticas de desarrollo seguro de software (S-SDLC) en este tipo de aplicativos, hemos definido algunos escenarios con debilidades obtenidas de pruebas en diferentes aplicativos con el fin de ayudar a su entendimiento. Escenario De-Compilación: Usando herramientas de reversing se puede llegar a de-compilar los archivos ejecutables (binarios), en este caso un aplicativo .NET donde se obtiene el código legible y a través de estas técnicas obtener datos “hardcodeados” (credenciales de conexión a DBMS SQL Server). Decompilacion de Código en Memoria (Aplicativo ClickOnce .NET) A través de estos datos un atacante se podría conectar arbitrariamente al servidor SQL y obtener datos de la empresa. Este tipo de datos se podrían usar para escalar privilegios, por ejemplo. Conexión a la base de datos exitosa con credenciales obtenidas del Aplicativo Cliente Otro tipo de ataque podría ser algún tipo de ejecutable .jar que se pudiera decompilar, modificar y volver a empaquetar. Escenario Debilidades en Backends (Webservices/APIs): En varias ocasiones, este tipo de aplicativos tienen conexión a servidores de base de datos o aplicaciones web (webservices/API). Por esto, es otro potencial riesgo ante ataques más allá del binario; los mismos que podrían mantener debilidades en las vulnerabilidades ya conocidas para aplicaciones web. Análisis y descubrimiento de comunicación con Backend (Webservices) Ataques generados al Webservices (Inyección SQL explotada) Escenario DLL Hijacking: Mediante este tipo de ataques, un potencial atacante con privilegios más bajos podría usar técnicas de ‘DLL Hijacking’ para que a través del aplicativo cliente, cargar en tiempo de ejecución o sobrescribir los archivos binarios en el directorio de instalación con una copia maliciosa. El aplicativo cliente/servidor ejecutándose en el host de algún usuario podría explotarse para realizar una escalada de privilegios a algún usuario administrador en caso de ejecutarse de esta manera el aplicativo cliente. Detectando potenciales DLL Hijacking en Aplicativo Windows Estos solo son algunos de los escenarios de ataque que podría usar un auditor dentro de un test de intrusión o un atacante para escalar de privilegios dentro de una estación de trabajo o una red corporativa. Se puede observar que los vectores aparentemente son viejos conocidos, pero sin embargo, en varios análisis que hemos realizado de manera aleatoria en la actualidad de ciertos aplicativos de este tipo identificamos varias de estas debilidades que aún persisten. Podemos realizar pruebas a mayor detalle como carga arbitraria de archivos, lógica del negocio, gestión de sesiones, manipulación de registros deserialización de objetos, análisis de memoria y más. En definitiva, los vectores migran, se actualizan, mejoran y se diversifican, pero los riesgos siempre están presentes a través de cualquier aplicativo dentro de tu red; con lo cual, acerca de las debilidades, ¿te has preguntado cuántos de tus programas cliente has analizado en detalle?

Muchas personas saben que desde hace tiempo sus “huellas” o rastros médicos han comenzado a ser registrados durante sus visitas al médico por medio de dispositivos tecnológicos. En la industria hospitalaria, estos datos se conocen como EHR/EMR/PHR y si bien difieren en varios aspectos, no será la finalidad de este post el analizar sus diferencias. Con la transformación digital, datos contables, agrícolas, industriales, financieros, médicos y otros muchos, forman parte de la masa de información que está digitalizada en internet y disponible para que el usuario pueda consultarla cuando sea necesario. Características de Plataformas EHR EMR PHR Pero, ¿ qué son los EHR o EMR? Por sus siglas en inglés (Electronic Medical Records), básicamente, hablamos de registros médicos de una persona o paciente que se almacenan digitalizados como una colección de datos sobre historiales clínicos, exámenes realizados, enfermedades, alergias, medicinas suministradas, información de facturación.... y cuya variedad, dependerá del software que se utilice. Este tipo de datos se gestionan actualmente tanto por doctores como por pacientes desde un dispositivo móvil a través de una aplicación. Descripciones de Aplicaciones EMR Hemos revisado aplicaciones en las principales plataformas (Android & iOS) identificando ciertas vulnerabilidades que pondrían poner en riesgo la privacidad de los datos de los pacientes. Dentro de este análisis, observamos que algunas de estas aplicaciones han sido desarrolladas por hospitales y clínicas, las cuales proporcionan acceso a sus usuarios y tienen comunicación directa desde internet con su infraestructura interna. Esto conlleva que aquellas instituciones que utilizan estas aplicaciones, puedan enfrentarse a un ataque que afecte a los datos de estos registros, sin ser plenamente conscientes de ello. En este análisis seleccionamos la última versión de las 53 aplicaciones EHR más destacadas del sector. Dentro de este muestreo, nos hemos enfocado en analizar únicamente la aplicación móvil, ya que si bien se descubrieron debilidades del lado del servidor (backend), no están incluidas en este articulo. En 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, las mismas que solo representan un vistazo general de una cantidad de pruebas en detalle y de manera exhaustiva que se podrían realizar a las aplicaciones. Como contamos en el post de Aplicaciones PACS/DICOM (que también juega un papel importante en la industria sanitaria), los resultados en esta ocasión también demostraron, desafortunadamente, que para el desarrollo de este tipo de aplicaciones, la seguridad no ha sido una prioridad. Las vulnerabilidades encontradas conforme a los controles evaluados se encuentran en las siguientes secciones. (Los datos y detalles técnicos donde se mencionan a la empresa dueña o detalles del desarrollador de la aplicación han sido censurados) Estadística General de Resultados del Análisis Una de las primeras impresiones sobre este tipo de aplicaciones es que, los datos sensibles como credenciales de usuarios se continúan almacenando 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, encontramos passcode o pins como control de acceso en las aplicaciones, almacenados en archivos XML con cadenas encodificadas (base64), sin utilizar algoritmos de cifrado. Usando base64 para “cifrar” contraseñas (archivo xml legible) Base de datos SQLite con estructuras que almancenan pincode/ contraseñas en texto plano En aplicaciones que hacen uso de APIs hacia diferentes servicios de terceros, encontramos aplicaciones que almacenan este tipo de información de manera incorrecta y legible. En dos aplicaciones observamos el uso parcial de librerías de cifrado de SQLite Archivo de Certificado/Key Hardcodeado en App iOS API Keys almacenada de Servicios Terceros Treinta de las aplicaciones establecen canales HTTP no cifrados en varias de sus comunicaciones, mientras otra parte de aplicaciones usan comunicación HTTPS con certificados autofirmados y no verifican la autenticidad del certificado digital (Métodos Certificate Pinning), lo que facilitaría a un atacante generar ataques MiTM (Main-in-the-Middle) por ejemplo. Comunicación de Autenticación con Webservices en HTTP Entre los principales hallazgos de este tipo de fallos, seguimos encontrando grandes posibilidades de explotación de Inyección SQL y XSS (Cross Site Scripting) sobre la App y en 10 aplicaciones encontramos cómo utilizando “Webviews” se podía ejecutar código JavaScript o agregar librerías HTML. Las 23 aplicaciones Android se podrían descargar y manipular de manera arbitraria, con lo cual se puede obtener de manera legible las clases de java de las aplicaciones ya que no mantienen ninguna característica de ofuscación de código (despersonalización) para dificultar el proceso de reversing. Archivos de certificados hardcodeados dentro del App Revisión de clases java luego de proceso de reversing Archivos JKS & Credenciales AWS Contraseñas de certificados almacenados en texto plano Desde ElevenPaths, contemplamos con preocupación como este tipo de tecnología (cada vez más utilizada), continúe implementándose sin los controles necesarios y sin asegurar unos mínimos de seguridad, ya que, a diferencia de otros sectores en los que la pérdida económica supone el principal problema, en el sector sanitario, la privacidad de los datos médicos de los pacientes debería controlarse por encima de todo. La comunidad lleva a cabo muchos esfuerzos en explorar estas nuevas implementaciones y buscar fallos de seguridad que sirvan como retroalimentación para las empresas propietarias de las aplicaciones con el objetivo de seguir despertando la conciencia del sector sanitario para que adopten las soluciones integrales necesarias para que sus usuarios sientan mayor seguridad de sus datos. Desde nuestra parte, esperamos que estos aportes sigan sensibilizando a la comunidad y que los errores no sigan conllevando incidentes de seguridad o fugas de datos como hemos contemplado recientemente.