The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

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

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 enBlackHat 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 yJon 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 stockvulnerabilidades en Androiddebugging…) 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):

 

Popout

 

Podéis acceder al código de las aplicaciones y demás material en:
Artículo cortesía de Luis Delgado 

Comments are closed.