Trabajo optativo sobre la seguridad en Android, descripción de las principales vulnerabilidades más conocidas y aplicaciones malware.

1. Aplicaciones para Plataformas
Móviles
Seguridad en Android
David Albela Pérez

3. Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 3.0 España.

4. Tabla de Contenidos
1.Introducción.......................................................................................................................................4
2.Malware en Android..........................................................................................................................4
2.1.Motivaciones..............................................................................................................................5
2.2.Múltiples capas de defensa........................................................................................................6
2.3.Consejos para un entorno seguro...............................................................................................7
2.3.1.La realidad de Sandbox......................................................................................................7
3.Aplicaciones malware conocidas.......................................................................................................7
3.1.1.Tap Snake...........................................................................................................................7
3.1.2.Fake Player.........................................................................................................................7
3.1.3.Gemini................................................................................................................................8
3.1.4.Droid Kungfu.....................................................................................................................8
3.1.5.Obad...................................................................................................................................8
3.1.6.AndroRAT..........................................................................................................................9
3.1.7.Linterna Led.....................................................................................................................10
3.1.8.Malware minero de criptomonedas..................................................................................11
4.Vulnerabilidades en Android...........................................................................................................12
4.1.Master Key...............................................................................................................................12
4.2.Tapjacking................................................................................................................................14
4.2.1.Phising con TapJacking....................................................................................................15
4.3.SecureRandom en Android 4.2................................................................................................16
4.4.OS Memory Corruption...........................................................................................................16
4.5.Otros problemas.......................................................................................................................16
4.5.1.Android Data Extraction..................................................................................................16
4.5.2.Orden de las suites criptográficas....................................................................................17
5.Rootkit para Android.......................................................................................................................17
5.1.Pasos para la creación del rootkit............................................................................................18
6.Seguridad en aplicaciones de Mensajería........................................................................................19
6.1.WhatsApp y AES Key: Jugando al gato y el ratón..................................................................21
6.1.1.Mensajes de WhatsApp sin cifrar....................................................................................21
6.1.2.Primer intento, mensajes cifrados AES-192-ECB...........................................................21
6.1.3.Segundo intento, extensión crypt5...................................................................................21
6.1.4.Tercer intento: Claves distintas para cada dispositivo.....................................................22
7.Espionaje en los dispositivos móviles.............................................................................................22
8.Conclusiones....................................................................................................................................24
9.Referencias......................................................................................................................................25

5. 1. Introducción
En esta memoria se describen problemas de seguridad en dispositivos Android así como los
principales malware reportados de Google Play u otras fuente.
En primer lugar se analiza la actualidad del malware en Android, cuales son las motivaciones para
su creación y su uso.
A continuación se describen las aplicaciones malware más destacables y su evolución en el sistema
operativo. Además se describen las vulnerabilidades para Android más conocidas y como se podrían
crear Rootkits para tener el control total del dispositivo.
Finalmente se abordan los problemas de la privacidad existentes en las aplicaciones, en concreto en
las aplicaciones de mensajería y se comentan los problemas de espionaje bajo los que los
dispositivos móviles son el principal objetivo.
2. Malware en Android
Desde el año 2011 el malware en dispositivos Android se ha visto incrementado
significativamente. En parte gracias al uso cada vez mayor de esta plataforma y la laxitud por parte
del usuario final que no mira los permisos de acceso de la aplicación.
En la siguiente figura se muestra el informe publicado a finales de 2013 por el jefe de seguridad en
Android, Adrian Ludwig1
, “Android, practical security from the ground up” donde se detallan las
aplicaciones potencialmente dañinas que han sido instaladas en dispositivos Android.
1 Informe Adrian Ludwig:
https://docs.google.com/a/ldelgado.es/presentation/d/1YDYUrD22Xq12nKkhBfwoJBfw2Q-
OReMr0BrDfHyfyPw/pub#slide=id.g1202bd8e5_05
Figura 1: Estimación de 2013 de aplicaciones peligrosas por millón de instalaciones.

6. Destacan en un primer lugar aplicaciones que requieren de acceso root pero que no son maliciosas.
En cambio le siguen, casi en mismo número, las aplicaciones con fraudes por mensajes SMS,
seguido de aplicaciones de espionaje. En la cola están los troyanos, puestas traseras, fraudes phising
y exploits maliciosos.
El informe publicado en 2013 por la empresa Juniper Network2
indica que la presencia de malware
en el market Google Play se cuadriplicado respecto al año 2012.
Desde otro punto de vista, Sergio de los Santos de ElevenPaths publicó en febrero de 2014 un
interesante artículo3
que intenta realizar una apoximación realista de como el malware sí está
presente en Google Play. En el artículo se pone en entre dicho el resultados publicados por Google y
terceras compañías donde se plantea hasta que punto son realmente peligrosas todas las aplicaciones
definidas como “maliciosas” para Android.
2.1. Motivaciones
Los desarrolladores de malware conocen el uso importante que se le está dando a los smartphones,
prácticamente sustituyendo un ordenador donde se realizan actividades diarias como conectarse a
internet, leer el correo electrónico, acceder a una VPN o manejar datos bancarios.
Las principales motivaciones a desarrollar aplicaciones malware son:
• El aumento del número de usuarios con dispositivos Android. A finales del 2012 se
registraron más de 500 millones de dispositivos Android.
• Hoy en día un smartphone tiene la capacidad de procesamiento equivalente al de un
ordenador de hace unos años.
• Además, la mayoría está conectado a internet la mayor parte del tiempo (3G/Wifi) y son
geolocalizables.
2 Informe Juniper de 2013: http://www.juniper.net/us/en/local/pdf/additional-resources/3rd-jnpr-mobile-threats-
report-exec-summary.pdf
3 El negocio de las FakeApps en Android: http://blog.elevenpaths.com/2014/02/el-negocio-de-las-fakeapps-y-el-
malware.html
Figura 2: Informe de malware en móviles de Juniper Network de
2013.

