SlideShare una empresa de Scribd logo

Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.

•
•
Internet Security Auditors
Internet Security Auditors

Este documento presenta una introducción a la ingeniería inversa en Android. Cubre temas como el análisis estático y dinámico de aplicaciones Android, la arquitectura de Android incluyendo la máquina virtual Dalvik y el formato de archivo APK, y herramientas como Apktool y Dex2Jar que son útiles para la ingeniería inversa de aplicaciones Android.

Tecnología
1 de 237
Descargar para leer sin conexión
Ingeniería Inversa en Android Sebastián Guerrero sguerrero@isecauditors.com
Agenda 1. Introducción a la plataforma. 2. Análisis estático. 3. Análisis dinámico. 4. Análisis forense. 5. Desarrollando un malware. 2
¿Qué es Android? • Android es un conjunto de aplicaciones para dispositivos móviles. Entre las que se incluyen un sistema operativo, aplicaciones nativas y aplicaciones de terceros. • El SDK de Android provee de las herramientas y las APIs necesarias para comenzar a desarrollar aplicaciones para la plataforma utilizando el lenguaje de programación Java.
Características • Framework de aplicaciones – Permite la reutilización de los componentes. • Máquina virtual de Dalvik – Optimizada para dispositivos móviles. • Navegador integrado – Basado en el motor de código libre WebKit. • Sqlite – Para almacenamiento estructurado de datos. • Soporte multimedia – audio, vídeo, imágenes (MPEG4, H.264, Mp3, AAC, AMR, JPG, PNG, GIF) • Telefonía GSM – Dependiente del hardware. • Bluetooth, EDGE, 3g, Wifi – Dependiente del hardware. • Cámara, GPS, brújula y acelerómetro – Dependiente del hardware. • Rico entorno de desarrollo – Emulador, herramientas de debugging, plugin para Eclipse, etc.
Arquitectura • La arquitectura de la plataforma se divide en cinco niveles distintos.
Arquitectura • Nivel 1 - Aplicaciones – Plataforma Android viene con un conjunto de aplicaciones por defecto instaladas en su núcleo (Cliente email, SMS, Calendario, Maps, Navegador, etc…). - Es el servicio mínimo que la plataforma nos puede ofrecer. - Es posible arrancar el teléfono en un entorno limpio y seguro. - Nivel 2 – Framework Aplicaciones – Acceso completo a las APIs de las aplicaciones base. – Arquitectura basada en la reutilización de componentes. – Cualquier aplicación puede hacer pública sus características. – Cualquier aplicación puede aprovechar las características de otra aplicación. – Los componentes pueden ser reemplazados por los usuarios - Nivel 3 – Bibliotecas – Conjunto de bibliotecas en C/C++ utilizadas por componentes del sistema. – Se exponen a los desarrolladores a través del framework de aplicaciones. – Bibliotecas de medios, bibliotecas de gráficos, 3D, SQLite, etc… - Nivel 4 – Runtime de Android – Compartido entre las librerías del núcleo y la máquina virtual de Dalvik. – Set de bibliotecas. – Funcionalidades incluidas en la biblioteca de Java. – Una instancia Dalvik por cada Aplicación. – Ejecución de ficheros .dex. • Nivel 5 – Kernel – Núcleo en el que se basa el sistema. – Evolucionando a través de varias versiones. – Incluye mejoras en la seguridad, administración de energía, drivers para distintos componentes hardware. – Su finalidad es ejercer como capa de abstracción entre el hardware y el resto de capas.
Dalvik Virtual Machine • Su arquitectura está basada en registros. • Utiliza una herramienta llamada dx para convertir algunos ficheros .class en ficheros .dex • Realiza diversas optimizaciones a la hora de transformar los ficheros a .dex – Llamadas a métodos virtuales , reemplaza el índice del método por un índice de vtable. – Reemplaza llamadas a métodos como string.length() por métodos inline. – Elimina métodos vacíos – Añade datos precalculados.
Dalvik Virtual Machine • Realiza optimización en el uso y asignación de memoria. – Tiene dividida la memoria en 4 regiones • Clean/Dirty • Shared/Private – La información en la zona llamada Clean y que es compartida de forma pública o privada contiene las librerías y los ficheros de las aplicaciones. – Por otro lado en la zona de memoria Dirty lo que encontramos son la pila, montículos y estructuras de datos de control que necesitan los ficheros .dex. • En el núcleo está el Zygote (Cigoto) que es el padre encargado de arrancar todas las máquinas virtuales Dalvik que haya en el sistema. – Carga e inicializa todas las clases utilizadas con mayor frecuencia por las aplicaciones. – Fomenta el intercambio rápido de código entre las aplicaciones. • Recolector de basura que se ejecuta en cada máquina virtual recolectando la basura que queda tras ejecutar una aplicación.
Dalvik Virtual Machine • Arquitectura basada en registros – Requieren un promedio de 48% menos de instrucciones ejecutadas, en comparación a las Mvs basadas en pila. – El código generado es un 25% mayor, pero supone una carga del 1.07% superior para el sistema. – Tardan un promedio del 32% menos en ejecutar los benchmarks. • Google toma esta decisión en base a: – Al almacenar las instrucciones en un procesador segmentado, la sobrecarga viene dada por el tiempo que tarda en enviar las instrucciones y reducir el número de estas ejecutadas. – La verificación de los bytecodes que integran la máquina virtual es más rápida en máquinas basadas en registros.
Principios fundamentales • Las aplicaciones de Android son escritas en el lenguaje de programación Java. • El SDK de Android es el encargado de compilar el código en un paquete con el sufijo .apk. • Los ficheros apk son considerados como aplicaciones que se instalan en los terminales. • Una vez instalado cada aplicación se ejecuta en su propia SandBox – Sistema multiusuario, cada aplicación pertenece a un usuario. – Cada aplicación tiene asignado un UID único. – Los ficheros de las aplicaciones tienen asignados unos permisos. – Solo el usuario cuyo UID esté asociado con una aplicación puede acceder a los ficheros de esta. – Cada aplicación se ejecuta en una instancia de Dalvik. – Se fomenta la independencia entre procesos y aplicaciones. • Es posible compartir información entre aplicaciones: – Pueden compartir el mismo UID, permitiendo acceder a los ficheros de ambas entre ellas. – Una aplicación puede solicitar permiso para acceder a la información de los dispositivos. – El usuario debe conceder tales permisos en tiempo de instalación.
Anatomía de las aplicaciones • Los componentes que integran las aplicaciones son el principal núcleo de las mismas. • Hay un total de 4 componentes distintos. Donde cada uno posee un propósito distinto y tiene un ciclo de vida de creación y destrucción. – Actividades • Representa una pantalla con una interfaz de usuario – Servicios • Componentes que se ejecutan en segundo plano realizando tareas que requieren un tiempo largo de ejecución. • También pueden servir para procesar información de forma remota. – Proveedores de contenido • Manejan conjuntos de datos de las aplicaciones. • Podemos almacenar los datos en cualquier sitio que sea requerido posteriormente por nuestra aplicación. – Receptores de broadcast • Responden a mensajes de difusión en todo el sistema
Ficheros APK • Usado para empacar las aplicaciones • Todo APK incluye: • classes.dex • resources.asc • /res • /META-INF • AndroidManifest.xml
Formato de fichero DEX
AndroidManifest • Todas las aplicaciones necesitan tener un fichero XML en el directorio raíz. • Es utilizado para obtener información sobre la administración y organización de la aplicación. • Existen 23 tipos predefinidos de elementos que permiten especificar y amoldar las características de la aplicación. • Todos los componentes que van a ser utilizados por la aplicación deben ser declarados aquí. • El AndroidManifest realiza otra serie de acciones adicionales – Identifica cualquier permiso que requiera la aplicación. – Declara el nivel mínimo de API que requiere la aplicación para funcionar. – Declara las características de hardware/software que va a utilizar la aplicación. – Librerías de la API que la aplicación necesita enlazar para ser utilizadas.
Declarando los componentes • La primera tarea del AndroidManifest es informar al sistema de los componentes que integran la aplicación. • Debemos declararlos de la siguiente manera – <activity> para las actividades. – <service> para los servicios. – <receiver> para los receptores de broadcast. – <provider> para los proveedores de contenido.
Permisos en Android • ACCESS_CHECKIN_PROPERTIES • ACCESS_COARSE_LOCATION • ACCESS_FINE_LOCATION • ACCESS_LOCATION_EXTRA_COMMANDS • ACCESS_MOCK_LOCATION • ACCESS_NETWORK_STATE • ACCESS_SURFACE_FLINGER • ACCESS_WIFI_STATE • ACCOUNT_MANAGER • ADD_VOICEMAIL • AUTHENTICATE_ACCOUNTS • BATTERY_STATS • BIND_APPWIDGET • BIND_DEVICE_ADMIN • BIND_INPUT_METHOD • BIND_REMOTEVIEWS • BIND_TEXT_SERVICE • BIND_VPN_SERVICE • BIND_WALLPAPER • BLUETOOTH • BLUETOOTH_ADMIN • BRICK • BROADCAST_PACKAGE_REMOVED • BROADCAST_SMS • BROADCAST_STICKY • BROADCAST_WAP_PUSH • CALL_PHONE CALL_PRIVILEGED CAMERA CHANGE_COMPONENT_ENABLED_STATE CHANGE_CONFIGURATION CHANGE_NETWORK_STATE CHANGE_WIFI_MULTICAST_STATE CHANGE_WIFI_STATE CLEAR_APP_CACHE CLEAR_APP_USER_DATA CONTROL_LOCATION_UPDATES DELETE_CACHE_FILES DELETE_PACKAGES DEVICE_POWER DIAGNOSTIC DISABLE_KEYGUARD DUMP EXPAND_STATUS_BAR FACTORY_TEST FLASHLIGHT FORCE_BACK GET_ACCOUNTS GET_PACKAGE_SIZE GET_TASKS GLOBAL_SEARCH HARDWARE_TEST INJECT_EVENTS INSTALL_LOCATION_PROVIDER INSTALL_PACKAGES INTERNAL_SYSTEM_WINDOW INTERNET KILL_BACKGROUND_PROCESSES MANAGE_ACCOUNTS MANAGE_APP_TOKENS MASTER_CLEAR MODIFY_AUDIO_SETTINGS MODIFY_PHONE_STATE MOUNT_FORMAT_FILESYSTEMS MOUNT_UNMOUNT_FILESYSTEMS NFC PERSISTENT_ACTIVITY PROCESS_OUTGOING_CALLS READ_CALENDAR READ_CONTACTS READ_FRAME_BUFFER READ_HISTORY_BOOKMARKS READ_INPUT_STATE READ_LOGS READ_PHONE_STATE READ_PROFILE READ_SMS READ_SOCIAL_STREAM READ_SYNC_SETTINGS READ_SYNC_STATS REBOOT RECEIVE_BOOT_COMPLETED RECEIVE_MMS RECEIVE_SMS RECEIVE_WAP_PUSH RECORD_AUDIO REORDER_TASKS RESTART_PACKAGES SEND_SMS SET_ACTIVITY_WATCHER SET_ALARM SET_ALWAYS_FINISH SET_ANIMATION_SCALE SET_DEBUG_APP SET_ORIENTATION SET_POINTER_SPEED SET_PREFERRED_APPLICATIONS SET_PROCESS_LIMIT SET_TIME SET_TIME_ZONE SET_WALLPAPER SET_WALLPAPER_HINTS SIGNAL_PERSISTENT_PROCESSES STATUS_BAR SUBSCRIBED_FEEDS_READ SUBSCRIBED_FEEDS_WRITE SYSTEM_ALERT_WINDOW UPDATE_DEVICE_STATS USE_CREDENTIALS USE_SIP VIBRATE WAKE_LOCK WRITE_APN_SETTINGS WRITE_CALENDAR WRITE_CONTACTS WRITE_EXTERNAL_STORAGE WRITE_GSERVICES WRITE_HISTORY_BOOKMARKS WRITE_PROFILE WRITE_SECURE_SETTINGS WRITE_SETTINGS WRITE_SMS WRITE_SOCIAL_STREAM WRITE_SYNC_SETTINGS
Montando un laboratorio • Podemos hacerlo de dos maneras posibles – Máquina virtual A.R.E. (Android Reverse Engineering) • Creada por Honeynet Project • Combina las últimas herramientas de Android para analizar malware en una única caja de herramientas • Listado de aplicaciones – AndroGuard, Android sdk/ndk, APKInspector, Apktool, Axmlprinter, Ded, Dex2Jar, Droidbox, Jad, Smali/BakSmali. – Instalar las aplicaciones que necesitemos y construirnos nuestro entorno de trabajo de forma manual. • Cada una presenta sus propias ventajas y desventajas.
Apktool • ¿Qué es? – Herramienta para hacer reversing en aplicaciones de terceros. – Permite obtener los recursos originales y empaquetarlos nuevamente tras realizarles modificaciones. – Permite realizar debug de código smali paso a paso. • ¿Cómo se instala? – Linux 1. Descargar fichero apktool-install-linux-* 2. Descargar fichero apktool-* 3. Chown +R $USER:$USER sobre cada fichero. 4. Chmod +x sobre cada fichero. 5. Descomprimimos ambos ficheros sobre el directorio /usr/local/bin (Permisos de root necesarios). • ¿Qué son los ficheros de framework? – En ocasiones ciertas aplicaciones hacen uso de código y recursos almacenados e integrados en el sistema Android que ejecuta la aplicación. – Cuando se trata de frameworks especiales, es necesario traérnoslo desde el teléfono e instalarlo en apktool. • ¿Dónde están? – /system/framework o /data/system-framework (Depende del terminal) – Nombrados como resources, res, framework, etc.
Apktool • Uso – Para desensamblar una aplicación • d[edoce] [OPTS] <file.apk> [<dir>] – Desensambla la aplicación file.apk en el directorio dir. – -s, --no-src – No desensambla los fuentes. – -r, --no-res – No desensambla los recursos. – -d, --debug – Desensambla en modo debug. – -f. –force – Fuerza a eliminar el directorio de destino si existe. – -t <tag>, --frame-tag<tag> - Utiliza los ficheros framework etiquetados por <tag>. – --keep-broken-res – Se utiliza cuando obtenemos algún error con los recursos de una aplicación, pero queremos seguir igualmente con el proceso. – Para ensamblar una aplicación • b[uild] [OPTS] [<app_path>] [<out_files>] – Ensambla una aplicación de los fuentes que encuentr en <app_path>. Si se omite alguno de los dos directorios tomará el de por defecto. – -f, --force-all – Salta la detección de cambios en los ficheros y ensambla todos los ficheros. – -d, --debug – Ensambla en modo debug. – Para comprobar si tenemos un framework instalado o instalarlo en nuestro sistema • If|install-framework <framework.apk> [<tag>] - Instala el framework especificado en el sistema.
Ejemplo en funcionamiento • Utilizando la aplicación framework-res.apk vamos a ejemplificar el uso de esta herramienta. 1. Desensamblamos la aplicación 1. $ apktool d framework-res.apk out I: Loading resource table... I: Loaded. I: Decoding file-resources... I: Decoding values*/* XMLs... I: Done. I: Copying assets and libs... 2. Revisamos el nuevo directorio cambiado. 1. $ ls -la total 112 drwxr-xr-x 4 sebas sebas 4096 2012-01-14 18:52 . drwxr-xr-x 4 sebas sebas 4096 2012-01-14 18:52 .. -rw-r--r-- 1 sebas sebas 46533 2012-01-14 18:52 AndroidManifest.xml -rw-r--r-- 1 sebas sebas 67 2012-01-14 18:52 apktool.yml drwxr-xr-x 5 sebas sebas 4096 2012-01-14 18:52 assets drwxr-xr-x 182 sebas sebas 32768 2012-01-14 18:52 res 1. Ensamblamos de nuevo la aplicación. 1. $ apktool b out Tool W: Could not find sources I: Checking whether resources has changed... |: Building resources... I: Building apk file... 1. Resultado de cómo ha quedado la aplicación 1. $ ls framework-res.apk out Tool
Dex2JAR • Permite convertir el formato de ficheros .dex para Android al fomarto .class de Java. • Se compone de cuatro componentes principalmente – Dex-reader – Permite leer ficheros .dex/.odex (Ejecutables Dalvik). – Dex-translator – Realiza el trabajo de conversión. Lee las instrucciones dex, realiza procesos de optimización y finalmente realiza la conversión a ASM. – Dex-ir – Utilizado por el dex-translator, se encarga de representar las instrucciones dex. – Dex-tools – Herramientas para trabajar con los ficheros.class. • El proceso para poder obtener el código fuente es el siguiente: 1. Código fuente original (fichero .java tradicional) public String getInitParameter(String name) { ServletConfig sc = getServletConfig(); if (sc == null) { throw new IllegalStateException( lStrings.getString("err.servlet_config_not_initialized")); } return sc.getInitParameter(name); }
Dex2JAR 2. Compilación utilizando javac (fichero .class) 0 aload_0 1 invokevirtual #2 <javax/servlet/GenericServlet.getServletConfig> 4 astore_2 5 aload_2 6 ifnonnull 25 (+19) 9 new #3 <java/lang/IllegalStateException> 12 dup 13 getstatic #4 <javax/servlet/GenericServlet.lStrings> 16 ldc #5 <err.servlet_config_not_initialized> 18 invokevirtual #6 <java/util/ResourceBundle.getString> 21 invokespecial #7 <java/lang/IllegalStateException.<init>> 24 athrow 25 aload_2 26 aload_1 27 invokeinterface #8 <javax/servlet/ServletConfig.getInitParameter> count 2 32 areturn
Dex2JAR 3. Traducción utilizando dexdump (dx) 022644: |[022644] javax.servlet.GenericServlet.getInitParameter:(Ljava/lang/String;)Ljava/lang/String; 022654: 6e10 d703 0400 |0000: invoke-virtual {v4}, Ljavax/servlet/GenericServlet;.getServletConfig:()Ljavax/servlet/ServletConfig; // method@03d7 02265a: 0c00 |0003: move-result-object v0 02265c: 3900 1000 |0004: if-nez v0, 0014 // +0010 022660: 2201 7800 |0006: new-instance v1, Ljava/lang/IllegalStateException; // class@0078 022664: 6202 2f00 |0008: sget-object v2, Ljavax/servlet/GenericServlet;.lStrings:Ljava/util/ResourceBundle; // field@002f 022668: 1a03 2914 |000a: const-string v3, "err.servlet_config_not_initialized" // string@1429 02266c: 6e20 5103 3200 |000c: invoke-virtual {v2, v3}, Ljava/util/ResourceBundle;.getString:(Ljava/lang/String;)Ljava/lang/String; // method@0351 022672: 0c02 |000f: move-result-object v2 022674: 7020 3b01 2100 |0010: invoke-direct {v1, v2}, Ljava/lang/IllegalStateException;.<init>:(Ljava/lang/String;)V // method@013b 02267a: 2701 |0013: throw v1 02267c: 7220 e703 5000 |0014: invoke-interface {v0, v5}, Ljavax/servlet/ServletConfig;.getInitParameter:(Ljava/lang/String;)Ljava/lang/String; // method@03e7 022682: 0c01 |0017: move-result-object v1 022684: 1101 |0018: return-object v1
Dex2JAR 4. Traducción por dex2jar (Al fichero .class nuevamente) 0 aload_0 1 invokevirtual #49 <javax/servlet/GenericServlet.getServletConfig> 4 astore_2 5 aload_2 6 ifnonnull 27 (+21) 9 getstatic #37 <javax/servlet/GenericServlet.lStrings> 12 ldc #51 <err.servlet_config_not_initialized> 14 invokevirtual #56 <java/util/ResourceBundle.getString> 17 astore_3 18 new #58 <java/lang/IllegalStateException> 21 dup 22 aload_3 23 invokespecial #61 <java/lang/IllegalStateException.<init>> 26 athrow 27 aload_2 28 aload_1 29 invokeinterface #63 <javax/servlet/ServletConfig.getInitParameter> count 2 34 areturn
Dex2JAR 5. Traducción utilizando jd-gui public String getInitParameter(String paramString) { ServletConfig localServletConfig = getServletConfig(); if (localServletConfig == null) { String str = lStrings.getString("err.servlet_config_not_initialized"); throw new IllegalStateException(str); } return localServletConfig.getInitParameter(paramString); }
Dex2JAR • Para instalar la aplicación – Unzip –x dexjar-version.zip –z <path_usuario> • Uso – La aplicación está integrada por un conjunto de herramientas d2j-verify-asm, d2j-dex2jar, d2j-dex-asmifier, d2j-dex- dump, d2j-jar2dex, d2j-jar2jasmin, dex2jar, dex-dump. $./dex2jar.sh ../classes.dex dex2jar version: reader-1.7, translator-0.0.9.6, ir-1.4 dex2jar ../classes.dex -> ../classes_dex2jar.jar Done. • ¿Cómo puedo modificar una aplicación con DexTool? – Es necesario tener instalado Android-sdk, ant, dex2jar, jdk6 – android create project --name test_apk --path test_apk --package a.b --activity Main --target 1 – Esto nos creará un “Hola mundo” básico. – cd test_apk ant debug cd bin – Instalamos la aplicación en el emulador.
Trabajando con DexTools • Antes de editar el código necesitamos transformarlo a Jasmin 1. Convertimos el fichero clases.dex de la aplicación test_apk-debug.apk a test_apk-debug_dex2jar.jar d2j-dex2jar.sh test_apk-debug.apk 2. Comprobamos que el fichero .jar está correcto d2j-asm-verify.sh test_apk-debug_dex2jar.jar 3. Realizamos la conversión al formato jasmin d2j-jar2jasmin.sh -f -o test_apk_jasmin test_apk-debug_dex2jar.jar 4. Editamos el fichero “test_apk_jasmin/a/b/Main.j” para que muestre un toast. .method public onCreate(Landroid/os/Bundle;)V aload 0 aload 1 invokespecial android/app/Activity/onCreate(Landroid/os/Bundle;)V aload 0 ldc_w 2130837504 invokevirtual a/b/Main/setContentView(I)V aload 0 invokevirtual android/app/Activity/getApplicationContext()Landroid/content/Context; ldc "hi" ldc_w 1 invokestatic android/widget/Toast/makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast; invokevirtual android/widget/Toast/show()V return .limit locals 2 .limit stack 3 .end method
Trabajando con DexTools • Ensamblamos nuevamente el APK 1. Construimos el jar d2j-jasmin2jar.sh -f -o test_apk_jasmin.jar test_apk_jasmin/ 2. Verificamos que ha sido bien construido d2j-asm-verify.sh test_apk_jasmin.jar 3. Realizamos la conversión a .dex d2j-jar2dex.sh -f -o classes.dex test_apk_jasmin.jar 4. Hacemos una copia de respaldo cp test_apk-debug.apk test_apk-debug-toast.apk 5. Reemplazamos el fichero classes.dex de la aplicación test_apk-debug-toast.apk zip -r test_apk-debug-toast.apk classes.dex 6. Eliminamos el fichero META-INF de test_apk-debug-toast.apk zip -d test_apk-debug-toast.apk "META-INF*“ 7. Generamos un key para debugging keytool -genkeypair -alias androiddebugkey -keyalg RSA -keysize 2048 -dname "CN=android-debug" -validity 100000 - keystore .ks -storepass android -keypass Android 8. Firmamos el apk jarsigner -keystore .ks -storepass android -keypass android test_apk-debug-toast.apk androiddebugkey • Ejecutamos la aplicación 1. Desinstalamos la aplicación anterior adb uninstall a.b 2. Instalamos la nueva adb install test_apk-debug-toast.apk 3. Lanzamos la actividad principal adb shell am start -n a.b/.Main
JD-GUI • Decompilador para el lenguaje de programación Java. Provee una interfaz de línea de comandos utilizada para extraer el código fuente y los ficheros de clase. • Uso – sebas@Helios:~/Android/tools/jd-gui$ ./jd-gui -h – Usage: jd-gui [-h] [input file…] -h, --help displays this help • Para ejecutar la herramienta basta con indicar por terminal: – $ ./jd-gui ../classes_dex2jar.jar &
DroidBox • Sandbox utilizada para ofrecer un análisis dinámico de las aplicaciones en Android. Generando la siguiente información una vez el análisis ha concluido: – Hashes para los paquetes analizados. – Datos de red entrantes/salientes. – Operaciones de lectura/escritura en ficheros. – Servicios iniciados y clases cargadas a través de DexClassLoader. – Envío de información privada a través de la red, ficheros o SMS. – Permisos. – Operaciones de criptografía utilizando la API de Android. – Broadcast receivers. – Envío de SMS y llamadas de teléfono • Generas dos imágenes que permiten visualizar el comportamiento de los paquetes.
DroidBox • Para hacer funcionar DroidBox es necesario tener el SDK instalado y las librerías pylab y matplotlib para poder dibujar los gráficos. • Instalación – Exportar el path del SDK export PATH=$PATH:/path/to/android-sdk/tools/ export PATH=$PATH:/path/to/android-sdk/platform-tools/ – Descargar los ficheros necesarios y descomprimirlos donde sea wget http://droidbox.googlecode.com/files/DroidBox.tar.gz – Crear un nuevo emulador con Android 2.1 Android – Iniciar el emulador ./startemu.sh NameOfAVD – Cuando haya arrancado el terminal, analizar la aplicación. ./droidbox.sh file.apk
AXMLPrinter2 • Nos devuelve el contenido del fichero AndroidManifest.xml • Uso: – $java –jar AXMLPrinter2 .jar ruta_fichero_xml
AndroGuard • Herramienta escrita en python para jugar con – .dex (Dalvik Virtual Machine), APK (Aplicaciones Android), Ficheros XML, .class (Java Virtual Machine), JAR (Aplicación Java). • Entre sus características – Trabaja y transforma ficheros DEX/CLASS/APK/JAR en objetos Python. – Soporte nativo de código DEX, a través de librería en C++. – Análisis estático de código (instrucciónes, bloques básicos, permisos, etc…) – Comprueba si una aplicación está en una BBDD (malware, trojan, goodware…) y mide el riesgo que entraña. – Diffing de aplicaciones Android – Reverse engineering de aplicaciones. – Transforma un XML binario a un XML estándar, Dump del proceso jvm para encontrar clases en memoria. • Permite analizar, modificar y guardar aplicaciones de forma sencilla, bien sea creando nuestra propia aplicación haciendo uso de la API o utilizando androlyze a través de la línea de comandos
Zoológico de malware • Obtener una fuente de descargas – AndroidMarket – Markets de terceros – Markets alternativos – Honeypots – Aplicaciones de orígenes desconocidos. • Automatizar las descargas. • Decompilar las aplicaciones. • Buscar strings que revelen patrones curiosos, delicados y repetitivos. • Lanzar herramienta que compruebe contra una BBDD de malware.
Análisis estático&dinámico • Retos en el análisis estático. • Amenazas. • Técnicas de ofuscación. • Estudiando muestras de malware – Trojan.FakePlayer – NickiSpy – Foncy SMS
Amenazas en Android • Amenazas basadas en aplicaciones • Malware • Spyware • Amenazas de privacidad • Vulnerabilidades en aplicaciones • Amenazas basadas en la web • Phishing • Drive-by-downloads • Exploits en navegadores • Amenazas basadas en las redes • Exploits para protocolos de red • Wi-fi sniffing • Amenazas físicas • Pérdida o robo del dispositivo
Evolución malware Nombre Características Riesgo AndroidOS.FakePlayer.a AndroidOS_Droisnake.A AndroidOS.FakePlayer.b AndroidOS.FakePlayer.c Android.Geinimi Android.HongTouTou Android.Pjapps Android.DroidDream Android.BgServ Android.Zeahache Android.Walkinwat Android.Adsms Android.Zsone Android.Spacem Android.LightDD Android/DroidKungFu.A Nombre Características Riesgo Android.Basebridge Android.Uxipp Andr/Plankton-A Android.Jsmshider Android.GGTracker Android.KungFu Variants AndroidOS_Crusewin.A AndroidOS_SpyGold.A DroidDream Light Variant Android.Smssniffer Android.HippoSMS Android.Fokonge Android/Sndapps.A Android.Nickispy Android.Lovetrap Android.Premiumtext Android.NickiBot
Técnicas de ofuscación • Nombrar ficheros de clases con el mismo nombre minúscula/mayúscula. • Cifrar las conexiones que realiza el malware utilizando DES. • Introducir comprobaciones para ver si la aplicación se está ejecutando en un emulador. • Hacer vibrar al dispositivo. • Comprobar el IMEI del terminal. • Mejorar la eficiencia del código y ofuscarlo utilizando Proguard. • Modificar el propio bytecode para inutilizar las herramientas de reversing.
Trojan SMS-FakePlayer (*) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
Virus total • ¿A qué nos enfrentamos? – Un buen punto de partida es subir el sample que tengamos a VirusTotal, y obtener una ligera de idea de lo que nos traemos entre manos.
Virus Total • Sample de malware – Android FakePlayer.A • Ratio de detección – 34/43 • Nivel de amenaza – Bajo • Información – Primer malware aparecido para plataformas Android. Surge como prueba de concepto, dado que escasea de peligro alguno. Realiza el envío de mensajes de texto
Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada? – $ tree files files ├── AndroidManifest.xml ├── classes.dex ├── META-INF │ ├── CERT.RSA │ ├── CERT.SF │ └── MANIFEST.MF ├── res │ ├── drawable │ │ └── icon.png │ └── layout │ └── main.xml └── resources.arsc
Estructura de la aplicación • ¿Qué nos interesa a primera vista? – Desempaquetar el fichero de clases para ver su contenido. – Observar el contenido del AndroidManifest • ¿Qué sacamos con esto? – Determinar los permisos que la aplicación va a solicitar. – Hacernos una ligera idea de cómo estará estructurada la aplicación.
Obteniendo el fichero .jar • ¿Cómo empezamos? – Primero debemos de realizar la conversión del fichero .dex a fichero .jar • ¿Cómo obtenemos el fichero .jar? – Utilizaremos dex2jar, que se encarga de realizar la conversión del fichero de clases basado en los bytecodes de Dalvik a fichero de clases Java. • Ejecutando dex2jar – $dex2jar fichero_clases.dex • ¿Dónde obtenemos la salida? – El fichero transformado estará en el mismo directorio donde la muestra que hemos proporcionado como entrada.
Obteniendo los ficheros .class • ¿Cómo obtenemos los ficheros .class? – Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. • ¿Para qué necesitamos estos ficheros .class? – Los usaremos más adelante para transformarlos a .jad y crear un proyecto en UnderStand, que permita analizarlos. • ¿Qué son los ficheros .class? – Es el acercamiento más próximo al código original que forma la aplicación a analizar. Permitiéndonos conocer los ficheros de clases, los métodos, y las clases que integran esta.
Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación? – $ tree class/ class/ └── org └── me └── androidapplication1 ├── DataHelper.class ├── DataHelperOpenHelper.class ├── HelloWorld.class ├── MoviePlayer.class ├── Rattr.class ├── R.class ├── Rdrawable.class ├── Rlayout.class └── Rstring.class • ¿Qué ficheros son los que nos interesan? – A priori centraremos nuestra atención en los ficheros DataHelper, HelloWorld, y MoviePlayer.
Analizando el AndroidManifest • ¿Cómo podemos ver el contenido del fichero? – $java –jar AXMLPrinter2 .jar ruta_fichero_xml • ¿Cuál es la salida que vamos a obtener? – Obtendremos el contenido del fichero XML que contiene todas las actividades, intents, receivers y permisos que solicitará la aplicación al ser instalada, y que necesitará para el correcto funcionamiento de la misma. • ¿Qué nos permite esto? – Tener un acercamiento más profundo a la actividad que desempeñará la aplicación. – Agilitar el proceso de detección de malware, cuando nos enfrentamos a un gran número de aplicaciónes. – Montar listas negras de permisos, parseando y comprobando el contenido del fichero.
AndroidManifest de FakePlayer • El contenido del fichero AndroidManifest – <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="org.me.androidapplication1"> <application android:icon="@7F020000"> <activity android:label="Movie Player" android:name=".MoviePlayer"> <intent-filter> <action android:name="android.intent.action.MAIN"> </action> <category android:name="android.intent.category.LAUNCHER"> </category> </intent-filter> </activity> </application> <uses-permission android:name="android.permission.SEND_SMS"> </uses-permission> </manifest>
Obteniendo los ficheros .jad • ¿Qué es el formato .JAD? – Java Application Descriptor, extensión asociada a las aplicaciones Java ME, que suelen ser distribuidas como ficheros .JAR. Utilizados normalmente para empaquetar juegos y aplicaciones utilizadas en dispositivos móviles • ¿Para qué queremos esos ficheros? – Obteniendo ese tipo de ficheros, podemos cargarlos directamente en la aplicación Understand, para estudiar las trazas de sus funciones y clases. Además podemos abrirlos con cualquier editor de texto para trabajar sobre ellos. • ¿Cómo los podemos obtener? – Utilizando la herramienta del mismo nombre JAD (Java Decompiler). Que se encarga de extraer el código fuente de los ficheros de clases contenidos en el fichero .jar
Obteniendo los ficheros .jad • ¿Recordáis los ficheros que descomprimimos del archivo .jar que se originó al realizar la transformación del fichero de clases para la máquina Dalvik, al fichero de clases java? • DataHelper.jad, DataHelper$OpenHelper.jad, R$attr.jad, R$drawable.jad, etc… • Es necesario eliminar el carácter $ de los ficheros, de lo contrario no obtendremos el resultado esperado con JAD – $ for i in *; do mv $i $(echo $i | tr -d '$'); done • Realizamos la transformación ejecutando JAD – $./jad ruta_ficheros/*.class • Los resultados obtenidos serán generados en el directorio donde tengamos instalada la herramienta.
Utilizando Understand • ¿Qué es Understand? – Es una herramienta de análisis estático, que nos permite mantener, comprar y analizar proyectos de gran envergadura. • ¿Cómo lo configuramos para que acepte ficheros .jad? – Por defecto no acepta los ficheros con extensión .jad – File > New > Project • Seleccionamos nombre y directorio donde albergar nuestro proyecto. • Elegimos Java como idioma del código fuente que vamos a cargar. • Al añadir los ficheros, pulsamos sobre el botón “…” de Configure Filters • Pulsamos sobre Configure. Pulsamos sobre New: – Extension: jad ; Language: java
Cargando FakePlayer • Una vez configurado Understand para ficheros .jad cargamos el código de FakePlayer en este. • Automáticamente nos reconoce todos los ficheros en la aplicación y nos permite visualizarlos además de ver las dependencias entre sus métodos, clases, diagramas de clase, etc.
Dependencias internas • Para dibujar las dependencias entre clases: – Graphs > Dependency Graphs > By Directory Structure • Lo interesante parece estar en los ficheros MoviePlayer y DataHelper.
Diagrama de clases
Analizando el código • Nuestro punto de partida es el siguiente: – Sospechamos de los ficheros MoviePlayer y DataHelper. – Tenemos la ligera idea de que la muestra realiza envío de SMS. – No lo sabemos con exactitud pero es posible que se realicen operaciones contra una base de datos. • Tener una ligera idea del propósito inicial de la aplicación, nos ayudará a la hora de enfrentarnos a la muestra de malware.
DataHelper • Observando el código extraemos – Una base de datos con nombre movieplayer.db es creada. – El nombre de la tabla donde se va a insertar la información es table1. – Cuando se crea e inicia la actividad principal de la app, se lanza la query: – CREATE TABLE table1(was TEXT PRIMARY KEY) – Cuando se actualiza la aplicación con una nueva versión, se lanza la query: – DROP TABLE IF EXISTS table1 – La query encargada de realizar inserciones en la tabla es: – INSERT INTO table1(was) VALUES (‘was’)
MoviePlayer • Observando el código extraemos – Se carga un textView con el siguiente mensaje en ruso: “Подождите, запрашивает доступ к медиатеке..” – Ahora no hay dudas, procede de Rusia. (Captain Obvious to the rescue). – Se realizan dos llamadas al método sendTextMessage – ((SmsManager)localObject).sendTextMessage(“3353”, null, “798657”, null, null). – ((SmsManager)localObject).sendTextMessage(“3354”, null, “798657”, null, null).
MoviePlayer – Revisando los parámetros que recibe dicho método en la API: – Public final void sendTextMessage(String destinationAddress, String scAddress, String text, PendingIntent setIntent, PendingIntent deliveryIntent). – Sabemos que los destinatarios son los números 3353 y 3354. – Para ambos destinatarios el mensaje de entrega es el número 798657. – Cuando por distintos motivos la aplicación falla y el mensaje no es entrega, se captura el error y se muestra el siguiente código: – “Oops in playsound”. – Los números del destinatario pertenecen a la empresa INcore Media Ltd (Rusia) que ofrece servicios relacionados con telefonía.
Instalando la aplicación 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. • Emulator –port 5554 @RootedLabs –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb install foo.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se ha creado org.me.androidapplication1 , aunque actualmente está vacío y únicamente contiene una carpeta llamada lib. 4. Lanzamos una batería de pruebas contra la aplicación para ver si se producen cambios • ./adb shell moneky –v –p org.me.androidapplication1
Instalando la aplicación 1. Realizamos una lectura del log para observar comportamientos anómalos • ./adb shell logcat D | grep SQLite 2. Del directorio padre surge una carpeta llamada databases y dentro encontramos el fichero movieplayer.db
Realizando análisis dinámico 1. Nos traemos a local el fichero, bien usando adb o utilizando el botón de pull de la ventana File Explorer en la pestaña DDMS de Eclipse. • ./adb pull /data/data/org.me.androidapplication1/databases/movieplayer.db 2. Analizando la base de datos utilizando SQLite3, extraemos: • $ sqlite3 ./movieplayer.db SQLite version 3.7.4 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables android_metadata table1 sqlite> select * from android_metadata; en_US sqlite> select * from table1; was
Analizando el Pcap con Wireshark • A pesar de que en esta muestra de malware, no se realiza ningún tipo de conexión con ningún C&C y no se envía ningún dato a través de Internet, en otras ocasiones este punto resulta fundamental.
Modifiquemos el apk • El objetivo de este ejercicio será desensamblar el malware y realizarle modificaciones a nivel de código para que el mensaje de texto que envía lo realice al número del emulador (5556 en este caso), empacar la aplicación de nuevo y probarla en el emulador.
Modifiquemos el apk • Lo primero será asegurarnos de que poseemos una llave privada con la que firmar las aplicaciones de Android. – $keytool –genkey –v –keystore millave.keystore –alias mi_alias –keyalg RSA –keysize 2048 –validity 1000 • El siguiente paso será usar apktool para desempaquetar la aplicación. – $./apktool d –d ficheroMalware.apk directorio_salida • La estructura de directorios que obtendremos después de esto será: – $ tree . . ├── AndroidManifest.xml ├── apktool.yml ├── build │ └── apk │ ├── AndroidManifest.xml │ ├── classes.dex │ ├── res │ │ ├── drawable │ │ │ └── icon.png │ │ └── layout │ │ └── main.xml │ └── resources.arsc ├── res │ ├── drawable │ │ └── icon.png │ ├── layout │ │ └── main.xml │ └── values │ ├── public.xml │ └── strings.xml └── smali └── org └── me └── androidapplication1 ├── DataHelper$OpenHelper.smali ├── DataHelper.smali ├── HelloWorld.smali ├── MoviePlayer.smali ├── R$attr.smali ├── R$drawable.smali ├── R$layout.smali ├── R.smali └── R$string.smali 13 directories, 20 files
Modifiquemos el apk • Nosotros sólo queremos modificar los ficheros que posean el número de teléfono de destino de los SMS: • HelloWorld.smali • Línea 59 – const-string v1, “3353”. • Línea 86 – const-string v1, “3354”. • Línea 104 – const-string v1, “3353”. • MoviePlayer.smali • Línea 77 – const-string v1, “3353”. • Línea 104 – const-string v1, “3354”. • Línea 122 – const-string v1, “3353”. • Sustituimos esos valores por 5556.
Modifiquemos el apk • Empacamos la aplicación utilizando apktool: • $apktool b –d directorio_salida Aplicación_modificada.apk • Firmamos la aplicación con la llave que creamos anteriormente: • $jarsigner –verbose –keystore millave.keystore Aplicación_modificada.apk mi_alias • Ahora podemos instalar la aplicación (PERO ANTES…) • $adb install foo.apk
Operando entre emuladores • Para poder operar entre emuladores y que reciban SMS necesitamos: – Levantar dos máquinas • Emulator-5554 • Emulator-5556 • Instalaremos la muestra en emulator 5554 – $adb –s emulator-5554 install Aplicación_Modificada.apk
NickiSpy (***) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
VirusTotal • Sample de malware – Trojan/AndroidOS.Foncy • Ratio de detección – 18/43 • Nivel de amenaza – Medio • Información – Añade técnicas de ofuscación y ocultación a través de ficheros ELF camuflados en PNGs. Incluye un exploit para obtener acceso root y realiza suscripción a servicios premium de mensajes.
Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada? – $ tree . . ├── AndroidManifest.xml ├── classes.dex ├── META-INF │ ├── CERT.RSA │ ├── CERT.SF │ └── MANIFEST.MF ├── res │ ├── drawable │ │ └── icon.png │ └── menú │ └── menu.xml └── resources.arsc 4 directories, 8 files
Preparando el terreno • Procedemos igual que en el caso anterior – Transformamos el fichero .dex. • $dex2jar fichero_clases.dex – Obtenemos los ficheros .class. • Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. – Transformamos los ficheros .class a .jad • $ for i in *; do mv $i $(echo $i | tr -d '$'); done • $./jad ruta_ficheros/*.class – Observamos el contenido del AndroidManifest. • $java –jar AXMLPrinter2 .jar ruta_fichero_xml
Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación? – $tree . . └── com └── nicky └── lyyws └── xmall ├── AlarmReceiver.jad ├── BootReceiver.jad ├── GpsService$1.jad ├── GpsService.jad ├── MainService$1.jad ├── MainService.jad ├── oo │ ├── CallInfo.jad │ ├── FileInfo.jad │ ├── GpsInfo.jad │ ├── HeadInfo.jad │ ├── LacInfo.jad │ ├── ParamInfo.jad │ ├── Result.jad │ ├── SmsInfo.jad │ ├── Test.jad │ └── UpInfo.jad • ¿Qué ficheros nos interesan? – A simple vista nos interesan RecordService, MainService, SocketService, SmsListener, entre otros. ├── R$attr.jad ├── R$drawable.jad ├── RecordService$1.jad ├── RecordService.jad ├── R$id.jad ├── R.jad ├── R$menu.jad ├── R$string.jad ├── SocketService$1.jad ├── SocketService$2.jad ├── SocketService$3.jad ├── SocketService$4.jad ├── SocketService$5.jad ├── SocketService.jad ├── XM_CallListener$CallContent$1.jad ├── XM_CallListener$CallContent.jad ├── XM_CallListener.jad ├── XM_CallRecordService.jad ├── XM_CallRecordService$TeleListener.jad ├── XM_SmsListener.jad └── XM_SmsListener$SmsContent.jad 5 directories, 37 files
AndroidManifest NickiSpy • El contenido del fichero AndroidManifest: – android:name="android.permission.CALL_PHONE" android:name="android.permission.PROCESS_OUTGOING_CALLS" android:name="android.permission.INTERNET" android:name="android.permission.ACCESS_GPS" android:name="android.permission.ACCESS_COARSE_LOCATION" android:name="android.permission.ACCESS_COARSE_UPDATES" android:name="android.permission.ACCESS_FINE_LOCATION" android:name="android.permission.READ_PHONE_STATE" android:name="android.permission.READ_CONTACTS" android:name="android.permission.WRITE_CONTACTS" android:name="android.permission.ACCESS_WIFI_STATE" android:name="android.permission.PERMISSION_NAME" android:name="android.permission.SEND_SMS" android:name="android.permission.READ_SMS" android:name="android.permission.WRITE_SMS" android:name="android.permission.WAKE_LOCK" android:name="android.permission.RECORD_AUDIO" android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:name="android.permission.DEVICE_POWER"
Dependencias internas • El peso de la aplicación recae en los ficheros SmsContent, CallContent, RecordService además de sus respectivos listeners.
Diagrama de clases • La importancia recae en ficheros como: – RecordService – SMSLister – GPSInfo – SmsInfo – … • Es imposible hacernos una idea fijándonos en el diagrama. – Hay que profundizar en el código.
Analizando el código • Nuestro punto de partida es el siguiente: – Tenemos diversos ficheros sospechosos a analizar: RecordService, MainService, SocketService, SmsListener, entre otros. – Sospechamos que puede realizar grabaciones de audio y enviar estas a un C&C. – Solicita acceso a los mensajes de texto y a la cartera de contactos. Al tratarse de una muestra de unas dimensiones considerables, sólo analizaremos los ficheros que presentan cierta importancia de cara a nuestra investigación.
MainService • Observando el código extraemos – Declaración de diversas variables que hacen apuntar a un panel de control encargado de enviar comandos con las acciones a realizar. – Obtiene información de un fichero llamado XM_All_Setting (El método getSharedPreferences permite almacenar y obtener datos almacenados en forma de par clave/valor). – Dicha información apunta: – Service: jin.56mo.com – Port: 2018 – Da formato a la fecha utilizando la constante “SIMPLIFIED_CHINESE”, esto nos permite presuponer que el C&C puede ser de origen chino. – Las restantes variables de tipo booleano sirven para controlar el estado de los servicios que han sido lanzados.
XM_CallRecordService • Observando el código extraemos – Contiene una variable llamada callpath con el valor /sdcard/shangzou/callrecord que parece apuntar a la ruta donde se almacenan las llamadas que el teléfono graba. – Realiza la comprobación del IMEI, y en caso de que este sea nulo (eso significa que se está ejecutando en un emulador) asigna por defecto el 00…00. – Almacena la información de las llamdas como el id, número, fecha, tipo, duración.
XM_SmsListener • Observando el código extraemos – Monitoriza los mensajes tanto del outbox como del inbox. – Para cada uno de ellos recoge datos como el número de origen, el contenido y la fecha.
GPSService • Observando el código extraemos – Un listener encargado de actualizar los datos cuando el teléfono cambia de coordenadas GPS.
XM_CallListener • Del código destacamos – Funcionamiento similar al SmsListener, monitoriza los logs de las llamadas para obtener información como el número de origen, la duración, el tipo o la fecha.
SocketService • Extraemos del código: – Se encarga de recoger toda la información que hemos comentado con anterioridad desde los diferentes ficheros y la envía al C&C.
Instalando la aplicación • En esta ocasión para estudiar el funcionamiento de la muestra, vamos a levantar dos máquinas de prueba, una donde instalaremos la aplicación y otra donde realizaremos las pruebas. 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. (Esta será la máquina que infectaremos) • Emulator –port 5556 @RootedLabs_infectado –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb –s emulator-5556 install ruta/fichero.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se crea en /data/data una nueva jerarquía de directorios llamada com.nicky.lyyws.xmal/lib que actualmente está vacía.
Instalando la aplicación 1. En este caso en particular no hay evidencias de que ninguna aplicación haya sido instalada. Para activar el malware es necesario reiniciar el terminal. 2. Tras reiniciarlo vemos en la pestaña DDMS que un nuevo paquete comienza a ejecutarse en nuestro terminal: com.nicky.lyyws.xmall 3. Una nueva carpeta es creada dentro del directorio /data/data – Bajo el nombre de shared_prefs podemos encontrar el fichero XM_All_Setting.xml 4. Volcando el contenido del fichero: – <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="Move">10</string> <string name="Service">jin.56mo.com</string> <int name="Port" value="2018" /> <string name="EndTime">23:59</string> <string name="Time">1</string> <string name="BeginTime">00:01</string> <boolean name="IsFirst" value="false" /> </map>
Reproduciendo la actividad • Partimos de que poseemos dos máquinas virtuales – RootedLabs, emulador sin infectar, conocido internamente por emulator-5554. – RootedLabs_infectado, emulador infectado, conocido internamente por emulator-5556. • El nombre realmente no importa, si no lo sabemos, podemos ejecutar adb devices para obtenerlo.
Reproduciendo la actividad • Desde el emulador no infectado, lanzamos el dialer para realizar llamadas • Lo hacemos pulsando sobre el botón del emulador • Introducimos el número 5556 (O el asociado al teléfono infectado, que en caso de no ser ese, podemos comprobarlo ejecutando adb devices).
Reproduciendo la actividad • Acto seguido recibiremos una llamada en el emulador indicado, si procedemos a descolgarla estaremos simulando las llamadas entre terminales.
Realizando análisis dinámico • Revisando la ventana FileExplorer dentro de la pestaña DDMS de Eclipse, observamos: • Se ha creado una nueva carpeta en /sdcard llamada shangzou/callrecord/. • Dentro contiene bajo el nombre de la fecha y hora exactas, la conversación grabada que hemos tenido anteriormente.
Realizando el análisis dinámico • Por último revisamos el fichero pcap: • Al poco de ejecutarse la aplicación trata de establecer conexión con el centro de mando, enviando una petición a jin.56mo.com
Realizando el análisis dinámico • Realiza el envío de un mensaje de texto al C&C con la palabra test
Realizando el análisis dinámico • Realiza el envío del IMEI del teléfono en cuestión (en este caso 00…00 al tratarse de un emulador)
Realizando el análisis dinámico • Realiza el envío de la fecha correspondiente a la que se realizó la grabación de teléfono anterior.
Juguemos un poco • Si intentamos establecer conexión con la dirección del C&C (jin.56mo.com) obtenemos el siguiente mensaje de error. • Si establecemos conexión sin embargo con el dominio 56mo.com, obtenemos: • La cadena 您的域名因未备案或其他原因禁止访问 puede ser traducida por “Su dominio ha sido bloqueado”.
Juguemos un poco • Lanzando un whois logramos averiguar qué: • El dominio fue creado el 2010-07.17. • El nombre de contacto al que fue registrado es: qmingdeng. • La dirección registrada es: 15B Room, B Tower Taiya Building, Xiamen, CN. • Localización: China, Provincia: Fujian, Ciudad: Xiameng, CP: 361012. • Número de teléfono: +86.5157781. • Dirección de email registrada: qmingdeng@163.com
Sabemos dónde vives • Encadenando los datos obtenidos y jugando con Google Maps:
Foncy-SMS (*****) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
VirusTotal • Sample de malware – Trojan/AndroidOS.Foncy • Ratio de detección – 18/43 • Nivel de amenaza – Medio • Información – Añade técnicas de ofuscación y ocultación a través de ficheros ELF camuflados en PNGs. Incluye un exploit para obtener acceso root y realiza suscripción a servicios premium de mensajes.
Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada?
Preparando el terreno • Procedemos igual que en el caso anterior – Transformamos el fichero .dex. • $dex2jar fichero_clases.dex – Obtenemos los ficheros .class. • Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. – Transformamos los ficheros .class a .jad • $ for i in *; do mv $i $(echo $i | tr -d '$'); done • $./jad ruta_ficheros/*.class – Observamos el contenido del AndroidManifest. • $java –jar AXMLPrinter2 .jar ruta_fichero_xml
Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación?
AndroidManifest FoncySMS • El contenido del android manifest es el siguiente – android:name="android.permission.READ_LOGS" android:name="android.permission.READ_PHONE_STATE" android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:name="android.permission.INTERNET" android:name="android.permission.VIBRATE" android:name="android.permission.WAKE_LOCK" android:name="android.permission.ACCESS_WIFI_STATE" android:name="android.permission.CHANGE_WIFI_STATE" android:name="android.permission.CHANGE_NETWORK_STATE" android:name="android.permission.ACCESS_NETWORK_STATE" android:name="android.permission.MODIFY_AUDIO_SETTINGS" android:name="com.android.vending.CHECK_LICENSE" … • Permisos para leer el estado de los logs y el teléfono, acceso a la vibración del mismo, control sobre el estado del wifi, etc.
Dependencias internas • El peso de la aplicación recae en el fichero AndroidBotActivity, que conecta los ficheros alojados dentro del directorio shellcommand.
Diagramas de clase
Analizando el código • Nuestro punto de partida es el siguiente: – Tenemos diversos ficheros sospechosos a analizar: AndroidBotActivity y ShellCommand – Sospechamos que puede tener funcionalidades de botnet y es posible que exista un C&C por detrás. – Aunque a simple vista y por lo que hemos analizado no podamos confirmarlo, más adelante veremos que hay muchas más características ocultas en la aplicación.
AndroidBotActivity • Observando el código extraemos – La decompilación generada no es del todo la esperada, mostrando basura de por medio *. – Se crea una instancia de la clase ShellCommand al iniciar la actividad de la aplicación. – Se crea el directorio /data/data/com.android.bot/files con los permisos de lectura/escritura para todos los ficheros contenidos en él. – Se extraen tres ficheros bajo los nombres de: • /data/data/com.android.bot/files/header01.png (Ejecutable ELF). • /data/data/com.android.bot/file/footer01.png (Ejecutable ELF). • /data/data/com.android.bot/file/border01.png (Aplicación Android- Fichero APK) – Otorga permisos de lectura/escritura al fichero header01.png – Ejecuta el fichero. – Muestra un toast con el mensaje “(0x14) Error – Not registred application” • * El error mostrado al descompilar se sucede cuando JAD es incapaz de descomponer las construcciones como bloques etiquetados con breaks o bucles anidados controlados por sentencias break/continue, mostrando comúnmente el mensaje “Couldn’t fully decompile method” o “Couldn’t resolve all exception handlers in method” ($apktool d –d FoncySms.apk Foncy_smali )
Shellcommand • Observando el código extraemos – Métodos encargados de realizar las labores de ejecución de los comandos que le son pasados por parámetros, además de controlar la salida y los errores de los resultados obtenidos.
Instalando la aplicación 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. (Esta será la máquina que infectaremos) • Emulator –port 5556 @RootedLabs_infectado –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb –s emulator-5556 install ruta/fichero.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se crea en /data/data una nueva jerarquía de directorios llamada com.android.bot/lib que actualmente está vacío. • En el menú de apliacciones, aparece una nueva llamada Madden NFL 12. Al ejecutarla lo único que observamos es un mensaje de “Hello World, AndroidMeActivity!” (En este caso no necesitamos simular la ejecución de eventos con ShellMonkey). 4. Observando la pestaña DDMS vemos una nueva actividad llamada com.android.bot que se está ejecutando en nuestro teléfono, y en el directorio comentado anteriormente han aparecido los ficheros creados por AndroidBotActivity.
Instalando la aplicación • Lanzando el comando file sobre los ficheros que se han creado averiguamos: • Boomsh: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dinamically linked (uses shared libs), not stripped. • Border01.png: Zip archive data, at least v2.0 to extract. • Footer01.png: ELF 32-bit LSB executable, ARM, version 1(SYSV), dynamically linked (uses shared libs), not stripped. • Header01.png: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped. • Rooted: ASCII text • El siguiente paso es analizar esos ficheros con IDA y ver qué resultados obtenemos.
Header01.png • Vulnerabilidad en la función handlePartitionAdded(). • Se asumía que variable part_num >= 1 para acceder a mPartMinors[]. • Pasando valor negativo referenciar y sobreescribir la memoria (GOT). • GOT almacena información de las APIs importadas. (strcmp(), atoi(), …). • Sustituimos offset de función por offset de system(). • Si pasamos como parámetro a la función la ruta de un fichero o un comando… • Dicha función solo entra en acción cuando un evento hotplug ocurre. – El demonio encargado de quedar a la escucha del socket espera recibir un paquete.
Header01.png • Abre el fichero /proc/net/netlink y lee su contenido. • Construye strings /proc/%PID%/cmdline • Abre fichero hasta encontrar /system/bin/vold. • Parsea su contenido para recoger princpio y fin del GOT. • Llegados a este punto el atacante conoce los límites del GOT y el offset de la instrucción system(). • Realiza un ataque de fuerza bruta construyendo la cadena malformada. • El valor negativo lo utiliza para comprobar si referencia a una zona de memoria incluida dentro de los limites del GOT. • Redirige la excepción ocurrida a /data/local/tmp/crashlog. – Parsea el contenido buscando “fault addr” y compara la dirección con los límites del GOT.
Explotando la vulnerabilidad • Se construye la cadena malformada. • Ejecuta la función system(“/data/local/tmp/boomsh”); • Comprueba si su nombre contiene el string boomsh • El troyano se ejecuta correctamente con permisos administrador. • Inicia la segunda fase de su ataque, ejecutando footer01.png
Footer01.png • Lo primero que hace al ejecutarse es escribir 1 en el fichero /data/data/com.android.bot/files/rooted, indicando que el exploit para conseguir root ha tenido éxito.
Footer01.png • Elimina el directorio /etc/sent para establecer posteriormente permisos de lectura/escritura (para el propietario) y permisos de sólo lectura para el resto de usuarios al fichero /data/data/com.android.bot/files/border01.png
Footer01.png • El siguiente paso es instalar la aplicación border01.png utilizando el administrador de paquetes para ello, acto seguido lanza la actividad principal de la misma y establece un flag de activación a 1 en el fichero /etc/sent
Footer01.png • Realiza conexión con el IRC alojado en la dirección 192.68.196.198 generando un nombre de usuario al azar para utilizarlo a la hora de hacer login en el servidor IRC. • El bot se conecta al canal #andros y queda a la espera de recibir mensajes privados con las órdenes a realizar. • Una vez el mensaje es recibido, el bot parsea su contenido (normalmente cadenas precedidas por el string PRIVMGS) para ejecutar uno de los 3 posibles comandos: – Si el bot recibe el comando sh, ejecutará el ejecutable o comando a través de una llamada a system(), devolviendo el mensaje: • PRIVMSG #andros :[SH] - %COMMAND_TO_RUN% – Si recibe el comando id, obligará al bot a devolver el ide del usuario que está ejecutando el proceso, obteniéndose con una llamada a getuid(). El mensaje que devuelve es: • PRIVMSG #andros :[ID] - %REAL_USER_ID% – Comando exit, que fuerza la salida del bot mostrando el mensaje: • PRIVMSG #andros :[EXIT] – existing ordered….
Border01.png • Corresponde al fichero APK creado por la aplicación original. • Analizando la aplicación sin desempaquetar el fichero de clases observamos la siguiente estructura
Border01.png • Después de hacer la correspondiente transformación del fichero de clases obtenemos lo siguiente:
AndroidManifest Border01 • Revisando el fichero AndroidManifest que posee la aplicación descubrimos que solicita: – android:name="android.permission.RECEIVE_SMS” – android:name="android.permission.SEND_SMS“ – android:name="android.permission.INTERNET“ • Permisos para enviar/recibir mensajes de texto. • Podemos encontrarnos ante una aplicación que realiza envíos de SMS premiums además de otros datos de carácter privados.
Diagrama de clases – Vemos que hace uso del método SMSReceiver por lo que confirmamos nuestras dudas sobre el envío de mensajes.
Analizando la aplicación • En este caso nuestro punto de partida serán los ficheros AndroidMeActivity.jad y SMSReceiver.jad. • Podemos deducir por el nombre de que será en el segundo fichero donde esté implementada la lógico encargada del envío y recepción de mensajes de texto. • Revisando el fichero AndroidMeActivity extraemos: – Al iniciar la actividad principal, se solicita el código ISO de la ciudad. – En base a esto se establece un número Premium u otro donde realizar el envío de mensajes. – Se crea una instancia de SmsManager y se realizan un total de 5 envíos.
Analizando la aplicación • Las ciudades a las que realiza el envío son: – Spain Number: 35024 Message: GOLD – Great Britain Number: 60999 Message: SP2 – Morocco Number: 2052 Message: CODE – Sierra Leone Number: 7604 Message: PASS – Romania Number: 1339 Message: PASS – Norway Number: 2227 Message: PASS – Sweden Number: 72225 Message: PASS – United States Number: 23333 Message: PASS
Analizando la aplicación • Analizando el fichero SMSReceiver.class obtenemos: – Es la responsable de la lógica encargada de interceptar los mensajes de texto recibidos. – Se reservan dos campos donde se almacenan el número del destinatario y el contenido de cada SMS. – Si el número del SMS interceptado procede de 81083, 3075, 64747, 60999, 63000, 35024, 2052, 7064, 1339, 9903, 2227, 72225, 23333, entonces el broadcast se aborta. – Independientemente de que se aborte o no, el malware envía al centro de mando con IP: 46.166.146.102 el mensaje de texto y el número que ha realizado el envío, formando el string: • http://46.166.146.102/?=STR2(cuerpo mensaje)///STR1(número)
Análisis Forense • Introducción. • Retos en el análisis forense. • Bases del sistema de ficheros. • Técnicas en el análisis forense • Jerarquía de directorios. • Analizando la memoria.
Introducción • El análisis forense en móviles sigue la misma metodología que en los análisis convencionales: – Herramientas forenses. – Buenas prácticas. – Preservación de la información. – Aplicación de métodos. • El sector empieza a tener constancia de la importancia de estos dispositivos. • Con el auge de los smartphones, el uso intensivo de los mismos propician el uso criminal o fraudulento de ellos.
Retos en el análisis forense • Arquitectura diferente. • Diversidad en los modelos y tecnología. • Software de análisis forense y hardware específico. • La mayoría de software de forense es de pago. • Diseño de aplicaciones específicas e incluso determinado tipo de dispositivos.
Técnicas • Para realizar un análisis forense en condiciones, es bueno conocer técnicas como: – TimeLine Analysis. – FileSystem Analysis. – File Carving. – Strings – DataBases Analysis.
Tarjeta SIM • Tarjeta inteligente, utilizada en teléfonos móviles. • Información para identificarnos en la red del operador, además: – IMSI – Clave autenticado – ICCID (Identificador Internacional de la tarjeta de circuito) – MSIDSN – Información sobre la localización, proveedor y llamadas. • Presentan dos mecanismos de protección – PIN – PUK • Aplicaciones para trabajar con este tipo de tarjetas: – USIM Detective – MOBILedit! – Oxygen Forensics Suite 2012
Copiar/Clonar tarjeta SIM • Conceptos estrechamente ligados. • Copiar es generar un nuevo IMSI y Ki y copiar todo el contenido de la otra tarjeta. • Clonar es generar una tarjeta exactamente igual, mismo IMSI y Ki. • Para poder realizar este proceso – A nivel de hardware • Grabadora de PIC tipo Ludipipo. • Grabadora EEPROM. • Tarjeta con microprocesador donde poder volcar y grabar la información – A nivel de software • ICPRO - Graba el PIC • Winexplorer – Graba el EEPROM
TimeLine Analysis • Componente fundamental para cualquier investigación. • Existen diversas maneras de realizarlo, aunque es un proceso tedioso sino se realiza con herramientas especializadas. • Dependiendo del tipo de sistemas de ficheros que utilicemos en la tarjeta SD se utilizan un tipo de herramientas u otras. • La primera fuente para crear un timeline es la información almacenada en los metadatos del sistema de ficheros. – Incluyendo la modificación, el acceso, o la modificación y creación de los ficheros.
Jugando con los TimeStamps • ¿Qué es un timestamp? – Suelen ser una secuencia de caracteres que denotan la hora y fecha en la que ocurrió un evento determinado. – 2005-10-30 T 10:45 UTC 2007-11-09 T 11:20 UTC Sat Jul 23 02:16:57 2005 • ¿Qué otros usos tienen? – Marca digital usada en criptografía. – Código de tiempo usado en redes, o vídeos. – Tiempo universal de Linux. – ICMP TimeStamp. – Tipo de dato T-SQL, que muestra números binarios generados en una base de datos automáticamente.
Tipos de TimeStamp • Existen 5 tipos de TimeStamps que pueden llevarnos a confusiones
Tipos de TimeStamp • System TimeStamp – Tiempo obtenido del reloj interno del equipo. – Formato Año-Mes-Fecha-segundos-milisegundos • File Time – Intervalos de 100 nanosegundos desde el 1 de Enero de 1601. • Local – System Time • Tiempo del sistema convertido al tiempo local del sistema. – File Time • Tiempo del fichero convertido al tiempo local del sistema. • Windows – Número de milisegundos desde que se inició el sistema. • Ciclos cada 49.7 días.
Tipos de TimeStamp • Los sistemas FAT12/FAT16 sólo tienen la fecha de la última modificación. Mientras que los sistemas FAT32 y NTFS tiene 3 tipos diferentes de timestamps: – Fecha cuando el fichero fue creado. – Fecha cuando fue accedido por última vez. – Fecha cuando fue modificado por última vez.
Ejemplo • Tomemos como ejemplo una carpeta FAT al azar, cuyo valor para la última modificación es la siguiente. • Convirtiendo 3a75 b9 78 a binario obtenemos la siguiente representación 00111010 01110101 10111001 01111000. • Traduciendo esto a un TimeStamp válido obtenemos – 2009.03.21 23:11:48 • 7 bits = 0011101 = 29 años desde 1980. • 4 bits = 0011 = 3 meses. • 5 bits = 10101 = 21 días. • 5 bits = 10111 = 23 horas. • 6 bits = 001011 = 11 minutos. • 5 bits = 11000 = 24 = 48 segundos.
FileSystem Analysis • Los directorios y ficheros en un sistema Android son el primer objetivo de un análisis forense. • Existen una serie de directorios que son necesarios ser examinados. – Pueden variar debido a que los sistemas van creciendo frecuentemente. • Cada teléfono es un mundo diferente. • La mejor forma de abarcar esta técnica es comprobar: – Que sistemas de ficheros están montados. – Dónde han sido montados. – Qué tipo de sistemas de ficheros son.
Ejemplo • Analizando los puntos de montaje para un Nexus One: – Hay 5 sistemas de ficheros montados donde deberíamos enfocar nuestra investigación
Ejemplo • Analizando un Motorola Droid – Posee 7 sistemas de ficheros interesantes a analizar.
Comenzando la investigación • ¿Cómo establecemos entonces el punto de partida en nuestra investigación? – Es recomendable incluir los siguientes directorios en cualquier investigación forense. Punto de montaje Sistema de ficheros Importancia /proc PROC Recomendable examinarlo lanzando un cat, para obtener datos de relevancia , como metadatos con información acerca de las estadísticas del sistema. /data/data YAFFS2 Contiene toda la información de las aplicaciones. /data EXT3/EXT4/YAFFs2 Contiene los datos de aplicaciones y del sistema que han sido excluidos de /data/data /cache YAFFS2/EXT3 Ficheros de caché utilizados por algunas aplicaciones y el sistema.
Comenzando la investigación Punto de montaje Sistema de ficheros Importancia /mnt/asec Tmpfs Ficheros descifrados pertenecientes a las aplicaciones apk. Son los mismos que están en la tarjeta SD pero descifrados debido a su uso por el sistema. /app-cache Tmpfs Temporalmente donde com.android.browser almacena su caché. Otras aplicaciones también pueden usar este directorio. /mnt/sdcard Vfat Sistema de ficheros FAT32 donde se monta la tarjeta SD. /mnt/emmc Vfat Sistema de ficheros FAT32 donde se monta el eMMC
FileCarving • ¿En qué consiste hacer FileCarving? – Proceso cuya misión es recuperar ficheros en un escenario forense basado en el análisis en contenidos y no en metadatos. – Nos permite recuperar estructuras corruptas. • ¿Qué tipos de FileCarving existen? – Basados en bloques. – Basados en cabeceras. – Basados en pies. – Limitados en el tamaño del fichero. – Carving con validación. – Carving semántico. – Recuperación de fragmentos. – Basado en estructuras de ficheros.
Usando Scalpe • Scalpe es una herramienta desarrollada por Golden G. Richard. • Lee un fichero de configuración para el fichero de cabecera y pie deseado con la intención de extraer los ficheros de una imagen raw. • Se puede obtener a través de : – sudo apt-get install scalpel
Usando Scalpe • Las cabeceras del fichero de configuración definen el tipo de fichero que se trata (si es case sensitive o no), el tamaño máximo de carving, la definición de la cabecera, y el footer, si existe.
Strings • El comando strings, por defecto nos devuelve las cadenas de un fichero que pueden ser imprimidas de cualquier fichero, texto o binario. • No es una técnica elegante o sofisticada. • Es muy efectiva cuando queremos obtener información rápida y efectiva examinando un fichero binario para hacernos una idea de lo que contiene. • Permite utilizar varios parámetros que modificarán considerablemente lo que obtendremos como salida. • Podemos automatizar búsquedas apoyándonos en expresiones regulares.
Strings • Buscando direcciones de correo electrónico Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” • Buscando sitios donde se ha realizado inicios de sesión Strings userdata.img | grep –n10 “login” • Buscando parámetros de sitios visitados strings userdata.img | grep –oE “((mailto:|(news|(ht|f)tp(s?))://){1}S+)” • Buscando números de teléfono strings userdata.img | grep -oE "([0-9]{9})" • …
Jerarquía de directorios
Jerarquía de directorios
Jerarquía de directorios
Jerarquía de directorios
Jerarquía de directorios
Realizando un forense • ¿Por dónde empezamos? – Un buen punto de partida es observar los puntos de montaje
Realizando un forense • ¿Qué información extraemos de aquí? – Apreciamos que para mtdblock3, mtdblock4 y mtdblock5 el sistema de ficheros utiliza yaffs2 y realiza los montajes del sistema, cache y datos. – Por otro lado monta la tarjeta SDCARD (En caso de que la tengamos) utilizando vfat. • ¿Qué dificultades podemos encontrarnos? – Si no tenemos un dispositivo rooteado, no podremos realizar ninguna operación que requiera lectura/escritura de los datos almacenados. • ¿Cómo damos el primer paso? – Utilizando NanDroid para traernos una imagen del sistema • Proceso tedioso, ya que necesitamos desbloquear el bootloader, flashear la imagen del sistema, etc. • Utilizando el comando DD.
Obteniendo información • Antes de realizar nada, vamos a sacar información de los directorios /dev y /proc • Cada dispositivo cuenta con una versión ro (read only) asociada al dispositivo original, así tenemos mtd0 con mtd0ro, etc.
Obteniendo información • Para ver a qué directorio está asociado cada punto de montaje ejecutamos un cat /proc/mtd.
Realizando una correlación • Utilizando el comando dd vamos a traernos una imagen de los distintos puntos de montaje: – Mtd0 – misc # dd if=/dev/mtd/mtd0 of=/sdcard/misc.img bs=2048 dd if=/dev/mtd/mtd0 of=/sdcard/misc.img bs=2048 448+0 records in 448+0 records out 917504 bytes transferred in 0.354 secs (2591819 bytes/sec) – Mtd1 – recovery # dd if=/dev/mtd/mtd1 of=/sdcard/recovery.img bs=2048 dd if=/dev/mtd/mtd1 of=/sdcard/recovery.img bs=2048 2048+0 records in 2048+0 records out 4194304 bytes transferred in 1.238 secs (3387967 bytes/sec)
Realizando una correlación Mtd2 – boot # dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=2048 dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=2048 1792+0 records in 1792+0 records out 3670016 bytes transferred in 1.038 secs (3535660 bytes/sec) Mtd3 – system # dd if=/dev/mtd/mtd3 of=/sdcard/system.img bs=2048 dd if=/dev/mtd/mtd3 of=/sdcard/system.img bs=2048 74240+0 records in 74240+0 records out 152043520 bytes transferred in 122.245 secs (1243760 bytes/sec)
Realizando una correlación – Mtd4 – cache # dd if=/dev/mtd/mtd4 of=/sdcard/cache.img bs=2048 dd if=/dev/mtd/mtd4 of=/sdcard/cache.img bs=2048 48640+0 records in 48640+0 records out 99614720 bytes transferred in 69.614 secs (1430958 bytes/sec) – Mtd5 – userdata # dd if=/dev/mtd/mtd5 of=/sdcard/userdata.img bs=2048 dd if=/dev/mtd/mtd5 of=/sdcard/userdata.img bs=2048 100480+0 records in 100480+0 records out 205783040 bytes transferred in 110.475 secs (1862711 bytes/sec)
Realizando una correlación • Dara como resultado: • Donde: – Boot.img Contiene los datos relativos al inicio de sistema. – Cache.img Contiene los datos volátiles que estaban en la memoria del teléfono en el momento de volcarlos a disco. – Data.img Contiene todos los datos de relativa importancia para el móvil, agenda, tareas, llamadas, mensajes, etc. – Misc.img Contiene datos relativos de las aplicaciones instaladas. – Recovery.img Contiene los datos utilizados por el recovery de nuestro teléfono. – System.img Contiene los datos relativos a la configuración del sistema.
Trayéndonos los ficheros • Es posible instalar un servicio SSH o FTP, en nuestro caso usaremos el comando pull del SDK: – Boot.img $ ./adb pull /mnt/sdcard/boot.img E:/roote/Android/RootedLab/forense/boot.img 1624 KB/s (3670016 bytes in 2.206s) – Cache.img $ ./adb pull /mnt/sdcard/cache.img E:/roote/Android/RootedLab/forense/cache.img 1902 KB/s (99614720 bytes in 51.146s) – Misc.img $ ./adb pull /mnt/sdcard/misc.img E:/roote/Android/RootedLab/forense/misc.img 1836 KB/s (917504 bytes in 0.488s) – Recovery.img $ ./adb pull /mnt/sdcard/recovery.img E:/roote/Android/RootedLab/forense/recovery.img 1873 KB/s (4194304 bytes in 2.186s) – System.img $ ./adb pull /mnt/sdcard/system.img E:/roote/Android/RootedLab/forense/system.img 1900s (152043520 bytes in 78.145s) – Userdata.img $ ./adb pull /mnt/sdcard/userdata.img E:/roote/Android/RootedLab/forense/userdata.img 1911 KB/s (205783040 bytes in 105.105s)
Extrayendo información • Podemos empezar analizando los ficheros contenidos en /data/data que contendrán la información almacenada y utilizada por las aplicaciones instaladas en nuestro teléfono. • Haremos un análisis de userdata.img. • Utilizaremos para empezar el comando strings, posteriormente sqlite3 y por último SQLite Viewer. – Buscando direcciones de correo electrónico • Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” – Buscando sitios donde se han realizado inicios de sesión • Strings userdata.img | grep –n10 “login” – Buscando parámetros de sitios visitados • strings userdata.img | grep –oE “((mailto:|(news|(ht|f)tp(s?))://){1}S+)” – Buscando números de teléfono • strings userdata.img | grep -oE "([0-9]{9})"
Extrayendo información – Buscando correos electrónicos • Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” – Buscando imágenes JPG – strings data.img | grep -oE "(.*.jpe?g|.*.JPE?G)" – Buscando paquetes de programas instalados – strings userdata.img | grep -oE "(.*.ptk?g|.*.PTK?G)" – Buscando dominios visitados – strings userdata.img | grep -oE "^[a-zA-Z0-9-.]+.(es|com|org|net|mil|edu|COM|ORG|NET|MIL|EDU)$" – Buscando tarjetas de crédito – strings userdata.img | grep -oE "^((4d{3})|(5[1-5]d{2})|(6011))-?d{4}-?d{4}-?d{4}|3[4,7]d{13}$" – Buscando direcciones MAC – strings userdata.img |grep –oE “((d|([a-f]|[A-F])){2}:){5}(d|([a-f]|[A-F])){2}” – Buscando claves WiFi • strings userdata.img | grep psk=
Jugando con BBDDs • ¿Dónde podemos encontrar los datos? – Suelen encontrarse en /data/data – Podemos averiguar su paradero exacto ejecutando: • strings –a –t –x userdata.img | grep databases | more • ¿Cómo nos hacemos un backup? – $ ./adb pull /data/data E:/roote/Android/RootedLab/forense/datosApps – En otras ocasiones será necesario instalar alguna aplicación como Terminal Emulator y ejecutar: • $ su # cp –r –L /data/data /sdcard/datosAPPForense
Auditando la BBDD del correo • ¿Dónde se encuentra? – Se encuentra en el directorio com.google.android.email/databases bajo el nombre de EmailProvider.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 EmailProvider.db • ¿Cómo vemos su contenido? • ¿Dónde se encuentra la información interesante? – En la tabla HostAuth
Auditando la BBDD de los contactos • ¿Dónde se encuentra? – Se encuentra en el directorio com.android.providers.contacts/databases bajo el nombre de contacts2.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 contacts2.db • ¿Cómo vemos su contenido?
Auditando la BBDD de los contactos • ¿Dónde se encuentra la información interesante? – Calls contiene todas las llamadas realizadas por el dispositivo. – Settings contiene información sobre las cuentas con las que tenemos sincronizados los contactos en nuestro dispositivo. – View_v1_photos contiene información referente a las fotos de los contactos que tenemos añadidos en nuestro dispositivo
Auditando la BBDD de los contactos • ¿Dónde se encuentra la información interesante? – View_v1_phones contiene todos los números de teléfono que tenemos añadidos en nuestra agenda. – View_v1_people contiene información de todos los contactos sincronizados que tenemos en nuestro dispositivo, ya sean de twitter, facebook, whatsapp o cualquier servicio que permita añadir información a la lista de contactos de nuestro teléfono
Auditando la BBDD de los mensajes • ¿Dónde se encuentra? – Se encuentra en el directorio com.android.providers.telephony/databases bajo el nombre de mmssms.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 mmssms.db • ¿Cómo vemos su contenido? • ¿Dónde se encuentra la información interesante? – A pesar de disponer de varias talbas a nosotros sólo nos interesa la llamada sms
Auditando la BBDD de los mensajes • ¿Dónde se encuentra la información interesante? • Como se puede ver los mensajes no usan ningún tipo de cifrado.
Auditando la BBDD deWhatsapp • ¿Dónde se encuentra? – Se encuentra en el directorio com.whatsapp/databases bajo el nombre de mgstore.db y wa.db • Mgstore.db contine los mensajes que han sido enviados. • Wa.db contiene información sobre nuestros contactos que poseen Whatsapp. • ¿Sólo están esos ficheros interesantes? – También hay información relevante en la carpeta shared_folders • Com.whatsapp_preferences.xml contiene las opciones de configuración que hemos establecido para nuestra cuenta asociada a la aplicación • RegisterPhone.xml contiene la información acerca del número de teléfono que hemos registrado para ser usado en whatsapp. • ¿Cómo vemos su contenido? – Para ver el contenido de los ficheros XML, basta con lanzar el comando cat por terminal para fichero que queramos ver. • RegisterPhone.xml
Auditando la BBDD de Whatsapp • ¿Cómo vemos su contenido? – Para ver el contenido de los ficheros XML, basta con lanzar el comando cat por terminal para fichero que queramos ver. • Com.whatsapp_preferences.xml
Auditando la BBDD de Whatsapp • ¿Qué información hay en la BBDD? – Comenzaremos auditando la base de datos wa.db abriendolo para ello con sqlite3. • ¿Qué estructura presenta? • ¿Qué tablas nos interesa? • ¿Qué información hay almacenada?
Auditando la BBDD de Whatsapp • ¿Qué tablas nos interesa? • ¿Qué información hay almacenada? • Nuevamente todos los mensajes van en claro y sin ningún tipo de cifrado.
Auditando la BBDD de Tuenti • Para realizar esta auditoría vamos a utilizar la aplicación SQLite Editor. • Es necesario disponer de root en el teléfono y hay que pagar una pequeña cuantía por ella. • Su funcionamiento es sencillo, primero realiza un análisis en busca de posibles bases de datos y posteriormente muestra todas las aplicaciones que contienen una.
Auditando la BBDD de Tuenti • Seleccionando la aplicación de tuenti nos mostrará las tablas disponibles por la misma, y dentro de esta las tablas que componen el esquema.
Auditando la BBDD de Tuenti • Bastará con hacer click sobre cualquiera de las tablas para obtener información sensible almacenada por la aplicación. Nosotros en concreto vamos a observar la tabla profiles. Cuyo contenido es el siguiente. • Información sobre el UID del usuario, el correo registrado, nuestro nombre y apellidos , el estado que tenemos establecido y un campo vació con el MD5 de la clave.
Auditando la BBDD de Tuenti • Otra tabla interesante es la llamada friends, donde está almacenada toda la información que nuestros amigos deciden registrar en la red social. • Si el usuario ha decidido registrar su número de teléfono en la red social, aparecerá en este campo.
Auditando la BBDD de Tuenti • Pero no todo acaba con las bases de dato, si decidimos analizar los ficheros creados por la aplicación. • Hay un fichero XML que parece de configuración com.tuenti.android.client_preferences.xml
Auditando la BBDD de Tuenti • El contenido de dicho fichero es el siguiente. • El MD5 de la clave es accesible. ¿Alguien se anima a realizar el proceso inverso?
Analizando la memoria volátil • Tradicionalmente las capturas de memoria en Linux se hacían accediendo a /dev/mem/ • Contenía un map con el primer giga de memoria. • Ya no es posible debido a problemas de seguridad. – Permitía realizar operaciones de lectura/escritura sobre el kernel. • Surge la solución de utilizar fmem – Crea un dispositivo en /dev/fmem que permite obtener la información de la memoria. • No funciona en Android
Obteniendo la memoria volátil • ¿Qué requisitos son necesarios? – No disponemos de ningún dispositivo que exponga la memoria física del teléfono al exterior. – No existe ningún tipo de API que ofrezca soporte de ningún tipo para realizar estas operaciones. – Necesitamos ejecutar código en el kernel. – Necesitamos realizar operaciones de lectura/escritura en el terminal. – Necesitamos nuevamente ser root! • ¿Cómo funciona fmem? 1. Obtiene el desplazamiento inicial especificado por la operación de lectura. 2. Comprueba que la página correspondiente a ese desplazamiento inicial corresponde a la memoria Ram física y no es parte del espacio reservado para el hardware del dispositivo. 3. Obtiene un puntero a la página física asociada al desplazamiento dado. 4. Escribe el contenido de la página obtenida en el búffer correspondiente al espacio de usuario. • ¿Qué problemas tenemos al utilizar fmem? – La función page_is_ram para realizar el punto dos, no existe en arquitecturas ARM. Luego no se puede especificar el rango de memoria que se quiere copiar. – La herramienta dd es incapaz de manejar desplazamientos en ficheros más allá de 0x800000000, sólo puede almacenar enteros de 32 bits y esto termina causando un integer overflow.
Obteniendo la memoria volátil • ¿Qué solución existe? – Utilizar Volatilitux • ¿Qué es? – Detecta automáticamente los desplazamientos en la estructura del kernel. – Permite detectar manualmente esos desplazamientos por medio de módulos que se pueden cargar en el kernel. – Soporte para múltiples arquitecturas: ARM, x86, x86 con PAE activado. – Puede ser utilizado con python para automatizar tareas o embeberlo en proyectos de mayor envergadura. • ¿Qué comandos trae? – Pslist – Muestra un listado de todos los procesos que se están ejecutando. – Memmap – Muestra el mapa de memoria de un proceso. – Memdmp – Muestra la memoria direccionable de un proceso. – Filedmp – Dumpea un fichero abierto. – Filelist - Muestra todos los ficheros abiertos para un proceso dado.
Ejecutando pslist • $ volatilitux.py -f challv2 pslist
Ejecutando memmap • $ volatilitux.py -f challv2 memmap -p 227
Ejecutando filelist • $ volatilitux.py -f challv2 filelist -p 227 | grep apk
Ejecutando filedmp • $ volatilitux.py -f challv2 filedmp -p 227 -t com.anssi.textviewer.apk -o output.apk
Desarrollo de malware • Un poco de trasfondo • ¿Cómo está planteada la seguridad? • Arquitectura de seguridad en Android • Seguridad a nivel de sistema y kernel – Seguridad de linux. – Sandboxing. – Particiones y arranque seguro. – Sistemas de ficheros basados en permisos. – Sistemas de ficheros cifrados. – Protección por contraseña. – Mejoras en la seguridad de la memoria. • ¿Qué es esto del tapjacking? – Estructura del malware a desarrollar – Desarrollando el malware.
Un poco de trasfondo • Android integrado por tres bloques – Hardware del dispositivo • Android está pensado para ser ejecutado en una amplia gama de dispositivos. – Sistema operativo Android • El núcleo está construido en la parte del kernel. • Todos los recursos del dispositivo son accesibles desde el SO. – Android Application Runtime • Aplicaciones escritas en Java. • Se ejecutan en la máquina Dalvik. • Cada aplicación obtiene un espacio privado.
Un poco de trasfondo • Las aplicaciones de Android suelen extender el núcleo del sistema operativo. • Distinguimos dos fuentes primarias de aplicaciones – Aplicaciones pre-instaladas • Aplicaciones instaladas por defecto en los terminales. • Teléfono, email, calendario, contactos, navegador, etc. • Suelen ser desarrolladas por un fabricante específico. • Otras veces forman parte del código fuente abierto del sistema. – Aplicaciones instaladas por el usuario • Se ofrece un amplio entorno de desarrollo a los usuarios. • Market de Android.
Un poco de trasfondo • Por otro lado Google ofrece una serie de servicios en la nube que permiten mejorar la experiencia del usuario. – Android Market • Colección de servicios que permiten descubrir, instalar nuevas aplicaciones para sus terminales Android. • Posee una comunidad que valora y comenta cada aplicación. • Licencia de verificación para comprobar si las aplicaciones han sido compradas o no. – Actualizaciones Android • Nuevas actualizaciones de seguridad para el sistema. • Bien a través de la web o a través de OTA’s – Servicio de aplicaciones • Frameworks que permiten a las aplicaciones usar características en la nube. • Hacer backups, configuraciones del terminal, envío de mensajes.
Cómo está planteada la seguridad • La seguridad del sistema está conformada por: – Revisión de diseño • Cada característica introducida es revisada por un ingeniero y analista de seguridad. – Revisión de código y test de intrusión • Durante el desarrollo de la plataforma , cada componente que la integra está sometido a rigurosos tests de seguridad. • El objetivo primordial es identificar cualquier tipo de vulnerabilidad o debilidad que amenace la plataforma. – Amplia comunidad Open Source • Al ser OpenSource permite que una amplia comunidad esté detrás revisando cualquier cambio realizado. – Respuesta ante incidentes • Siempre ocurren incidentes a pesar de las medidas que se tomen. • Se decide crear un sistema de respuesta ante incidentes. • Hay un equipo monitorizando constantemente las incidencias que se van enviando. • Si se descube cualquier tipo de amenaza, el equipo tiene completa libertad para actuar. • Lanzar actualizaciones del sistema, borrar aplicaciones del market, eliminar aplicaciones directamente de los terminales.
Arquitectura de seguridad en Android • El objetivo de Android es convertirse en una plataforma segura. • Reasignan los controles tradicionales de seguridad en el sistema operativo para: • Proteger los datos de los usuarios. • Proteger los recursos del sistema, incluyendo las comunicaciones. • Proporcionando el aislamiento de las aplicaciones. • Para conseguir esto, Android provee las siguientes características: • Robusta seguridad a nivel de sistema operativo gracias al kernel de linux. • Necesidad de ejecutar todas las aplicaciones en un entorno sandbox • Proceso de comunicación interno seguro. • Firmado de aplicaciones. • Necesidad de solicitud de permisos.
Seguridad a nivel de sistema y kernel • A nivel de sistema operativo, la plataforma Android ofrece seguridad a través del kernel, además de un mecanismo de comunicación entre procesos. • Esto permite limitar incluso el código nativo que se ejecuta en los dispositivos. • Si alguna aplicación trata de explotar una vulnerabilidad, el sistema impedirá que las zonas de memoria reservadas por otras aplicaciones se vean afectadas. • Pero además se incluyen otras medidas de seguridad extras: – Seguridad en Linux. – Sandboxing – Sistema de particiones y modo seguro. – Sistema de ficheros basados en permisos. – Sistema de ficheros cifrados. – Protección por contraseña. – Seguridad en la memoria.
Seguridad en Linux • La base de la plataforma Android es el kernel de Linux. • Ha sido utilizado en innumerables plataformas. • Condiciona que diversos investigadores hayan estudiado, corregido e investigado vulnerabilidades. • Como base de un entorno móvil, el kernel utilizado en Android provee una serie de mejoras: – Modelo de permisos basados en el usuario – Proceso de aislamiento. – Extenso mecanismo de seguridad para las comunicaciones entre procesos. – Capacidad para eliminar partes innecesarias y potencialmente inseguras en el núcleo.
Seguridad en Linux • Como sistema operativo multiusuario, un objetivo fundamental para la seguridad es aislar los recursos de una aplicación respecto a otras. • La filosofía aplicada en este caso es proteger los recursos de los usuarios para que no incidan ni afecten a otros: – Previene que el usuario A lea los ficheros del usuario B. – Asegura que el usuario A no agote la memoria del usuario B. – Asegura que el usuario A no agote los recursos de procesamiento del usuario B. – Asegura que el usuario A no agote los dispositivos disponibles del usuario B.
Sandboxing • Se ofrece al usuario como una ventaja para identificar y aislar los recursos de las aplicaciones. • Android asigna un identificador único a cada aplicación que ejecuta, otorgándole un espacio de memoria reservado para ello. • Esto permite establecer mayor seguridad entre las aplicaciones y el sistema. • Por defecto las aplicaciones no pueden interactuar entre sí y poseen un acceso limitado al sistema operativo. • Si una aplicación trata de invadir el espacio asignado a otra aplicación el sistema operativo se encarga de evitarlo. Gracias a los permisos y privilegios establecidos para cada aplicación.
Particiones y modo seguro • Solo es posible realizar operaciones de lectura por defecto. • Exceptuando carpetas especiales como la asignada a la tarjeta SD. • Hay disponible un modo seguro de arranque. – Sólo están disponibles las herramientas del núcleo que fueron instaladas por defecto. – Aseguramos un sistema libre de aplicaciones de tercero
Sistemas de ficheros basados en permisos • Un sistema de ficheros basado en permisos asegura: – Ningún usuario excepto el autor puede modificar o alterar el espacio reservado para una aplicación o los ficheros pertenecientes a ella. • En android cada aplicación se ejecuta bajo los permisos de un usuario específico. • A menos que el autor de una aplicación exponga implicitamente sus ficheros a aplicaciones de terceros, estos no podrán ser leídos.
Sistema de ficheros cifrados • A partir de la versión 3.0 se incluye un sistema de ficheros completamente cifrado. • Los ficheros del kernel pueden ser cifrados utilizando la implementación dmcrypt para el algoritmo AES128 con CBC y ESSIV:SHA256. • La llave de cifrado está protegida por AES128. • Para evitar ataques de fuerza bruta el password está combinado con un salt generador aleatoriamente y cifrado varias veces con SHA1 usando el algoritmo PBKDF2. • Esto es altamente configurable y el administrador del dispositivo puede decidir en todo momento si quiere cifrar o no los datos del sistema, para evitar fugas en caso de pérdidas.
Protección por contraseña • El sistema puede ser configurado para verificar la entrada de una contraseña introducida por un usuario para conseguir acceso al dispositivo. • Esta clave puede ser utilizada también para descifrar el sistema de ficheros del terminal. • Se puede configurar también patrones de desbloqueo para incrementar la seguridad.
Mejoras en la memoria • Ademas de todo lo explicado anteriormente Android incluye mejoras en la seguridad para la memoria de los dispositivos. – ASLR para aleatorizar los lugares claves de la memoria. – Hardware-based No eXecute (NX) para evitar ejecución de código en la pila y montículo. – ProPolice para evitar desbordamientos de pila. – Safe_iop para reducir los desbordamientos de enteros. – Dlmalloc para evitar vulnerabilidades del tipo double free(). – Calloc para prevenir los desbordamientos de enteros a la hora de realizar la asignación de memoria. – Mmap_min_addr() para mitigar el problema de escalación de privilegios a la hora de eliminar las referencias de punteros null.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.
Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.

Recomendados

Cloud Computing. Contenedores
Cloud Computing. ContenedoresCloud Computing. Contenedores
Cloud Computing. Contenedorespacvslideshare
 
Bii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixBii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixnuria garcia
 
Aplicaciones android
Aplicaciones androidAplicaciones android
Aplicaciones androidedwin
 
Aplicaciones Distribuídas
Aplicaciones DistribuídasAplicaciones Distribuídas
Aplicaciones DistribuídasJavierialv
 
Aplicaciones distribuidas
Aplicaciones distribuidasAplicaciones distribuidas
Aplicaciones distribuidasRaúl Guaranda Manzaba
 
Aplicaciones Distribuidas
Aplicaciones DistribuidasAplicaciones Distribuidas
Aplicaciones DistribuidasSorey García
 
P2p
P2pP2p
P2prebecach7
 
Ingeniería inversa básica en android tomo ii
Ingeniería inversa básica en android tomo iiIngeniería inversa básica en android tomo ii
Ingeniería inversa básica en android tomo iiFreelance
 

Recomendados

Cloud Computing. Contenedores
Cloud Computing. ContenedoresCloud Computing. Contenedores
Cloud Computing. Contenedorespacvslideshare
 
Bii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixBii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixnuria garcia
 
Aplicaciones android
Aplicaciones androidAplicaciones android
Aplicaciones androidedwin
 
Aplicaciones Distribuídas
Aplicaciones DistribuídasAplicaciones Distribuídas
Aplicaciones DistribuídasJavierialv
 
Aplicaciones distribuidas
Aplicaciones distribuidasAplicaciones distribuidas
Aplicaciones distribuidasRaúl Guaranda Manzaba
 
Aplicaciones Distribuidas
Aplicaciones DistribuidasAplicaciones Distribuidas
Aplicaciones DistribuidasSorey García
 
P2p
P2pP2p
P2prebecach7
 
Ingeniería inversa básica en android tomo ii
Ingeniería inversa básica en android tomo iiIngeniería inversa básica en android tomo ii
Ingeniería inversa básica en android tomo iiFreelance
 
iMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-ArchivierungiMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-Archivierungpswgroup
 
Informe herramientas tecnologias_
Informe herramientas tecnologias_Informe herramientas tecnologias_
Informe herramientas tecnologias_ncandolfi
 
Religion is natural (bloom 2007)
Religion is natural (bloom 2007)Religion is natural (bloom 2007)
Religion is natural (bloom 2007)SPK División Gráfica Digital de Surpack S.A.
 
Short Term Apartment Munich
Short Term Apartment MunichShort Term Apartment Munich
Short Term Apartment MunichGunther Kirschner
 
Full page fax print3
Full page fax print3Full page fax print3
Full page fax print3Doina Draganescu
 
Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015cabilderosciudadanos
 
Coach Armando Alvarado
Coach Armando AlvaradoCoach Armando Alvarado
Coach Armando Alvaradoescueladevalores
 
Writing for the Professions Syllabus
Writing for the Professions SyllabusWriting for the Professions Syllabus
Writing for the Professions SyllabusVinita Agarwal
 
How to promoting events on campus.
How to promoting events on campus.How to promoting events on campus.
How to promoting events on campus.silpalalan
 
Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012Antonio Palmieri
 
Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNY Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNYGeraima Espinoza-UNY
 
Matematica fcul
Matematica fculMatematica fcul
Matematica fculemantunes
 
Mitosis y meiosis
Mitosis y meiosisMitosis y meiosis
Mitosis y meiosisJuan Valencia
 
The XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar DealerThe XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar DealerMarin Luxury Cars
 
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cervezaEmprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cervezamaspixel
 
Magnetismo
MagnetismoMagnetismo
MagnetismoFisicaIVcecyt7
 
Pro-Ana y Pro-Mia
Pro-Ana y Pro-MiaPro-Ana y Pro-Mia
Pro-Ana y Pro-MiaKate P Verano
 
Arquitectura 63583.pptx
Arquitectura 63583.pptxArquitectura 63583.pptx
Arquitectura 63583.pptxlvaroTorres26
 
Presentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de TelefónicaPresentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de TelefónicaJavier Tellez Dones
 
arquitectura android y tecnologia mpls
arquitectura android y tecnologia mplsarquitectura android y tecnologia mpls
arquitectura android y tecnologia mplsjose-24
 
Android: introducción
Android: introducciónAndroid: introducción
Android: introducciónEnrique López Mañas
 
O.S Android
O.S AndroidO.S Android
O.S Androidbliys
 

Más contenido relacionado

Destacado

iMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-ArchivierungiMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-Archivierungpswgroup
 
Informe herramientas tecnologias_
Informe herramientas tecnologias_Informe herramientas tecnologias_
Informe herramientas tecnologias_ncandolfi
 
Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015cabilderosciudadanos
 
Writing for the Professions Syllabus
Writing for the Professions SyllabusWriting for the Professions Syllabus
Writing for the Professions SyllabusVinita Agarwal
 
How to promoting events on campus.
How to promoting events on campus.How to promoting events on campus.
How to promoting events on campus.silpalalan
 
Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012Antonio Palmieri
 
Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNY Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNYGeraima Espinoza-UNY
 
Matematica fcul
Matematica fculMatematica fcul
Matematica fculemantunes
 
The XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar DealerThe XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar DealerMarin Luxury Cars
 
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cervezaEmprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cervezamaspixel
 

Destacado (17)

iMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-ArchivierungiMARC - Dokumentenechte E-Mail-Archivierung
iMARC - Dokumentenechte E-Mail-Archivierung
 
Informe herramientas tecnologias_
Informe herramientas tecnologias_Informe herramientas tecnologias_
Informe herramientas tecnologias_
 
Religion is natural (bloom 2007)
Religion is natural (bloom 2007)Religion is natural (bloom 2007)
Religion is natural (bloom 2007)
 
Short Term Apartment Munich
Short Term Apartment MunichShort Term Apartment Munich
Short Term Apartment Munich
 
Full page fax print3
Full page fax print3Full page fax print3
Full page fax print3
 
Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015Columnas politicas martes 8 de diciembre de 2015
Columnas politicas martes 8 de diciembre de 2015
 
Coach Armando Alvarado
Coach Armando AlvaradoCoach Armando Alvarado
Coach Armando Alvarado
 
Writing for the Professions Syllabus
Writing for the Professions SyllabusWriting for the Professions Syllabus
Writing for the Professions Syllabus
 
How to promoting events on campus.
How to promoting events on campus.How to promoting events on campus.
How to promoting events on campus.
 
Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012Guida autoliquidazione 2011-2012
Guida autoliquidazione 2011-2012
 
Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNY Sistema Nervioso -Neurociencias -UNY
Sistema Nervioso -Neurociencias -UNY
 
Matematica fcul
Matematica fculMatematica fcul
Matematica fcul
 
Mitosis y meiosis
Mitosis y meiosisMitosis y meiosis
Mitosis y meiosis
 
The XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar DealerThe XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
The XJ at Marin Luxury Cars, a Bay Area Jaguar Dealer
 
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cervezaEmprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
Emprender haciendo SEM y SEO: Ejemplo con los cubos de cerveza
 
Magnetismo
MagnetismoMagnetismo
Magnetismo
 
Pro-Ana y Pro-Mia
Pro-Ana y Pro-MiaPro-Ana y Pro-Mia
Pro-Ana y Pro-Mia
 

Similar a Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.

Arquitectura 63583.pptx
Arquitectura 63583.pptxArquitectura 63583.pptx
Arquitectura 63583.pptxlvaroTorres26
 
Presentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de TelefónicaPresentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de TelefónicaJavier Tellez Dones
 
arquitectura android y tecnologia mpls
arquitectura android y tecnologia mplsarquitectura android y tecnologia mpls
arquitectura android y tecnologia mplsjose-24
 
O.S Android
O.S AndroidO.S Android
O.S Androidbliys
 
Desarrollo de aplicaciones en la nube
Desarrollo de aplicaciones en la nubeDesarrollo de aplicaciones en la nube
Desarrollo de aplicaciones en la nubeDaniel Cruz
 
Docker para Dummies
Docker para DummiesDocker para Dummies
Docker para DummiesRaúl Unzué
 
Reingsys framework v04_completo_new
Reingsys framework v04_completo_newReingsys framework v04_completo_new
Reingsys framework v04_completo_newReingsys
 
Deletreando Android
Deletreando AndroidDeletreando Android
Deletreando Androidjezabelink
 
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...Implementación de Cloud Computing con Software Libre y medidas de seguridad p...
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...campus party
 
Desarrollo en Android: Conceptos Básicos
Desarrollo en Android: Conceptos BásicosDesarrollo en Android: Conceptos Básicos
Desarrollo en Android: Conceptos BásicosGabriel Huecas
 
herramientas tecnológicas
herramientas tecnológicasherramientas tecnológicas
herramientas tecnológicasGerardo Linares
 
Desarrollo android - 2 - arquitectura del sistema
Desarrollo android - 2 - arquitectura del sistemaDesarrollo android - 2 - arquitectura del sistema
Desarrollo android - 2 - arquitectura del sistemaEmilio Aviles Avila
 

Similar a Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012. (20)

Arquitectura 63583.pptx
Arquitectura 63583.pptxArquitectura 63583.pptx
Arquitectura 63583.pptx
 
Presentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de TelefónicaPresentacion para la Flagship Store de Telefónica
Presentacion para la Flagship Store de Telefónica
 
arquitectura android y tecnologia mpls
arquitectura android y tecnologia mplsarquitectura android y tecnologia mpls
arquitectura android y tecnologia mpls
 
Android: introducción
Android: introducciónAndroid: introducción
Android: introducción
 
O.S Android
O.S AndroidO.S Android
O.S Android
 
S.O..pdf
S.O..pdfS.O..pdf
S.O..pdf
 
Desarrollo de aplicaciones en la nube
Desarrollo de aplicaciones en la nubeDesarrollo de aplicaciones en la nube
Desarrollo de aplicaciones en la nube
 
rojas landa vanessa.pdf
rojas landa vanessa.pdfrojas landa vanessa.pdf
rojas landa vanessa.pdf
 
Sistemas operativos
Sistemas operativosSistemas operativos
Sistemas operativos
 
Kubernetes para developers
Kubernetes para developersKubernetes para developers
Kubernetes para developers
 
Docker para Dummies
Docker para DummiesDocker para Dummies
Docker para Dummies
 
Reingsys framework v04_completo_new
Reingsys framework v04_completo_newReingsys framework v04_completo_new
Reingsys framework v04_completo_new
 
Deletreando Android
Deletreando AndroidDeletreando Android
Deletreando Android
 
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...Implementación de Cloud Computing con Software Libre y medidas de seguridad p...
Implementación de Cloud Computing con Software Libre y medidas de seguridad p...
 
Cap5 ssoo-ft
Cap5 ssoo-ftCap5 ssoo-ft
Cap5 ssoo-ft
 
Aplicaciones en red ppt
Aplicaciones en red pptAplicaciones en red ppt
Aplicaciones en red ppt
 
Desarrollo en Android: Conceptos Básicos
Desarrollo en Android: Conceptos BásicosDesarrollo en Android: Conceptos Básicos
Desarrollo en Android: Conceptos Básicos
 
herramientas tecnológicas
herramientas tecnológicasherramientas tecnológicas
herramientas tecnológicas
 
Desarrollo android - 2 - arquitectura del sistema
Desarrollo android - 2 - arquitectura del sistemaDesarrollo android - 2 - arquitectura del sistema
Desarrollo android - 2 - arquitectura del sistema
 
Introduccion Java.ppt
Introduccion Java.pptIntroduccion Java.ppt
Introduccion Java.ppt
 

Más de Internet Security Auditors

Explotando los datos como materia prima del conocimiento
Explotando los datos como materia prima del conocimientoExplotando los datos como materia prima del conocimiento
Explotando los datos como materia prima del conocimientoInternet Security Auditors
 
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligencia
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligenciaXIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligencia
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligenciaInternet Security Auditors
 
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301Internet Security Auditors
 
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOs
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOsProblemática de implementación de un SGSI o un SGCN en contact centers y BPOs
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOsInternet Security Auditors
 
PCI DSS en el Cloud: Transferencia Internacional Datos
PCI DSS en el Cloud: Transferencia Internacional DatosPCI DSS en el Cloud: Transferencia Internacional Datos
PCI DSS en el Cloud: Transferencia Internacional DatosInternet Security Auditors
 
Problematicas de PCI DSS en Contact Centers & BPO
Problematicas de PCI DSS en Contact Centers & BPOProblematicas de PCI DSS en Contact Centers & BPO
Problematicas de PCI DSS en Contact Centers & BPOInternet Security Auditors
 
Proteccion de Datos Personales: Conceptos, Sanciones, Metodologia
Proteccion de Datos Personales: Conceptos, Sanciones, MetodologiaProteccion de Datos Personales: Conceptos, Sanciones, Metodologia
Proteccion de Datos Personales: Conceptos, Sanciones, MetodologiaInternet Security Auditors
 
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)Internet Security Auditors
 
RootedCon 2017 - Workshop: IoT Insecurity of Things?
RootedCon 2017 - Workshop: IoT Insecurity of Things?RootedCon 2017 - Workshop: IoT Insecurity of Things?
RootedCon 2017 - Workshop: IoT Insecurity of Things?Internet Security Auditors
 
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCI
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCICambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCI
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCIInternet Security Auditors
 
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...Internet Security Auditors
 
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...Internet Security Auditors
 
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las Sanciones
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las SancionesConferencia sobre Protección de Datos (Bogotá): Aprendiendo de las Sanciones
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las SancionesInternet Security Auditors
 
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...Internet Security Auditors
 
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...Internet Security Auditors
 
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones Android
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones AndroidCIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones Android
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones AndroidInternet Security Auditors
 
(ISC)2 Security Congress EMEA. You are being watched.
(ISC)2 Security Congress EMEA. You are being watched.(ISC)2 Security Congress EMEA. You are being watched.
(ISC)2 Security Congress EMEA. You are being watched.Internet Security Auditors
 

Más de Internet Security Auditors (20)

Explotando los datos como materia prima del conocimiento
Explotando los datos como materia prima del conocimientoExplotando los datos como materia prima del conocimiento
Explotando los datos como materia prima del conocimiento
 
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligencia
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligenciaXIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligencia
XIII Jornadas STIC CCN-CERT. OSINT de la información a la inteligencia
 
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301
Proceso de implementación de los sistemas de gestión ISO 27001 e ISO 22301
 
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOs
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOsProblemática de implementación de un SGSI o un SGCN en contact centers y BPOs
Problemática de implementación de un SGSI o un SGCN en contact centers y BPOs
 
PCI DSS en el Cloud: Transferencia Internacional Datos
PCI DSS en el Cloud: Transferencia Internacional DatosPCI DSS en el Cloud: Transferencia Internacional Datos
PCI DSS en el Cloud: Transferencia Internacional Datos
 
Problematicas de PCI DSS en Contact Centers & BPO
Problematicas de PCI DSS en Contact Centers & BPOProblematicas de PCI DSS en Contact Centers & BPO
Problematicas de PCI DSS en Contact Centers & BPO
 
PCI DSS: Justificacion del Cumplimiento
PCI DSS: Justificacion del CumplimientoPCI DSS: Justificacion del Cumplimiento
PCI DSS: Justificacion del Cumplimiento
 
Proteccion de Datos Personales: Conceptos, Sanciones, Metodologia
Proteccion de Datos Personales: Conceptos, Sanciones, MetodologiaProteccion de Datos Personales: Conceptos, Sanciones, Metodologia
Proteccion de Datos Personales: Conceptos, Sanciones, Metodologia
 
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)
GigaTIC 2017 - Más allá del futuro: Negocio, tecnología y robótica. (Abril 2017)
 
RootedCon 2017 - Workshop: IoT Insecurity of Things?
RootedCon 2017 - Workshop: IoT Insecurity of Things?RootedCon 2017 - Workshop: IoT Insecurity of Things?
RootedCon 2017 - Workshop: IoT Insecurity of Things?
 
PCI DSS en la Nube
PCI DSS en la NubePCI DSS en la Nube
PCI DSS en la Nube
 
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCI
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCICambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCI
Cambios de las versiones 3.2, Cuestionarios y Ecosistema de Normas PCI
 
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...
Overdrive Hacking Conference 2016 - Riesgos en el uso de las Redes Sociales (...
 
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...
Conferencia sobre Protección de Datos (Bogotá): Errores comunes en la identif...
 
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las Sanciones
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las SancionesConferencia sobre Protección de Datos (Bogotá): Aprendiendo de las Sanciones
Conferencia sobre Protección de Datos (Bogotá): Aprendiendo de las Sanciones
 
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...
Catosfera 2016: Anàlisi de xarxes socials amb finalitats d'investigació: ris...
 
CIBERSEG'16. Técnicas #OSINT
CIBERSEG'16. Técnicas #OSINTCIBERSEG'16. Técnicas #OSINT
CIBERSEG'16. Técnicas #OSINT
 
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...
VI Foro Evidencias Electrónicas en la Investigación Policial. Análisis forens...
 
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones Android
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones AndroidCIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones Android
CIBERSEG '15 - Taller: Ingeniería inversa en aplicaciones Android
 
(ISC)2 Security Congress EMEA. You are being watched.
(ISC)2 Security Congress EMEA. You are being watched.(ISC)2 Security Congress EMEA. You are being watched.
(ISC)2 Security Congress EMEA. You are being watched.
 

Último

El uso delas tic en la vida cotidiana MFEL
El uso delas tic en la vida cotidiana MFELEl uso delas tic en la vida cotidiana MFEL
El uso delas tic en la vida cotidiana MFELmaryfer27m
 
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).ppt
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).pptLUXOMETRO EN SALUD OCUPACIONAL(FINAL).ppt
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).pptchaverriemily794
 
El uso de las tic en la vida ,lo importante que son
El uso de las tic en la vida ,lo importante que sonEl uso de las tic en la vida ,lo importante que son
El uso de las tic en la vida ,lo importante que son241514984
 
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptx
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptxGoogle-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptx
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptxAlexander López
 
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdf
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdfPARTES DE UN OSCILOSCOPIO ANALOGICO .pdf
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdfSergioMendoza354770
 
Presentación inteligencia artificial en la actualidad
Presentación inteligencia artificial en la actualidadPresentación inteligencia artificial en la actualidad
Presentación inteligencia artificial en la actualidadMiguelAngelVillanuev48
 
GonzalezGonzalez_Karina_M1S3AI6... .pptx
GonzalezGonzalez_Karina_M1S3AI6... .pptxGonzalezGonzalez_Karina_M1S3AI6... .pptx
GonzalezGonzalez_Karina_M1S3AI6... .pptx241523733
 
Hernandez_Hernandez_Practica web de la sesion 11.pptx
Hernandez_Hernandez_Practica web de la sesion 11.pptxHernandez_Hernandez_Practica web de la sesion 11.pptx
Hernandez_Hernandez_Practica web de la sesion 11.pptxJOSEMANUELHERNANDEZH11
 
El uso de las TIC's en la vida cotidiana.
El uso de las TIC's en la vida cotidiana.El uso de las TIC's en la vida cotidiana.
El uso de las TIC's en la vida cotidiana.241514949
 
Segunda ley de la termodinámica TERMODINAMICA.pptx
Segunda ley de la termodinámica TERMODINAMICA.pptxSegunda ley de la termodinámica TERMODINAMICA.pptx
Segunda ley de la termodinámica TERMODINAMICA.pptxMariaBurgos55
 
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptx
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptxLAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptx
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptxAlexander López
 
Tecnologias Starlink para el mundo tec.pptx
Tecnologias Starlink para el mundo tec.pptxTecnologias Starlink para el mundo tec.pptx
Tecnologias Starlink para el mundo tec.pptxGESTECPERUSAC
 
FloresMorales_Montserrath_M1S3AI6 (1).pptx
FloresMorales_Montserrath_M1S3AI6 (1).pptxFloresMorales_Montserrath_M1S3AI6 (1).pptx
FloresMorales_Montserrath_M1S3AI6 (1).pptx241522327
 
La Electricidad Y La Electrónica Trabajo Tecnología.pdf
La Electricidad Y La Electrónica Trabajo Tecnología.pdfLa Electricidad Y La Electrónica Trabajo Tecnología.pdf
La Electricidad Y La Electrónica Trabajo Tecnología.pdfjeondanny1997
 
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPO
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPOAREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPO
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPOnarvaezisabella21
 
definicion segun autores de matemáticas educativa
definicion segun autores de matemáticas educativadefinicion segun autores de matemáticas educativa
definicion segun autores de matemáticas educativaAdrianaMartnez618894
 
Arenas Camacho-Practica tarea Sesión 12.pptx
Arenas Camacho-Practica tarea Sesión 12.pptxArenas Camacho-Practica tarea Sesión 12.pptx
Arenas Camacho-Practica tarea Sesión 12.pptxJOSEFERNANDOARENASCA
 
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptxCrear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptxNombre Apellidos
 
dokumen.tips_36274588-sistema-heui-eui.ppt
dokumen.tips_36274588-sistema-heui-eui.pptdokumen.tips_36274588-sistema-heui-eui.ppt
dokumen.tips_36274588-sistema-heui-eui.pptMiguelAtencio10
 
Explorando la historia y funcionamiento de la memoria ram
Explorando la historia y funcionamiento de la memoria ramExplorando la historia y funcionamiento de la memoria ram
Explorando la historia y funcionamiento de la memoria ramDIDIERFERNANDOGUERRE
 

Último (20)

El uso delas tic en la vida cotidiana MFEL
El uso delas tic en la vida cotidiana MFELEl uso delas tic en la vida cotidiana MFEL
El uso delas tic en la vida cotidiana MFEL
 
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).ppt
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).pptLUXOMETRO EN SALUD OCUPACIONAL(FINAL).ppt
LUXOMETRO EN SALUD OCUPACIONAL(FINAL).ppt
 
El uso de las tic en la vida ,lo importante que son
El uso de las tic en la vida ,lo importante que sonEl uso de las tic en la vida ,lo importante que son
El uso de las tic en la vida ,lo importante que son
 
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptx
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptxGoogle-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptx
Google-Meet-como-herramienta-para-realizar-reuniones-virtuales.pptx
 
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdf
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdfPARTES DE UN OSCILOSCOPIO ANALOGICO .pdf
PARTES DE UN OSCILOSCOPIO ANALOGICO .pdf
 
Presentación inteligencia artificial en la actualidad
Presentación inteligencia artificial en la actualidadPresentación inteligencia artificial en la actualidad
Presentación inteligencia artificial en la actualidad
 
GonzalezGonzalez_Karina_M1S3AI6... .pptx
GonzalezGonzalez_Karina_M1S3AI6... .pptxGonzalezGonzalez_Karina_M1S3AI6... .pptx
GonzalezGonzalez_Karina_M1S3AI6... .pptx
 
Hernandez_Hernandez_Practica web de la sesion 11.pptx
Hernandez_Hernandez_Practica web de la sesion 11.pptxHernandez_Hernandez_Practica web de la sesion 11.pptx
Hernandez_Hernandez_Practica web de la sesion 11.pptx
 
El uso de las TIC's en la vida cotidiana.
El uso de las TIC's en la vida cotidiana.El uso de las TIC's en la vida cotidiana.
El uso de las TIC's en la vida cotidiana.
 
Segunda ley de la termodinámica TERMODINAMICA.pptx
Segunda ley de la termodinámica TERMODINAMICA.pptxSegunda ley de la termodinámica TERMODINAMICA.pptx
Segunda ley de la termodinámica TERMODINAMICA.pptx
 
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptx
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptxLAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptx
LAS_TIC_COMO_HERRAMIENTAS_EN_LA_INVESTIGACIÓN.pptx
 
Tecnologias Starlink para el mundo tec.pptx
Tecnologias Starlink para el mundo tec.pptxTecnologias Starlink para el mundo tec.pptx
Tecnologias Starlink para el mundo tec.pptx
 
FloresMorales_Montserrath_M1S3AI6 (1).pptx
FloresMorales_Montserrath_M1S3AI6 (1).pptxFloresMorales_Montserrath_M1S3AI6 (1).pptx
FloresMorales_Montserrath_M1S3AI6 (1).pptx
 
La Electricidad Y La Electrónica Trabajo Tecnología.pdf
La Electricidad Y La Electrónica Trabajo Tecnología.pdfLa Electricidad Y La Electrónica Trabajo Tecnología.pdf
La Electricidad Y La Electrónica Trabajo Tecnología.pdf
 
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPO
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPOAREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPO
AREA TECNOLOGIA E INFORMATICA TRABAJO EN EQUIPO
 
definicion segun autores de matemáticas educativa
definicion segun autores de matemáticas educativadefinicion segun autores de matemáticas educativa
definicion segun autores de matemáticas educativa
 
Arenas Camacho-Practica tarea Sesión 12.pptx
Arenas Camacho-Practica tarea Sesión 12.pptxArenas Camacho-Practica tarea Sesión 12.pptx
Arenas Camacho-Practica tarea Sesión 12.pptx
 
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptxCrear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
 
dokumen.tips_36274588-sistema-heui-eui.ppt
dokumen.tips_36274588-sistema-heui-eui.pptdokumen.tips_36274588-sistema-heui-eui.ppt
dokumen.tips_36274588-sistema-heui-eui.ppt
 
Explorando la historia y funcionamiento de la memoria ram
Explorando la historia y funcionamiento de la memoria ramExplorando la historia y funcionamiento de la memoria ram
Explorando la historia y funcionamiento de la memoria ram
 

Ingeniería Inversa en Android. Rooted Labs. Rooted CON 2012.

  • 1. Ingeniería Inversa en Android Sebastián Guerrero sguerrero@isecauditors.com
  • 2. Agenda 1. Introducción a la plataforma. 2. Análisis estático. 3. Análisis dinámico. 4. Análisis forense. 5. Desarrollando un malware. 2
  • 3. ¿Qué es Android? • Android es un conjunto de aplicaciones para dispositivos móviles. Entre las que se incluyen un sistema operativo, aplicaciones nativas y aplicaciones de terceros. • El SDK de Android provee de las herramientas y las APIs necesarias para comenzar a desarrollar aplicaciones para la plataforma utilizando el lenguaje de programación Java.
  • 4. Características • Framework de aplicaciones – Permite la reutilización de los componentes. • Máquina virtual de Dalvik – Optimizada para dispositivos móviles. • Navegador integrado – Basado en el motor de código libre WebKit. • Sqlite – Para almacenamiento estructurado de datos. • Soporte multimedia – audio, vídeo, imágenes (MPEG4, H.264, Mp3, AAC, AMR, JPG, PNG, GIF) • Telefonía GSM – Dependiente del hardware. • Bluetooth, EDGE, 3g, Wifi – Dependiente del hardware. • Cámara, GPS, brújula y acelerómetro – Dependiente del hardware. • Rico entorno de desarrollo – Emulador, herramientas de debugging, plugin para Eclipse, etc.
  • 5. Arquitectura • La arquitectura de la plataforma se divide en cinco niveles distintos.
  • 6. Arquitectura • Nivel 1 - Aplicaciones – Plataforma Android viene con un conjunto de aplicaciones por defecto instaladas en su núcleo (Cliente email, SMS, Calendario, Maps, Navegador, etc…). - Es el servicio mínimo que la plataforma nos puede ofrecer. - Es posible arrancar el teléfono en un entorno limpio y seguro. - Nivel 2 – Framework Aplicaciones – Acceso completo a las APIs de las aplicaciones base. – Arquitectura basada en la reutilización de componentes. – Cualquier aplicación puede hacer pública sus características. – Cualquier aplicación puede aprovechar las características de otra aplicación. – Los componentes pueden ser reemplazados por los usuarios - Nivel 3 – Bibliotecas – Conjunto de bibliotecas en C/C++ utilizadas por componentes del sistema. – Se exponen a los desarrolladores a través del framework de aplicaciones. – Bibliotecas de medios, bibliotecas de gráficos, 3D, SQLite, etc… - Nivel 4 – Runtime de Android – Compartido entre las librerías del núcleo y la máquina virtual de Dalvik. – Set de bibliotecas. – Funcionalidades incluidas en la biblioteca de Java. – Una instancia Dalvik por cada Aplicación. – Ejecución de ficheros .dex. • Nivel 5 – Kernel – Núcleo en el que se basa el sistema. – Evolucionando a través de varias versiones. – Incluye mejoras en la seguridad, administración de energía, drivers para distintos componentes hardware. – Su finalidad es ejercer como capa de abstracción entre el hardware y el resto de capas.
  • 7. Dalvik Virtual Machine • Su arquitectura está basada en registros. • Utiliza una herramienta llamada dx para convertir algunos ficheros .class en ficheros .dex • Realiza diversas optimizaciones a la hora de transformar los ficheros a .dex – Llamadas a métodos virtuales , reemplaza el índice del método por un índice de vtable. – Reemplaza llamadas a métodos como string.length() por métodos inline. – Elimina métodos vacíos – Añade datos precalculados.
  • 8. Dalvik Virtual Machine • Realiza optimización en el uso y asignación de memoria. – Tiene dividida la memoria en 4 regiones • Clean/Dirty • Shared/Private – La información en la zona llamada Clean y que es compartida de forma pública o privada contiene las librerías y los ficheros de las aplicaciones. – Por otro lado en la zona de memoria Dirty lo que encontramos son la pila, montículos y estructuras de datos de control que necesitan los ficheros .dex. • En el núcleo está el Zygote (Cigoto) que es el padre encargado de arrancar todas las máquinas virtuales Dalvik que haya en el sistema. – Carga e inicializa todas las clases utilizadas con mayor frecuencia por las aplicaciones. – Fomenta el intercambio rápido de código entre las aplicaciones. • Recolector de basura que se ejecuta en cada máquina virtual recolectando la basura que queda tras ejecutar una aplicación.
  • 9. Dalvik Virtual Machine • Arquitectura basada en registros – Requieren un promedio de 48% menos de instrucciones ejecutadas, en comparación a las Mvs basadas en pila. – El código generado es un 25% mayor, pero supone una carga del 1.07% superior para el sistema. – Tardan un promedio del 32% menos en ejecutar los benchmarks. • Google toma esta decisión en base a: – Al almacenar las instrucciones en un procesador segmentado, la sobrecarga viene dada por el tiempo que tarda en enviar las instrucciones y reducir el número de estas ejecutadas. – La verificación de los bytecodes que integran la máquina virtual es más rápida en máquinas basadas en registros.
  • 10. Principios fundamentales • Las aplicaciones de Android son escritas en el lenguaje de programación Java. • El SDK de Android es el encargado de compilar el código en un paquete con el sufijo .apk. • Los ficheros apk son considerados como aplicaciones que se instalan en los terminales. • Una vez instalado cada aplicación se ejecuta en su propia SandBox – Sistema multiusuario, cada aplicación pertenece a un usuario. – Cada aplicación tiene asignado un UID único. – Los ficheros de las aplicaciones tienen asignados unos permisos. – Solo el usuario cuyo UID esté asociado con una aplicación puede acceder a los ficheros de esta. – Cada aplicación se ejecuta en una instancia de Dalvik. – Se fomenta la independencia entre procesos y aplicaciones. • Es posible compartir información entre aplicaciones: – Pueden compartir el mismo UID, permitiendo acceder a los ficheros de ambas entre ellas. – Una aplicación puede solicitar permiso para acceder a la información de los dispositivos. – El usuario debe conceder tales permisos en tiempo de instalación.
  • 11. Anatomía de las aplicaciones • Los componentes que integran las aplicaciones son el principal núcleo de las mismas. • Hay un total de 4 componentes distintos. Donde cada uno posee un propósito distinto y tiene un ciclo de vida de creación y destrucción. – Actividades • Representa una pantalla con una interfaz de usuario – Servicios • Componentes que se ejecutan en segundo plano realizando tareas que requieren un tiempo largo de ejecución. • También pueden servir para procesar información de forma remota. – Proveedores de contenido • Manejan conjuntos de datos de las aplicaciones. • Podemos almacenar los datos en cualquier sitio que sea requerido posteriormente por nuestra aplicación. – Receptores de broadcast • Responden a mensajes de difusión en todo el sistema
  • 12. Ficheros APK • Usado para empacar las aplicaciones • Todo APK incluye: • classes.dex • resources.asc • /res • /META-INF • AndroidManifest.xml
  • 14. AndroidManifest • Todas las aplicaciones necesitan tener un fichero XML en el directorio raíz. • Es utilizado para obtener información sobre la administración y organización de la aplicación. • Existen 23 tipos predefinidos de elementos que permiten especificar y amoldar las características de la aplicación. • Todos los componentes que van a ser utilizados por la aplicación deben ser declarados aquí. • El AndroidManifest realiza otra serie de acciones adicionales – Identifica cualquier permiso que requiera la aplicación. – Declara el nivel mínimo de API que requiere la aplicación para funcionar. – Declara las características de hardware/software que va a utilizar la aplicación. – Librerías de la API que la aplicación necesita enlazar para ser utilizadas.
  • 15. Declarando los componentes • La primera tarea del AndroidManifest es informar al sistema de los componentes que integran la aplicación. • Debemos declararlos de la siguiente manera – <activity> para las actividades. – <service> para los servicios. – <receiver> para los receptores de broadcast. – <provider> para los proveedores de contenido.
  • 16. Permisos en Android • ACCESS_CHECKIN_PROPERTIES • ACCESS_COARSE_LOCATION • ACCESS_FINE_LOCATION • ACCESS_LOCATION_EXTRA_COMMANDS • ACCESS_MOCK_LOCATION • ACCESS_NETWORK_STATE • ACCESS_SURFACE_FLINGER • ACCESS_WIFI_STATE • ACCOUNT_MANAGER • ADD_VOICEMAIL • AUTHENTICATE_ACCOUNTS • BATTERY_STATS • BIND_APPWIDGET • BIND_DEVICE_ADMIN • BIND_INPUT_METHOD • BIND_REMOTEVIEWS • BIND_TEXT_SERVICE • BIND_VPN_SERVICE • BIND_WALLPAPER • BLUETOOTH • BLUETOOTH_ADMIN • BRICK • BROADCAST_PACKAGE_REMOVED • BROADCAST_SMS • BROADCAST_STICKY • BROADCAST_WAP_PUSH • CALL_PHONE CALL_PRIVILEGED CAMERA CHANGE_COMPONENT_ENABLED_STATE CHANGE_CONFIGURATION CHANGE_NETWORK_STATE CHANGE_WIFI_MULTICAST_STATE CHANGE_WIFI_STATE CLEAR_APP_CACHE CLEAR_APP_USER_DATA CONTROL_LOCATION_UPDATES DELETE_CACHE_FILES DELETE_PACKAGES DEVICE_POWER DIAGNOSTIC DISABLE_KEYGUARD DUMP EXPAND_STATUS_BAR FACTORY_TEST FLASHLIGHT FORCE_BACK GET_ACCOUNTS GET_PACKAGE_SIZE GET_TASKS GLOBAL_SEARCH HARDWARE_TEST INJECT_EVENTS INSTALL_LOCATION_PROVIDER INSTALL_PACKAGES INTERNAL_SYSTEM_WINDOW INTERNET KILL_BACKGROUND_PROCESSES MANAGE_ACCOUNTS MANAGE_APP_TOKENS MASTER_CLEAR MODIFY_AUDIO_SETTINGS MODIFY_PHONE_STATE MOUNT_FORMAT_FILESYSTEMS MOUNT_UNMOUNT_FILESYSTEMS NFC PERSISTENT_ACTIVITY PROCESS_OUTGOING_CALLS READ_CALENDAR READ_CONTACTS READ_FRAME_BUFFER READ_HISTORY_BOOKMARKS READ_INPUT_STATE READ_LOGS READ_PHONE_STATE READ_PROFILE READ_SMS READ_SOCIAL_STREAM READ_SYNC_SETTINGS READ_SYNC_STATS REBOOT RECEIVE_BOOT_COMPLETED RECEIVE_MMS RECEIVE_SMS RECEIVE_WAP_PUSH RECORD_AUDIO REORDER_TASKS RESTART_PACKAGES SEND_SMS SET_ACTIVITY_WATCHER SET_ALARM SET_ALWAYS_FINISH SET_ANIMATION_SCALE SET_DEBUG_APP SET_ORIENTATION SET_POINTER_SPEED SET_PREFERRED_APPLICATIONS SET_PROCESS_LIMIT SET_TIME SET_TIME_ZONE SET_WALLPAPER SET_WALLPAPER_HINTS SIGNAL_PERSISTENT_PROCESSES STATUS_BAR SUBSCRIBED_FEEDS_READ SUBSCRIBED_FEEDS_WRITE SYSTEM_ALERT_WINDOW UPDATE_DEVICE_STATS USE_CREDENTIALS USE_SIP VIBRATE WAKE_LOCK WRITE_APN_SETTINGS WRITE_CALENDAR WRITE_CONTACTS WRITE_EXTERNAL_STORAGE WRITE_GSERVICES WRITE_HISTORY_BOOKMARKS WRITE_PROFILE WRITE_SECURE_SETTINGS WRITE_SETTINGS WRITE_SMS WRITE_SOCIAL_STREAM WRITE_SYNC_SETTINGS
  • 17. Montando un laboratorio • Podemos hacerlo de dos maneras posibles – Máquina virtual A.R.E. (Android Reverse Engineering) • Creada por Honeynet Project • Combina las últimas herramientas de Android para analizar malware en una única caja de herramientas • Listado de aplicaciones – AndroGuard, Android sdk/ndk, APKInspector, Apktool, Axmlprinter, Ded, Dex2Jar, Droidbox, Jad, Smali/BakSmali. – Instalar las aplicaciones que necesitemos y construirnos nuestro entorno de trabajo de forma manual. • Cada una presenta sus propias ventajas y desventajas.
  • 18. Apktool • ¿Qué es? – Herramienta para hacer reversing en aplicaciones de terceros. – Permite obtener los recursos originales y empaquetarlos nuevamente tras realizarles modificaciones. – Permite realizar debug de código smali paso a paso. • ¿Cómo se instala? – Linux 1. Descargar fichero apktool-install-linux-* 2. Descargar fichero apktool-* 3. Chown +R $USER:$USER sobre cada fichero. 4. Chmod +x sobre cada fichero. 5. Descomprimimos ambos ficheros sobre el directorio /usr/local/bin (Permisos de root necesarios). • ¿Qué son los ficheros de framework? – En ocasiones ciertas aplicaciones hacen uso de código y recursos almacenados e integrados en el sistema Android que ejecuta la aplicación. – Cuando se trata de frameworks especiales, es necesario traérnoslo desde el teléfono e instalarlo en apktool. • ¿Dónde están? – /system/framework o /data/system-framework (Depende del terminal) – Nombrados como resources, res, framework, etc.
  • 19. Apktool • Uso – Para desensamblar una aplicación • d[edoce] [OPTS] <file.apk> [<dir>] – Desensambla la aplicación file.apk en el directorio dir. – -s, --no-src – No desensambla los fuentes. – -r, --no-res – No desensambla los recursos. – -d, --debug – Desensambla en modo debug. – -f. –force – Fuerza a eliminar el directorio de destino si existe. – -t <tag>, --frame-tag<tag> - Utiliza los ficheros framework etiquetados por <tag>. – --keep-broken-res – Se utiliza cuando obtenemos algún error con los recursos de una aplicación, pero queremos seguir igualmente con el proceso. – Para ensamblar una aplicación • b[uild] [OPTS] [<app_path>] [<out_files>] – Ensambla una aplicación de los fuentes que encuentr en <app_path>. Si se omite alguno de los dos directorios tomará el de por defecto. – -f, --force-all – Salta la detección de cambios en los ficheros y ensambla todos los ficheros. – -d, --debug – Ensambla en modo debug. – Para comprobar si tenemos un framework instalado o instalarlo en nuestro sistema • If|install-framework <framework.apk> [<tag>] - Instala el framework especificado en el sistema.
  • 20. Ejemplo en funcionamiento • Utilizando la aplicación framework-res.apk vamos a ejemplificar el uso de esta herramienta. 1. Desensamblamos la aplicación 1. $ apktool d framework-res.apk out I: Loading resource table... I: Loaded. I: Decoding file-resources... I: Decoding values*/* XMLs... I: Done. I: Copying assets and libs... 2. Revisamos el nuevo directorio cambiado. 1. $ ls -la total 112 drwxr-xr-x 4 sebas sebas 4096 2012-01-14 18:52 . drwxr-xr-x 4 sebas sebas 4096 2012-01-14 18:52 .. -rw-r--r-- 1 sebas sebas 46533 2012-01-14 18:52 AndroidManifest.xml -rw-r--r-- 1 sebas sebas 67 2012-01-14 18:52 apktool.yml drwxr-xr-x 5 sebas sebas 4096 2012-01-14 18:52 assets drwxr-xr-x 182 sebas sebas 32768 2012-01-14 18:52 res 1. Ensamblamos de nuevo la aplicación. 1. $ apktool b out Tool W: Could not find sources I: Checking whether resources has changed... |: Building resources... I: Building apk file... 1. Resultado de cómo ha quedado la aplicación 1. $ ls framework-res.apk out Tool
  • 21. Dex2JAR • Permite convertir el formato de ficheros .dex para Android al fomarto .class de Java. • Se compone de cuatro componentes principalmente – Dex-reader – Permite leer ficheros .dex/.odex (Ejecutables Dalvik). – Dex-translator – Realiza el trabajo de conversión. Lee las instrucciones dex, realiza procesos de optimización y finalmente realiza la conversión a ASM. – Dex-ir – Utilizado por el dex-translator, se encarga de representar las instrucciones dex. – Dex-tools – Herramientas para trabajar con los ficheros.class. • El proceso para poder obtener el código fuente es el siguiente: 1. Código fuente original (fichero .java tradicional) public String getInitParameter(String name) { ServletConfig sc = getServletConfig(); if (sc == null) { throw new IllegalStateException( lStrings.getString("err.servlet_config_not_initialized")); } return sc.getInitParameter(name); }
  • 22. Dex2JAR 2. Compilación utilizando javac (fichero .class) 0 aload_0 1 invokevirtual #2 <javax/servlet/GenericServlet.getServletConfig> 4 astore_2 5 aload_2 6 ifnonnull 25 (+19) 9 new #3 <java/lang/IllegalStateException> 12 dup 13 getstatic #4 <javax/servlet/GenericServlet.lStrings> 16 ldc #5 <err.servlet_config_not_initialized> 18 invokevirtual #6 <java/util/ResourceBundle.getString> 21 invokespecial #7 <java/lang/IllegalStateException.<init>> 24 athrow 25 aload_2 26 aload_1 27 invokeinterface #8 <javax/servlet/ServletConfig.getInitParameter> count 2 32 areturn
  • 23. Dex2JAR 3. Traducción utilizando dexdump (dx) 022644: |[022644] javax.servlet.GenericServlet.getInitParameter:(Ljava/lang/String;)Ljava/lang/String; 022654: 6e10 d703 0400 |0000: invoke-virtual {v4}, Ljavax/servlet/GenericServlet;.getServletConfig:()Ljavax/servlet/ServletConfig; // method@03d7 02265a: 0c00 |0003: move-result-object v0 02265c: 3900 1000 |0004: if-nez v0, 0014 // +0010 022660: 2201 7800 |0006: new-instance v1, Ljava/lang/IllegalStateException; // class@0078 022664: 6202 2f00 |0008: sget-object v2, Ljavax/servlet/GenericServlet;.lStrings:Ljava/util/ResourceBundle; // field@002f 022668: 1a03 2914 |000a: const-string v3, "err.servlet_config_not_initialized" // string@1429 02266c: 6e20 5103 3200 |000c: invoke-virtual {v2, v3}, Ljava/util/ResourceBundle;.getString:(Ljava/lang/String;)Ljava/lang/String; // method@0351 022672: 0c02 |000f: move-result-object v2 022674: 7020 3b01 2100 |0010: invoke-direct {v1, v2}, Ljava/lang/IllegalStateException;.<init>:(Ljava/lang/String;)V // method@013b 02267a: 2701 |0013: throw v1 02267c: 7220 e703 5000 |0014: invoke-interface {v0, v5}, Ljavax/servlet/ServletConfig;.getInitParameter:(Ljava/lang/String;)Ljava/lang/String; // method@03e7 022682: 0c01 |0017: move-result-object v1 022684: 1101 |0018: return-object v1
  • 24. Dex2JAR 4. Traducción por dex2jar (Al fichero .class nuevamente) 0 aload_0 1 invokevirtual #49 <javax/servlet/GenericServlet.getServletConfig> 4 astore_2 5 aload_2 6 ifnonnull 27 (+21) 9 getstatic #37 <javax/servlet/GenericServlet.lStrings> 12 ldc #51 <err.servlet_config_not_initialized> 14 invokevirtual #56 <java/util/ResourceBundle.getString> 17 astore_3 18 new #58 <java/lang/IllegalStateException> 21 dup 22 aload_3 23 invokespecial #61 <java/lang/IllegalStateException.<init>> 26 athrow 27 aload_2 28 aload_1 29 invokeinterface #63 <javax/servlet/ServletConfig.getInitParameter> count 2 34 areturn
  • 25. Dex2JAR 5. Traducción utilizando jd-gui public String getInitParameter(String paramString) { ServletConfig localServletConfig = getServletConfig(); if (localServletConfig == null) { String str = lStrings.getString("err.servlet_config_not_initialized"); throw new IllegalStateException(str); } return localServletConfig.getInitParameter(paramString); }
  • 26. Dex2JAR • Para instalar la aplicación – Unzip –x dexjar-version.zip –z <path_usuario> • Uso – La aplicación está integrada por un conjunto de herramientas d2j-verify-asm, d2j-dex2jar, d2j-dex-asmifier, d2j-dex- dump, d2j-jar2dex, d2j-jar2jasmin, dex2jar, dex-dump. $./dex2jar.sh ../classes.dex dex2jar version: reader-1.7, translator-0.0.9.6, ir-1.4 dex2jar ../classes.dex -> ../classes_dex2jar.jar Done. • ¿Cómo puedo modificar una aplicación con DexTool? – Es necesario tener instalado Android-sdk, ant, dex2jar, jdk6 – android create project --name test_apk --path test_apk --package a.b --activity Main --target 1 – Esto nos creará un “Hola mundo” básico. – cd test_apk ant debug cd bin – Instalamos la aplicación en el emulador.
  • 27. Trabajando con DexTools • Antes de editar el código necesitamos transformarlo a Jasmin 1. Convertimos el fichero clases.dex de la aplicación test_apk-debug.apk a test_apk-debug_dex2jar.jar d2j-dex2jar.sh test_apk-debug.apk 2. Comprobamos que el fichero .jar está correcto d2j-asm-verify.sh test_apk-debug_dex2jar.jar 3. Realizamos la conversión al formato jasmin d2j-jar2jasmin.sh -f -o test_apk_jasmin test_apk-debug_dex2jar.jar 4. Editamos el fichero “test_apk_jasmin/a/b/Main.j” para que muestre un toast. .method public onCreate(Landroid/os/Bundle;)V aload 0 aload 1 invokespecial android/app/Activity/onCreate(Landroid/os/Bundle;)V aload 0 ldc_w 2130837504 invokevirtual a/b/Main/setContentView(I)V aload 0 invokevirtual android/app/Activity/getApplicationContext()Landroid/content/Context; ldc "hi" ldc_w 1 invokestatic android/widget/Toast/makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast; invokevirtual android/widget/Toast/show()V return .limit locals 2 .limit stack 3 .end method
  • 28. Trabajando con DexTools • Ensamblamos nuevamente el APK 1. Construimos el jar d2j-jasmin2jar.sh -f -o test_apk_jasmin.jar test_apk_jasmin/ 2. Verificamos que ha sido bien construido d2j-asm-verify.sh test_apk_jasmin.jar 3. Realizamos la conversión a .dex d2j-jar2dex.sh -f -o classes.dex test_apk_jasmin.jar 4. Hacemos una copia de respaldo cp test_apk-debug.apk test_apk-debug-toast.apk 5. Reemplazamos el fichero classes.dex de la aplicación test_apk-debug-toast.apk zip -r test_apk-debug-toast.apk classes.dex 6. Eliminamos el fichero META-INF de test_apk-debug-toast.apk zip -d test_apk-debug-toast.apk "META-INF*“ 7. Generamos un key para debugging keytool -genkeypair -alias androiddebugkey -keyalg RSA -keysize 2048 -dname "CN=android-debug" -validity 100000 - keystore .ks -storepass android -keypass Android 8. Firmamos el apk jarsigner -keystore .ks -storepass android -keypass android test_apk-debug-toast.apk androiddebugkey • Ejecutamos la aplicación 1. Desinstalamos la aplicación anterior adb uninstall a.b 2. Instalamos la nueva adb install test_apk-debug-toast.apk 3. Lanzamos la actividad principal adb shell am start -n a.b/.Main
  • 29. JD-GUI • Decompilador para el lenguaje de programación Java. Provee una interfaz de línea de comandos utilizada para extraer el código fuente y los ficheros de clase. • Uso – sebas@Helios:~/Android/tools/jd-gui$ ./jd-gui -h – Usage: jd-gui [-h] [input file…] -h, --help displays this help • Para ejecutar la herramienta basta con indicar por terminal: – $ ./jd-gui ../classes_dex2jar.jar &
  • 30. DroidBox • Sandbox utilizada para ofrecer un análisis dinámico de las aplicaciones en Android. Generando la siguiente información una vez el análisis ha concluido: – Hashes para los paquetes analizados. – Datos de red entrantes/salientes. – Operaciones de lectura/escritura en ficheros. – Servicios iniciados y clases cargadas a través de DexClassLoader. – Envío de información privada a través de la red, ficheros o SMS. – Permisos. – Operaciones de criptografía utilizando la API de Android. – Broadcast receivers. – Envío de SMS y llamadas de teléfono • Generas dos imágenes que permiten visualizar el comportamiento de los paquetes.
  • 31. DroidBox • Para hacer funcionar DroidBox es necesario tener el SDK instalado y las librerías pylab y matplotlib para poder dibujar los gráficos. • Instalación – Exportar el path del SDK export PATH=$PATH:/path/to/android-sdk/tools/ export PATH=$PATH:/path/to/android-sdk/platform-tools/ – Descargar los ficheros necesarios y descomprimirlos donde sea wget http://droidbox.googlecode.com/files/DroidBox.tar.gz – Crear un nuevo emulador con Android 2.1 Android – Iniciar el emulador ./startemu.sh NameOfAVD – Cuando haya arrancado el terminal, analizar la aplicación. ./droidbox.sh file.apk
  • 32. AXMLPrinter2 • Nos devuelve el contenido del fichero AndroidManifest.xml • Uso: – $java –jar AXMLPrinter2 .jar ruta_fichero_xml
  • 33. AndroGuard • Herramienta escrita en python para jugar con – .dex (Dalvik Virtual Machine), APK (Aplicaciones Android), Ficheros XML, .class (Java Virtual Machine), JAR (Aplicación Java). • Entre sus características – Trabaja y transforma ficheros DEX/CLASS/APK/JAR en objetos Python. – Soporte nativo de código DEX, a través de librería en C++. – Análisis estático de código (instrucciónes, bloques básicos, permisos, etc…) – Comprueba si una aplicación está en una BBDD (malware, trojan, goodware…) y mide el riesgo que entraña. – Diffing de aplicaciones Android – Reverse engineering de aplicaciones. – Transforma un XML binario a un XML estándar, Dump del proceso jvm para encontrar clases en memoria. • Permite analizar, modificar y guardar aplicaciones de forma sencilla, bien sea creando nuestra propia aplicación haciendo uso de la API o utilizando androlyze a través de la línea de comandos
  • 34. Zoológico de malware • Obtener una fuente de descargas – AndroidMarket – Markets de terceros – Markets alternativos – Honeypots – Aplicaciones de orígenes desconocidos. • Automatizar las descargas. • Decompilar las aplicaciones. • Buscar strings que revelen patrones curiosos, delicados y repetitivos. • Lanzar herramienta que compruebe contra una BBDD de malware.
  • 35. Análisis estático&dinámico • Retos en el análisis estático. • Amenazas. • Técnicas de ofuscación. • Estudiando muestras de malware – Trojan.FakePlayer – NickiSpy – Foncy SMS
  • 36. Amenazas en Android • Amenazas basadas en aplicaciones • Malware • Spyware • Amenazas de privacidad • Vulnerabilidades en aplicaciones • Amenazas basadas en la web • Phishing • Drive-by-downloads • Exploits en navegadores • Amenazas basadas en las redes • Exploits para protocolos de red • Wi-fi sniffing • Amenazas físicas • Pérdida o robo del dispositivo
  • 37. Evolución malware Nombre Características Riesgo AndroidOS.FakePlayer.a AndroidOS_Droisnake.A AndroidOS.FakePlayer.b AndroidOS.FakePlayer.c Android.Geinimi Android.HongTouTou Android.Pjapps Android.DroidDream Android.BgServ Android.Zeahache Android.Walkinwat Android.Adsms Android.Zsone Android.Spacem Android.LightDD Android/DroidKungFu.A Nombre Características Riesgo Android.Basebridge Android.Uxipp Andr/Plankton-A Android.Jsmshider Android.GGTracker Android.KungFu Variants AndroidOS_Crusewin.A AndroidOS_SpyGold.A DroidDream Light Variant Android.Smssniffer Android.HippoSMS Android.Fokonge Android/Sndapps.A Android.Nickispy Android.Lovetrap Android.Premiumtext Android.NickiBot
  • 38. Técnicas de ofuscación • Nombrar ficheros de clases con el mismo nombre minúscula/mayúscula. • Cifrar las conexiones que realiza el malware utilizando DES. • Introducir comprobaciones para ver si la aplicación se está ejecutando en un emulador. • Hacer vibrar al dispositivo. • Comprobar el IMEI del terminal. • Mejorar la eficiencia del código y ofuscarlo utilizando Proguard. • Modificar el propio bytecode para inutilizar las herramientas de reversing.
  • 39. Trojan SMS-FakePlayer (*) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
  • 40. Virus total • ¿A qué nos enfrentamos? – Un buen punto de partida es subir el sample que tengamos a VirusTotal, y obtener una ligera de idea de lo que nos traemos entre manos.
  • 41. Virus Total • Sample de malware – Android FakePlayer.A • Ratio de detección – 34/43 • Nivel de amenaza – Bajo • Información – Primer malware aparecido para plataformas Android. Surge como prueba de concepto, dado que escasea de peligro alguno. Realiza el envío de mensajes de texto
  • 42. Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada? – $ tree files files ├── AndroidManifest.xml ├── classes.dex ├── META-INF │ ├── CERT.RSA │ ├── CERT.SF │ └── MANIFEST.MF ├── res │ ├── drawable │ │ └── icon.png │ └── layout │ └── main.xml └── resources.arsc
  • 43. Estructura de la aplicación • ¿Qué nos interesa a primera vista? – Desempaquetar el fichero de clases para ver su contenido. – Observar el contenido del AndroidManifest • ¿Qué sacamos con esto? – Determinar los permisos que la aplicación va a solicitar. – Hacernos una ligera idea de cómo estará estructurada la aplicación.
  • 44. Obteniendo el fichero .jar • ¿Cómo empezamos? – Primero debemos de realizar la conversión del fichero .dex a fichero .jar • ¿Cómo obtenemos el fichero .jar? – Utilizaremos dex2jar, que se encarga de realizar la conversión del fichero de clases basado en los bytecodes de Dalvik a fichero de clases Java. • Ejecutando dex2jar – $dex2jar fichero_clases.dex • ¿Dónde obtenemos la salida? – El fichero transformado estará en el mismo directorio donde la muestra que hemos proporcionado como entrada.
  • 45. Obteniendo los ficheros .class • ¿Cómo obtenemos los ficheros .class? – Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. • ¿Para qué necesitamos estos ficheros .class? – Los usaremos más adelante para transformarlos a .jad y crear un proyecto en UnderStand, que permita analizarlos. • ¿Qué son los ficheros .class? – Es el acercamiento más próximo al código original que forma la aplicación a analizar. Permitiéndonos conocer los ficheros de clases, los métodos, y las clases que integran esta.
  • 46. Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación? – $ tree class/ class/ └── org └── me └── androidapplication1 ├── DataHelper.class ├── DataHelperOpenHelper.class ├── HelloWorld.class ├── MoviePlayer.class ├── Rattr.class ├── R.class ├── Rdrawable.class ├── Rlayout.class └── Rstring.class • ¿Qué ficheros son los que nos interesan? – A priori centraremos nuestra atención en los ficheros DataHelper, HelloWorld, y MoviePlayer.
  • 47. Analizando el AndroidManifest • ¿Cómo podemos ver el contenido del fichero? – $java –jar AXMLPrinter2 .jar ruta_fichero_xml • ¿Cuál es la salida que vamos a obtener? – Obtendremos el contenido del fichero XML que contiene todas las actividades, intents, receivers y permisos que solicitará la aplicación al ser instalada, y que necesitará para el correcto funcionamiento de la misma. • ¿Qué nos permite esto? – Tener un acercamiento más profundo a la actividad que desempeñará la aplicación. – Agilitar el proceso de detección de malware, cuando nos enfrentamos a un gran número de aplicaciónes. – Montar listas negras de permisos, parseando y comprobando el contenido del fichero.
  • 48. AndroidManifest de FakePlayer • El contenido del fichero AndroidManifest – <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="org.me.androidapplication1"> <application android:icon="@7F020000"> <activity android:label="Movie Player" android:name=".MoviePlayer"> <intent-filter> <action android:name="android.intent.action.MAIN"> </action> <category android:name="android.intent.category.LAUNCHER"> </category> </intent-filter> </activity> </application> <uses-permission android:name="android.permission.SEND_SMS"> </uses-permission> </manifest>
  • 49. Obteniendo los ficheros .jad • ¿Qué es el formato .JAD? – Java Application Descriptor, extensión asociada a las aplicaciones Java ME, que suelen ser distribuidas como ficheros .JAR. Utilizados normalmente para empaquetar juegos y aplicaciones utilizadas en dispositivos móviles • ¿Para qué queremos esos ficheros? – Obteniendo ese tipo de ficheros, podemos cargarlos directamente en la aplicación Understand, para estudiar las trazas de sus funciones y clases. Además podemos abrirlos con cualquier editor de texto para trabajar sobre ellos. • ¿Cómo los podemos obtener? – Utilizando la herramienta del mismo nombre JAD (Java Decompiler). Que se encarga de extraer el código fuente de los ficheros de clases contenidos en el fichero .jar
  • 50. Obteniendo los ficheros .jad • ¿Recordáis los ficheros que descomprimimos del archivo .jar que se originó al realizar la transformación del fichero de clases para la máquina Dalvik, al fichero de clases java? • DataHelper.jad, DataHelper$OpenHelper.jad, R$attr.jad, R$drawable.jad, etc… • Es necesario eliminar el carácter $ de los ficheros, de lo contrario no obtendremos el resultado esperado con JAD – $ for i in *; do mv $i $(echo $i | tr -d '$'); done • Realizamos la transformación ejecutando JAD – $./jad ruta_ficheros/*.class • Los resultados obtenidos serán generados en el directorio donde tengamos instalada la herramienta.
  • 51. Utilizando Understand • ¿Qué es Understand? – Es una herramienta de análisis estático, que nos permite mantener, comprar y analizar proyectos de gran envergadura. • ¿Cómo lo configuramos para que acepte ficheros .jad? – Por defecto no acepta los ficheros con extensión .jad – File > New > Project • Seleccionamos nombre y directorio donde albergar nuestro proyecto. • Elegimos Java como idioma del código fuente que vamos a cargar. • Al añadir los ficheros, pulsamos sobre el botón “…” de Configure Filters • Pulsamos sobre Configure. Pulsamos sobre New: – Extension: jad ; Language: java
  • 52. Cargando FakePlayer • Una vez configurado Understand para ficheros .jad cargamos el código de FakePlayer en este. • Automáticamente nos reconoce todos los ficheros en la aplicación y nos permite visualizarlos además de ver las dependencias entre sus métodos, clases, diagramas de clase, etc.
  • 53. Dependencias internas • Para dibujar las dependencias entre clases: – Graphs > Dependency Graphs > By Directory Structure • Lo interesante parece estar en los ficheros MoviePlayer y DataHelper.
  • 55. Analizando el código • Nuestro punto de partida es el siguiente: – Sospechamos de los ficheros MoviePlayer y DataHelper. – Tenemos la ligera idea de que la muestra realiza envío de SMS. – No lo sabemos con exactitud pero es posible que se realicen operaciones contra una base de datos. • Tener una ligera idea del propósito inicial de la aplicación, nos ayudará a la hora de enfrentarnos a la muestra de malware.
  • 56. DataHelper • Observando el código extraemos – Una base de datos con nombre movieplayer.db es creada. – El nombre de la tabla donde se va a insertar la información es table1. – Cuando se crea e inicia la actividad principal de la app, se lanza la query: – CREATE TABLE table1(was TEXT PRIMARY KEY) – Cuando se actualiza la aplicación con una nueva versión, se lanza la query: – DROP TABLE IF EXISTS table1 – La query encargada de realizar inserciones en la tabla es: – INSERT INTO table1(was) VALUES (‘was’)
  • 57. MoviePlayer • Observando el código extraemos – Se carga un textView con el siguiente mensaje en ruso: “Подождите, запрашивает доступ к медиатеке..” – Ahora no hay dudas, procede de Rusia. (Captain Obvious to the rescue). – Se realizan dos llamadas al método sendTextMessage – ((SmsManager)localObject).sendTextMessage(“3353”, null, “798657”, null, null). – ((SmsManager)localObject).sendTextMessage(“3354”, null, “798657”, null, null).
  • 58. MoviePlayer – Revisando los parámetros que recibe dicho método en la API: – Public final void sendTextMessage(String destinationAddress, String scAddress, String text, PendingIntent setIntent, PendingIntent deliveryIntent). – Sabemos que los destinatarios son los números 3353 y 3354. – Para ambos destinatarios el mensaje de entrega es el número 798657. – Cuando por distintos motivos la aplicación falla y el mensaje no es entrega, se captura el error y se muestra el siguiente código: – “Oops in playsound”. – Los números del destinatario pertenecen a la empresa INcore Media Ltd (Rusia) que ofrece servicios relacionados con telefonía.
  • 59. Instalando la aplicación 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. • Emulator –port 5554 @RootedLabs –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb install foo.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se ha creado org.me.androidapplication1 , aunque actualmente está vacío y únicamente contiene una carpeta llamada lib. 4. Lanzamos una batería de pruebas contra la aplicación para ver si se producen cambios • ./adb shell moneky –v –p org.me.androidapplication1
  • 60. Instalando la aplicación 1. Realizamos una lectura del log para observar comportamientos anómalos • ./adb shell logcat D | grep SQLite 2. Del directorio padre surge una carpeta llamada databases y dentro encontramos el fichero movieplayer.db
  • 61. Realizando análisis dinámico 1. Nos traemos a local el fichero, bien usando adb o utilizando el botón de pull de la ventana File Explorer en la pestaña DDMS de Eclipse. • ./adb pull /data/data/org.me.androidapplication1/databases/movieplayer.db 2. Analizando la base de datos utilizando SQLite3, extraemos: • $ sqlite3 ./movieplayer.db SQLite version 3.7.4 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables android_metadata table1 sqlite> select * from android_metadata; en_US sqlite> select * from table1; was
  • 62. Analizando el Pcap con Wireshark • A pesar de que en esta muestra de malware, no se realiza ningún tipo de conexión con ningún C&C y no se envía ningún dato a través de Internet, en otras ocasiones este punto resulta fundamental.
  • 63. Modifiquemos el apk • El objetivo de este ejercicio será desensamblar el malware y realizarle modificaciones a nivel de código para que el mensaje de texto que envía lo realice al número del emulador (5556 en este caso), empacar la aplicación de nuevo y probarla en el emulador.
  • 64. Modifiquemos el apk • Lo primero será asegurarnos de que poseemos una llave privada con la que firmar las aplicaciones de Android. – $keytool –genkey –v –keystore millave.keystore –alias mi_alias –keyalg RSA –keysize 2048 –validity 1000 • El siguiente paso será usar apktool para desempaquetar la aplicación. – $./apktool d –d ficheroMalware.apk directorio_salida • La estructura de directorios que obtendremos después de esto será: – $ tree . . ├── AndroidManifest.xml ├── apktool.yml ├── build │ └── apk │ ├── AndroidManifest.xml │ ├── classes.dex │ ├── res │ │ ├── drawable │ │ │ └── icon.png │ │ └── layout │ │ └── main.xml │ └── resources.arsc ├── res │ ├── drawable │ │ └── icon.png │ ├── layout │ │ └── main.xml │ └── values │ ├── public.xml │ └── strings.xml └── smali └── org └── me └── androidapplication1 ├── DataHelper$OpenHelper.smali ├── DataHelper.smali ├── HelloWorld.smali ├── MoviePlayer.smali ├── R$attr.smali ├── R$drawable.smali ├── R$layout.smali ├── R.smali └── R$string.smali 13 directories, 20 files
  • 65. Modifiquemos el apk • Nosotros sólo queremos modificar los ficheros que posean el número de teléfono de destino de los SMS: • HelloWorld.smali • Línea 59 – const-string v1, “3353”. • Línea 86 – const-string v1, “3354”. • Línea 104 – const-string v1, “3353”. • MoviePlayer.smali • Línea 77 – const-string v1, “3353”. • Línea 104 – const-string v1, “3354”. • Línea 122 – const-string v1, “3353”. • Sustituimos esos valores por 5556.
  • 66. Modifiquemos el apk • Empacamos la aplicación utilizando apktool: • $apktool b –d directorio_salida Aplicación_modificada.apk • Firmamos la aplicación con la llave que creamos anteriormente: • $jarsigner –verbose –keystore millave.keystore Aplicación_modificada.apk mi_alias • Ahora podemos instalar la aplicación (PERO ANTES…) • $adb install foo.apk
  • 67. Operando entre emuladores • Para poder operar entre emuladores y que reciban SMS necesitamos: – Levantar dos máquinas • Emulator-5554 • Emulator-5556 • Instalaremos la muestra en emulator 5554 – $adb –s emulator-5554 install Aplicación_Modificada.apk
  • 68. NickiSpy (***) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
  • 69. VirusTotal • Sample de malware – Trojan/AndroidOS.Foncy • Ratio de detección – 18/43 • Nivel de amenaza – Medio • Información – Añade técnicas de ofuscación y ocultación a través de ficheros ELF camuflados en PNGs. Incluye un exploit para obtener acceso root y realiza suscripción a servicios premium de mensajes.
  • 70. Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada? – $ tree . . ├── AndroidManifest.xml ├── classes.dex ├── META-INF │ ├── CERT.RSA │ ├── CERT.SF │ └── MANIFEST.MF ├── res │ ├── drawable │ │ └── icon.png │ └── menú │ └── menu.xml └── resources.arsc 4 directories, 8 files
  • 71. Preparando el terreno • Procedemos igual que en el caso anterior – Transformamos el fichero .dex. • $dex2jar fichero_clases.dex – Obtenemos los ficheros .class. • Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. – Transformamos los ficheros .class a .jad • $ for i in *; do mv $i $(echo $i | tr -d '$'); done • $./jad ruta_ficheros/*.class – Observamos el contenido del AndroidManifest. • $java –jar AXMLPrinter2 .jar ruta_fichero_xml
  • 72. Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación? – $tree . . └── com └── nicky └── lyyws └── xmall ├── AlarmReceiver.jad ├── BootReceiver.jad ├── GpsService$1.jad ├── GpsService.jad ├── MainService$1.jad ├── MainService.jad ├── oo │ ├── CallInfo.jad │ ├── FileInfo.jad │ ├── GpsInfo.jad │ ├── HeadInfo.jad │ ├── LacInfo.jad │ ├── ParamInfo.jad │ ├── Result.jad │ ├── SmsInfo.jad │ ├── Test.jad │ └── UpInfo.jad • ¿Qué ficheros nos interesan? – A simple vista nos interesan RecordService, MainService, SocketService, SmsListener, entre otros. ├── R$attr.jad ├── R$drawable.jad ├── RecordService$1.jad ├── RecordService.jad ├── R$id.jad ├── R.jad ├── R$menu.jad ├── R$string.jad ├── SocketService$1.jad ├── SocketService$2.jad ├── SocketService$3.jad ├── SocketService$4.jad ├── SocketService$5.jad ├── SocketService.jad ├── XM_CallListener$CallContent$1.jad ├── XM_CallListener$CallContent.jad ├── XM_CallListener.jad ├── XM_CallRecordService.jad ├── XM_CallRecordService$TeleListener.jad ├── XM_SmsListener.jad └── XM_SmsListener$SmsContent.jad 5 directories, 37 files
  • 73. AndroidManifest NickiSpy • El contenido del fichero AndroidManifest: – android:name="android.permission.CALL_PHONE" android:name="android.permission.PROCESS_OUTGOING_CALLS" android:name="android.permission.INTERNET" android:name="android.permission.ACCESS_GPS" android:name="android.permission.ACCESS_COARSE_LOCATION" android:name="android.permission.ACCESS_COARSE_UPDATES" android:name="android.permission.ACCESS_FINE_LOCATION" android:name="android.permission.READ_PHONE_STATE" android:name="android.permission.READ_CONTACTS" android:name="android.permission.WRITE_CONTACTS" android:name="android.permission.ACCESS_WIFI_STATE" android:name="android.permission.PERMISSION_NAME" android:name="android.permission.SEND_SMS" android:name="android.permission.READ_SMS" android:name="android.permission.WRITE_SMS" android:name="android.permission.WAKE_LOCK" android:name="android.permission.RECORD_AUDIO" android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:name="android.permission.DEVICE_POWER"
  • 74. Dependencias internas • El peso de la aplicación recae en los ficheros SmsContent, CallContent, RecordService además de sus respectivos listeners.
  • 75. Diagrama de clases • La importancia recae en ficheros como: – RecordService – SMSLister – GPSInfo – SmsInfo – … • Es imposible hacernos una idea fijándonos en el diagrama. – Hay que profundizar en el código.
  • 76. Analizando el código • Nuestro punto de partida es el siguiente: – Tenemos diversos ficheros sospechosos a analizar: RecordService, MainService, SocketService, SmsListener, entre otros. – Sospechamos que puede realizar grabaciones de audio y enviar estas a un C&C. – Solicita acceso a los mensajes de texto y a la cartera de contactos. Al tratarse de una muestra de unas dimensiones considerables, sólo analizaremos los ficheros que presentan cierta importancia de cara a nuestra investigación.
  • 77. MainService • Observando el código extraemos – Declaración de diversas variables que hacen apuntar a un panel de control encargado de enviar comandos con las acciones a realizar. – Obtiene información de un fichero llamado XM_All_Setting (El método getSharedPreferences permite almacenar y obtener datos almacenados en forma de par clave/valor). – Dicha información apunta: – Service: jin.56mo.com – Port: 2018 – Da formato a la fecha utilizando la constante “SIMPLIFIED_CHINESE”, esto nos permite presuponer que el C&C puede ser de origen chino. – Las restantes variables de tipo booleano sirven para controlar el estado de los servicios que han sido lanzados.
  • 78. XM_CallRecordService • Observando el código extraemos – Contiene una variable llamada callpath con el valor /sdcard/shangzou/callrecord que parece apuntar a la ruta donde se almacenan las llamadas que el teléfono graba. – Realiza la comprobación del IMEI, y en caso de que este sea nulo (eso significa que se está ejecutando en un emulador) asigna por defecto el 00…00. – Almacena la información de las llamdas como el id, número, fecha, tipo, duración.
  • 79. XM_SmsListener • Observando el código extraemos – Monitoriza los mensajes tanto del outbox como del inbox. – Para cada uno de ellos recoge datos como el número de origen, el contenido y la fecha.
  • 80. GPSService • Observando el código extraemos – Un listener encargado de actualizar los datos cuando el teléfono cambia de coordenadas GPS.
  • 81. XM_CallListener • Del código destacamos – Funcionamiento similar al SmsListener, monitoriza los logs de las llamadas para obtener información como el número de origen, la duración, el tipo o la fecha.
  • 82. SocketService • Extraemos del código: – Se encarga de recoger toda la información que hemos comentado con anterioridad desde los diferentes ficheros y la envía al C&C.
  • 83. Instalando la aplicación • En esta ocasión para estudiar el funcionamiento de la muestra, vamos a levantar dos máquinas de prueba, una donde instalaremos la aplicación y otra donde realizaremos las pruebas. 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. (Esta será la máquina que infectaremos) • Emulator –port 5556 @RootedLabs_infectado –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb –s emulator-5556 install ruta/fichero.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se crea en /data/data una nueva jerarquía de directorios llamada com.nicky.lyyws.xmal/lib que actualmente está vacía.
  • 84. Instalando la aplicación 1. En este caso en particular no hay evidencias de que ninguna aplicación haya sido instalada. Para activar el malware es necesario reiniciar el terminal. 2. Tras reiniciarlo vemos en la pestaña DDMS que un nuevo paquete comienza a ejecutarse en nuestro terminal: com.nicky.lyyws.xmall 3. Una nueva carpeta es creada dentro del directorio /data/data – Bajo el nombre de shared_prefs podemos encontrar el fichero XM_All_Setting.xml 4. Volcando el contenido del fichero: – <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="Move">10</string> <string name="Service">jin.56mo.com</string> <int name="Port" value="2018" /> <string name="EndTime">23:59</string> <string name="Time">1</string> <string name="BeginTime">00:01</string> <boolean name="IsFirst" value="false" /> </map>
  • 85. Reproduciendo la actividad • Partimos de que poseemos dos máquinas virtuales – RootedLabs, emulador sin infectar, conocido internamente por emulator-5554. – RootedLabs_infectado, emulador infectado, conocido internamente por emulator-5556. • El nombre realmente no importa, si no lo sabemos, podemos ejecutar adb devices para obtenerlo.
  • 86. Reproduciendo la actividad • Desde el emulador no infectado, lanzamos el dialer para realizar llamadas • Lo hacemos pulsando sobre el botón del emulador • Introducimos el número 5556 (O el asociado al teléfono infectado, que en caso de no ser ese, podemos comprobarlo ejecutando adb devices).
  • 87. Reproduciendo la actividad • Acto seguido recibiremos una llamada en el emulador indicado, si procedemos a descolgarla estaremos simulando las llamadas entre terminales.
  • 88. Realizando análisis dinámico • Revisando la ventana FileExplorer dentro de la pestaña DDMS de Eclipse, observamos: • Se ha creado una nueva carpeta en /sdcard llamada shangzou/callrecord/. • Dentro contiene bajo el nombre de la fecha y hora exactas, la conversación grabada que hemos tenido anteriormente.
  • 89. Realizando el análisis dinámico • Por último revisamos el fichero pcap: • Al poco de ejecutarse la aplicación trata de establecer conexión con el centro de mando, enviando una petición a jin.56mo.com
  • 90. Realizando el análisis dinámico • Realiza el envío de un mensaje de texto al C&C con la palabra test
  • 91. Realizando el análisis dinámico • Realiza el envío del IMEI del teléfono en cuestión (en este caso 00…00 al tratarse de un emulador)
  • 92. Realizando el análisis dinámico • Realiza el envío de la fecha correspondiente a la que se realizó la grabación de teléfono anterior.
  • 93. Juguemos un poco • Si intentamos establecer conexión con la dirección del C&C (jin.56mo.com) obtenemos el siguiente mensaje de error. • Si establecemos conexión sin embargo con el dominio 56mo.com, obtenemos: • La cadena 您的域名因未备案或其他原因禁止访问 puede ser traducida por “Su dominio ha sido bloqueado”.
  • 94. Juguemos un poco • Lanzando un whois logramos averiguar qué: • El dominio fue creado el 2010-07.17. • El nombre de contacto al que fue registrado es: qmingdeng. • La dirección registrada es: 15B Room, B Tower Taiya Building, Xiamen, CN. • Localización: China, Provincia: Fujian, Ciudad: Xiameng, CP: 361012. • Número de teléfono: +86.5157781. • Dirección de email registrada: qmingdeng@163.com
  • 95. Sabemos dónde vives • Encadenando los datos obtenidos y jugando con Google Maps:
  • 96. Foncy-SMS (*****) Metodología 1. VirusTotal. 2. Estudiar la estructura de la aplicación. 3. Analizar el fichero AndroidManifest. 4. Understand. 5. Analizando el código. 6. Instalar la aplicación. 7. Estudiar el comportamiento.
  • 97. VirusTotal • Sample de malware – Trojan/AndroidOS.Foncy • Ratio de detección – 18/43 • Nivel de amenaza – Medio • Información – Añade técnicas de ofuscación y ocultación a través de ficheros ELF camuflados en PNGs. Incluye un exploit para obtener acceso root y realiza suscripción a servicios premium de mensajes.
  • 98. Estructura de la aplicación • ¿Qué aspecto presenta la aplicación empaquetada?
  • 99. Preparando el terreno • Procedemos igual que en el caso anterior – Transformamos el fichero .dex. • $dex2jar fichero_clases.dex – Obtenemos los ficheros .class. • Descomprimimos el fichero .jar que hemos obtenido al pasar el dex2jar. – Transformamos los ficheros .class a .jad • $ for i in *; do mv $i $(echo $i | tr -d '$'); done • $./jad ruta_ficheros/*.class – Observamos el contenido del AndroidManifest. • $java –jar AXMLPrinter2 .jar ruta_fichero_xml
  • 100. Analizando la nueva estructura • ¿Qué aspecto presenta la aplicación después de la transformación?
  • 101. AndroidManifest FoncySMS • El contenido del android manifest es el siguiente – android:name="android.permission.READ_LOGS" android:name="android.permission.READ_PHONE_STATE" android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:name="android.permission.INTERNET" android:name="android.permission.VIBRATE" android:name="android.permission.WAKE_LOCK" android:name="android.permission.ACCESS_WIFI_STATE" android:name="android.permission.CHANGE_WIFI_STATE" android:name="android.permission.CHANGE_NETWORK_STATE" android:name="android.permission.ACCESS_NETWORK_STATE" android:name="android.permission.MODIFY_AUDIO_SETTINGS" android:name="com.android.vending.CHECK_LICENSE" … • Permisos para leer el estado de los logs y el teléfono, acceso a la vibración del mismo, control sobre el estado del wifi, etc.
  • 102. Dependencias internas • El peso de la aplicación recae en el fichero AndroidBotActivity, que conecta los ficheros alojados dentro del directorio shellcommand.
  • 104. Analizando el código • Nuestro punto de partida es el siguiente: – Tenemos diversos ficheros sospechosos a analizar: AndroidBotActivity y ShellCommand – Sospechamos que puede tener funcionalidades de botnet y es posible que exista un C&C por detrás. – Aunque a simple vista y por lo que hemos analizado no podamos confirmarlo, más adelante veremos que hay muchas más características ocultas en la aplicación.
  • 105. AndroidBotActivity • Observando el código extraemos – La decompilación generada no es del todo la esperada, mostrando basura de por medio *. – Se crea una instancia de la clase ShellCommand al iniciar la actividad de la aplicación. – Se crea el directorio /data/data/com.android.bot/files con los permisos de lectura/escritura para todos los ficheros contenidos en él. – Se extraen tres ficheros bajo los nombres de: • /data/data/com.android.bot/files/header01.png (Ejecutable ELF). • /data/data/com.android.bot/file/footer01.png (Ejecutable ELF). • /data/data/com.android.bot/file/border01.png (Aplicación Android- Fichero APK) – Otorga permisos de lectura/escritura al fichero header01.png – Ejecuta el fichero. – Muestra un toast con el mensaje “(0x14) Error – Not registred application” • * El error mostrado al descompilar se sucede cuando JAD es incapaz de descomponer las construcciones como bloques etiquetados con breaks o bucles anidados controlados por sentencias break/continue, mostrando comúnmente el mensaje “Couldn’t fully decompile method” o “Couldn’t resolve all exception handlers in method” ($apktool d –d FoncySms.apk Foncy_smali )
  • 106. Shellcommand • Observando el código extraemos – Métodos encargados de realizar las labores de ejecución de los comandos que le son pasados por parámetros, además de controlar la salida y los errores de los resultados obtenidos.
  • 107. Instalando la aplicación 1. Levantamos un emulador indicando el puerto a la escucha y reenviando todas las conexiones a un fichero .pcap. (Esta será la máquina que infectaremos) • Emulator –port 5556 @RootedLabs_infectado –tcpdump foo.pcacp 2. Instalamos la aplicación • ./adb –s emulator-5556 install ruta/fichero.apk 3. Nos dirigimos a la pestaña DDMS de Eclipse y utilizamos File Explorer para ver qué directorios han sido creados en /data/data. • Se crea en /data/data una nueva jerarquía de directorios llamada com.android.bot/lib que actualmente está vacío. • En el menú de apliacciones, aparece una nueva llamada Madden NFL 12. Al ejecutarla lo único que observamos es un mensaje de “Hello World, AndroidMeActivity!” (En este caso no necesitamos simular la ejecución de eventos con ShellMonkey). 4. Observando la pestaña DDMS vemos una nueva actividad llamada com.android.bot que se está ejecutando en nuestro teléfono, y en el directorio comentado anteriormente han aparecido los ficheros creados por AndroidBotActivity.
  • 108. Instalando la aplicación • Lanzando el comando file sobre los ficheros que se han creado averiguamos: • Boomsh: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dinamically linked (uses shared libs), not stripped. • Border01.png: Zip archive data, at least v2.0 to extract. • Footer01.png: ELF 32-bit LSB executable, ARM, version 1(SYSV), dynamically linked (uses shared libs), not stripped. • Header01.png: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped. • Rooted: ASCII text • El siguiente paso es analizar esos ficheros con IDA y ver qué resultados obtenemos.
  • 109. Header01.png • Vulnerabilidad en la función handlePartitionAdded(). • Se asumía que variable part_num >= 1 para acceder a mPartMinors[]. • Pasando valor negativo referenciar y sobreescribir la memoria (GOT). • GOT almacena información de las APIs importadas. (strcmp(), atoi(), …). • Sustituimos offset de función por offset de system(). • Si pasamos como parámetro a la función la ruta de un fichero o un comando… • Dicha función solo entra en acción cuando un evento hotplug ocurre. – El demonio encargado de quedar a la escucha del socket espera recibir un paquete.
  • 110. Header01.png • Abre el fichero /proc/net/netlink y lee su contenido. • Construye strings /proc/%PID%/cmdline • Abre fichero hasta encontrar /system/bin/vold. • Parsea su contenido para recoger princpio y fin del GOT. • Llegados a este punto el atacante conoce los límites del GOT y el offset de la instrucción system(). • Realiza un ataque de fuerza bruta construyendo la cadena malformada. • El valor negativo lo utiliza para comprobar si referencia a una zona de memoria incluida dentro de los limites del GOT. • Redirige la excepción ocurrida a /data/local/tmp/crashlog. – Parsea el contenido buscando “fault addr” y compara la dirección con los límites del GOT.
  • 111. Explotando la vulnerabilidad • Se construye la cadena malformada. • Ejecuta la función system(“/data/local/tmp/boomsh”); • Comprueba si su nombre contiene el string boomsh • El troyano se ejecuta correctamente con permisos administrador. • Inicia la segunda fase de su ataque, ejecutando footer01.png
  • 112. Footer01.png • Lo primero que hace al ejecutarse es escribir 1 en el fichero /data/data/com.android.bot/files/rooted, indicando que el exploit para conseguir root ha tenido éxito.
  • 113. Footer01.png • Elimina el directorio /etc/sent para establecer posteriormente permisos de lectura/escritura (para el propietario) y permisos de sólo lectura para el resto de usuarios al fichero /data/data/com.android.bot/files/border01.png
  • 114. Footer01.png • El siguiente paso es instalar la aplicación border01.png utilizando el administrador de paquetes para ello, acto seguido lanza la actividad principal de la misma y establece un flag de activación a 1 en el fichero /etc/sent
  • 115. Footer01.png • Realiza conexión con el IRC alojado en la dirección 192.68.196.198 generando un nombre de usuario al azar para utilizarlo a la hora de hacer login en el servidor IRC. • El bot se conecta al canal #andros y queda a la espera de recibir mensajes privados con las órdenes a realizar. • Una vez el mensaje es recibido, el bot parsea su contenido (normalmente cadenas precedidas por el string PRIVMGS) para ejecutar uno de los 3 posibles comandos: – Si el bot recibe el comando sh, ejecutará el ejecutable o comando a través de una llamada a system(), devolviendo el mensaje: • PRIVMSG #andros :[SH] - %COMMAND_TO_RUN% – Si recibe el comando id, obligará al bot a devolver el ide del usuario que está ejecutando el proceso, obteniéndose con una llamada a getuid(). El mensaje que devuelve es: • PRIVMSG #andros :[ID] - %REAL_USER_ID% – Comando exit, que fuerza la salida del bot mostrando el mensaje: • PRIVMSG #andros :[EXIT] – existing ordered….
  • 116. Border01.png • Corresponde al fichero APK creado por la aplicación original. • Analizando la aplicación sin desempaquetar el fichero de clases observamos la siguiente estructura
  • 117. Border01.png • Después de hacer la correspondiente transformación del fichero de clases obtenemos lo siguiente:
  • 118. AndroidManifest Border01 • Revisando el fichero AndroidManifest que posee la aplicación descubrimos que solicita: – android:name="android.permission.RECEIVE_SMS” – android:name="android.permission.SEND_SMS“ – android:name="android.permission.INTERNET“ • Permisos para enviar/recibir mensajes de texto. • Podemos encontrarnos ante una aplicación que realiza envíos de SMS premiums además de otros datos de carácter privados.
  • 119. Diagrama de clases – Vemos que hace uso del método SMSReceiver por lo que confirmamos nuestras dudas sobre el envío de mensajes.
  • 120. Analizando la aplicación • En este caso nuestro punto de partida serán los ficheros AndroidMeActivity.jad y SMSReceiver.jad. • Podemos deducir por el nombre de que será en el segundo fichero donde esté implementada la lógico encargada del envío y recepción de mensajes de texto. • Revisando el fichero AndroidMeActivity extraemos: – Al iniciar la actividad principal, se solicita el código ISO de la ciudad. – En base a esto se establece un número Premium u otro donde realizar el envío de mensajes. – Se crea una instancia de SmsManager y se realizan un total de 5 envíos.
  • 121. Analizando la aplicación • Las ciudades a las que realiza el envío son: – Spain Number: 35024 Message: GOLD – Great Britain Number: 60999 Message: SP2 – Morocco Number: 2052 Message: CODE – Sierra Leone Number: 7604 Message: PASS – Romania Number: 1339 Message: PASS – Norway Number: 2227 Message: PASS – Sweden Number: 72225 Message: PASS – United States Number: 23333 Message: PASS
  • 122. Analizando la aplicación • Analizando el fichero SMSReceiver.class obtenemos: – Es la responsable de la lógica encargada de interceptar los mensajes de texto recibidos. – Se reservan dos campos donde se almacenan el número del destinatario y el contenido de cada SMS. – Si el número del SMS interceptado procede de 81083, 3075, 64747, 60999, 63000, 35024, 2052, 7064, 1339, 9903, 2227, 72225, 23333, entonces el broadcast se aborta. – Independientemente de que se aborte o no, el malware envía al centro de mando con IP: 46.166.146.102 el mensaje de texto y el número que ha realizado el envío, formando el string: • http://46.166.146.102/?=STR2(cuerpo mensaje)///STR1(número)
  • 123. Análisis Forense • Introducción. • Retos en el análisis forense. • Bases del sistema de ficheros. • Técnicas en el análisis forense • Jerarquía de directorios. • Analizando la memoria.
  • 124. Introducción • El análisis forense en móviles sigue la misma metodología que en los análisis convencionales: – Herramientas forenses. – Buenas prácticas. – Preservación de la información. – Aplicación de métodos. • El sector empieza a tener constancia de la importancia de estos dispositivos. • Con el auge de los smartphones, el uso intensivo de los mismos propician el uso criminal o fraudulento de ellos.
  • 125. Retos en el análisis forense • Arquitectura diferente. • Diversidad en los modelos y tecnología. • Software de análisis forense y hardware específico. • La mayoría de software de forense es de pago. • Diseño de aplicaciones específicas e incluso determinado tipo de dispositivos.
  • 126. Técnicas • Para realizar un análisis forense en condiciones, es bueno conocer técnicas como: – TimeLine Analysis. – FileSystem Analysis. – File Carving. – Strings – DataBases Analysis.
  • 127. Tarjeta SIM • Tarjeta inteligente, utilizada en teléfonos móviles. • Información para identificarnos en la red del operador, además: – IMSI – Clave autenticado – ICCID (Identificador Internacional de la tarjeta de circuito) – MSIDSN – Información sobre la localización, proveedor y llamadas. • Presentan dos mecanismos de protección – PIN – PUK • Aplicaciones para trabajar con este tipo de tarjetas: – USIM Detective – MOBILedit! – Oxygen Forensics Suite 2012
  • 128. Copiar/Clonar tarjeta SIM • Conceptos estrechamente ligados. • Copiar es generar un nuevo IMSI y Ki y copiar todo el contenido de la otra tarjeta. • Clonar es generar una tarjeta exactamente igual, mismo IMSI y Ki. • Para poder realizar este proceso – A nivel de hardware • Grabadora de PIC tipo Ludipipo. • Grabadora EEPROM. • Tarjeta con microprocesador donde poder volcar y grabar la información – A nivel de software • ICPRO - Graba el PIC • Winexplorer – Graba el EEPROM
  • 129. TimeLine Analysis • Componente fundamental para cualquier investigación. • Existen diversas maneras de realizarlo, aunque es un proceso tedioso sino se realiza con herramientas especializadas. • Dependiendo del tipo de sistemas de ficheros que utilicemos en la tarjeta SD se utilizan un tipo de herramientas u otras. • La primera fuente para crear un timeline es la información almacenada en los metadatos del sistema de ficheros. – Incluyendo la modificación, el acceso, o la modificación y creación de los ficheros.
  • 130. Jugando con los TimeStamps • ¿Qué es un timestamp? – Suelen ser una secuencia de caracteres que denotan la hora y fecha en la que ocurrió un evento determinado. – 2005-10-30 T 10:45 UTC 2007-11-09 T 11:20 UTC Sat Jul 23 02:16:57 2005 • ¿Qué otros usos tienen? – Marca digital usada en criptografía. – Código de tiempo usado en redes, o vídeos. – Tiempo universal de Linux. – ICMP TimeStamp. – Tipo de dato T-SQL, que muestra números binarios generados en una base de datos automáticamente.
  • 131. Tipos de TimeStamp • Existen 5 tipos de TimeStamps que pueden llevarnos a confusiones
  • 132. Tipos de TimeStamp • System TimeStamp – Tiempo obtenido del reloj interno del equipo. – Formato Año-Mes-Fecha-segundos-milisegundos • File Time – Intervalos de 100 nanosegundos desde el 1 de Enero de 1601. • Local – System Time • Tiempo del sistema convertido al tiempo local del sistema. – File Time • Tiempo del fichero convertido al tiempo local del sistema. • Windows – Número de milisegundos desde que se inició el sistema. • Ciclos cada 49.7 días.
  • 133. Tipos de TimeStamp • Los sistemas FAT12/FAT16 sólo tienen la fecha de la última modificación. Mientras que los sistemas FAT32 y NTFS tiene 3 tipos diferentes de timestamps: – Fecha cuando el fichero fue creado. – Fecha cuando fue accedido por última vez. – Fecha cuando fue modificado por última vez.
  • 134. Ejemplo • Tomemos como ejemplo una carpeta FAT al azar, cuyo valor para la última modificación es la siguiente. • Convirtiendo 3a75 b9 78 a binario obtenemos la siguiente representación 00111010 01110101 10111001 01111000. • Traduciendo esto a un TimeStamp válido obtenemos – 2009.03.21 23:11:48 • 7 bits = 0011101 = 29 años desde 1980. • 4 bits = 0011 = 3 meses. • 5 bits = 10101 = 21 días. • 5 bits = 10111 = 23 horas. • 6 bits = 001011 = 11 minutos. • 5 bits = 11000 = 24 = 48 segundos.
  • 135. FileSystem Analysis • Los directorios y ficheros en un sistema Android son el primer objetivo de un análisis forense. • Existen una serie de directorios que son necesarios ser examinados. – Pueden variar debido a que los sistemas van creciendo frecuentemente. • Cada teléfono es un mundo diferente. • La mejor forma de abarcar esta técnica es comprobar: – Que sistemas de ficheros están montados. – Dónde han sido montados. – Qué tipo de sistemas de ficheros son.
  • 136. Ejemplo • Analizando los puntos de montaje para un Nexus One: – Hay 5 sistemas de ficheros montados donde deberíamos enfocar nuestra investigación
  • 137. Ejemplo • Analizando un Motorola Droid – Posee 7 sistemas de ficheros interesantes a analizar.
  • 138. Comenzando la investigación • ¿Cómo establecemos entonces el punto de partida en nuestra investigación? – Es recomendable incluir los siguientes directorios en cualquier investigación forense. Punto de montaje Sistema de ficheros Importancia /proc PROC Recomendable examinarlo lanzando un cat, para obtener datos de relevancia , como metadatos con información acerca de las estadísticas del sistema. /data/data YAFFS2 Contiene toda la información de las aplicaciones. /data EXT3/EXT4/YAFFs2 Contiene los datos de aplicaciones y del sistema que han sido excluidos de /data/data /cache YAFFS2/EXT3 Ficheros de caché utilizados por algunas aplicaciones y el sistema.
  • 139. Comenzando la investigación Punto de montaje Sistema de ficheros Importancia /mnt/asec Tmpfs Ficheros descifrados pertenecientes a las aplicaciones apk. Son los mismos que están en la tarjeta SD pero descifrados debido a su uso por el sistema. /app-cache Tmpfs Temporalmente donde com.android.browser almacena su caché. Otras aplicaciones también pueden usar este directorio. /mnt/sdcard Vfat Sistema de ficheros FAT32 donde se monta la tarjeta SD. /mnt/emmc Vfat Sistema de ficheros FAT32 donde se monta el eMMC
  • 140. FileCarving • ¿En qué consiste hacer FileCarving? – Proceso cuya misión es recuperar ficheros en un escenario forense basado en el análisis en contenidos y no en metadatos. – Nos permite recuperar estructuras corruptas. • ¿Qué tipos de FileCarving existen? – Basados en bloques. – Basados en cabeceras. – Basados en pies. – Limitados en el tamaño del fichero. – Carving con validación. – Carving semántico. – Recuperación de fragmentos. – Basado en estructuras de ficheros.
  • 141. Usando Scalpe • Scalpe es una herramienta desarrollada por Golden G. Richard. • Lee un fichero de configuración para el fichero de cabecera y pie deseado con la intención de extraer los ficheros de una imagen raw. • Se puede obtener a través de : – sudo apt-get install scalpel
  • 142. Usando Scalpe • Las cabeceras del fichero de configuración definen el tipo de fichero que se trata (si es case sensitive o no), el tamaño máximo de carving, la definición de la cabecera, y el footer, si existe.
  • 143. Strings • El comando strings, por defecto nos devuelve las cadenas de un fichero que pueden ser imprimidas de cualquier fichero, texto o binario. • No es una técnica elegante o sofisticada. • Es muy efectiva cuando queremos obtener información rápida y efectiva examinando un fichero binario para hacernos una idea de lo que contiene. • Permite utilizar varios parámetros que modificarán considerablemente lo que obtendremos como salida. • Podemos automatizar búsquedas apoyándonos en expresiones regulares.
  • 144. Strings • Buscando direcciones de correo electrónico Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” • Buscando sitios donde se ha realizado inicios de sesión Strings userdata.img | grep –n10 “login” • Buscando parámetros de sitios visitados strings userdata.img | grep –oE “((mailto:|(news|(ht|f)tp(s?))://){1}S+)” • Buscando números de teléfono strings userdata.img | grep -oE "([0-9]{9})" • …
  • 150. Realizando un forense • ¿Por dónde empezamos? – Un buen punto de partida es observar los puntos de montaje
  • 151. Realizando un forense • ¿Qué información extraemos de aquí? – Apreciamos que para mtdblock3, mtdblock4 y mtdblock5 el sistema de ficheros utiliza yaffs2 y realiza los montajes del sistema, cache y datos. – Por otro lado monta la tarjeta SDCARD (En caso de que la tengamos) utilizando vfat. • ¿Qué dificultades podemos encontrarnos? – Si no tenemos un dispositivo rooteado, no podremos realizar ninguna operación que requiera lectura/escritura de los datos almacenados. • ¿Cómo damos el primer paso? – Utilizando NanDroid para traernos una imagen del sistema • Proceso tedioso, ya que necesitamos desbloquear el bootloader, flashear la imagen del sistema, etc. • Utilizando el comando DD.
  • 152. Obteniendo información • Antes de realizar nada, vamos a sacar información de los directorios /dev y /proc • Cada dispositivo cuenta con una versión ro (read only) asociada al dispositivo original, así tenemos mtd0 con mtd0ro, etc.
  • 153. Obteniendo información • Para ver a qué directorio está asociado cada punto de montaje ejecutamos un cat /proc/mtd.
  • 154. Realizando una correlación • Utilizando el comando dd vamos a traernos una imagen de los distintos puntos de montaje: – Mtd0 – misc # dd if=/dev/mtd/mtd0 of=/sdcard/misc.img bs=2048 dd if=/dev/mtd/mtd0 of=/sdcard/misc.img bs=2048 448+0 records in 448+0 records out 917504 bytes transferred in 0.354 secs (2591819 bytes/sec) – Mtd1 – recovery # dd if=/dev/mtd/mtd1 of=/sdcard/recovery.img bs=2048 dd if=/dev/mtd/mtd1 of=/sdcard/recovery.img bs=2048 2048+0 records in 2048+0 records out 4194304 bytes transferred in 1.238 secs (3387967 bytes/sec)
  • 155. Realizando una correlación Mtd2 – boot # dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=2048 dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=2048 1792+0 records in 1792+0 records out 3670016 bytes transferred in 1.038 secs (3535660 bytes/sec) Mtd3 – system # dd if=/dev/mtd/mtd3 of=/sdcard/system.img bs=2048 dd if=/dev/mtd/mtd3 of=/sdcard/system.img bs=2048 74240+0 records in 74240+0 records out 152043520 bytes transferred in 122.245 secs (1243760 bytes/sec)
  • 156. Realizando una correlación – Mtd4 – cache # dd if=/dev/mtd/mtd4 of=/sdcard/cache.img bs=2048 dd if=/dev/mtd/mtd4 of=/sdcard/cache.img bs=2048 48640+0 records in 48640+0 records out 99614720 bytes transferred in 69.614 secs (1430958 bytes/sec) – Mtd5 – userdata # dd if=/dev/mtd/mtd5 of=/sdcard/userdata.img bs=2048 dd if=/dev/mtd/mtd5 of=/sdcard/userdata.img bs=2048 100480+0 records in 100480+0 records out 205783040 bytes transferred in 110.475 secs (1862711 bytes/sec)
  • 157. Realizando una correlación • Dara como resultado: • Donde: – Boot.img Contiene los datos relativos al inicio de sistema. – Cache.img Contiene los datos volátiles que estaban en la memoria del teléfono en el momento de volcarlos a disco. – Data.img Contiene todos los datos de relativa importancia para el móvil, agenda, tareas, llamadas, mensajes, etc. – Misc.img Contiene datos relativos de las aplicaciones instaladas. – Recovery.img Contiene los datos utilizados por el recovery de nuestro teléfono. – System.img Contiene los datos relativos a la configuración del sistema.
  • 158. Trayéndonos los ficheros • Es posible instalar un servicio SSH o FTP, en nuestro caso usaremos el comando pull del SDK: – Boot.img $ ./adb pull /mnt/sdcard/boot.img E:/roote/Android/RootedLab/forense/boot.img 1624 KB/s (3670016 bytes in 2.206s) – Cache.img $ ./adb pull /mnt/sdcard/cache.img E:/roote/Android/RootedLab/forense/cache.img 1902 KB/s (99614720 bytes in 51.146s) – Misc.img $ ./adb pull /mnt/sdcard/misc.img E:/roote/Android/RootedLab/forense/misc.img 1836 KB/s (917504 bytes in 0.488s) – Recovery.img $ ./adb pull /mnt/sdcard/recovery.img E:/roote/Android/RootedLab/forense/recovery.img 1873 KB/s (4194304 bytes in 2.186s) – System.img $ ./adb pull /mnt/sdcard/system.img E:/roote/Android/RootedLab/forense/system.img 1900s (152043520 bytes in 78.145s) – Userdata.img $ ./adb pull /mnt/sdcard/userdata.img E:/roote/Android/RootedLab/forense/userdata.img 1911 KB/s (205783040 bytes in 105.105s)
  • 159. Extrayendo información • Podemos empezar analizando los ficheros contenidos en /data/data que contendrán la información almacenada y utilizada por las aplicaciones instaladas en nuestro teléfono. • Haremos un análisis de userdata.img. • Utilizaremos para empezar el comando strings, posteriormente sqlite3 y por último SQLite Viewer. – Buscando direcciones de correo electrónico • Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” – Buscando sitios donde se han realizado inicios de sesión • Strings userdata.img | grep –n10 “login” – Buscando parámetros de sitios visitados • strings userdata.img | grep –oE “((mailto:|(news|(ht|f)tp(s?))://){1}S+)” – Buscando números de teléfono • strings userdata.img | grep -oE "([0-9]{9})"
  • 160. Extrayendo información – Buscando correos electrónicos • Strings userdata.img | egrep “[a-z A-Z_-.]+@[a-z A-Z-.]+.[a-z A-Z-.]+” – Buscando imágenes JPG – strings data.img | grep -oE "(.*.jpe?g|.*.JPE?G)" – Buscando paquetes de programas instalados – strings userdata.img | grep -oE "(.*.ptk?g|.*.PTK?G)" – Buscando dominios visitados – strings userdata.img | grep -oE "^[a-zA-Z0-9-.]+.(es|com|org|net|mil|edu|COM|ORG|NET|MIL|EDU)$" – Buscando tarjetas de crédito – strings userdata.img | grep -oE "^((4d{3})|(5[1-5]d{2})|(6011))-?d{4}-?d{4}-?d{4}|3[4,7]d{13}$" – Buscando direcciones MAC – strings userdata.img |grep –oE “((d|([a-f]|[A-F])){2}:){5}(d|([a-f]|[A-F])){2}” – Buscando claves WiFi • strings userdata.img | grep psk=
  • 161. Jugando con BBDDs • ¿Dónde podemos encontrar los datos? – Suelen encontrarse en /data/data – Podemos averiguar su paradero exacto ejecutando: • strings –a –t –x userdata.img | grep databases | more • ¿Cómo nos hacemos un backup? – $ ./adb pull /data/data E:/roote/Android/RootedLab/forense/datosApps – En otras ocasiones será necesario instalar alguna aplicación como Terminal Emulator y ejecutar: • $ su # cp –r –L /data/data /sdcard/datosAPPForense
  • 162. Auditando la BBDD del correo • ¿Dónde se encuentra? – Se encuentra en el directorio com.google.android.email/databases bajo el nombre de EmailProvider.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 EmailProvider.db • ¿Cómo vemos su contenido? • ¿Dónde se encuentra la información interesante? – En la tabla HostAuth
  • 163. Auditando la BBDD de los contactos • ¿Dónde se encuentra? – Se encuentra en el directorio com.android.providers.contacts/databases bajo el nombre de contacts2.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 contacts2.db • ¿Cómo vemos su contenido?
  • 164. Auditando la BBDD de los contactos • ¿Dónde se encuentra la información interesante? – Calls contiene todas las llamadas realizadas por el dispositivo. – Settings contiene información sobre las cuentas con las que tenemos sincronizados los contactos en nuestro dispositivo. – View_v1_photos contiene información referente a las fotos de los contactos que tenemos añadidos en nuestro dispositivo
  • 165. Auditando la BBDD de los contactos • ¿Dónde se encuentra la información interesante? – View_v1_phones contiene todos los números de teléfono que tenemos añadidos en nuestra agenda. – View_v1_people contiene información de todos los contactos sincronizados que tenemos en nuestro dispositivo, ya sean de twitter, facebook, whatsapp o cualquier servicio que permita añadir información a la lista de contactos de nuestro teléfono
  • 166. Auditando la BBDD de los mensajes • ¿Dónde se encuentra? – Se encuentra en el directorio com.android.providers.telephony/databases bajo el nombre de mmssms.db • ¿Cómo la abrimos para trabajar con ella? – Lanzando el comando sqlite3 mmssms.db • ¿Cómo vemos su contenido? • ¿Dónde se encuentra la información interesante? – A pesar de disponer de varias talbas a nosotros sólo nos interesa la llamada sms
  • 167. Auditando la BBDD de los mensajes • ¿Dónde se encuentra la información interesante? • Como se puede ver los mensajes no usan ningún tipo de cifrado.
  • 168. Auditando la BBDD deWhatsapp • ¿Dónde se encuentra? – Se encuentra en el directorio com.whatsapp/databases bajo el nombre de mgstore.db y wa.db • Mgstore.db contine los mensajes que han sido enviados. • Wa.db contiene información sobre nuestros contactos que poseen Whatsapp. • ¿Sólo están esos ficheros interesantes? – También hay información relevante en la carpeta shared_folders • Com.whatsapp_preferences.xml contiene las opciones de configuración que hemos establecido para nuestra cuenta asociada a la aplicación • RegisterPhone.xml contiene la información acerca del número de teléfono que hemos registrado para ser usado en whatsapp. • ¿Cómo vemos su contenido? – Para ver el contenido de los ficheros XML, basta con lanzar el comando cat por terminal para fichero que queramos ver. • RegisterPhone.xml
  • 169. Auditando la BBDD de Whatsapp • ¿Cómo vemos su contenido? – Para ver el contenido de los ficheros XML, basta con lanzar el comando cat por terminal para fichero que queramos ver. • Com.whatsapp_preferences.xml
  • 170. Auditando la BBDD de Whatsapp • ¿Qué información hay en la BBDD? – Comenzaremos auditando la base de datos wa.db abriendolo para ello con sqlite3. • ¿Qué estructura presenta? • ¿Qué tablas nos interesa? • ¿Qué información hay almacenada?
  • 171. Auditando la BBDD de Whatsapp • ¿Qué tablas nos interesa? • ¿Qué información hay almacenada? • Nuevamente todos los mensajes van en claro y sin ningún tipo de cifrado.
  • 172. Auditando la BBDD de Tuenti • Para realizar esta auditoría vamos a utilizar la aplicación SQLite Editor. • Es necesario disponer de root en el teléfono y hay que pagar una pequeña cuantía por ella. • Su funcionamiento es sencillo, primero realiza un análisis en busca de posibles bases de datos y posteriormente muestra todas las aplicaciones que contienen una.
  • 173. Auditando la BBDD de Tuenti • Seleccionando la aplicación de tuenti nos mostrará las tablas disponibles por la misma, y dentro de esta las tablas que componen el esquema.
  • 174. Auditando la BBDD de Tuenti • Bastará con hacer click sobre cualquiera de las tablas para obtener información sensible almacenada por la aplicación. Nosotros en concreto vamos a observar la tabla profiles. Cuyo contenido es el siguiente. • Información sobre el UID del usuario, el correo registrado, nuestro nombre y apellidos , el estado que tenemos establecido y un campo vació con el MD5 de la clave.
  • 175. Auditando la BBDD de Tuenti • Otra tabla interesante es la llamada friends, donde está almacenada toda la información que nuestros amigos deciden registrar en la red social. • Si el usuario ha decidido registrar su número de teléfono en la red social, aparecerá en este campo.
  • 176. Auditando la BBDD de Tuenti • Pero no todo acaba con las bases de dato, si decidimos analizar los ficheros creados por la aplicación. • Hay un fichero XML que parece de configuración com.tuenti.android.client_preferences.xml
  • 177. Auditando la BBDD de Tuenti • El contenido de dicho fichero es el siguiente. • El MD5 de la clave es accesible. ¿Alguien se anima a realizar el proceso inverso?
  • 178. Analizando la memoria volátil • Tradicionalmente las capturas de memoria en Linux se hacían accediendo a /dev/mem/ • Contenía un map con el primer giga de memoria. • Ya no es posible debido a problemas de seguridad. – Permitía realizar operaciones de lectura/escritura sobre el kernel. • Surge la solución de utilizar fmem – Crea un dispositivo en /dev/fmem que permite obtener la información de la memoria. • No funciona en Android
  • 179. Obteniendo la memoria volátil • ¿Qué requisitos son necesarios? – No disponemos de ningún dispositivo que exponga la memoria física del teléfono al exterior. – No existe ningún tipo de API que ofrezca soporte de ningún tipo para realizar estas operaciones. – Necesitamos ejecutar código en el kernel. – Necesitamos realizar operaciones de lectura/escritura en el terminal. – Necesitamos nuevamente ser root! • ¿Cómo funciona fmem? 1. Obtiene el desplazamiento inicial especificado por la operación de lectura. 2. Comprueba que la página correspondiente a ese desplazamiento inicial corresponde a la memoria Ram física y no es parte del espacio reservado para el hardware del dispositivo. 3. Obtiene un puntero a la página física asociada al desplazamiento dado. 4. Escribe el contenido de la página obtenida en el búffer correspondiente al espacio de usuario. • ¿Qué problemas tenemos al utilizar fmem? – La función page_is_ram para realizar el punto dos, no existe en arquitecturas ARM. Luego no se puede especificar el rango de memoria que se quiere copiar. – La herramienta dd es incapaz de manejar desplazamientos en ficheros más allá de 0x800000000, sólo puede almacenar enteros de 32 bits y esto termina causando un integer overflow.
  • 180. Obteniendo la memoria volátil • ¿Qué solución existe? – Utilizar Volatilitux • ¿Qué es? – Detecta automáticamente los desplazamientos en la estructura del kernel. – Permite detectar manualmente esos desplazamientos por medio de módulos que se pueden cargar en el kernel. – Soporte para múltiples arquitecturas: ARM, x86, x86 con PAE activado. – Puede ser utilizado con python para automatizar tareas o embeberlo en proyectos de mayor envergadura. • ¿Qué comandos trae? – Pslist – Muestra un listado de todos los procesos que se están ejecutando. – Memmap – Muestra el mapa de memoria de un proceso. – Memdmp – Muestra la memoria direccionable de un proceso. – Filedmp – Dumpea un fichero abierto. – Filelist - Muestra todos los ficheros abiertos para un proceso dado.
  • 181. Ejecutando pslist • $ volatilitux.py -f challv2 pslist
  • 182. Ejecutando memmap • $ volatilitux.py -f challv2 memmap -p 227
  • 183. Ejecutando filelist • $ volatilitux.py -f challv2 filelist -p 227 | grep apk
  • 184. Ejecutando filedmp • $ volatilitux.py -f challv2 filedmp -p 227 -t com.anssi.textviewer.apk -o output.apk
  • 185. Desarrollo de malware • Un poco de trasfondo • ¿Cómo está planteada la seguridad? • Arquitectura de seguridad en Android • Seguridad a nivel de sistema y kernel – Seguridad de linux. – Sandboxing. – Particiones y arranque seguro. – Sistemas de ficheros basados en permisos. – Sistemas de ficheros cifrados. – Protección por contraseña. – Mejoras en la seguridad de la memoria. • ¿Qué es esto del tapjacking? – Estructura del malware a desarrollar – Desarrollando el malware.
  • 186. Un poco de trasfondo • Android integrado por tres bloques – Hardware del dispositivo • Android está pensado para ser ejecutado en una amplia gama de dispositivos. – Sistema operativo Android • El núcleo está construido en la parte del kernel. • Todos los recursos del dispositivo son accesibles desde el SO. – Android Application Runtime • Aplicaciones escritas en Java. • Se ejecutan en la máquina Dalvik. • Cada aplicación obtiene un espacio privado.
  • 187. Un poco de trasfondo • Las aplicaciones de Android suelen extender el núcleo del sistema operativo. • Distinguimos dos fuentes primarias de aplicaciones – Aplicaciones pre-instaladas • Aplicaciones instaladas por defecto en los terminales. • Teléfono, email, calendario, contactos, navegador, etc. • Suelen ser desarrolladas por un fabricante específico. • Otras veces forman parte del código fuente abierto del sistema. – Aplicaciones instaladas por el usuario • Se ofrece un amplio entorno de desarrollo a los usuarios. • Market de Android.
  • 188. Un poco de trasfondo • Por otro lado Google ofrece una serie de servicios en la nube que permiten mejorar la experiencia del usuario. – Android Market • Colección de servicios que permiten descubrir, instalar nuevas aplicaciones para sus terminales Android. • Posee una comunidad que valora y comenta cada aplicación. • Licencia de verificación para comprobar si las aplicaciones han sido compradas o no. – Actualizaciones Android • Nuevas actualizaciones de seguridad para el sistema. • Bien a través de la web o a través de OTA’s – Servicio de aplicaciones • Frameworks que permiten a las aplicaciones usar características en la nube. • Hacer backups, configuraciones del terminal, envío de mensajes.
  • 189. Cómo está planteada la seguridad • La seguridad del sistema está conformada por: – Revisión de diseño • Cada característica introducida es revisada por un ingeniero y analista de seguridad. – Revisión de código y test de intrusión • Durante el desarrollo de la plataforma , cada componente que la integra está sometido a rigurosos tests de seguridad. • El objetivo primordial es identificar cualquier tipo de vulnerabilidad o debilidad que amenace la plataforma. – Amplia comunidad Open Source • Al ser OpenSource permite que una amplia comunidad esté detrás revisando cualquier cambio realizado. – Respuesta ante incidentes • Siempre ocurren incidentes a pesar de las medidas que se tomen. • Se decide crear un sistema de respuesta ante incidentes. • Hay un equipo monitorizando constantemente las incidencias que se van enviando. • Si se descube cualquier tipo de amenaza, el equipo tiene completa libertad para actuar. • Lanzar actualizaciones del sistema, borrar aplicaciones del market, eliminar aplicaciones directamente de los terminales.
  • 190. Arquitectura de seguridad en Android • El objetivo de Android es convertirse en una plataforma segura. • Reasignan los controles tradicionales de seguridad en el sistema operativo para: • Proteger los datos de los usuarios. • Proteger los recursos del sistema, incluyendo las comunicaciones. • Proporcionando el aislamiento de las aplicaciones. • Para conseguir esto, Android provee las siguientes características: • Robusta seguridad a nivel de sistema operativo gracias al kernel de linux. • Necesidad de ejecutar todas las aplicaciones en un entorno sandbox • Proceso de comunicación interno seguro. • Firmado de aplicaciones. • Necesidad de solicitud de permisos.
  • 191. Seguridad a nivel de sistema y kernel • A nivel de sistema operativo, la plataforma Android ofrece seguridad a través del kernel, además de un mecanismo de comunicación entre procesos. • Esto permite limitar incluso el código nativo que se ejecuta en los dispositivos. • Si alguna aplicación trata de explotar una vulnerabilidad, el sistema impedirá que las zonas de memoria reservadas por otras aplicaciones se vean afectadas. • Pero además se incluyen otras medidas de seguridad extras: – Seguridad en Linux. – Sandboxing – Sistema de particiones y modo seguro. – Sistema de ficheros basados en permisos. – Sistema de ficheros cifrados. – Protección por contraseña. – Seguridad en la memoria.
  • 192. Seguridad en Linux • La base de la plataforma Android es el kernel de Linux. • Ha sido utilizado en innumerables plataformas. • Condiciona que diversos investigadores hayan estudiado, corregido e investigado vulnerabilidades. • Como base de un entorno móvil, el kernel utilizado en Android provee una serie de mejoras: – Modelo de permisos basados en el usuario – Proceso de aislamiento. – Extenso mecanismo de seguridad para las comunicaciones entre procesos. – Capacidad para eliminar partes innecesarias y potencialmente inseguras en el núcleo.
  • 193. Seguridad en Linux • Como sistema operativo multiusuario, un objetivo fundamental para la seguridad es aislar los recursos de una aplicación respecto a otras. • La filosofía aplicada en este caso es proteger los recursos de los usuarios para que no incidan ni afecten a otros: – Previene que el usuario A lea los ficheros del usuario B. – Asegura que el usuario A no agote la memoria del usuario B. – Asegura que el usuario A no agote los recursos de procesamiento del usuario B. – Asegura que el usuario A no agote los dispositivos disponibles del usuario B.
  • 194. Sandboxing • Se ofrece al usuario como una ventaja para identificar y aislar los recursos de las aplicaciones. • Android asigna un identificador único a cada aplicación que ejecuta, otorgándole un espacio de memoria reservado para ello. • Esto permite establecer mayor seguridad entre las aplicaciones y el sistema. • Por defecto las aplicaciones no pueden interactuar entre sí y poseen un acceso limitado al sistema operativo. • Si una aplicación trata de invadir el espacio asignado a otra aplicación el sistema operativo se encarga de evitarlo. Gracias a los permisos y privilegios establecidos para cada aplicación.
  • 195. Particiones y modo seguro • Solo es posible realizar operaciones de lectura por defecto. • Exceptuando carpetas especiales como la asignada a la tarjeta SD. • Hay disponible un modo seguro de arranque. – Sólo están disponibles las herramientas del núcleo que fueron instaladas por defecto. – Aseguramos un sistema libre de aplicaciones de tercero
  • 196. Sistemas de ficheros basados en permisos • Un sistema de ficheros basado en permisos asegura: – Ningún usuario excepto el autor puede modificar o alterar el espacio reservado para una aplicación o los ficheros pertenecientes a ella. • En android cada aplicación se ejecuta bajo los permisos de un usuario específico. • A menos que el autor de una aplicación exponga implicitamente sus ficheros a aplicaciones de terceros, estos no podrán ser leídos.
  • 197. Sistema de ficheros cifrados • A partir de la versión 3.0 se incluye un sistema de ficheros completamente cifrado. • Los ficheros del kernel pueden ser cifrados utilizando la implementación dmcrypt para el algoritmo AES128 con CBC y ESSIV:SHA256. • La llave de cifrado está protegida por AES128. • Para evitar ataques de fuerza bruta el password está combinado con un salt generador aleatoriamente y cifrado varias veces con SHA1 usando el algoritmo PBKDF2. • Esto es altamente configurable y el administrador del dispositivo puede decidir en todo momento si quiere cifrar o no los datos del sistema, para evitar fugas en caso de pérdidas.
  • 198. Protección por contraseña • El sistema puede ser configurado para verificar la entrada de una contraseña introducida por un usuario para conseguir acceso al dispositivo. • Esta clave puede ser utilizada también para descifrar el sistema de ficheros del terminal. • Se puede configurar también patrones de desbloqueo para incrementar la seguridad.
  • 199. Mejoras en la memoria • Ademas de todo lo explicado anteriormente Android incluye mejoras en la seguridad para la memoria de los dispositivos. – ASLR para aleatorizar los lugares claves de la memoria. – Hardware-based No eXecute (NX) para evitar ejecución de código en la pila y montículo. – ProPolice para evitar desbordamientos de pila. – Safe_iop para reducir los desbordamientos de enteros. – Dlmalloc para evitar vulnerabilidades del tipo double free(). – Calloc para prevenir los desbordamientos de enteros a la hora de realizar la asignación de memoria. – Mmap_min_addr() para mitigar el problema de escalación de privilegios a la hora de eliminar las referencias de punteros null.