Curso PRESENCIAL de Análisis Forense de Dispositivos Móviles

Una de las mayores demandas que tengo desde el punto de vista de peritaje y análisis forense, se centra en la actividad de smartphones. Os pongo casos reales: “mi marido me espía y creo que me ha metido un troyano en el móvil”, “necesitamos extraer la actividad de whatsapp del empleado X en el teléfono de empresa”, “la custodia de mis hijos depende de que se puedan evidenciar las amenazas que he recibido por parte de mi ex en el teléfono”, “a mi hija la acosaban por el chat de instagram”, etc,… 

Al final, el smartphone es uno de más de la familia, y como pongo de ejemplo muchas veces: se nos puede olvidar el tupper con la comida en casa, y lo solucionamos comiendo fuera y cenando en casa el tupper, pero si se nos olvida el móvil, volvemos a por él… y debido a la alta interacción (e incluso dependencia) que tenemos con él, es por lo que el dispositivo es portador de tantísimas evidencias, que pueden suponer que la moneda caiga de nuestro lado, en un proceso judicial.

Por otra parte, en Securízame, como muchos sabéis, este año hemos comenzado a impartir cursos de formación presenciales. Empecé con uno de Hardening de Sistemas GNU/Linux y ahora estamos terminando una serie de cursos de Python (para sysadmins, avanzado y para pentesters). 

Con la idea de satisfacer la demanda que soléis sugerirme sobre formación, es que el viernes 8 y el sábado 9 de Julio, voy a impartir personalmente un curso presencial de Análisis Forense de Dispositivos Móviles. Debido a la cantidad de temario que quiero cubrir, es por lo que tendrá 15 horas de duración reales, comenzando el viernes por la tarde (de 16:00 a 21:30), con un descanso a media tarde, y el sábado en modo intensivo desde las 9 AM a 21:00 PM. 

La idea es que se pierda el menor tiempo posible entre descansos y comida, por lo que TODO estará incluido en el planning: Café y refrescos para los descansos, y pizza para comer. Sólo tienes que preocuparte de ir con ganas de aprender.

Os dejo bajo estas líneas, en modo muy global, el temario que quiero cubrir:

Análisis Forense en Dispositivos Móviles

- Introducción y estándares

- Fases de peritaje de Dispositivos móviles

- Estructura de laboratorio recomendada para análisis forense de dispositivos móviles

- Análisis forense de IOS

    + Modelo de seguridad de IOS

    + IOS Internals

    + Estructuras de datos

    + Fuentes de adquisición de datos:

         - Dispositivo físico

         - Backup

         - iCloud

    + Herramientas libres de análisis de IOS

    + Artifacts de aplicaciones de usuario

- Análisis forense de Android

    + Viaje al interior de Android

    + Estructuras de datos

    + Acceso a sistemas de ficheros

    + Carving de datos

    + Los Logs en Android

    + Análisis de aplicaciones APK

    + Artifacts de aplicaciones de usuario

- Utilización de herramientas automatizadas vs. manual

    + Forense con Nowsecure Viaextract 

    + Forense con Oxygen

Si estás interesado, que sepas que a día de hoy nos quedan 8 plazas disponibles, por lo que te sugiero que no te lo pienses mucho y te registres en el siguiente enlace: 

https://cursos.securizame.com/cursos/analisis-forense-en-dispositivos- moviles/

Leer más...

Hangout: Análisis Forense en Dispositivos Android

A raíz de participar en Palabra de Hacker con Yolanda Corral, desde un grupo privado de facebook llamado "Seguridad Informática Chile", me comentaron sobre la posibilidad de estar en un Hangout para hablar de seguridad. Se fueron dando las cosas y debido a que estaba llenando de vida las aplicaciones de un Android para las demos del último módulo del Curso de Forense 2.0, les propuse que podría preparar unas slides de Análisis Forense en Android.

El resultado del Hangout que tuvimos anoche lo podéis ver en el video Youtube que os dejo bajo estas líneas.  