7. • Los usuarios almacenan información privada.
• Un usuario casi nunca se cuestiona la integridad y seguridad en su móvil.
◦ Conexiones Wifi abiertas.
◦ Instalación de aplicaciones sin revisar los permisos o de fuentes desconocidas.
◦ Instalación de kernel modificados o ROM sin conocer su origen.
2.2. Múltiples capas de defensa
Android incluye una serie de capas o barreras de seguridad como medida contra aplicaciones
malware o PHA (Potential Harmful App).
• Sandbox y permisos: Todos los dispositivos Android tienen sandbox y permisos de acceso a
diferentes funcionalidades. Sandbox permite recrear un escenario virtual seguro donde
analizar las aplicaciones de forma dinámica para detectar las acciones que realiza a distintos
niveles y registrar para un análisis en profundidad. Realmente, permite registrar datos de la
aplicación y enviarla a terceros para que sean analizadas.
• Verificar la App: Las aplicaciones pueden ser verificadas, esto significa que google verficará
siempre que cualquier aplicación instalada pertenece a quien dice ser. El verificador de
aplicaciones de Android se ejecuta continuamente en segundo plano comprobando en todo
momento el código ejecutado por la aplicación.
• Instalación de fuentes conocidas: Por defecto no se permite la instalación de apk de orígenes
desconocidos.
• Las aplicaciones de fuentes desconocidas envían mensajes de advertencia al usuario antes de
ser instaladas.
• Por último, se encuentran aquellas aplicaciones que finalmente son instaladas e intentan
evadir las defensas en tiempo de ejecución, por ejemplo, asignar permisos que no tienen
disponibles.
Figura 3: Capas de defensa presente Android.

8. ◦ Dentro de estas aplicaciones, consiguen evadir la seguridad del dispositivo
aprovechando algún tipo de vulnerabilidad o exploit.
2.3. Consejos para un entorno seguro
Para tener una aplicación con el sistema protegido se recomienda:
• Aislar siempre los datos de la aplicación y la ejecución del código de otras aplicaciones
• Implementación robusta con funcionalidades seguras y probadas: permisos, criptografía,
IPC.
• Desarrollar aplicaciones con tecnologías de seguridad para mitigar los riesgos: NX, IPSec,
funciones malloc seguras como OpenBSD dlmalloc o calloc.
• Sistemas de archivos cifrados que puedan ser habilitados para proteger los datos en
dispositivos perdidos.
• Permisos de grano fino para restringir acceso al sistema y los datos de usuario.
2.3.1. La realidad de Sandbox
Sandbox permite monitorizar a través de la virtualización el código de la aplicación en
ejecución para determinar si es maliciosa. Sin embargo:
• Amenazas de seguridad causadas por malware dentro del sandbox:
◦ La inyección de código en aplicaciones legítimas es posible.
◦ Vulnerabilidad TapJacking.
◦ Múltiples aplicaciones malware, trojans y backdoors.
• Amenazas de seguridad causadas por malware dentro del sandbox:
◦ Aplicaciones webkit de control remoto.
◦ Código de explotación de privilegios root locales a partir de vulnerabilidades del kernel.
◦ LKM kernel rootkit.
◦ Actualizaciones de seguridad que no se aplican en muchos dispositivos.
3. Aplicaciones malware conocidas
Entre las aplicaciones malware conocidas destacan las descritas a continuación.
3.1.1. Tap Snake
Primer caso de malware conocido, aplicación del juego conocido Snake que incluía permisos
de acceso a las coordenadas GPS: android.permission.ACCESS_COARSE_LOCATION y
android.permission.ACCESS_FINE_LOCATION.
3.1.2. Fake Player
Malware creado en agosto del 2010 que pretendía ser un reproductor multimedia. Entre sus
permisos estaban android.permission.SEND_SMS teniendo como objetivo el envío de mensajes en
Ruso SMS a números de tarificación especial a países como Kazajistán.

9. 3.1.3. Gemini
Markets de terceros de dudosa reputación que ofrecen aplicaciones del market de google las
mismas aplicaciones gratuitas.
Se trata de una aplicación procedente de China que a partir de aplicaciones legítimas modifican
el código original incluyendo funcionalidades para recolectar todo tipo de información privada.
Una aplicación modificada por la aplicación de Gemini suele incluir los siguientes permisos en
AndroidManifest.xml:
CALL_PHONE: Realizar llamadas de teléfono sin necesidad de que el usuario de permiso
explícito.
• SEND_SMS: Enviar SMS.
• READ_SMS: Leer los SMS.
• ACCESS_FINE_LOCATION: Acceder a nuestra posición geográfica.
• READ_CONTACTS: Leer la agenda de contactos.
• MOUNT_UNMOUNT_FILESYSTEMS: Montar y desmontar sistemas de ficheros
para unidades extraíbles.
• WRITE_EXTERNAL_STORAGE: Posibilidad de escribir en un medio de
almacenamiento externo.
• INSTALL_SHORTCUT:
• WRITE_CONTACTS: Escribir en la agenda de contactos.
• ACCESS_GPS:
• ACCESS_LOCATION:
• RESTART_PACKAGES:
• RECEIVE_SMS: Monitorizar los SMS de entrada para almacenarlos o procesarlos.
• SMS_RECEIVE:
• WRITE_SMS: Escribir SMS.
Permisos como RECEIVE_SMS, WRITE_SMS hacen que una de las funcionalidades incluidas en
este malware sea el de formar parte de una botnet a la espera de recibir instrucciones por SMS.
Gemini además de modificar el código original realiza también ofuscación para complicar el
análisis de los antivirus.
Los usuarios no suelen ser conscientes del problema que implica añadir un Market alternativo o
la instalación de apk de pago modificadas de dudoso origen.
3.1.4. Droid Kungfu
Primer malware troyano capaz de pasar inadvertido por los antivirus, publicado en 2011
permitía infectar versiones de Android 2.2 Froyo y tomar el control del dispositivo.
Una vez instalado, DroidKungFu.C intenta rootear el teléfono para obtener el control del sistema
usando el uso de exploits como el método Rageagainstthecage de z4root. El código se almacena en
el paquete del malware y se cifran con una clave para que no pueda ser detectado por un antivirus.
3.1.5. Obad
En Junio de 2013 aparece el troyano Obad con multifuncionalidades como leer/enviar mensajes
SMS sin notificar al usuario, iniciar llamadas de teléfono o realizar la instalación de exploits
remotamente a través de un canal seguro para ocultarse de la lista de aplicaciones en el
administrador. El fichero .dex está cifrado y ofuscado para dificultar la detección de los antivirus.

