Archive for Ingeniería inversa

Desactivando ASLR en una app iOS con Radare2 – Parte 2

Introducción

Continuamos con la segunda y última parte de este artículo acerca de cómo desactivar ASLR en una aplicación iOS con Radare2. En la primera parte, que podéis consultar aquí, vimos cómo comprobar si un binario de tipo Mach-O tiene activado o no la protección PIE (Position-Independent Executable). PIE permite el uso de Exec Shield o PAX que utilizan técnicas de direccionamiento aleatorio como ASLR (Address Space Layout Randomization).

También vimos que dependiendo de la arquitectura, ARMv7 o ARM64 tendríamos que buscar una cadena u otra. Además vimos que esa cadena a buscar en nuestro binario estaría cerca de la cadena _PAGEZERO, que nos puede servir de referencia.

Manos a la obra

Vamos a “parchear” nuestro binario para modificar unos bytes que nos permitirán desactivar el PIE. Para ello abriremos el binario en modo escritura con Radare2. Para abrir un binario en modo escritura utilizaremos el parámetro -w (write).

Radare2 - Write modeEn la imagen anterior podemos ver que hemos abierto ya no está cifrado (aplicado Clutch en la primera parte), y que tiene habilitado PIE.

Localizamos la cadena a buscar, tal y como hemos visto en la primera parte de este artículo, y pasaremos a explorar el binario para hacer el “parcheo“.

Con la tecla v (visual mode) de Radare2 podemos entrar en modo visual, lo que nos va a permitir a ver las distintas direcciones relativas y sus contenidos. Con la tecla c (cursor mode) activamos el cursor y podremos desplazarnos por los contenidos mostrados.

Una vez localizados los bytes a modificar, 850020 (recordad que varía según la arquitectura), procedemos a activar el modo insertar, para lo que pulsaremos la tecla i en Radare2.

Radare2 - Insert modeEn este modo de inserción, podremos modificar los bytes, dejándolos como vemos en la siguiente imagen.

Radare2 - Insert mode

Salimos de Radare2, los cambios se guardarán automáticamente porque hemos “escrito” directamente en el binario.

Comprobación

Comprobamos nuevamente con la herramienta otool si PIE sigue activado o no.

otool - iOS PIE

Podemos comprobar como efectivamente en el binario cuyo nombre acaba en _NoPIE hemos conseguido deshabilitar PIE.

Para finalizar, con otra herramienta del framework de Radare2, como es radiff2, podemos buscar diferencias entre dos binarios. Si lo aplicamos a los dos binarios con los que hemos estado trabajando, uno con PIE activado y el otro con el PIE desactivado con Radare2, podemos ver la diferencia en el byte modificado.

A continuación se puede ver un ejemplo de radiff2 con estos archivos.

Radiff2 - PIE

Hasta aquí este artículo que, como siempre, esperemos haya sido de vuestro interés. Todos los comentarios y sugerencias serán bienvenidos. Gracias de antemano.

¡Hasta pronto!

Miguel A. Arroyo – @miguel_arroyo76

Desactivando ASLR en una app iOS con Radare2 – Parte 1

Introducción

En este artículo explicaremos cómo podemos desactivar ASLR (Address Space Layout Randomization) en una app iOS. Ya vimos en un artículo anterior cómo podemos comprobar con la herramienta otool si una aplicación iOS tiene activada esta protección o no. Podéis leer el artículo en este enlace.

ASLR, PIE, PAX y Exec Shield

En realidad lo que se comprueba es si el binario ha sido compilado con PIE (Position-Independent Executable). Los binarios de tipo PIE permiten en algunas distribuciones GNU-Linux orientadas a seguridad a hacer uso de PAX y Exec Shield, que son unas implementaciones realizadas a nivel de kernel. Estas implementaciones aumentan la seguridad del sistema, permitiendo por ejemplo el direccionamiento aleatorio de los objetos del programa en memoria, dificultando así posibles explotaciones de vulnerabilidades de tipo buffer overflow, entre otros. Aquí es donde ASLR entra en juego.

La siguiente imagen corresponde a la versión PAX de Tux. 😉

170px-pax_tux

Para evitar confusiones, aunque la finalidad es deshabilitar el direccionamiento aleatorio (ASLR), nos referiremos a PIE, ya que así es como se refleja el flag en el binario que vayamos a analizar. De hecho, con otool el resultado del análisis se muestra de la siguiente forma.

Comprobar PIE con otool

Se puede observar a la derecha de la imagen que el binario analizado muestra el flag PIE activado.

Radare2

