StrandHogg 2.0 es una nueva y peligrosa vulnerabilidad de Android. Así es como puede afectar a los usuarios y cómo los desarrolladores pueden proteger sus aplicaciones.
Son las 22:00. ¿Sabes dónde están tus actividades? Hay una nueva vulnerabilidad que puede explotarse en millones de dispositivos Android, y además es bastante desagradable. En pocas palabras, este error de diseño permite a un atacante presentar su propia Actividad (página) encima de la de otra aplicación, lo que podría confundir al usuario y obligarlo a revelar sus datos privados. La vulnerabilidad ha sido denominada StrandHogg 2.0 y fue revelada recientemente por promoción, una empresa de seguridad noruega.
En teoría, la vulnerabilidad StrandHogg 2.0 afecta a todos los dispositivos Android que ejecutan versiones de Android tan antiguas como Honeycomb (3.0) y hasta Android 9 Pie (9.0). Basado en el últimas estadísticas de distribución de versiones de Android, Eso significa que Aproximadamente el 91,8% de todos los dispositivos Android son vulnerables a StrandHogg 2.0
. La vulnerabilidad fue asignada CVE-2020-0096 y se le dio un nivel de gravedad de "crítico". No requiere ningún permiso especial para funcionar y puede funcionar casi por completo sin interacción del usuario. Todo lo que un usuario tiene que hacer es abrir una aplicación con un código malicioso oculto y luego será vulnerable a la explotación.Promon tuvo la amabilidad de enviarnos su aplicación de prueba de concepto y su código fuente para que pudiéramos mejorar explique cómo funciona el exploit, por qué es importante para los usuarios y cómo los desarrolladores pueden proteger sus aplicaciones. En contra.
Cómo funciona
Digamos que estás usando Gmail y haces clic en un enlace web. Si va a la pantalla de aplicaciones recientes, puede notar que la página web parece estar "dentro" de Gmail. La vista previa muestra el sitio web, pero el icono y el nombre de la aplicación siguen siendo de Gmail. Esto es algo que sucede cuando una aplicación/actividad inicia otra aplicación/actividad en la misma tarea. Ahora imagina que no abriste ese enlace a propósito. Para ti, parece que es sólo parte de la aplicación Gmail. Este es el comportamiento que explota StrandHogg 2.0.
Tendremos que omitir algunos detalles aquí, pero así es como funciona este exploit. Para lo siguiente, supongamos que el atacante desea obtener el inicio de sesión de Gmail del usuario.
- El usuario descarga una aplicación maliciosa (por supuesto, sin saber que es maliciosa) y la abre.
- En segundo plano, la aplicación abre Gmail, coloca encima una Actividad de inicio de sesión similar y luego inicia otra Actividad.
- El usuario abre Gmail y ve lo que parece la pantalla de inicio de sesión de Gmail, pero en realidad es la actividad de phishing del atacante.
La actividad final iniciada en el paso 2 puede ser cualquier cosa que evite sospechas. La aplicación podría fingir un bloqueo y volver a la pantalla de inicio, o simplemente abrirse en su Actividad principal como si nada hubiera pasado. Lo único sospechoso que el usuario podría ver es un montón de animaciones de apertura cuando se inician todas las actividades. La peor parte: ni siquiera parecerá que se abrió Gmail.
Por supuesto, un atacante puede hacer más que simplemente mostrar una pantalla de inicio de sesión falsa. En su lugar, una aplicación maliciosa podría presentar un mensaje de permisos, engañando al usuario para que conceda permisos no deseados. Si bien solicitar permisos especiales como Accesibilidad puede hacer que el usuario sospeche, es posible causar mucho daño con algo como Acceso al almacenamiento.
Los bits técnicos
La siguiente sección es una descripción general de alto nivel de cómo funciona StrandHogg 2.0. Promon no publicará todos los detalles hasta dentro de unos meses, por lo que no podemos compartir exactamente cómo se implementa este exploit. Sin embargo, hay algunos detalles técnicos de los que podemos hablar.
En pocas palabras, StrandHogg 2.0 secuestra Android Context.startActivities() Método API, que utiliza tres Intents.
- El primer Intent es el que inicia, en el caso de nuestro ejemplo, Gmail. Está marcado con
Intent.FLAG_ACTIVITY_NEW_TASK. - La segunda intención es la maliciosa. En nuestro ejemplo, es para la Actividad de inicio de sesión similar. Esta intención no tiene banderas.
- El tercer intento es la distracción. Se asegura de que el usuario no sospeche de que Gmail simplemente se abra aleatoriamente en lugar de la aplicación que accedió (es decir, la que lanzó el ataque). Está marcado con
Intent.FLAG_ACTIVITY_NEW_TASK.
Todos estos Intents luego se pasan en una matriz al startActivities() método.
La falta de banderas del segundo Intent es la clave aquí. Al hacerlo, básicamente hemos replicado el ejemplo de Gmail anterior. La tarea es técnicamente de Gmail, pero la actividad superior es del atacante. Cuando el usuario hace clic en el ícono de la pantalla de inicio de Gmail, se muestra la Actividad del atacante en lugar de la de Gmail.
Prueba de concepto
Con la información que nos envió Promon pudimos replicar su prueba de concepto. Aquí hay una grabación de pantalla de un Samsung Galaxy Note8 con Android 9 Pie que lo muestra en acción.
Técnicas y problemas de mitigación
Ahora bien, simplemente replicar lo anterior en el código no funcionará. No es un ejemplo completo y hay algunas otras cosas que un atacante debe hacer para que funcione, que no podemos compartir. Pero no son particularmente difíciles de adivinar por tu cuenta, y eso es parte de lo que hace que este ataque sea tan peligroso. StrandHogg 2.0 es un exploit relativamente fácil de implementar y difícil de mitigar.
La mitigación no puede implicar simplemente incluir en la lista negra todas las aplicaciones que utilizan startActivities(), ya que existen muchos usos legítimos para él. También es muy difícil automatizar un algoritmo de detección. Los desarrolladores maliciosos pueden emplear todo tipo de trucos para hacer que su implementación de StrandHogg 2.0 sea efectivamente invisible para servicios como Google Play Protect. StrandHogg 1.0 requirió que el atacante agregara un atributo en AndroidManifest.xml de la aplicación maliciosa, que era relativamente fácil de detectar. StrandHogg 2.0, por otro lado, funciona completamente en Java/Kotlin.
Teniendo en cuenta la ofuscación, la reflexión e incluso los diferentes estilos de codificación, parece poco práctico detectar automáticamente y de forma adecuada una aplicación que utiliza este exploit. Lo que es más, si un usuario es objeto de un ataque StrandHogg 2.0, es posible que ni siquiera lo sepa. Si abre Gmail y ve su pantalla de inicio de sesión, puede pensar que su sesión expiró e ingresar sus datos de inicio de sesión sin pensarlo dos veces.
Cuando contactamos a Google para obtener una respuesta, un portavoz ofreció la siguiente declaración:
"Apreciamos el trabajo de los investigadores y hemos publicado una solución para el problema que identificaron. Además, Google Play Protect detecta y bloquea aplicaciones maliciosas, incluidas las que utilizan esta técnica".
Esto suena bien y, con suerte, tendrá al menos algún efecto contra los ataques de StrandHogg 2.0. Sin embargo, vale la pena señalar que Google Play Protect No detectar nuestra aplicación de prueba de concepto como maliciosa, incluso después de realizar un análisis manual.
Promon dice que ellos "No hemos observado ningún malware de la vida real que utilice la vulnerabilidad StrandHogg 2.0.", pero no hay garantía de que sea la primera vez que se descubre el exploit. Por esa razón, Promon recomienda que los desarrolladores sigan adelante y protejan sus aplicaciones configurando la Actividad de su iniciador. launchMode bandera a cualquiera singleTask o singleInstance. Cualquiera de estos indicadores evitará la inyección de tareas, que es en lo que se basa StrandHogg 2.0. Sin embargo, hacer que tu Actividad utilice uno de estos indicadores puede causar problemas con ciertos flujos de aplicaciones, por lo que no siempre es deseable.
Promon también está promocionando su propio producto "In-App Protection by Promon SHIELD", que suena como una biblioteca. que los desarrolladores de aplicaciones pueden implementar para monitorear las tareas en el proceso de su aplicación para verificar si hay irregularidades inserciones. Debido a que no existe una estrategia de mitigación verdaderamente eficaz para desarrolladores o usuarios, es muy importante que los fabricantes implementen el parche para solucionar este problema lo antes posible.
Afortunadamente, Promon siguió pautas de divulgación responsable antes de hacer público este exploit (y todavía no es completamente público: Promon está esperando 90 días antes de revelar completamente cómo funciona StrandHogg 2.0. obras). Desde entonces, Google ha respaldado parches para este exploit en Android 8.0 Oreo, Android 8.1 Oreo y Android 9 Pie con el Nivel de parche de seguridad de Android (SPL) de mayo de 2020. Los usuarios de Android 10 y superior no son vulnerables, aunque no estamos del todo seguros de por qué es así. Probablemente tenga algo que ver con las nuevas restricciones de Android 10 con respecto al inicio de actividades y cómo Google las integró en la pila de tareas. Promon dice que "en Android 10 el ataque es completamente ineficaz y las actividades se dividen en diferentes tareas y en pilas de tareas separadas según adb shell dumpsys activity activities."
Si el fabricante de su dispositivo aún proporciona actualizaciones de seguridad (puede leer más sobre cómo funciona el proceso del parche de seguridad aquí), deberías molestarlos para que actualicen lo antes posible. De lo contrario, sólo tendrás que tener cuidado con las aplicaciones que descargas y ejecutas (aunque deberías hacerlo de todos modos).
Para obtener más detalles y casos de uso de StrandHogg 2.0, consulte el anuncio oficial en el sitio web de Promon. Para los desarrolladores de ROM personalizados, pueden encontrar las confirmaciones de AOSP relevantes para prevenir ataques de StrandHogg 2.0. aquí y aquí.
Cronograma de divulgación
Aquí está el cronograma de divulgación que Promon compartió en su documento StandHogg 2.0:
- 4 de diciembre de 2019 – Problema reportado a Google
- 4 de diciembre de 2019 – Compartió una «aplicación maliciosa» PoC y un vídeo con Google
- 4 de diciembre de 2019 – Google confirmó haber recibido el informe.
- 9 de diciembre de 2019 – Google estableció la gravedad del hallazgo como «Crítico»
- 9 de diciembre de 2019 – Google confirma que pueden reproducir el problema.
- 14 de febrero de 2020 – Informamos a Google que la divulgación de 90 días se acerca a principios de marzo y solicitamos el estado de su parte.
- 14 de febrero de 2020 – Google responde que abril es lo más pronto que podrán implementar una solución
- 14 de febrero de 2020 – Informamos a Google que estamos trabajando en mitigaciones.
- 14 de febrero de 2020 – responde Google. Están trabajando en soluciones y preguntan si podemos compartir qué mitigaciones recomendamos.
- 17 de febrero de 2020 – Informamos a Google que podemos retrasar la divulgación hasta abril. Solicitamos el número CVE
- 17 de febrero de 2020 – Compartimos nuestras estrategias de mitigación, así como cómo prevemos una plataforma de mitigación.
- 23 de marzo de 2020 – Google responde con el CVE ID (CVE-2020-0096)
- 23 de marzo de 2020 – Google responde que la disponibilidad general del parche para Android estará disponible en mayo
- 23 de marzo de 2020 – Google pregunta si consideraremos retrasar la divulgación hasta mayo
- 27 de marzo de 2020 – Respondemos que retrasaremos la divulgación hasta mayo
- 22 de abril de 2020 – Google nos informa que está previsto que el Boletín de Seguridad de mayo contenga un parche para la vulnerabilidad