10. La aplicación antes de ser instalada solicita hasta 24 permisos y realiza además la solicitud de
administrador del dispositivo.
Además usaba un protector comercial de código para prevenir el proceso de decompilación. En
truco consistía en añadir una instrucciones Goto en el medio de un bloque if con el fin de confundir
al desensamblador y hacer que se genere el código fuente equivocado.
A mayores usaba múltiples capas de cifrado para ocultar las líneas de código malware usando 3
parámetros cuyo orden podía ser aleatorio.
Al instalar la aplicación se solicitaban permisos de administrador a través de un diálogo. Una vez
que un usuario establece la aplicación como administrador de dispositivos, obtiene permiso para
bloquear la pantalla y ocultase con éxito de la lista de administradores de dispositivos, explotando
así la vulnerabilidad.
Más información en el informe publicado por la compañía Comodo4
.
3.1.6. AndroRAT
Herramienta de administración remota para controlar dispositivos Android con la herramienta
cliente instalada a través de un servidor en una aplicación Java/Swing.
Incluye funcionalidades como obtener la lista de contactos, registro de llamadas, leer mensajes,
localización GPS, monitorizar el teclado en tiempo real, sacar fotografías desde la pantalla frontal,
grabar sonidos, enviar mensajes de texto, realizar llamadas, abrir urls en el navegador y hacer vibrar
el teléfono.
La aplicación se puede ejecutar como un servicio y se inicia en el arranque. La conexión con el
servidor puede establecerse mediante SMS o llamadas.
4 Obad trojan Comodo report: http://www.comodo.com/resources/Android_OBAD_Tech_Reportv3.pdf
Figura 4: Función de descifrado del código
malware de Obad escrito en C.

11. La aplicación se puede encontrar en páginas .onion de la Tor5
. Si bien es difícil que alguien la
instale por error o sin mirar los permisos de acceso a la aplicación.
3.1.7. Linterna Led
La Linterna Led era una aplicación disponible en Google Play para usar el flash del móvil
como linterna de uso muy simple, gratuita y sin añadir publicidad.
Los únicos permisos que requería eran leer mensajes SMS y conectarse a internet. Pero
ningún permiso para enviar SMS o realizar llamadas.
Sin embargo, la aplicación al ejecutarse se conectaba a internet para darse de alta en servicios
de mensajería de pago por SMS usando el número del dispositivo. El servicio de mensajería enviaba
un SMS con un PIN al teléfono para solicitar la confirmación de alta en el servicio y la aplicación
de linterna leía automáticamente el mensaje validando la suscripción.
A mayores, si el dispositivo tenía instalada la App de Facebook, publicaba un mensaje con la
cuenta de usuario en Facebook recomendado dicha aplicación.
La aplicación estaba ofuscada utilizando la herramienta Proguard6
. A finales de 2013 tenía entre
10.000 y 50.000 descargas. Tras ser retirada de Google Play, aún podía ser descargada de otros
markets.
5 Tor: https://www.torproject.org
6 Ofuscador Proguard: http://proguard.sourceforge.net
Figura 5: AndroRAT incluye una aplicación de escritorio
para controlar el dispositivo.
Figura 6: Linterna Led se instaló en al menos 10.000 terminales.

12. Toda la información del caso de la estafa se puede encontrar el blog de Chema Alonso7
.
3.1.8. Malware minero de criptomonedas
Desde la aparición de Bitcoin y otras monedas basadas criptográfica, aparece un nuevo tipo de
malware que utiliza software de minado para monedas criptográficas botnet.
A finales de año de 2013, se detecta en un importante pool de minado de Litecoin que determinados
usuarios (gpu174v6, gpu174v7, cpu174v6, cpu174v7, etc) tenían una capacidad de cálculo
demasiado elevada, descubriéndose que se trataba de botnes instaladas en miles de ordenadores8
.
En marzo del 2014, la empresa de seguridad Trend Micro9
descubrió que algunas aplicaciones de
Google Play utilizaban los recursos de los dispositivos móviles para minar monedas digitales tales
como Litecoin o Dogecoin.
En la siguiente imagen se muestra código desensamblado, la clase MiningService.class contiene los
parámetros de configuración del software de minado cpuminer para cálculo con CPU adaptado para
procesadores ARM.
7 Linterna Led: http://www.elladodelmal.com/2014/01/la-estafa-de-la-linterna-molona-que.html
8 Mensaje de Reddit sobre botnets mineros:
http://www.reddit.com/r/litecoin/comments/1tvlv0/are_scrypt_asic_units_out_in_the_wild_take_a_look/
9 Tren Micro Mobile Malware Mines: http://blog.trendmicro.com/trendlabs-security-intelligence/mobile-malware-
mines-dogecoins-and-litecoins-for-bitcoin-payout/
Figura 7: Usuarios gpu174v y cpu174v en el pool de wemineltc.com.
Figura 8: Código desensamblado de una de las aplicaciones que
minaba criptomonedas.

