27 diciembre 2012

Google Play, ocultación de malware y ExynosAbuse > Pwned!

Hace algo más de mes y medio tuve la oportunidad de acudir a la No cON Name 2012 con la ponencia Being smarter than G00gle! en la que presentaba una técnica para inyectar código malicioso en aplicaciones Android que a priori son inofensivas.

Este verano Nicholas J. Percoco y Sean Schulte presentaron en BlackHat USA 2012 una ponencia titulada "Adventures in Bouncerland" (podéis encontrar el whitepaper aquí) en la que explicaron cómo se podía convertir una aplicación inofensiva en maliciosa a través de JSBridge. Simplemente comentar que esta técnica se aprovecha de los puentes que se crean entre código Javascript (de ahora en adelante JS), que interpreta la aplicación a través del componente WebView, y métodos de código nativo de la aplicación. De esta forma, es posible acceder a métodos de la aplicación (como enviar un SMS) a través de JS; como hacían aplicaciones como Facebook (versión HTML5).

A continuación se muestra un ejemplo sencillo que ilustra esta técnica:


Si bien es una técnica muy interesante que permite modificar dinámicamente el comportamiento de la aplicación (a partir del código HTML/JS de las páginas que se abren con el componente WebView), el código nativo que ejecuta siempre está presente en la aplicación y éste no puede modificarse salvo que se actualice la aplicación.

Visto el inconveniente que supone el uso de JSBridge, se me ocurrió que podía ser interesante hacer uso de las posibilidades que nos ofrece Java en cuanto a la carga dinámica de clases en memoria, para crear malware modular que permita mantener una aplicación inofensiva (sin código sospechoso ni comportamiento malicioso) a la que se le agreguen las distintas capacidades en función de lo que requiera en cada momento (y dependiendo del dispositivo, firmware y demás características en las que se esté ejecutando).

Además, haciendo uso de este tipo de técnicas, podemos evitar los mecanismos de seguridad implementados en Google Play (la tienda de aplicaciones oficial de Android) y más recientemente a nivel del dispositivo (las versiones 4.2+ comprueban si las aplicaciones instaladas desde fuentes desconocidas contienen malware) puesto que un análisis automático de la aplicación no es capaz de encontrar ningún código ni comportamiento malicioso porque a priori no existe en la aplicación (ni siquiera parte del código como ocurría con la técnica de JSBridge).

Para ver más en detalle el funcionamiento de esta técnica utilizaremos de ejemplo una aplicación que simula ser una galería con las últimas siete fotografías utilizadas en el buscador Bing.



La aplicación BingImages ha estado publicada en Google Play desde el 6 de septiembre de 2012 (la acabo de retirar) para demostrar que el uso de estas técnicas es totalmente factible. También es importante destacar que este tipo de situaciones (uso de librerías) es normal y por ello, puesto que no se ejecuta ningún tipo de código malicioso durante el análisis que realiza Bouncer, su detección es complicada. Además se podría hacer uso de técnicas de 'fingerprinting' para detectar si estamos siendo analizados por Bouncer y, en ese caso, camuflarnos aun más si cabe (se puede leer más acerca de FP de Bouncer en el whitepaper 'Dissecting de Android Bouncer' de Charlie Miller y Jon Oberheide).

El código de las aplicaciones (tanto BingImages como BingUpdater -actualizador que incluye el payload malicioso-) puede ser descargado desde mi página.

Con respecto al código que se utiliza en BingImages para contactar con el servidor de comando y control que le indicará si tiene que descargarse algún payload y cómo ejecutarlo, y posteriormente su carga en memoria:


Simplemente comentar que, si el servidor de comando y control indica que existen actualizaciones, descarga el APK indicado en el JSON, lo carga en memoria haciendo uso del cargador DexClassLoader (se le indica una ruta temporal donde creará el DEX y que posteriormente eliminaremos -método cleanTemporalyFiles()-) y ejecuta el método inicial (indicado también en el JSON). De esta forma, el payload puede tener la estructura que nosotros queramos, sin tener que "atarnos" a una fija que pueda limitarnos en un futuro.