Este magnífico framework de ingeniería inversa creado por Sergi Álvarez (@pancake), que surgió como una herramienta de forense, actuando como un editor hexadecimal capaz de abrir archivos de disco. A día de hoy cuenta con un interesante arsenal de utilidades que permiten analizar binario, desensamblar código, depurar programas o hacer depuración remota a través de servidores gdb.

Podéis encontrar toda la información en el siguiente enlace: https://github.com/radare/radare2

A título personal decir que, aunque la curva de aprendizaje es alta, es un framework que merece la pena conocer, estudiar y usar, sobre todo si te dedicas a ingeniería inversa, o estás pensando en dedicarte. Yo soy un auténtico novato de esta herramienta, pero lo poco que he aprendido hasta ahora quería compartirlo vosotros, y qué mejor manera que hacerlo de manera práctica con este ejemplo que estamos viendo.

¿Qué buscamos exactamente?

Después de analizar varios binarios de aplicaciones iOS de diferentes arquitecturas (ARMv7 y ARM64), he llegado a la conclusión que el volcado en hexadecimal que hay que buscar con Radare2 son los siguientes:

Hex bytes: 858021 para la arquitectura ARMv7

Después de abrir Radare2 con el binario a analizar (thin_binary), para lo que usaremos la sintaxis “r2 thin_binary“, haremos una búsqueda (seek) con el comando “s“, especificando que estamos buscando un volcado en hexadecimal, de ahí la “/x” y a continuación lo que queremos buscar (858021).

PIE hexdump in Radare2

Si estamos analizando una app de iOS de ARM64, los hex bytes a buscar serían 850020.

PIE flag in Radare2

Observad que en ambos casos, cuando encuentra el patrón buscado, es decir hace 1 hit, Radare2 automáticamente nos posiciona en el offset donde los ha encontrado (0x00000018, en el último ejemplo). Finalmente mostramos un volcado de 16 bytes con el comando “px” donde podemos ver que se muestran los hex bytes que estábamos localizando.

También podemos localizar fácilmente el offset donde encontrar estos hex bytes buscando la sección / segmento _PAGEZERO, que suele estar siempre muy cerca de estos bytes. Pero sin lugar a duda, lo más certero es utilizar el comando “s/x [hexbytes_armx]” para localizarlo y ubicarnos.

Hasta aquí esta primera parte de este artículo. En el siguiente artículo veremos qué bytes hay que modificar, cómo abrir el binario en Radare2 en modo escritura, cómo buscar diferencias enter el binario original y el parcheado con rabin2 y finalmente comprobar nuevamente con otool que hemos conseguido deshabilitar el flag de PIE.

Como siempre, espero que sea de vuestro interés y nos vemos pronto en la segunda parte de este artículo.

PD: Cualquier comentario, consulta y recomendación será bienvenido, sobre todo si es de Radare2, donde me tenéis que disculpar, pero soy muy novato. Eso sí, con muchas ganas de seguir aprendiendo y compartiendo. 🙂

 

Auditando Aplicaciones en Android

Vamos a ver algunos ejemplos de controles que se llevan a cabo en un Pentesting de Aplicaciones en Android. Lo más importante en un proceso de auditoría será el hacer uso de una metodología, de tal forma que podamos llevar a cabo una serie de pasos de manera ordenada.

Os propongo que hagamos uso de la metodología OWASP, concretamente en su apartado de OWASP Mobile Security Project podemos encontrarnos con muchos recursos: herramientas, guía de desarrollo seguro, plantilla de controles, guía de testing de Apps… Centrándonos en esta última podemos dividir nuestra auditoría en tres partes: recopilar información, análisis estático y análisis dinámico. Read more

Spyware en Android

En el día de hoy os traigo un artículo generado a raíz de una pequeña investigación que realicé al móvil android chino (chino, re-chino, vamos que ni la marca es pronunciable) de un familiar el cual, al utilizarlo yo mismo para realizar una llamada (hay que ahorrar xD), noté, por intuición más bien, que algo en el teléfono no andaba bien.

Llevo usando android hace bastante tiempo, “tuneando” ROMs en mis terminales, haciendole mods y otros “enrreos” así como en el último año, he estado más centrado en probar herramientas de pentesting de Android aunque no haya publicado ni expuesto nada sobre esto.

Bueno pues tras pelearme unos instantes con él detecté que ¡estaba roteado! A partir de ahí os podéis imaginar un poco que posibilidades se puede abrir en el caso de ser infectado por algún malware.

Por lo pronto detecté que, al desbloquearlo, siempre salía una pantallita con un anuncio. Oh Shit! Siempre. Desinstalé alguna APP de estas famosillas de programas de la TV y algún Widgets del tiempo un poco cutre pero el problema seguía. El teléfono mostraba publicidad.