13. Con la capacidad de cálculo de todos los dispositivos con la aplicación instalada se podría alcanzar
una importante suma de monedas digitales que podrían llegar a alcanzar un valor desde cientos a
miles de euros al día.
4. Vulnerabilidades en Android
En la siguiente imagen se muestran los 4 problemas de seguridad más destacados en el Android
a fecha de 2013 (sin incluir el problema de la cifrado descubierto por bitcoin.org).
A continuación se describen vulnerabilidad más conocidas recientemente en Android.
4.1. Master Key
Vulnerabilidad descubierta por BlueBlox10
que permite en Android saltar la verificación de
firma digital de los ficheros e instalar versiones modificadas en su lugar.
Un atacante podría modificar el código de una aplicación de Android y ser instalada sin llegar a
invalidar la verificación de la firma digital. Es como tener una “llave maestra” para desbloquear el
acceso a un dispositivo e instalar la aplicación haciéndose pasar por la original.
El fichero META-INF/MANIFEST.MF contiene los hash SHA1 de cada fichero del paquete
APK, entre ellos el classes.dex. Los ficheros classes.dex contienen el Bytecode de la aplicación y si
este es modificado, el hash ya no coincide con el original invalidando la firma al intentar instalarlo.
10 BlueBox Securing Mobile: https://bluebox.com/technical/uncovering-android-master-key-that-makes-99-of-devices-
vulnerable/
Figura 9: Aplicaciones malware y vulnerabilidad que más afectan en Android.

14. Por tanto el hash SHA1 debe ser el mismo siempre para la verificación de la firma.
Sin embargo, es posible añadir dos ficheros con el mismo nombre en el contenido del APK
(contenido zip) de forma que Android verifique el primero con el hash válido e instale la versión
modificada.
En la imagen, se puede ver el contenido de un paquete APK con dos ficheros classes.dex y
AndroidManifest.xml, el original servirá para validar la aplicación y el segundo se trata de la
versión modificada que será instalada en el dispositivo.
Aunque el archivo AndroidManifest.xml, el cual indica los permisos y limitaciones de la
aplicación indicadas por el desarrollador, en este caso solo funcionaría volviendo a firmar la
aplicación con el fichero modificado o recalculando su valor para que coincida con el original.
El español Pau Oliva publicó en su github11
un script en python para reempaquetar el APK con
varios ficheros.
El bug publicado con el identificador 8219321 ha sido solucionado en las mayoría de
dispositivos, pero pronto se descubrió otro tipo de vulnerabilidad Master Key, bug 9695860,
11 PoC empaquetador para Master Key de Pau Oliva: https://gist.github.com/poliva/36b0795ab79ad6f14fd8
Figura 10: El contenido de MANIFEST.MF incluye el hash SHA1 de
todos los ficheros del paquete APK.
Figura 11: Paquete APK con ficheros
duplicados para aprovechar la
vulnerabilidad Master Key.

15. demostrada por el grupo de seguridad Chino Android Security Squad12
la cual permite engañar la
validación de firmas modificando la cabecera de los APK. Para ello se resta la posición del
classes.dex original y se extiende longitud del campo extra field a 0xFFFD, 64k que es el tamaño
máximo del este campo, para poder así añadir a continuación un fichero clasess.dex modificado.
En la imagen de ejemplo se muestra como cambiando la longitud de “extra field” se puede
hacer que la firma sea validada con el fichero classes.dex original e instalar realmente el
modificado. De todos modos, solo puede ser reemplazado el fichero classes.dex y solo si el original
es menor de 64k, tamaño máximo de la cabecera extra field. Además, es necesario realizar la
reconstrucción del APK modificando la cabecera.
El experto en seguridad Jay Freeman13
, también conocido como Saurik, demostró una prueba
de concepto para una tercera variante que podría ser explotada incluso en la última versión de
Android 4.4 Kit Kat, bug numerado 995069714
.
off64_t dataOffset = localHdrOffset + kLFHLen + get2LE(lfhBuf + kLFHNameLen) + get2LE(lfhBuf +
kLFHExtraLen);
Saurik, basándose en la vulnerabilidad Master Key, publicó la herrramienta Cydia Impactor15
para obtener acceso root o “rootear” en la mayoría de dispositivos Android.
Aplicaciones como ReKey16
permiten corregir los problemas de Master Key (requiere
privilegios de root).
4.2. Tapjacking
TapJacking se trata de una técnica muy similar a Clickjacking en html donde una aplicación puede
engañar a un usuario para realizar acciones no deseadas en un dispositivo Android. La aplicación se
puede desarrollar sin ningún permiso, esto podría permitir a un atacante cambiar la configuración de
12 Android Security Squad, segundo Master Key: http://blog.sina.com.cn/s/blog_be6dacae0101bksm.html
13 Artículos Master Key de Jay Freeman: http://www.saurik.com/id/18 y http://www.saurik.com/id/19
14 Bug Master Key 9950697: https://code.google.com/p/android/issues/detail?id=57851
15 Herramienta para Rootear Android basada en Master Key: http://www.cydiaimpactor.com/
16 ReKey protector ante MasterKey: http://www.rekey.io
Figura 12: Master Key v2, la cabecera del APK puede ser
modificadas para engañar al sistema de verificación.

