Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Aplicaciones para Plataformas
Mó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...........................................................................................
1. Introducción
En esta memoria se describen problemas de seguridad en dispositivos Android así como los
principales malwa...
Destacan en un primer lugar aplicaciones que requieren de acceso root pero que no son maliciosas.
En cambio le siguen, cas...
• Los usuarios almacenan información privada.
• Un usuario casi nunca se cuestiona la integridad y seguridad en su móvil.
...
◦ Dentro de estas aplicaciones, consiguen evadir la seguridad del dispositivo
aprovechando algún tipo de vulnerabilidad o ...
3.1.3. Gemini
Markets de terceros de dudosa reputación que ofrecen aplicaciones del market de google las
mismas aplicacion...
La aplicación antes de ser instalada solicita hasta 24 permisos y realiza además la solicitud de
administrador del disposi...
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 ...
Toda la información del caso de la estafa se puede encontrar el blog de Chema Alonso7
.
3.1.8. Malware minero de criptomon...
Con la capacidad de cálculo de todos los dispositivos con la aplicación instalada se podría alcanzar
una importante suma d...
Por tanto el hash SHA1 debe ser el mismo siempre para la verificación de la firma.
Sin embargo, es posible añadir dos fich...
demostrada por el grupo de seguridad Chino Android Security Squad12
la cual permite engañar la
validación de firmas modifi...
seguridad del dispositivo, el envío de SMS de pago o la instalación de nuevas cargas aplicaciones.
Esto es posible mediant...
4.3. SecureRandom en Android 4.2
A principios de agosto del 2013 se publicó en Bitcoin.org19
un problema en la generación ...
<string name="app_name">My First App</string>
4.5. Otros problemas
4.5.1. Android Data Extraction
No se trata de una vulne...
El módulo del kernel LKM o Loadable Kernel Module permite extender las funcionalidades del
kernel ya que se ejecuta en el ...
◦ Se puede engañar al código para indicar que se usa la misma versión del dispositivo en
la directiva vermagic. El problem...
En concreto, la aplicación Snapchat fue seguramente el mayor problema de datos
comprometidos de ese tipo de aplicaciones c...
En el blog de Chema Alonso43
se pueden encontrar multitud de artículos interesantes sobre los
problemas de seguridad Whats...
346a23652a46392b4d73257c67317e352e3372482177652c
6.1.3. Segundo intento, extensión crypt5
Más tarde WhatsApp decidió mejor...
6.1.4. Tercer intento: Claves distintas para cada dispositivo.
La última versión de WhatsApp añade la extensión crypt6 y c...
Para Android necesita una aplicación como CsipSimple51
para la configuración de VoIP.
Sin embargo, los propios autores adv...
prácticamente continua, datos almacenados y la pasividad de los usuarios a la hora de instalar
aplicaciones hacen un paste...
• Vulnerabilidades reportadas por Symantec: http://www.symantec.com/connect/blogs/first-
malicious-use-master-key-android-...
Seguridad en Android
Upcoming SlideShare
Loading in …5
×

Seguridad en Android

2,257 views

Published on

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

Published in: Technology
  • Login to see the comments

Seguridad en Android

  1. 1. Aplicaciones para Plataformas Móviles Seguridad en Android David Albela Pérez
  2. 2. Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 3.0 España.
  3. 3. 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
  4. 4. 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.
  5. 5. 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.
  6. 6. • 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.
  7. 7. ◦ 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. <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
  18. 18. 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.
  19. 19. ◦ 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
  20. 20. 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
  21. 21. 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
  22. 22. 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.
  23. 23. 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.
  24. 24. 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
  25. 25. 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.
  26. 26. • 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/

×