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):
Fuente: Securitybydefault
No hay comentarios:
Publicar un comentario