16. seguridad del dispositivo, el envío de SMS de pago o la instalación de nuevas cargas aplicaciones.
Esto es posible mediante la superposición de una pantalla real en la parte superior de la pila junto
con otro objeto Toast. El resultado es que el usuario no sabe realmente donde está haciendo clic
porque la pantalla real está oculta.
El elemento usado para lanzar esta vulnerabilidad es el tipo de diálogo Toast, el cual puede ser
personalizarlo con el fin de llenar la pantalla completa y haciéndose pasar por una Activity real que
permanece oculta al usuario.
Un desarrollador tiene la libertad de diseñar un Toast del tamaño que quiera permitiendo incluso
añadir además de texto otros elementos como imágenes. Esto podría ser útil en combinación con
una Activity de otra aplicación para aprovechar ciertas partes de la pantalla y, justo antes de que el
usuario tocase la parte de la pantalla iniciar, una notificación Toast maliciosa que se parezca a la
Activity original.
Hay disponible un ejemplo de Tapjacking para Android en el repositorio de github de Sebastián
Guerrero17
(0xroot).
4.2.1. Phising con TapJacking
A finales de marzo de 2014 se publicó en la FireEye18
un problema de aplicaciones en Background
que con permisos normales podría llegar a hacer que una aplicación maliciosa puede modificar los
iconos de la Activity principal de forma que lancen aplicaciones o sitios web de phishing.
Este problema se puede explotar en versiones de Android 4.4.2.
17 PoC TapJacking de Sebastián Guerrero: https://github.com/0xroot/Tapjacking-Framework-for-Android
18 Problemas de Pishing en Android: http://unaaldia.hispasec.com/2014/04/vulnerabilidad-en-android-facilita-la.html
Figura 13: La técnica de Tapjacking permite engañar al
usuario utilizando Toast a pantalla completa.

17. 4.3. SecureRandom en Android 4.2
A principios de agosto del 2013 se publicó en Bitcoin.org19
un problema en la generación de
números aleatorios en versiones de Android 4.2 que permitía desde cualquier dispositivo repetir
una secuencia de números. Cualquier usuario que generase una cartera con la aplicación de Bitcoin
para Android (clave pública/privada) en la versión vulnerable de Android podría ser duplicada y
robada por terceros.
Tal como se recomienda en el artículo de Bitcoin.org, es necesario añadir una semilla a la
inicialización de la secuencia de generación de números aleatorios, PRNG.
4.4. OS Memory Corruption
Se trata de un bug que provocaba la corrupción de memoria en el sistema al superar el nombre
de la aplicación 387000 caracteres de longitud. El nombre se indica en el atributo android:label de
la etiqueta application en el fichero AndroidManifest.xml.
El verdadero problema de este bug no es solo que hacía que el terminal se colgase al lanzar la
aplicación, sino que además el autor que descubrió el bug, Ibrahim Balic20
, al subir la aplicación con
el bug a Google Play provocó una denegación de servicio que duró dos días. Durante ese tiempo,
nadie podría subir ninguna aplicación al market oficial de Android.
El nombre de la aplicación se indica en el fichero AndroidManifest.xml, el cual describe
componentes, permisos y compatibilidad de la aplicación.
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
Normalmente, el nombre de aplicación se referencia en el fichero de internacionalización
/res/values/strings.xml.
19 Bug SecureRandom: https://bitcoin.org/en/alert/2013-08-11-android
20 DoS Google Play: http://ibrahimbalic.com/2014/android-os-memory-corruption-bug/
Figura 14: Respuesta de error en Google Play recibida por Ibrahim Balic tras subir la
aplicación con el bug.

18. <string name="app_name">My First App</string>
4.5. Otros problemas
4.5.1. Android Data Extraction
No se trata de una vulnerabilidad, pero sí de la facilidad de extracción de datos (SQLite, dat,
xml, etc) disponibles en un dispositivo Android y de los que se podría extraer información relevante
del usuario.
La herramienta ADEL21
de Michael Spreitzenbarth es un conjunto de scripts en Python que
permiten extraer la información de un dispositivo conectado por USB y generar un informe en
XML.
Para que funcione, el dispositivo Android necesita tener un kernel inseguro y estar rooteado.
4.5.2. Orden de las suites criptográficas
Según el blog de SecuriyByDefault, en el artículo Actualidad del Malware en Android (2 de
3)22
, el orden de preferencia del uso de suites criptográficas para establecer la comunicación SSL
con el servidor en la evolución de las versiones de Android ha cambiado a peor.
Antes de establecer un canal seguro SSL entre cliente-servidor, ambos siempre negocian que
algoritmos de cifrado y función hash se van a utilizar. Mientras que en las versiones de Android
2.2.1 prevalecía en la lista AES256-SHA ahora es RC4-MD5.
5. Rootkit para Android
Un rootkit es un conjunto de aplicaciones del sistema modificadas e instaladas en un sistema
con privilegios de root para disponer del control total del dispositivo. Un rootkit instalado en un
dispositivo Android podría realizar operaciones como:
• Ocultar ficheros y procesos que no se desean que vea el usuario.
• Acceder información del usuario.
• Instalar backdoors para acceder al dispositivo remotamente.
• Ocultar registros de log para evitar la detección de intrusión en el sistema.
En la conferencia de seguridad RootedCon23
de 2013 en Madrid, Sebastián Guerrero (@0xroot)
explicó en la charla “Ke ase Android?”24
como es posible crear un rootKit para Android saltándose
la seguridad y los privilegios de acceso sin llegar a ser detectable por los antivirus.
Para que funciona, los dispositivos Android deben tener habilitado los privilegios de root,
“rooteado”, y tener el módulo LKM25
del kernel activado. Prácticamente todos los móviles con
“ROM cocinada”.
21 ADEL: http://forensics.spreitzenbarth.de/adel/
22 SecurityByDefault: http://www.securitybydefault.com/2013/12/actualidad-del-malware-en-android-2-de-3.html
23 RootedCon: www.rootedcon.es
24 Charla de Sebastián Guerrero en la RootedCon de 2013: http://vimeo.com/68252601
25 LKM Module: http://en.wikipedia.org/wiki/Loadable_kernel_module