Tras dos horas entretenidas, fue un placer participar con la comunidad chilena, país en el que siempre me han tratado genial, y al que espero volver este año. 
Las slides que utilicé en la charla las he colgado en slideshare.

Seguridad informatica chile from Lorenzo Rodriguez

Leer más...

Análisis forense en Android con Viaextract sobre Caine 7

Si alguna vez te has planteado llevar a cabo un análisis forense en un dispositivo móvil, sobre todo Android, habrás utilizado una herramienta llamada Viaextract. Esta fantástica herramienta, originalmente de la empresa Viaforensics (actualmente llamada Nowsecure), te permite en su versión libre, extraer toda la información disponible a nivel lógico. En la versión de pago, además es capaz, entre otras funciones, de hacer un análisis utilizando extracción física.

Viaextract, habitualmente viene incorporada dentro de una distribución Linux llamada Santoku, desarrollada originalmente por Viaforensics y mantenida actualmente por Nowsecure. En la web de Nowsecure se puede descargar una máquina virtual en formato virtualbox o en formato vmware, por la que se puede utilizar directamente la herramienta, tras arrancar la máquina virtual, en modo plug and play.

Santoku es una distribución Linux específica para análisis forense, y especializada en herramientas para dispositivos móviles. Es una de mis distribuciones preferidas, fundamentalmente por la inclusión de Viaextract. Sin embargo, en mi opinión, no es tan completa para el análisis forense del resto de sistemas, por lo que en otras ocasiones he declarado mi preferencia por CAINE. Incluso en ese post hablaba de la posibilidad de incluir los repositorios de Santoku, permitiendo tener lo mejor de dos mundos, en cuanto a posibilidades de herramientas se refiere.

Al haberse publicado hace un mes la última versión de Caine, la 7, he querido incluir un procedimiento a seguir para hacer funcionar Viaextract en Caine, según lo hice para el portátil que utilizo habitualmente para peritaje y análisis forense.

Así pues, si queréis poder instalar las herramientas de Santoku Linux en Caine 7 (o en cualquier otra distro basada en Ubuntu 14.04) podéis seguir los siguientes pasos:

1.-) sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys F6D8FCF5A647374B

2.-) sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys F6D8FCF5A647374B

Con esto, recuperamos las claves públicas necesarias para poder instalar paquetes firmados por viaforensics y nowsecure.

3.-) Añadir a /etc/apt/sources.list o crear un fichero nuevo con extensión .list en /etc/apt/sources.list.d con el siguiente contenido:
deb https://apt.nowsecure.com/repo/ trusty main
# deb-src https://apt.nowsecure.com/repo/ trusty main
deb http://packages.santoku-linux.com/ubuntu trusty main

4.-) adduser santoku

Necesario puesto que el paquete viaextract hace referencia a este usuario (el que viene por defecto con contraseña santoku1 en la distro Santoku Linux)

5.-) apt-get remove android-tools-adb

La herramienta adb viene incluída por el paquete android-sdk (en los repositorios de nowsecure o de santoku, no recuerdo ahora), que es dependencia del paquete viaextract, por lo que si no eliminamos el paquete android-tools-adb, no se instalará

6.-) apt-get update && apt-get install viaextract

Varios megabytes después, se instalará viaextract. El siguiente paso será licenciar el producto correctamente, ya sea con la versión community o con la de pago, ejecutando vactivate en una terminal.

Y ya por fin, desde línea de comandos también, ejecutar viaextract o hacer un enlace directo en el escritorio (o donde más rabia os de) a /usr/bin/viaextract

Leer más...

Análisis dinámico de apps Android por hooking

Cuando nos enfrentamos a un proceso de reversing sobre una app Android una de las dificultades que podemos encontrar al hacer un análisis estático es un código complejo de trazar, ya sea por intención propia del desarrollador al escribirlo, por el uso de algún sistema de ofuscación, o incluso porque el propio proceso de decompilación ha generado un código poco legible.

