Aplicaciones para PlataformasMóviles

Seguridad en Android

David Albela Pérez

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

Tabla de Contenidos

1.Introducción.......................................................................................................................................42.Malware en Android..........................................................................................................................4

2.1.Motivaciones..............................................................................................................................52.2.Múltiples capas de defensa........................................................................................................62.3.Consejos para un entorno seguro...............................................................................................7

2.3.1.La realidad de Sandbox......................................................................................................73.Aplicaciones malware conocidas.......................................................................................................7

3.1.1.Tap Snake...........................................................................................................................73.1.2.Fake Player.........................................................................................................................73.1.3.Gemini................................................................................................................................83.1.4.Droid Kungfu.....................................................................................................................83.1.5.Obad...................................................................................................................................83.1.6.AndroRAT..........................................................................................................................93.1.7.Linterna Led.....................................................................................................................103.1.8.Malware minero de criptomonedas..................................................................................11

4.Vulnerabilidades en Android...........................................................................................................124.1.Master Key...............................................................................................................................124.2.Tapjacking................................................................................................................................14

4.2.1.Phising con TapJacking....................................................................................................154.3.SecureRandom en Android 4.2................................................................................................164.4.OS Memory Corruption...........................................................................................................164.5.Otros problemas.......................................................................................................................16

4.5.1.Android Data Extraction..................................................................................................164.5.2.Orden de las suites criptográficas....................................................................................17

5.Rootkit para Android.......................................................................................................................175.1.Pasos para la creación del rootkit............................................................................................18

6.Seguridad en aplicaciones de Mensajería........................................................................................196.1.WhatsApp y AES Key: Jugando al gato y el ratón..................................................................21

6.1.1.Mensajes de WhatsApp sin cifrar....................................................................................216.1.2.Primer intento, mensajes cifrados AES-192-ECB...........................................................216.1.3.Segundo intento, extensión crypt5...................................................................................216.1.4.Tercer intento: Claves distintas para cada dispositivo.....................................................22

7.Espionaje en los dispositivos móviles.............................................................................................228.Conclusiones....................................................................................................................................249.Referencias......................................................................................................................................25

1. Introducción

En esta memoria se describen problemas de seguridad en dispositivos Android así como losprincipales malware reportados de Google Play u otras fuente.

En primer lugar se analiza la actualidad del malware en Android, cuales son las motivaciones parasu creación y su uso.

A continuación se describen las aplicaciones malware más destacables y su evolución en el sistemaoperativo. Además se describen las vulnerabilidades para Android más conocidas y como se podríancrear Rootkits para tener el control total del dispositivo.

Finalmente se abordan los problemas de la privacidad existentes en las aplicaciones, en concreto enlas aplicaciones de mensajería y se comentan los problemas de espionaje bajo los que losdispositivos móviles son el principal objetivo.

2. Malware en Android

Desde el año 2011 el malware en dispositivos Android se ha visto incrementadosignificativamente. En parte gracias al uso cada vez mayor de esta plataforma y la laxitud por partedel 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 enAndroid, Adrian Ludwig1, “Android, practical security from the ground up” donde se detallan lasaplicaciones 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.

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 phisingy 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 yterceras compañías donde se plantea hasta que punto son realmente peligrosas todas las aplicacionesdefinidas 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 ainternet, 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 seregistraron más de 500 millones de dispositivos Android.

• Hoy en día un smartphone tiene la capacidad de procesamiento equivalente al de unordenador de hace unos años.

• Además, la mayoría está conectado a internet la mayor parte del tiempo (3G/Wifi) y songeolocalizables.

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 de2013.

• 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ígenesdesconocidos.

• Las aplicaciones de fuentes desconocidas envían mensajes de advertencia al usuario antes deser 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.

◦ 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 endispositivos 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 enejecució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 permisosde acceso a las coordenadas GPS: android.permission.ACCESS_COARSE_LOCATION yandroid.permission.ACCESS_FINE_LOCATION.

3.1.2. Fake Player

Malware creado en agosto del 2010 que pretendía ser un reproductor multimedia. Entre suspermisos estaban android.permission.SEND_SMS teniendo como objetivo el envío de mensajes enRuso SMS a números de tarificación especial a países como Kazajistán.

3.1.3. Gemini

Markets de terceros de dudosa reputación que ofrecen aplicaciones del market de google lasmismas aplicaciones gratuitas.

Se trata de una aplicación procedente de China que a partir de aplicaciones legítimas modificanel 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 enAndroidManifest.xml:

CALL_PHONE: Realizar llamadas de teléfono sin necesidad de que el usuario de permisoexplí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 eneste 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 elanálisis de los antivirus.

Los usuarios no suelen ser conscientes del problema que implica añadir un Market alternativo ola 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 2011permití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 mensajesSMS sin notificar al usuario, iniciar llamadas de teléfono o realizar la instalación de exploitsremotamente a través de un canal seguro para ocultarse de la lista de aplicaciones en eladministrador. El fichero .dex está cifrado y ofuscado para dificultar la detección de los antivirus.

La aplicación antes de ser instalada solicita hasta 24 permisos y realiza además la solicitud deadministrador del dispositivo.