19. El módulo del kernel LKM o Loadable Kernel Module permite extender las funcionalidades del
kernel ya que se ejecuta en el espacio del kernel, pudiendo añadir y modificar piezas de código
sin necesidad de recompilar o reiniciar.
Para crear el rootkit y tener acceso a LKM es necesario acceder a las llamadas del sistema, las
cuales se hacen uso de los punteros de funciones accesibles desde el fichero /proc/kallsyms. En la
siguiente captura, parte de la presentación de Sebastián Guerrero, se muestra la estructura de la
tabla de llamadas al sistema.
Para modificar el código de las aplicaciones instaladas en el dispositivo es necesario crear una
llamada al sistema modificada registrando la nueva dirección con el código modificado.
El resultado es que con una aplicación que pueda acceder a las llamadas del sistema y tenga
privilegios para modificar el código, gracias al módulo de LKM. se puede llegar a tener un control
total del dispositivo.
5.1. Pasos para la creación del rootkit
A continuación se enumeran de forma simple y descriptiva los 4 pasos del ejemplo de creación del
rootkit de la memoria de Sebastián Guerrero.
1. Encontrar la dirección de la tabla de llama al sistema “sys_call_table_address”.
◦ Buscando la dirección en la instrucción adr (add + ldr).
◦ Ejemplo:
e28f8080: add r8, pc, 0x80;
e599c000: ldr ip, [r9];
2. Compilar el código para la misma versión de kernel del dispositivo objetivo.
Figura 15: Es necesario que en la tabla de llamada al sistema
se apunte hacia el hook para que este se ejecute en lugar de
las funciones originales.

20. ◦ Se puede engañar al código para indicar que se usa la misma versión del dispositivo en
la directiva vermagic. El problema es que sigue siendo necesario compilar la versión del
kernel de la arquitectura del dispositivo (ARMv5 y ARMv7 tienen versiones distintas del
kernel de Linux).
3. Activar el modo depuración de la llamada al sistema para obtener información útil.
◦ Para descubrir rutinas del dispositivo en los mensajes de log de dmesg.
4. Realizar el despliegue de ataque. Evitar detección.
◦ Modificar los dex con la herramienta DEXparser26
para modificar la cabecera de los
archivos *header.class_def_off.
▪ Se necesita desempaquetar el apk, en realidad se trata de un fichero comprimido en
formato zip con la firma y el checksum de los .dex.
▪ Existen herramientas para desensamblar el código:
• Dex2Jar27
: Convierte ficheros .dex a .jar o .j.
• Apktook28
: Desempaquetar apk.
• Jad29
y JDProject30
: Decompiladores de .class a Java.
• Jadx31
: Decompilador Dex a Java.
• Radare232
o R2: Decompilador multiplataforma con soporte para Java y Android.
◦ Recompilar el apk con classes.dex modificado.
▪ Firmar con jarsigner.
▪ Comprimir apk en formato zip.
• Hay que recalcular el hash SHA1 de los ficheros modificados obviando los
primeros 32 bits en classes.dex y recalcular el checksum. Para ello se usa el
script de perl DEXreHash33
.
6. Seguridad en aplicaciones de Mensajería
Las aplicaciones de mensajería llegaron para sustituir el SMS. Desde la aparición de la
conocida aplicación Whatsapp34
surgen muchas aplicaciones alternativas: ChatOn de Samsung,
Viber, Line, Snaptchat o Telegram.
En el evento de la RootedCon de 2014, la ponencia de Jaime Sánchez y Pablo San Emeterio35
describe los problemas de la comunicación segura en estas aplicaciones.
Aunque la presentación se centra en problemas con las aplicaciones para iPhone, no deja de ser
curioso lo fácil que puede llegar a ser suplantar o interceptar los mensajes de ciertas aplicaciones.
26 Dexterity basada en DEXparser: https://github.com/0xroot/dexterity
27 Dex2Jar: http://code.google.com/p/dex2jar
28 Android Apktool: https://code.google.com/p/android-apktool/
29 Jad Java Decompiler: http://varaneckas.com/jad/
30 JDProject Decompiler: http://jd.benow.ca/
31 JadX: https://github.com/skylot/jadx
32 Radare2 (o R2): https://github.com/radare/radare2
33 DEXreHash: https://github.com/cryptax/dextools/
34 WhatsApp: http://www.whatsapp.com/
35 Seguridad Ofensiva: http://www.seguridadofensiva.com/2014/03/slides-de-nuestra-charla-whatsapp-mentiras-y-
cintas-de-video-en-rootedcon-2014.html