Para lograr encajar las piezas de estos puzzles difíciles de resolver nos podemos apoyar en un análisis dinámico para por ejemplo identificar qué ocurre en las comunicaciones, qué cambios se producen en el sistema de ficheros, qué eventos genera la app, a cuáles responde, etc. Pero seguiremos teniendo un código muy oscuro que en algunos casos requerirá de un gran esfuerzo para determinar por ejemplo si un fragmento de código malicioso se llega a ejecutar.

Hace tiempo comentaba en un artículo cómo podíamos alterar en tiempo de ejecución el código de una app Android haciendo uso de la librería para hooking Cydia Substrate para por ejemplo desactivar el certificate pinning en Android.

Vista la capacidad de la librería, ¿porque no utilizarla para reflejar métodos y parámetros recibidos en una app que queramos analizar?, de este modo podríamos construir un árbol con el flujo de ejecución de la app según interactuamos con ella (o mientras ella misma hace sus procesos en background), identificando qué métodos llamaron a qué otros métodos además de reflejando qué valores fueron pasados como parámetros.

Con la idea clara de representar el flujo de ejecución y parámetros recibidos, decidí dar un paso más y hacerlo todo más sencillo, ¿por qué no hacer una herramienta que automatice al máximo el proceso?, podría conectarse al dispositivo, listar las apps, enumerar todas las clases que participan en una app seleccionada y permitir al analista seleccionar cuáles quiere observar...

android-hooker

Para poder utilizar la herramienta necesitaremos el siguiente entorno:

• Un dispositivo Android (físico o VM) rooteado, con Cydia Substrate instalado
• En el equipo desde el que vamos a realizar el análisis, será necesario tener Java (JRE para ejecutar o JDK si queremos modificar el proyecto) y las SDK tools de Android (con las Build Tools y una versión de la API de Android compatible con la instalada en el dispositivo)

La herramienta funciona del siguiente modo:

• Descargamos la app del repositorio de Github con el siguiente enlace (MD5: bbf563831e3d6be77c773c15f8a978e1 ) o clonamos el repositorio y lo compilamos con "mvn clean assembly:assembly" (nos generará el JAR a ejecutar en el directorio target)

• Iniciamos la aplicación con "java -jar android-hooker-1.0-jar-with-dependencies.jar". La primera vez que iniciamos la app tendremos que configurar la ruta al directorio donde tengamos el Android SDK, seleccionar la versión de las build tools que queramos utilizar y la versión del SDK que se ajuste al dispositivo que vamos a analizar:

• Lo siguiente que hacemos es introducir la IP del dispositivo a analizar (o dejarlo vacío si nos vamos a conectar a un dispositivo físico conectado en modo depuración) y seleccionamos la opción Connect, nos listará las apps instaladas en el dispositivo:

• Seleccionamos la app que queremos analizar y seguimos con el botón Extract classes from APK, descargará la app del dispositivo y podremos seleccionar las clases que queremos hookear. Ya casi hemos terminado, seleccionamos las clases que nos interesen y le damos a Hook classes:

En este punto es donde sucede la magia, dentro de android-hooker hay incluida una app Android que será compilada e instalada en el dispositivo. La app Android está preparada con un plugin Substrate diseñado para recibir un listado de clases sobre los que aplicará reflection para hookear todos sus métodos y crear así una traza dejando un rastro en el logcat que posteriormente android-hooker utilizará para crear el árbol de ejecución.

• Cuando se compile e instale la app Android veremos la notificación de Substrate en el dispositivo:

• En este momento ya podemos seleccionar en android-hooker la opción Watch logcat y reiniciar el dispositivo para que se aplique el plugin. En cuanto los métodos hookeados sean llamados comenzaremos a verlos reflejados en pantalla:

Dejo también un vídeo para que lo podáis ver en marcha:

Detalles finales

En cuanto al uso de la tool en sí, como toda herramienta "automatizada", recomiendo hacer un uso controlado. Si decidís hookear clases a diestro y siniestro, especialmente sobre clases muy básicas del framework de Android, posiblemente dejéis colgado el dispositivo al generar una actividad elevada sobre el logcat. Recordar, en la mesura está la maestría ;) .