Además usaba un protector comercial de código para prevenir el proceso de decompilación. Entruco consistía en añadir una instrucciones Goto en el medio de un bloque if con el fin de confundiral 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 3pará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 vezque un usuario establece la aplicación como administrador de dispositivos, obtiene permiso parabloquear la pantalla y ocultase con éxito de la lista de administradores de dispositivos, explotandoasí 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 herramientacliente 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 vibrarel teléfono.

La aplicación se puede ejecutar como un servicio y se inicia en el arranque. La conexión con elservidor 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ódigomalware de Obad escrito en C.

La aplicación se puede encontrar en páginas .onion de la Tor5. Si bien es difícil que alguien lainstale 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óvilcomo 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. Peroningún permiso para enviar SMS o realizar llamadas.

Sin embargo, la aplicación al ejecutarse se conectaba a internet para darse de alta en serviciosde mensajería de pago por SMS usando el número del dispositivo. El servicio de mensajería enviabaun SMS con un PIN al teléfono para solicitar la confirmación de alta en el servicio y la aplicaciónde 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 lacuenta de usuario en Facebook recomendado dicha aplicación.

La aplicación estaba ofuscada utilizando la herramienta Proguard6. A finales de 2013 tenía entre10.000 y 50.000 descargas. Tras ser retirada de Google Play, aún podía ser descargada de otrosmarkets.

5 Tor: https://www.torproject.org6 Ofuscador Proguard: http:// proguard.sourceforge.net

Figura 5: AndroRAT incluye una aplicación de escritoriopara controlar el dispositivo.

Figura 6: Linterna Led se instaló en al menos 10.000 terminales.

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 demalware 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 determinadosusuarios (gpu174v6, gpu174v7, cpu174v6, cpu174v7, etc) tenían una capacidad de cálculodemasiado 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 deGoogle Play utilizaban los recursos de los dispositivos móviles para minar monedas digitales talescomo Litecoin o Dogecoin.

En la siguiente imagen se muestra código desensamblado, la clase MiningService.class contiene losparámetros de configuración del software de minado cpuminer para cálculo con CPU adaptado paraprocesadores ARM.

7 Linterna Led: http://www.elladodelmal.com/2014/01/la-estafa-de-la-linterna-molona-que.html8 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 queminaba criptomonedas.

Con la capacidad de cálculo de todos los dispositivos con la aplicación instalada se podría alcanzaruna importante suma de monedas digitales que podrían llegar a alcanzar un valor desde cientos amiles 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 Androida 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 defirma 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 ainvalidar la verificación de la firma digital. Es como tener una “llave maestra” para desbloquear elacceso 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 paqueteAPK, entre ellos el classes.dex. Los ficheros classes.dex contienen el Bytecode de la aplicación y sieste 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.

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ónmodificada.

En la imagen, se puede ver el contenido de un paquete APK con dos ficheros classes.dex yAndroidManifest.xml, el original servirá para validar la aplicación y el segundo se trata de laversión modificada que será instalada en el dispositivo.

Aunque el archivo AndroidManifest.xml, el cual indica los permisos y limitaciones de laaplicación indicadas por el desarrollador, en este caso solo funcionaría volviendo a firmar laaplicació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 convarios ficheros.

El bug publicado con el identificador 8219321 ha sido solucionado en las mayoría dedispositivos, 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 detodos los ficheros del paquete APK.

Figura 11: Paquete APK con ficherosduplicados para aprovechar la

vulnerabilidad Master Key.

demostrada por el grupo de seguridad Chino Android Security Squad12 la cual permite engañar lavalidación de firmas modificando la cabecera de los APK. Para ello se resta la posición delclasses.dex original y se extiende longitud del campo extra field a 0xFFFD, 64k que es el tamañomá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 puedehacer que la firma sea validada con el fichero classes.dex original e instalar realmente elmodificado. De todos modos, solo puede ser reemplazado el fichero classes.dex y solo si el originales menor de 64k, tamaño máximo de la cabecera extra field. Además, es necesario realizar lareconstrucción del APK modificando la cabecera.