21. En concreto, la aplicación Snapchat fue seguramente el mayor problema de datos
comprometidos de ese tipo de aplicaciones con 4,6 millones de usuarios expuestos36
con sus
números de teléfono y mensajes. El problema venía dado por el tiempo de validez de parámetro
req_token y el nombre de usuario, el cual era posible de suplantar usando ataques de repetición.
Viber directamente envía toda la información en claro37
.
WhatsApp siempre tuvo problemas de seguridad desde que se lanzó:
• Ausencia de clave de sesión única por dispositivo.
• Usando IMEI como contraseña.
• Problemas con el cifrado RC4.
◦ El creador de xmpp.net, Thijs Alkemade, daba la voz de alarma en su blog38
:
1. Usaba la misma clave de cifrado en ambos sentidos, cliente y servidor.
2. Usaba la misma HMAC en ambas direcciones.
• Copias de seguridad en el almacenamiento externo y cifradas con la misma clave.
◦ Cualquier aplicación con acceso al almacenamiento externo podría leer los mensajes de
las copias.
• No se necesita autorización para enviar mensajes.
• Los servidores almacenan contenido de los mensajes.
Además:
• Es posible enviar un mensaje a cualquier teléfono móvil sin autorización.
• Se puede conocer la localización de dispositivos mediante MitM39
.
• Hay herramientas para enviar mensajes desde un script como Yowsup40
.
• Obtener datos del perfil de un usuario era posible con WhatsApp Voyeur41
.
• Hasta la versión 2.11.7 de iOS se podía colgar enviando mensajes con caracteres no
imprimibles42
.
36 SnapHack: http://techcrunch.com/2013/12/31/hackers-claim-to-publish-list-of-4-6m-snapchat-usernames-and-
numbers/
37 Viber Security Vulnerabilities: http://www.youtube.com/watch?v=kqgn-HF4gKg
38 WhatsApp RC4: https://blog.thijsalkema.de/blog/2013/10/08/piercing-through-whatsapp-s-encryption/
39 Compartir localización en WhatsApp: http://thehackernews.com/2014/04/whatsapp-flaw-leaves-user-
location.html
40 Yowsup: https://github.com/tgalal/yowsup
41 Como espiar WhatsApp: http://www.elladodelmal.com/2013/07/como-espiar-whatsapp.html
42 WhatsApp Remote Crash: https://github.com/segofensiva/WhatsAppRemoteCrash

22. En el blog de Chema Alonso43
se pueden encontrar multitud de artículos interesantes sobre los
problemas de seguridad WhatsApp.
6.1. WhatsApp y AES Key: Jugando al gato y el ratón.
Uno de los problemas de la aplicación de WhatsApp es que los mensajes se guardan cifrados en el
almacenamiento externo del terminal automáticamente, permitiendo que cualquiera con acceso
pueda copiarlos.
El contenido de los mensajes se almacenan en ficheros SQLite.
6.1.1. Mensajes de WhatsApp sin cifrar
Las primeras copias de WhatsApp se almacenaban en claro en el fichero msgstore.db. Con tan solo
leer el fichero o cargarlo en un cliente SQLite era posible leer los mensajes.
El experto en seguridad Alejandro Ramos explica en la RootedCon de 201344
como es posible leer
los datos de un SQLite aún incluso después de haber sido borrados de la base de datos, ya que estos
se mantienen en el fichero siempre que no se haga VACUUM.
En el blog SecurityByDefault se puede leer un artículo de Yago Jesús45
de Junio de 2011 muy
interesante sobre los problemas que tenía WhatsApp con los mensajes.
6.1.2. Primer intento, mensajes cifrados AES-192-ECB
En la ruta /sdcard/WhatsApp/Databases/msgstore.db.crypt se puede encontrar la copia de los
mensajes en SQLite de WhatsApp cifrados en AES con una clave de 192 bits.
El problema que el cifrado de las copias de mensajes de todos los dispositivos se realizaba con la
misma clave “346a23652a46392b4d73257c67317e352e3372482177652c”.
Por lo tanto, usando el programa de openssl era posible descifrar el contenido del fichero,
ejecutando el siguiente comando.
$ openssl enc -d -aes-192-ecb -in msgstore.db.crypt -out msgstore.db.sqlite -K
43 Robar WhatsApp de Android con Meterpreter: http://www.elladodelmal.com/2014/04/robar-whatsapp-de-
android-con.html
44 Ponencia de Alenjandro Ramos RootedCon 2013: http://www.slideshare.net/rootedcon/alejandro-ramos-
18351093
45 Lo que no te cuenta WhatsApp: http://www.securitybydefault.com/2011/06/lo-que-no-te-cuenta-whatsapp.html
Figura 16: La herramienta de WhatsAppRemoteCrash de
Jaime Sánchez cuelga la aplicación en iOS

23. 346a23652a46392b4d73257c67317e352e3372482177652c
6.1.3. Segundo intento, extensión crypt5
Más tarde WhatsApp decidió mejorar el algoritmo de cifrado añadiendo el email del usuario y otra
clave distinta, añadiendo nuevos ficheros de copia con la extensión .crypt5.
Alejandro Ramos publicó en Github46
un script en Python con el que fácilmente se puede descifrar
los ficheros msgstore.db.crypt5.
Para descifrar el fichero se ejecuta la siguiente linea
$ python pwncrypt5.py msgstore-db.crypt5 email > msgstore.sdb
El script requiere tener python y la librería python-m2crypto instalada en el sistema.
Usuarios sin ningún tipo de conocimiento técnico tiene disponible la página
www.recovermessages.com creada por los autores del blog SecurityByDefault para la lectura y
recuperación de mensajes de SQLite de distintas aplicaciones tales como WhatsApp, Telegram,
Skype, Twitter o Facebook.
Cualquier aplicación con acceso al almacenamiento externo podría obtener y descifrar47
los
mensajes.
46 Pwncrypt5 de Alejandro Ramos: https://github.com/aramosf/pwncrypt5
47 Steal WhatsApp database: http://bas.bosschert.nl/steal-whatsapp-database/
Figura 18: La página recoverymessages.com permite recuperar los mensajes.
Figura 17: La clave de WhatsApp pronto fue liberada y
publicada en las redes sociales.