La ocultación se realiza a nivel aplicación (indicamos al DexClassLoader la ruta en la que tiene que crear los archivos DEX temporales) haciendo que el código malicioso esté disponible sólo en memoria y únicamente durante su ejecución puesto que posteriormente el recolector de basura de Java se encarga de eliminarlo sin necesidad de tener que liberar espacio en memoria de forma manual o reiniciar el dispositivo. Si bien siempre quedan evidencias (p.e la caché Dalvik en la que se almacenan los DEX optimizados para evitar su creación en cada ejecución -y que no podríamos eliminar salvo con un exploit o si el dispositivo está 'rooteado'-), esta técnica complica un nivel más el estudio del especímen de malware y/o el análisis forense del dispositivo infectado (a priori se encontrarían con un dispositivo que ha sido infectado sin tener claro qué aplicación es la culpable).

Un ejemplo de un payload sencillo podría ser un módulo que envíe al servidor de comando y control todos los ficheros que se estén almacenando en la carpeta Whatsapp de la SDCard (sólo necesitaríamos permisos de internet, la lectura de la SDCard no tienen ningún tipo de restricción -este permiso tendría que estar declarado en la aplicación 'padre'-). Y como ya comentó Alex hace un tiempo, el cifrado no sería un problema.


Siempre que hablo sobre este tema comento que uno de los usos de esta técnica podría ser el crear una aplicación 'padre' que únicamente tenga el permiso internet (es muy fácil justificarlo) y que los módulos se aprovechen de vulnerabilidades que permitan la escalada de privilegios (vulnerabilidades en aplicaciones stock, vulnerabilidades en Android, debugging...) o 'bypass' de los permisos, etc.

Hace más de una semana que se está hablando de la famosa vulnerabilidad descubierta en los teléfonos Samsung con procesadores Exynos 4210 y 4412 (podeis acceder a una buena explicación del tema en el artículo de Una al día). Básicamente la vulnerabilidad se encuentra en la asignación de los permisos del fichero /dev/exynos-mem que permite el acceso a toda la memoria RAM del dispositivos a cualquier usuario del dispositivo. Podéis acceder al exploit en este post del foro de XDA-Developers.

¿Y si el módulo que descarga nuestro malware comprueba si se encuentra entre los modelos afectados -comprobar la existencia de dicho fichero y sus permisos- y descarga el exploit? ¡Tendríamos una aplicación en la tienda de aplicaciones de Android que es capaz de ejecutar permisos como root sin que el dispositivo tenga que estar rooteado ni notificar al usuario en ningún momento!

En el código publicado de BingUpdater se presentan dos ejemplos, uno en el que se copia la base de datos 'fb.db' de la aplicación de Facebook a la SDCard (contiene, entre otra mucha información, los tokens de autenticación) y el segundo que hace 'root' al dispositivo.

A continuación se muestra un video de todo el proceso (descarga de una aplicación del Google Play que acaba siendo un malware con acceso completo al dispositivo):


Podéis acceder al código de las aplicaciones y demás material en:

Artículo cortesía de Luis Delgado 

10 comments :

Anónimo dijo...

Gracias por el aporte!!


No hay permisos de descarga sobre los ficheros exynosabuse.png y su.png


Saludos

Luis Delgado dijo...

A mí no me da problemas (simplemente que el navegador no lo carga por ser una imagen "corrupta"). He subido al mismo directorio un archivo comprimido con todos > compilation.zip

Un saludo!

car dijo...

Los chicos de XDA sacaron no hace mucho un parche para contrarrestar esta vulnerabilidad sin embargo en algunos modelos de Samsung (como el SGS3) puede afectar al funcionamiento de la cámara. Como siempre y ante una situación asi pienso que el sentido común es en un 80% nuestro salvavidas no instalar nada que sea de dudosa procedencia es providencial hasta que samsung se haga cargo y podamos actualizar via OTA nuestros Smartphones.