androchina_logo

Read more

De camino al Buffer Overflow (III)

Hoy Lunes, retomamos la Parte III de la saga de artículos “De camino al Buffer Overflow”. Esta vez, desbordaremos de forma interesante una variable de la pila, la cual nos permitirá alterar el flujo normal del programa. Simplemente y como de costumbre, espero que os guste y que sea de vuestro interés.

Antes que nada, se facilitan los enlaces correspondientes a las entradas previas:

De camino al Buffer Overflow – Parte I

De camino al Buffer Overflow – Parte II

Para iniciar la explicación nos respaldaremos del siguiente código:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

 void func1(char *arg) {

            char name[32] = {0};

            strcpy(name, arg);

            printf(“Hi %s\n”, name);

}

 int main(int argc, char *argv[]) {

            if ( argc != 2 ) {

                        printf(“Use: %s YourName\n”, argv[0]);

                        exit(0);

            }

             func1(argv[1]);

             printf(“End of program\n”);

            return 0;

}

Fuente: sevillasecandbeer.org

Fuente: sevillasecandbeer.org

Read more

De camino al Buffer Overflow (II)

Volvemos en Hacking-Etico.com con esta segunda entrega de “De camino al Buffer Overflow” para abrir el apetito este fin de semana. Se trabajarán en profundidad los conceptos de la primera, disponible en este enlace, con lo cual recomiendo su relectura para no obviar algún detalle que se nos pueda pasar por alto, especialmente información relacionada con los registros ESP y EBP.

Para iniciar la explicación, nos respaldaremos del siguiente código:

int add(int x, int y) {

            int sum;

            sum = x + y;

            return rum;

}

func1() { add(3, 4); }

Fuente: sevillasecandbeer.org

Fuente: sevillasecandbeer.org

Read more

De camino al Buffer Overflow (I)

El Karma siempre estará de nuestro lado si conocemos las entrañas de nuestro sistema operativo y aún más, cuando queramos averiguar lo que le está sucediendo a un programa o conocer aquello a lo que está expuesto. En esta secuencia de posts se intentará dar un conocimiento avanzado sobre el entorno de ejecución. Sin más, espero que os guste y gracias por leerlo.

Cuando se inicia la ejecución de un programa, el sistema operativo carga el código ejecutable en una zona de memoria no ocupada y reserva dos espacios más de memoria que serán utilizados durante su ejecución, en concreto, como pila de ejecución y como área de datos dinámicos (en Inglés, heap).

La pila es encargada de contener los parámetros de las funciones, sus variables locales y sus valores de retorno, mientras que el heap almacena aquellos datos que se han solicitado mediante una instrucción de reserva de memoria, como por ejemplo, utilizando malloc en C o new en C++. Pues bien, una vez el código esté copiado a la memoria, sola será necesario que el sistema operativo indique a la CPU que tiene que apuntar con el registro puntero de instrucciones (conocido como EIP, del Inglés Extended Instruction Pointer) a la primera posición de éste.

Fuente: sevillasecandbeer.org

Fuente: sevillasecandbeer.org

Read more

mitmproxy: MitM de tráfico Web for fun and profit

¿Qué es mitmproxy?

En esta nueva entrada del blog vamos a tratar un tema que siempre despierta un gran interés. No se trata de ninguna técnica nueva ni mucho menos, pero sigue dando mucho “juego“. Se trata de los ataques a la red TCP/IP, concretamente haciendo Man-in-the-Middle con envenenamiento de ARP. Algo de lo que ya hemos hablado en varias ocasiones en ese blog, pero en esta ocasión nos vamos a centrar en el tráfico Web el cual vamos a controlar con un proxy Web diseñado precisamente para el tipo de ataque que vamos a ver a continuación, mitmproxy.

Esta herramienta, que la podéis descargar desde su GitHub en esta dirección https://github.com/mitmproxy/mitmproxy, actúa como un proxy Web donde podemos interceptar tráfico, como lo haría otros proxies Web locales como Burp o ZAP, y nos proporciona una serie de scripts en Python para, por ejemplo, inyectar código HTML. Suena divertido, ¿verdad? Hay muchas herramientas que también permiten hacer esto, pero hemos elegido esta por su sencillez a la hora de lanzar este ataque.

Objetivo: inyectar código HTML

Nuestro objetivo es lanzar un ataque de MitM utilizando la técnica de envenenamiento ARP, redirigir el tráfico Web a nuestro proxy local, mitmproxy, e inyectar nuevo código en la respuesta del servidor, para alterar la apariencia de la Web en el navegador del usuario.

Escenario

