Superficie de ataque crítica de las aplicaciones móviles

LiveOverflow publicó un interesante vídeo sobre la seguridad de las aplicaciones móviles en el que abordaba la superficie de ataque de las aplicaciones móviles y el caso de un «investigador» de seguridad que exagera los resultados de su trabajo.

Las aplicaciones móviles se construyen sobre un entorno diseñado para reducir la superficie de ataque, mediante el uso de sandboxing, un modelo de permisos explícitos, actualizaciones automáticas y una API que intenta ser segura por defecto.

Sin embargo, algunas aplicaciones móviles sí exponen una superficie de ataque crítica que requiere una atención especial, ya sea por la pila tecnológica en la que se basan, por el tipo de usos que ofrece la aplicación o por la interacción que la aplicación mantiene con otros componentes. Otro factor clave que hay que tener en cuenta es la necesidad de estos entornos de incorporar más características y funcionalidades. Estas funcionalidades dan a los desarrolladores margen para ser creativos al encontrar nuevas formas de usar nuestros teléfonos, pero al mismo tiempo aumentan la superficie de ataque. Tomemos como ejemplo las App Extension de iOS, una funcionalidad similar a los intents de Android que se añadió más tarde al ecosistema de iOS.

Estos son algunos ejemplos que hemos visto en el pasado como vulnerabilidades críticas para la seguridad, pero que son muy específicos del entorno móvil:

Inyección de JavaScript explotable de forma remota en aplicaciones basadas en JavaScript:

Las aplicaciones desarrolladas con un framework de JavaScript, como Cordova o Ionic, pueden ser vulnerables a la inyección de JavaScript o de HTML. Estas vulnerabilidades pueden aprovecharse para inyectar código de forma remota debido a la naturaleza de la API expuesta a través de estos frameworks.

Para que una vulnerabilidad de este tipo se considere crítica, el atacante debe tener la capacidad de enviar la entrada maliciosa a otros usuarios sin ninguna interacción especial.

Por ejemplo, una aplicación deportiva que permite a los usuarios compartir su progreso a través de un muro personal. Si ese muro es vulnerable a la inyección de JavaScript (XSS), cualquier usuario que vea el muro del atacante quedará comprometido.

Incluso las vulnerabilidades de inyección de HTML pueden transformarse en inyección de JavaScript mediante un ataque de JavaScript Gadget.

Corrupción de memoria en código nativo a través de entradas no confiables:

Varias aplicaciones gestionan el análisis de formatos binarios como audio, vídeo e imágenes mediante bibliotecas nativas. Una vulnerabilidad de corrupción de memoria en estas bibliotecas, mediante una entrada no confiable, dará lugar a una ejecución remota de código.

Por ejemplo, si una aplicación de chat que permite enviar grabaciones de voz en formato MP4 sufre una vulnerabilidad de corrupción de memoria, esto dará lugar a una ejecución remota de código en el contexto de la aplicación.

Java, Kotlin, Objective C y Swift son lenguajes con seguridad de memoria, salvo que se usen API inseguras; sin embargo, enlazar con bibliotecas en C y C++ abre la puerta a este tipo de vulnerabilidades.

Inyección de intents en Activities con categoría Browsable, explotada mediante ataques drive-by en Chrome:

Chrome permite enviar intents con parámetros adicionales a las activities con la categoría Browsable. Una aplicación vulnerable a la inyección a través de los parámetros adicionales del intent es vulnerable a la explotación drive-by.

El atacante puede incitar a la víctima a visitar su página maliciosa, o servir el ataque mediante anuncios, por ejemplo. El navegador Firefox requiere una interacción adicional del usuario para activar el envío del intent, mientras que la mayoría de los demás navegadores en dispositivos móviles no admiten esta funcionalidad.

Comunicación mediante tráfico en texto claro o con una validación insegura del certificado de servidor TLS/SSL:

El impacto de esta vulnerabilidad depende de la naturaleza de los datos intercambiados. Por ejemplo, si la fase de autenticación o cualquier acción que requiera sesión se realiza a través de canales inseguros, esto dará lugar al compromiso de la sesión de los usuarios.

Si la aplicación está desarrollada con frameworks de JavaScript, la descarga de JavaScript o HTML remotos dará lugar a una ejecución remota de código. Si la aplicación descarga una biblioteca compartida (.so, .dex, .jar) a través de canales inseguros, esto también dará lugar a una ejecución remota de código.

Un ejemplo de esta vulnerabilidad es el uso de ALLOW_ALL_HOSTNAME_VERIFIER:

La implementación de ALLOW_ALL_HOSTNAME_VERIFIER no realiza ninguna validación:

Gestión de sesiones compartida entre la aplicación móvil y la web, y ausencia de protecciones propias de la web en el backend móvil:

Las aplicaciones web comparten el mismo navegador con otras aplicaciones web, lo que crea oportunidades para una serie de ataques que no son aplicables a las aplicaciones móviles, como CRSF, el secuestro de sesiones mediante todo tipo de XSS e incluso el clickjacking.

En general, estos vectores de ataque no existen en las aplicaciones móviles, por lo que los desarrolladores no necesitan implementar ninguna protección de seguridad contra estos ataques.

Sin embargo, algunos backends de aplicaciones móviles comparten el sistema de gestión de sesiones entre el backend web y el móvil, lo que brinda al atacante la oportunidad de enlazar con el backend móvil desde el navegador y explotar estas vulnerabilidades.