El experto en seguridad Jay Freeman13, también conocido como Saurik, demostró una pruebade concepto para una tercera variante que podría ser explotada incluso en la última versión deAndroid 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 (requiereprivilegios 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.html13 Artículos Master Key de Jay Freeman: http://www.saurik.com/id/18 y http://www.saurik.com/id/1914 Bug Master Key 9950697: https://code.google.com/p/android/issues/detail?id=5785115 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 sermodificadas para engañar al sistema de verificación.

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ánGuerrero17 (0xroot).

4.2.1. Phising con TapJacking

A finales de marzo de 2014 se publicó en la FireEye18 un problema de aplicaciones en Backgroundque con permisos normales podría llegar a hacer que una aplicación maliciosa puede modificar losiconos 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-Android18 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 alusuario utilizando Toast a pantalla completa.

4.3. SecureRandom en Android 4.2

A principios de agosto del 2013 se publicó en Bitcoin.org19 un problema en la generación denúmeros aleatorios en versiones de Android 4.2 que permitía desde cualquier dispositivo repetiruna secuencia de números. Cualquier usuario que generase una cartera con la aplicación de Bitcoinpara Android (clave pública/privada) en la versión vulnerable de Android podría ser duplicada yrobada por terceros.

Tal como se recomienda en el artículo de Bitcoin.org, es necesario añadir una semilla a lainicializació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 nombrede la aplicación 387000 caracteres de longitud. El nombre se indica en el atributo android:label dela 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 laaplicación, sino que además el autor que descubrió el bug, Ibrahim Balic20, al subir la aplicación conel 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 describecomponentes, 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-android20 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 laaplicación con el bug.

<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 relevantedel usuario.

La herramienta ADEL21 de Michael Spreitzenbarth es un conjunto de scripts en Python quepermiten extraer la información de un dispositivo conectado por USB y generar un informe enXML.

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 de3)22, el orden de preferencia del uso de suites criptográficas para establecer la comunicación SSLcon 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 quealgoritmos de cifrado y función hash se van a utilizar. Mientras que en las versiones de Android2.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 sistemacon privilegios de root para disponer del control total del dispositivo. Un rootkit instalado en undispositivo 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ándosela 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.html23 RootedCon: www.rootedcon.es24 Charla de Sebastián Guerrero en la RootedCon de 2013: http://vimeo.com/6825260125 LKM Module: http://en.wikipedia.org/wiki/Loadable_kernel_module

El módulo del kernel LKM o Loadable Kernel Module permite extender las funcionalidades delkernel ya que se ejecuta en el espacio del kernel, pudiendo añadir y modificar piezas de códigosin necesidad de recompilar o reiniciar.

Para crear el rootkit y tener acceso a LKM es necesario acceder a las llamadas del sistema, lascuales se hacen uso de los punteros de funciones accesibles desde el fichero /proc/kallsyms. En lasiguiente captura, parte de la presentación de Sebastián Guerrero, se muestra la estructura de latabla de llamadas al sistema.

Para modificar el código de las aplicaciones instaladas en el dispositivo es necesario crear unallamada 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 tengaprivilegios para modificar el código, gracias al módulo de LKM. se puede llegar a tener un controltotal 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 delrootkit 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 sistemase apunte hacia el hook para que este se ejecute en lugar de

las funciones originales.

◦ 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 delkernel de la arquitectura del dispositivo (ARMv5 y ARMv7 tienen versiones distintas delkernel 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 elscript 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 laconocida 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 Emeterio 35

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 sercurioso 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/dexterity27 Dex2Jar: http://code.google.com/p/dex2jar28 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/jadx32 Radare2 (o R2): https://github.com/radare/radare233 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

En concreto, la aplicación Snapchat fue seguramente el mayor problema de datoscomprometidos de ese tipo de aplicaciones con 4,6 millones de usuarios expuestos36 con susnúmeros de teléfono y mensajes. El problema venía dado por el tiempo de validez de parámetroreq_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 delas 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 noimprimibles42.

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-HF4gKg38 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.html40 Yowsup: https://github.com/tgalal/yowsup41 Como espiar WhatsApp: http://www.elladodelmal.com/2013/07/como-espiar-whatsapp.html42 WhatsApp Remote Crash: https://github.com/segofensiva/WhatsAppRemoteCrash

En el blog de Chema Alonso43 se pueden encontrar multitud de artículos interesantes sobre losproblemas 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 elalmacenamiento externo del terminal automáticamente, permitiendo que cualquiera con accesopueda 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 sololeer 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 leerlos datos de un SQLite aún incluso después de haber sido borrados de la base de datos, ya que estosse 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 muyinteresante 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 deJaime Sánchez cuelga la aplicación en iOS

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 otraclave 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 descifrarlos 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áginawww.recovermessages.com creada por los autores del blog SecurityByDefault para la lectura yrecuperació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 losmensajes.

46 Pwncrypt5 de Alejandro Ramos: https://github.com/aramosf/pwncrypt547 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 ypublicada en las redes sociales.

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 unaclave 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 losmensajes ya que se supone que la clave es distinta. Sin embargo, si el móvil tiene privilegios de rootes 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 escuchastelefónicas por parte del gobierno estadounidense a importantes personalidades como políticoseuropeos 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 llamadascifradas de punto a punto, requiere que los dos móviles soporte el cifrado.

Otras soluciones son aplicaciones software como RedPhone49 para Android, pero que requierenen 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 sintelco 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.html49 RedPhone: https://play.google.com/store/apps/details?id=org.thoughtcrime.redphone&hl=es_41950 SecureCall: http://securecall.org/

Figura 19: El servidor Relay puede almacenar la información.

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 privacidaden la comunicación ya que aunque exista un canal cifrado entre emisor-receptor, el servidoractuando 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 decomunicación vía VoIP

Figura 21: Captura de la presentación de José Luis Verdeguer yVíctor Seva en la Rooted 2014

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 53hacen plantearse el uso determinales 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 Androidhttp://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.pdf55 Bug OpenSSL: http://heartbleed.com/

Figura 22: Precios estimados por Forbes de venta de 0-day en el mercado negro.

• 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/