Y en cuanto al código:

• Si queréis hacer vuestros propios ajustes sobre la app Android encargada del hooking, el código relevante lo tenéis en la clase LoggerPlugin
• Si queréis modificar la app Android, tendréis que comprimir todo el directorio de la app en un zip con nombre substrateApp y guardarlo en el directorio de resources (podéis darle un vistazo al zip que hay ahora para haceros una idea). Con esto el siguiente empaquetado que hagáis con "mvn clean assembly:assembly" usará vuestra app modificada.

Artículo cortesía de Miguel Ángel García

@nodoraiz

Leer más...

Alterando la ejecución de aplicaciones Android con Substrate

Siguiendo con la idea del artículo anterior, Evadiendo implementaciones de certificate pinning, vamos a ver otra forma de resolver el mismo problema: utilizar la API de Cydia Substrate la cual nos permitirá hacer hooking y alterar la ejecución de las aplicaciones en memoria sin necesidad de modificar el código original de la aplicación que queremos analizar.

Los ingredientes

Para aplicar esta técnica de análisis de aplicaciones vamos a necesitar:

1. Un dispositivo rooteado, nos vale una máquina virtual
2. Instalar en el dispositivo la aplicación Cydia Substrate
3. Tener configurado un entorno de desarrollo Android (vamos a implementar una extensión Substrate para alterar la ejecución de las aplicaciones)
4. Descargar el SDK de Android Substrate
5. Proxydroid instalado en el dispositivo + Máquina con Web proxy donde redirigir el tráfico (en mi caso Burp) + Certificado Burp instalado en dispositivo

Y para que podamos apreciar mejor la diferencia entre desensamblar + alterar el código + re-empaquetar y alterar el código en memoria con Substrate, vamos a realizar las pruebas sobre la misma app: eTools Private Search, de modo que si ya la teníamos instalada y alterada por la anterior prueba es el momento de reinstalarla desde Google Play.

El paso a paso

Antes de entrar en materia recordemos que en el artículo evadimos la implementación del certificate pinning (de aquí en adelante CP para abreviar) anulando el paso del array TrustManager, el cual contenía la clave pública del servicio que se quería certificar:

Figura 1

Utilizando esta técnica de hooking lo que vamos a hacer es añadir un hook sobre la clase y método de la que queremos alterar el comportamiento para, una vez obtenido el flujo de ejecución de la aplicación, ajustarlo a nuestra necesidad.

Y dicho lo anterior, se nos plantean dos posibilidades:

a) Podemos hacer un hook a nivel de la app sobre el método mostrado en la Figura 1 para reescribir todo su comportamiento. Lo que haríamos sería no crear el array TrustManager que contiene la clave pública del certificado y que así el objeto SSLContext no lo tenga en cuenta y nos admita el certificado de nuestro Web proxy.

b) Podemos hacer un hook a nivel de la API de Android sobre el método init de la clase SSLContext, de modo que cuando la app haga la llamada a esa función nosotros capturemos esa ejecución. Una vez con el control podemos delegar la ejecución al método init original, pero pasando un argumento nulo donde se esperaba el array TrustManager con la clave pública fijada.

Vamos a elegir la opción b) ya que como veréis más adelante incluirá una grata sorpresa al modificar el comportamiento a nivel de la API de Android.

Ya con la estrategia definida nos ponemos manos a la obra, vamos a crear una extensión Substrate y a cargarla en nuestro dispositivo de análisis para alterar la ejecución en memoria y evadir el mecanismo de seguridad de CP:

1. Creamos un proyecto Android, en mi caso usaré Android Studio aunque podemos usar cualquier IDE que nos permita desarrollar para Android:

Figura 2

Y agregamos en el proyecto la librería de Substrate que hemos descargado en el punto 4 del apartado anterior:

Figura 3

2. Creamos el código de la extensión para modificar el comportamiento del método init de la clase SSLContext, para ello creamos una clase a la que llamamos por ejemplo BypassCertificatePinning con el siguiente contenido:

Figura 4

