5.500 apps potencialmente vulnerables a ataques de Man in the Middle en Google Play

Se ha descubierto que AppsGeyser, un creador de aplicaciones «a golpe de clic», desactiva la comprobación de certificados SSL en sus aplicaciones. Un atacante en la misma red local que un usuario que utilice estas aplicaciones, podrá inyectar cualquier página cuando navega desde las apps afectadas, o bien ver y modificar webs que deberían estar protegidas. Este generador es muy popular y (según ellos mismos) se han instalado mil millones de apps. Existen más de 5.500 aplicaciones suyas en estos momentos en Google Play. Veamos los detalles del fallo, con los matices necesarios.

Página principal de AppsGeyser

AppsGeyser es un servicio que facilita la creación de apps de Android «a golpe de clic», basadas en un contenido web. Literalmente, permite crear programas en tres pasos, de la forma más sencilla, y así llevar a una app la experiencia web de una página. Este tipo de aplicaciones introducen riesgos de los que ya hemos hablado, pues el programador no controla el código que se inyecta, y puede desencadenar en efectos no deseados en la seguridad del usuario.

En este caso, AppsGeyser ha introducido deliberadamente una función que desactiva la comprobación de la validez de certificados SSL en todas las aplicaciones creadas desde su plataforma. Esto quiere decir que cualquier navegación realizada desde una aplicación creada con AppsGeyser, puede ser interceptada, redirigida, falseada… En ningún momento se validará el certificado del servidor remoto.

Para que el ataque tenga éxito, el atacante solo tiene que encontrarse en la misma red local que la víctima. Acceder a su tráfico a través de cualquier técnica (ARP Spoofing, tener el control de un proxy, del gateway…) y observar el tráfico generado desde las apps creadas con AppsGeyser. Si un usuario de una app de este tipo visita una web HTTPS, el atacante solo tendría que introducir su propia página firmada con cualquier certificado, y la víctima no notaría nada extraño. Sería el phishing perfecto. O situarse en medio de la navegación entre una web segura y la víctima. Aun así, si no visita ninguna página explícitamente con HTTPS, podría redirigirla. Por ejemplo, si una app de AppsGeyser visita una página de publicidad, el atacante podría redirigirle a una supuesta página de Facebook, Twitter, etc. y preguntar por las credenciales en cualquier momento.

5.500 aplicaciones vulnerables

Utilizando Path5, la herramienta de investigación, correlación y monitorización de mercados de ElevenPaths, hemos podido comprobar que existen en estos momentos 5.532 aplicaciones creadas y activas con AppsGeyser en Google Play. Durante este año, se han subido unas 7000, lo que da una idea de su popularidad. Existe incluso un navegador creado con AppsGeyser que sirve para visitar Facebook, Amazon, Twitter… de una forma totalmente insegura.
Algunos antivirus ya detectaban desde hace tiempo estas aplicaciones como badware, independientemente de qué hiciesen. Ahora se comprueba que tenían buenos motivos para hacerlo.

Un navegador de accesos directos a páginas populares, creado con AppsGeyser

Si bien muchas apps son meros entretenimientos, existen instituciones y empresas serias que han utilizado este método para crear su app. Incluso aplicaciones muy populares y descargadas. Existen unas 50 apps creadas con esta plataforma, que superan las 100.000 descargas.

Puede que no sean vulnerables todas y cada una, pero es poco probable. Para no serlo, el programador original podría añadir código para activar de nuevo la desactivación de SSL realizada por AppsGeyser. Al tratarse de un perfil de usuario que ha preferido delegar la creación de la app a un tercero, vemos poco probable que baje al nivel técnico necesario para solucionarlo. Además, AppsGeyser no avisa de que está realizando esta desactivación de la comprobación.

¿Por qué desactivar SSL? Sospechamos que para facilitar la vida en el caso de que el creador de la app utilice certificados autofirmados para su web, o certificados que no pueden ser validados por el sistema. AppsGeyser se ahorra así quejas en su sistema de soporte de usuarios creadas con su sistema en los que existe «un error de validación SSL». AppsGeyser desactiva toda comprobación y evita problemas para su soporte técnico, pero pone en riesgo a cualquier usuario de sus aplicaciones.

Prueba de concepto


Valga como prueba de concepto que permite observar el tráfico cifrado esta demostración de un ataque MITM contra una aplicación de AppsGeyser (https://play.google.com/store/apps/details?id=com.SantiniLabsWebBrowser). El atacante tendría que habilitar IP forwarding y redirigir el tráfico HTTP y HTTPS a un webproxy configurado en la máquina.

Para conseguir el ataque de hombre en el medio, se realiza arp-spoofing sobre el dispositivo (aunque podría utilizarse cualquier otra técnica).

La víctima inicia sesión en Facebook desde el navegador incluido en la app:

El tráfico queda capturado, aunque al usuario le parezca cifrado, puesto que en realidad todo se está realizando con el certificado no confiable del webproxy:

El usuario ni siquiera tendría la oportunidad en este caso de comprobar el certificado desde ese navegador, puesto que la aplicación no lo permite.

Detalles técnicos

Técnicamente, el fallo es muy sencillo. Tomemos como ejemplo ese navegador creado con AppsGeyser, aunque el comportamiento sería el mismo en todas las aplicaciones de AppsGeyser en las que no se haya arreglado explícitamente la desactivación.

En el método onCreate(…) de la actividad de inicio, tenemos el siguiente código:

La primera línea destacada, guarda en el atributo mStartupScreenViewContainer el FrameLayout startupScreenContainer que veremos cuando se arranque la aplicación. La segunda, crea un controlador desde el FrameLayout anterior según el siguiente código:

A su vez, la clase StartupScreenController tiene los siguientes atributos:

BrowserWebView será el encargado de presentar las páginas web. Para esto necesitará hacer uso de un objeto WebViewClient que se establece en la construcción de StartupScreenController:

Destacamos de este código cómo se recupera el BrowserWebView (en el layout de la actividad de inicio) y cómo se asigna como WebViewClient la instancia del objeto FullScreenBannerWebViewClient.

Como vemos, la clase hereda de SimpleWebViewClient:

Que a su vez hereda de WebViewClient, el cual según la documentación de la API de Android dispone del siguiente método:

Y este método es sobrescrito en SimpleWebViewClient con el siguiente código, invalidando así el comportamiento de denegación de carga de la página Web en caso de encontrarse con un certificado SSL inválido:

Las conexiones en riesgo dentro de las apps, serían pues las que se hagan desde objetos que hereden de SimpleWebViewClient y BrowserWebViewClient, y siempre que no sobrescriban el comportamiento de onReceivedSslError con un paramSslErrorHandler.cancel().