Anónimo dijo...

Podrías por favor subir los apk al directorio?

Gracias y felices fiestas!!

Reaper dijo...

Si usas PathClassLoader en vez del DexClassLoader, te ahorras la caché dex a cambio de una ejecución por reflection algo más lenta.

La verdad, yo no veo más vulnerabilidad que el exploit. Las clases que cargas por reflection tienen los permisos de la aplicación padre, ni uno más ni uno menos. Si cargas un exploit, eso es otra cosa.

Miguel dijo...

Hola gente, hace poco instale el parche de XDA, el exynosabuse, para solucionar el bug en mi S3, tambien con Supersu me hice root. Hasta ahi todo bien, ni siquiera tuve problemas con la camara como si tuvieron muchos usuarios luego de instalar el parche. Al cabo de unos días actualice a JB 4.1.2 con Premium Suite vía Odín, la ROM oficial que salió el 30 de noviembre, no hice una instalación limpia pero salio todo muy bien. Al hacer esta actualización tuve que hacer el root nuevamente, hasta ahí ningún problema, pero el Avast antivirus que tengo instalado me detecta a exynosabuse como software malicioso y ahora la camara trasera se ve todo verde, me deja tomar fotografías pero no puedo ver a que le estoy tomando ya que en la pantalla solo se ve una imagen verde.
Quisiera saber si es una falsa alarma de Avast o si en verdad es malicioso el exynosabuse, igual si hay algun otro parche que solucione la vulnerabilidad sin ocasionar problemas en la camara del S3.
Disculpen sino soy muy claro pero es que soy nuevo en esto de rootear e instalar via Odín. Desde ya muchas gracias!

Luis Delgado dijo...

Como comenta @bf6c14bcc33b6d07ba2e46973d1fb3a3:disqus, el aplicar el 'fix' que han publicado en XDA (y que contiene el APK de ExynosAbuse) puede afectar a la cámara. Tendrás que esperar a que lo solucione Samsung (que ya se ha pronunciado y ha dicho que está trabajando en ello) y evitar cambiar los permisos del archivo y demás "soluciones" propuestas.

Luis Delgado dijo...

Se ha publicado el código fuente de ambas aplicaciones y todos los recursos necesarios para su ejecución por lo que no se van a publicar directamente los APK.

Luis Delgado dijo...

En ningún momento se ha planteado el tema como una vulnerabilidad sino como una técnica a usar para modificar el comportamiento de las aplicaciones de forma dinámica sin estar "atados" a un código ya existente en la aplicación (como ocurría con JSBridge, que es otra técnica). La idea a priori no es elevar privilegios o 'bypass' de permisos sino generar un comportamiento malicioso temporal directamente en el dispositivo infectado. Si luego encima tenemos la opción de ejecutar exploits puesto que podemos cargar librerías de forma arbitraria... ¡+1!

¿Estás seguro de que usando PathClassLoader te ahorras la caché? Porque leyéndome la documentación[1][2], el código[3][4] e Issue966[5] parece que sí que lo guarda en la cache...

[1] https://developer.android.com/reference/dalvik/system/PathClassLoader.html
[2] https://www.cs.cmu.edu/~srini/15-446/android/android-sdk-linux_x86-1.0_r2/docs/reference/dalvik/system/PathClassLoader.html
[3] https://android.googlesource.com/platform/libcore-snapshot/+/gingerbread/dalvik/src/main/java/dalvik/system/PathClassLoader.java
[4] https://android.googlesource.com/platform/libcore-snapshot/+/ics-mr1/dalvik/src/main/java/dalvik/system/PathClassLoader.java
[5] https://code.google.com/p/android/issues/detail?id=966

car dijo...

Que tal @Miguel en este enlace podrías tener la solución a tu problema con la camara http://forum.xda-developers.com/showthread.php?t=2052675 saludos.