En el fragmento de código anterior hacemos lo siguiente:

• Utilizando la función MS.hookClassLoad(...) de la API de Substrate establecemos un hook sobre la clase SSLContext de modo que cuando se creen objetos de ese tipo se ejecute el código contenido en classLoaded(...)
• Cuando se detecte la creación de objetos SSLContext se ejecutará nuestro código, que utilizando reflection nos permitirá acceder al método init que vamos a alterar
• Utilizando la función MS.hookMethod(...) de la API de Substrate definiremos el nuevo comportamiento a realizar por el método init:

Figura 5

Entrando en más detalle sobre el código de la Figura 5 lo que he hecho ha sido alterar su comportamiento para pasar la llamada al método init original ( usando invoke(...) )con una diferencia sustancial: anular el segundo parámetro (que es el que contiene el array TrustManager con las claves públicas que harán el CP).

3. Ajustamos el manifiesto de la aplicación preparándolo para la ejecución de la extensión que vamos a desarrollar:

Figura 6

4. Instalamos la aplicación en el dispositivo y si todo ha ido bien veremos como recibimos una notificación de que se ha detectado una nueva extensión de Substrate:

Figura 7

Ahora debemos reiniciar el dispositivo para que la extensión tenga efecto, lo podemos hacer desde el botón Restart System (Soft) que se mostrará en la app de Substrate al hacer click en la notificación, este reinicio será bastante rápido:

Figura 8

5. Ya estamos preparados, redirigimos el tráfico HTTP/S al web proxy y ejecutamos la aplicación. Si revisamos los logs del sistema veremos las trazas que he dejado en el código:

Figura 9

Finalmente podemos ver el tráfico en nuestro Web proxy y confirmar la evasión del CP:

Figura 10

Bonus track

Otra ejemplo de implementación de CP como mecanismo de seguridad lo podemos encontrar en la app de Twitter, que si probáis a re-empaquetar con el método que comentaba en el artículo anterior veréis que incluso sin modificar código la aplicación falla al iniciarse.

Sin embargo, con el paso a paso que hemos descrito en el punto anterior y sin necesidad de hacer nada más ya estaremos evadiendo su implementación de CP:

Figura 11

Conclusiones

Como veis se trata de un método bastante inocuo ya que no alteramos la aplicación en sí sino su ejecución en memoria.

Nos ofrece muchísimo potencial ya que tras un análisis previo del código de la aplicación podemos alterar tanto las funciones de la propia aplicación como de la API de Android para tener un control todavía mayor, lo cual nos depurar y alterar la ejecución mientras que pasamos desapercibidos a determinadas validaciones como puede ser la verificación de firma de la propia app, comprobación de hash de ficheros del APK, aapt modificados para complicar el proceso de re-empaquetado, etc.

Artículo cortesía de Miguel Ángel García

@nodoraiz

Leer más...

Evadiendo implementaciones de certificate pinning en Android

Pongamos la siguiente situación: estamos realizando el análisis de una aplicación en la que nos interesa ver las comunicaciones HTTP/S que realiza, para ello disponemos de un dispositivo Android rooteado en el que redirigimos el tráfico de estos protocolos a un web proxy del que tenemos instalado su certificado en el dispositivo.

Todo está configurado correctamente pero algo falla, la aplicación nos indica que no puede establecer comunicación con el servidor de destino y confirmamos que sin redirigir al web proxy la aplicación funciona perfectamente. Puede que nos hayamos encontrado con una implementación de certificate pinning, pero esto no nos va a detener.

Llevemos a la práctica un método de evasión sobre un ejemplo real cogido de Google Play.

La aplicación de ejemplo, eTools

Figura 1

eTools se presenta como una herramienta orientada a realizar búsquedas en la web utilizando los motores más conocidos de manera segura y totalmente privada, implementando entre otros mecanismos de seguridad un certificate pinning.

Preparamos el escenario que hemos descrito anteriormente (dispositivo rooteado + Proxydroid +  Burp + certificado Burp instalado en dispositivo), probamos a realizar una búsqueda utilizando la aplicación y confirmamos como el certificate pinning entra en juego y no nos permite realizar la búsqueda bajo estas condiciones:

