google play, ocultación de malware y exynosabuse

google play, ocultación de malware y exynosabuse

GOOGLE PLAY, OCULTACIÓN DE MALWARE Y EXYNOSABUSE > PWNED!
Luis Delgado
Que 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 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):
http://youtu.be/jP2296XRYvw
Podéis acceder al código de las aplicaciones y demás material en:
http://www.ldelgado.es/?bingimages