Como venimos haciendo últimamente en el blog, pasamos a explicar cuál es el escenario que vamos a usar para esta prueba de concepto del ataque.

Tenemos dos máquinas virtuales; una Windows 7 (192.168.10.146) que actuará como víctima y una Kali 2 (192.168.10.149) que actuará como máquina atacante.

Herramientas a usar en máquina atacante:

  • arpspoof: para lanzar ataque MitM evenando tabla ARP
  • iptables: para redirigir tráfico 80/443 a mitmproxy
  • mitmproxy: para interceptar e inyectar código HTML

Si usáis como máquina atacante Kali 2, estas herramientas ya las tendréis a vuestra disposición para ser usadas.

Ataque MitM y redirección de tráfico

Antes de poder inyectar tráfico HTML en las respuestas del servidor al cliente (navegador Web de la víctima), necesitamos que su tráfico de red pase por nuestra máquina atacante, para ello lanzamos un ataque de arpspoofing con la herramienta arpspoof.

Pero antes de hacer esto, si no queremos dejar a la víctima sin acceso a Internet u otras redes, tenemos que hacer que nuestra máquina atacante actúe como un router, y haga reenvío de paquetes.

echo 1 > /proc/sys/net/ipv4/ip_forward

Teniendo en cuenta, que la puerta de enlace es la 192.168.10.2, la sintaxis quedaría de la siguiente manera:

arpspoof -i eth0 -t 192.168.10.146 192.168.10.2

Si todo se ha ejecutado correctamente, ya tenemos pasando por nuestra interfaz el tráfico de red de la máquina Windows 7. Como hemos comentado anteriormente, nuestro objetivo es interceptar el tráfico Web, tanto http (80) como https (443), así que necesitamos que este tráfico sea redirigido a mitmproxy, que por defecto escucha en el puerto 8080.

iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 8080

iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-port 8080

Read more

Fuzzing a una aplicación con zzuf

Introducción: ¿por qué fuzzing?

Cuando nos encontramos haciendo tareas de ingeniería inversa a una aplicación, una de las tareas más monótonas es la de enviar stuff (“cosas“) a un punto de entrada de la aplicación para ver cómo responde. En función de nuestro objetivo (descubrir buffer overflow, format string…), el tipo de stuff que enviemos variará, no sólo en su contenido si no también en su cantidad, sobre todo si lo que buscamos es provocar un buffer overflow. Y cuando hablamos de cantidad, lo ideal es hacer fuzzing en lugar de hacerlo con peticiones manuales.

En el caso de los desbordamientos, más que el tipo de contenido lo que se busca es la cantidad, y aquí tenemos varias opciones de enviar “cosas” a la aplicación; de forma manual, mediante ejecución de instrucciones Python / Perl desde la consola, creándonos nuestro propio script o utilizar herramientas ya desarrolladas para este tipo de tareas; fuzzers.

En este artículo veremos distintas opciones, para finalmente presentar y ver algunos ejemplos de zzuf, el fuzzer del que vamos a hablar en este post.

Escenario

Para explicar el funcionamiento de un fuzzer, y de zzuf concretamente hemos preparado el siguiente escenario; una aplicación remota vulnerable a buffer overlflow (basado en stack), accesible a través del puerto TCP/9999.

Ese puerto a la escucha es nuestro único punto de entrada. Podríamos escanear el puerto, descubrir versión del servicio y buscar si hay alguna vulnerabilidad desconocida. En caso negativo, no nos queda otra que enviar cosas al puerto y ver cómo responde la aplicación.

Fuzzing - Netcat a vulnserver

En este caso, haciendo netcat al puerto conseguimos acceso a la aplicación, donde nos indica que podemos obtener ayuda escribiendo el comando HELP.

Peticiones manuales a la aplicación

Obviamente nuestra intención es otra, es encontrar qué tipo de información tenemos que enviarle y en qué cantidad. La explotación de la vulnerabilidad de buffer overflow no entra en el contexto de este artículo, lo explicaremos más adelante en otro, pero se puede ver marcado en amarillo una serie de comandos de la aplicación. Estos comandos son los usaremos para enviar nuestro stuff e intentar provocar el BO (buffer overflow).

Fuzzing - Netcat a vulnserver

Como decíamos en la introducción al artículo, podemos hacer peticiones manuales. En la imagen anterior al comando HELP le hemos añadido una serie de caracteres, primero dígitos y a continuación acompañados de varios caracteres “A“. La respuesta de la aplicación es que ese comando no está implementado. Podríamos seguir probando con más cantidad, con otros comandos, pero como os podéis imaginar esto llega a ser bastante tedioso y monótono si lo hacemos manualmente. Read more