Figura 2

Evasión por parcheo de código

Para saltarnos esta restricción el proceso que vamos a seguir se resume en descargar el APK y analizar su código, anular las llamadas que comprobarán el certificate pinning, re-empaquetar la aplicación y reinstalar.

Vamos con ello:

1. Descargamos el APK del dispositivo

Figura 3

2. Buscamos cadenas que apunten al uso de la clase TrustManager

Utilizando dex2jar podemos extraer el JAR del APK y utilizando JD-GUI podremos ver el código Java. Ya desde JD-GUI podemos comenzar nuestras búsqueda por el código:

Figura 4

Como vamos viendo, el código se encuentra ofuscado y puede llegar a complicarnos el análisis, aunque veremos que en este caso tenemos suerte ya que si abrimos la clase "a" encontraremos claramente que es la implementación de la interfaz X509TrustManager:

Figura 5

El código anterior nos deja ver la clave pública contra la que se validará cuando se realice la petición HTTPS. Tenéis información más detallada sobre esta implementación en la web de OWASP.

Por otro lado si miramos el otro resultado de la búsqueda en JD-GUI, la clase "c", encontraremos en ella el método que se encarga de realizar la petición por HTTPS:

Figura 6

He remarcado las partes más relevantes:

• El primer bloque declara y asigna un array compuesto por la implementación de X509TrustManager. Este array se pasa como parámetro al objeto SSLContext que se utilizará para crear la conexión HTTPS.
• En el segundo bloque se define que se utilizará la implementación X509TrustManager para la verificación.

En este punto la situación es clara, hay que anular en el método de la Figura 6 todo rastro de uso de la clase "a" si queremos evadir el certificate pinning implementado.

3. Modificamos el código

Tendremos que desensamblar el código Jasmin del APK para modificarlo, así que podéis seguir el paso a paso desde la documentación de dex2jar ModifyApkWithDexTool o utilizar el script modify.py que os comentaba en el artículo sobre inyección de Meterpreter en aplicaciones.

Si optáis por el script, saltaremos el primer paso ya que no necesitamos tocar nada en el AndroidManifest.xml y nos pararemos a modificar el código en el segundo paso:

Figura 7

Respecto a la modificación de código vamos atacar al punto más débil, la clase "c" en su método "a" encargado de gestionar la conexión por HTTPS.

Figura 8

Si recordamos la figura 6, en la línea de código "localSSLContext.init(...)" se pasaban dos valores nulos y el array de TrustManager. En nuestro caso para anularlo vamos a pasar en lugar del array otro valor null, de modo que sustituiremos el valor de la línea 469 por aconst_null .

También en la figura 6 veíamos como se definía el uso de la clase "a" para verificar el hostname, en este caso lo que haremos será eliminar las líneas 484, 485 y 486 para anular esa parte del código.

Finalmente nos debería quedar algo así:

Figura 9

Ya tenemos preparado el código modificado, sólo queda re-empaquetar y firmar el APK. Si estabais usando el script modify.py sólo tendréis que guardar el código modificar y dar a enter.

4. Probamos nuestra obra

Reinstalamos la aplicación:

Figura 10

Activamos Proxydroid, abrimos la aplicación y realizamos una búsqueda:

Figura 11

Perfecto, ya estamos capturando las comunicaciones:

Figura 12

Conclusiones

Realizar certificate pinning en nuestras aplicaciones puede aportarnos una capa más de seguridad, pero debemos entenderlo como una capa más y no delegar en esta técnica la seguridad de nuestras comunicaciones ya que como hemos visto no la hace inmune a su análisis.

Desde el punto de vista del ataque realizado, podría haberse complicado el escenario si hubiéramos encontrado una ofuscación más fuerte o si se hubiera incluido algún método de validación de código en tiempo de ejecución que debidamente ofuscado nos llevara a dedicar más tiempo de reversing (aunque incluso ante estas contra-medidas quedaría la posibilidad de aplicar otras técnicas de hooking y debugging).