24. 6.1.4. Tercer intento: Claves distintas para cada dispositivo.
La última versión de WhatsApp añade la extensión crypt6 y cryp7 a las copias y utiliza una
clave diferente para cada dispositivo. La clave del terminal se puede encontrar en la ruta interna
/data/data/com.whatsapp/files/key.
Esta vez las aplicaciones con acceso al almacenamiento externo no pueden descifrar los
mensajes ya que se supone que la clave es distinta. Sin embargo, si el móvil tiene privilegios de root
es posible obtener la clave desde la memoria interna del dispositivo.
7. Espionaje en los dispositivos móviles
Con el escándalo provocado por el proyecto PRISM48
de la NSA junto con las escuchas
telefónicas por parte del gobierno estadounidense a importantes personalidades como políticos
europeos plantea la necesidad de soluciones cifrado y seguridad en los dispositivos móviles.
Existen soluciones hardware como Cryptophone es un tipo de móvil que proporciona llamadas
cifradas de punto a punto, requiere que los dos móviles soporte el cifrado.
Otras soluciones son aplicaciones software como RedPhone49
para Android, pero que requieren
en todo caso requieren de un servidor intermediario que siempre puede realizar la escucha en claro.
Ante la falta de confianza de terceros, los ingenieros informáticos José Luis Verdeguer
(@pepelux) y Víctor Seva (@linuxmaniac) proponen un sistema propio llamado SecureCall50
sin
telco involucrados ni intervención de terceros mediante comunicación VoIP cifrada.
48 PRISM: http://www.elladodelmal.com/2013/06/prism-fisa-y-el-usa-patriot-act.html
49 RedPhone: https://play.google.com/store/apps/details?id=org.thoughtcrime.redphone&hl=es_419
50 SecureCall: http://securecall.org/
Figura 19: El servidor Relay puede almacenar la información.

25. Para Android necesita una aplicación como CsipSimple51
para la configuración de VoIP.
Sin embargo, los propios autores advierten de que nunca se puede estar seguro de la privacidad
en la comunicación ya que aunque exista un canal cifrado entre emisor-receptor, el servidor
actuando como proxy puede desviar el tráfico de un terminal a otro mediante hacia otro, el Relay.
Este servidor tendía acceso en claro de la comunicación.
8. Conclusiones
El malware en los dispositivos Android se ha cuadriplicado en muy poco tiempo. La razón es
bastante clara, las oportunidades que ofrecen os smartphones debido a su uso, conexión
51 CsipSimple: http://code.google.com/p/csipsimple/
Figura 20: SecureCall parece que ofrece un canal seguro de
comunicación vía VoIP
Figura 21: Captura de la presentación de José Luis Verdeguer y
Víctor Seva en la Rooted 2014

26. prácticamente continua, datos almacenados y la pasividad de los usuarios a la hora de instalar
aplicaciones hacen un pastel bastante apetecible para los desarrolladores de aplicaciones maliciosas.
Por otro lado están las vulnerabilidades tanto del sistema operativo, Master Key no deja de ser
una vuelta de hoja del empaquetado APK basado en el algoritmo zip, tras soluciones por parte del
equipo de desarrollo de Android acaban saliendo a la luz nuevos problemas y los Zero-days se
venden en el mercado negro a muy buen precio52
.
Además, la preocupación por el espionaje de altos cargos políticos 53
hacen plantearse el uso de
terminales incluso en sus vidas privadas, viéndose en la necesidad de alternativas con uso canales
alternativos y comunicaciones cifradas. Sin embargo aún así no se puede estar seguro al cien por
cien cuestionando algoritmos robustos como el de RSA54
y el reciente bug HeartBleed55
descubierto en openssl, el cual estaba presente sin reportar durante más de dos años, pudiendo
comprometer la integridad de cuentas de usuarios y claves privadas.
9. Referencias
• Presentación de Sebastian Guerrero "Ke ase Android?"
http://www.slideshare.net/rootedcon/sebastin-guerrero-ke-ase-android-rooted-con-2013
• Actualidad del Malware en Android: http://www.securitybydefault.com/2013/12/actualidad-
del-malware-en-android-2-de-3.html
• Evolución del malware en Android: http://www.securitybydefault.com/2011/02/evolucion-
del-malware-en-dispositivos.html
• Foro Elotrolado, criptomonendas en Android
http://www.elotrolado.net/noticia_aplicaciones-disponibles-en-google-play-minan-divisas-
digitales-sin-avisar-al-usuario_23833
• ADEL Andrid Data Extraction Lite: http://forensics.spreitzenbarth.de/adel
• Vulnerabilidad Master Key: https://bluebox.com/technical/uncovering-android-master-key-
that-makes-99-of-devices-vulnerable
52 Precios 0-day: http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-
hackers-secret-software-exploits/
53 Espionaje de la NSA: http://www.spiegel.de/international/germany/cover-story-how-nsa-spied-on-merkel-cell-
phone-from-berlin-embassy-a-930205.html
54 Problemas con RSA: http://www.criptored.upm.es/descarga/articuloRSAcumple36.pdf
55 Bug OpenSSL: http://heartbleed.com/
Figura 22: Precios estimados por Forbes de venta de 0-
day en el mercado negro.

27. • Vulnerabilidades reportadas por Symantec: http://www.symantec.com/connect/blogs/first-
malicious-use-master-key-android-vulnerability-discovered
• Android 4.4 KitKay afectada por Master Key:
http://securityaffairs.co/wordpress/19400/hacking/android44-master-key-vulnerability.html
• Blog de SecurityByDefaul: http://www.securitybydefault.com
• Repositorio de Pau Oliva: https://gist.github.com/poliva/
• Blog de Jay Freeman blog http://www.saurik.com/
• Blog de Chema Alonso: http://www.elladodelmal.com
• Blog de Sebastián Guerrero: http://blog.seguesec.com/blog-2/
• Blog de Jaime Sánchez: http://www.seguridadofensiva.com/