Artículo cortesía de Miguel Ángel García

@nodoraiz

Leer más...

Kali Linux NetHunter: comprometiendo sistemas desde dispositivos Nexus

Nuevo proyecto del equipo de la distribución de seguridad Kali Linux, en la que ha creado un spinoff para dispositivos móviles y tablets Nexus, llamado NetHunter.

NetHunter nace como plataforma para realizar tests de intrusión desde dispositivos Android (más concretamente, dispositivos Nexus), en la que se incluyen, además de las herramientas típicas de Kali Linux, un conjunto más de aplicaciones con propósitos concretos (ataques por BadUSB, generación de puntos de acceso rogue, inyección de paquetes 802.11 por USB, etc). Además, es posible acceder a la pantalla del dispositivo a través de una conexión VNC desde cualquier ordenador.

Los dispositivos soportados son los siguientes:

• Nexus 5 (GSM/LTE) - “hammerhead”
• Nexus 7 [2012] (Wi-Fi) - “nakasi”
• Nexus 7 [2012] (Mobile) - “nakasig”
• Nexus 7 [2013] (Wi-Fi) - “razor”
• Nexus 7 [2013] (Mobile) - “razorg”
• Nexus 10 - “mantaray”

Los creadores del proyecto han publicado dos videos como demostración del potencial de la utilización de esta nueva plataforma para el ataque sobre sistemas.

El primer video corresponde con un ataque HID (simulación de teclado), en la que el dispositivo, una vez conectado por USB al sistema víctima, simulará la pulsación de un conjunto de comandos como administrador para establecer una shell reversa sobre un equipo:

El segundo video publicado por el momento muestra un ataque de man-in-the-middle utilizando la técnica BadUSB (presentada en la pasada BlackHat USA 2014), en el que será posible, mediante USB, hacer que el dispositivo Android se interponga entre las comunicaciones y sustituya al Gateway original:

Sin duda un proyecto interesante que seguir de cerca, sobretodo para aquellos poseedores de un dispositivo Nexus ya que con unos pocos clicls sobre la interfaz de usuario creada conseguiremos llevar a cabo tareas avanzadas de explotación por USB.

En la página del proyecto http://www.nethunter.com/ encontraréis todos los pasos necesarios tanto para instalar como utilizar y configurar esta plataforma, así como problemáticas a tener en cuenta.

[+] Página del proyecto NetHunter (Offensive-Security): http://www.nethunter.com/

Leer más...

Alterando el contenido de un APK (parte 2 de 2)

En el artículo anterior vimos lo fácil que es generar con msfpayload un APK que incluya Meterpreter y de forma muy somera la estructura del código generado por la herramienta.

Aprovechando ese conocimiento vamos a alterar una aplicación para que sin perder su funcionalidad original, se incluya el shellcode Meterpreter de regalo.

Para lograr este objetivo, y como no podemos editar directamente el fichero .dex, utilizaremos las herramientas dex2jar para desensamblar el código en Jasmin, alterarlo y re-empaquetarlo.

Segunda disección del payload Meterpreter para Android

A través de su código en Java vimos que todo se desencadenaba realizando una llamada única a una función ubicada en la clase Payload, la cual se encargaría de establecer la conexión con nuestra consola de Metasploit, descargar el payload y ejecutarlo:

Esta vez vamos a ver la llamada a esa función a través de su desensamblado Jasmin. Para ello lanzaremos los siguientes comandos sobre el fichero Meterpreter.apk que generamos anteriormente:

Ejecutando estos comandos se creará un directorio con el código Jasmin organizado según los paquetes en los que se haya estructurado el código de la aplicación:

Si abrimos el fichero MainActivity.j podremos ver el código desensamblado del método onCreate:

He sombreado en la imagen la parte que nos interesa:

• aload 0: Empuja a la pila la variable "this"
• invokestatic com/metasploit...: Realiza la llamada al método estático de la clase Payload

Visto esto, podremos inyectar el shellcode en otra aplicación si incluimos en ella:

1. El código que acabamos de desensamblar de Meterpreter.apk
2. Las dos instrucciones sombreadas anteriormente sobre un método que sepamos que se va a ejecutar, por ejemplo el onCreate de su actividad inicial

Preparando el entorno

El proceso que vamos a seguir para alterar el fichero es el que propone dex2jar desde su página de la wiki ModifyApkWithDexTool.

Si observáis el proceso veréis que es algo tedioso ya que implica la creación de muchos ficheros diferentes mientras que se hace malabares con ellos. Para simplificar esta tarea he creado un script en Python que automatiza todo ese proceso, lo podéis descargar de GitHub desde este enlace.

El script hace uso de las herramientas apktool y dex2jar, de modo que además de descargar el script tendréis que descargar ambas herramientas y configurarlas en el path para que cuando el script las ejecute las pueda encontrar.

Una vez configurado el entorno, descargaremos el APK que queramos modificar.

Para la prueba de concepto y que así veamos lo increíblemente fácil que es editar cualquier aplicación yo he seleccionado una aplicación conocida: Tapatalk.

Inyectando el código Meterpreter en otra aplicación

Ya tenemos todas las herramientas y el APK que queremos modificar, así que ejecutamos el script sobre la aplicación a editar:

Lo primero que nos permitirá el script es modificar el manifiesto por si queremos incluir alguna actividad, permiso, cambiar la versión, etc. Vamos a utilizar este momento para dirigirnos al directorio indicado, abrir el fichero AndroidManifest.xml y localizar la actividad de inicio de la aplicación:

Presionamos ENTER para que el script continúe con su ejecución. Su siguiente parada será la edición del código:

Como indicamos cuando vimos el código Jasmin de Meterpreter.apk, en este punto tendremos que hacer dos acciones sobre el código ubicado en el directorio que nos indica el script:

1. Copiar la carpeta com/metasploit con el código Jasmin de Meterpreter.apk:

2. Añadir las dos instrucciones de carga del código de Meterpreter al método onCreate ubicado en el fichero com/quoord/tapatalkpro/activity/directory/ics/IcsEntryActivity.j que descubrimos al analizar el manifiesto:

Si todo ha ido correctamente, cuando volvamos a presionar ENTER el script re-empaquetará la aplicación (en mi caso ha mostrado algunas advertencias, pero el proceso ha finalizado correctamente) y la dejará preparada para su instalación:

Ya sólo queda ejecutar, para ello antes configuramos multi/handler en msfconsole y lo ponemos a la escucha:

Desinstalamos la versión previa de Tapatalk (en caso de que la tuviéramos) y reinstalamos la modificada:

Ejecutamos la aplicación en el dispositivo:

Y obtendremos nuestra sesión Meterpreter:

Ultimando detalles

Es muy importante que tengamos en cuenta que al re-empaquetarse la aplicación y para que pueda ser instalada ha tenido que volver a ser firmada, y al no disponerse de la firma original se firmará con una genérica:

El problema de este punto es que, como vimos en el artículo anterior, cuando instalamos una aplicación desde un origen desconocido no se muestra a quién pertenece la firma de esa aplicación, impidiendo que el usuario final pueda saber si está instalando una aplicación original o una alterada.

Lo que sí que hará el sistema operativo es comprobar si la aplicación ya se encuentra instalada para no permitir su instalación en caso de que no coincida la firma.

Otro aspecto relevante es que si recordamos el artículo anterior, la aplicación generada de Meterpreter con msfpayload solicitaba una cantidad importante de permisos para poder explotar todo su potencial, y de aquí podemos sacar dos conclusiones:

1. Los permisos que no existieran previamente y no se incluyan durante la fase de edición del manifiesto limitarán las opciones de la sesión Meterpreter

2. Los permisos que se incluyan se le mostrarán al usuario durante la instalación haciéndose notar una diferencia entre la aplicación original y la modificada

Artículo cortesía de Miguel Ángel García

@nodoraiz

Leer más...