Un blog de Seguridad Informática, desde un punto de vista tecnológico

Archivo para noviembre, 2014

Write-up VODKA – Final CTF NCN 2014

¡Buenas! Primero de todo me presento: mi nombre es Marc Peña (@p4chul0) y también soy miembro del equipo 0xB33r$. Hoy, continuando con las publicaciones sobre los retos de la final del CTF de la No cON Name, publicamos otro write-up.

Uno de los retos con los que estuve enfrascado durante el CTF fue VODKA (https://github.com/ctfs/write-ups/tree/master/ncn-ctf-2014/Vodka); en el mismo se obtenía un archivo con ese mismo nombre, que tras un primer análisis con file:

root@wheezy-kali:~/ctf_NCN/vodka# file vodka
vodka: bzip2 compressed data, block size = 900k

Parecía que se trataba de un archivo comprimido; tras extraerlo:

root@wheezy-kali:~/ctf_NCN/vodka# bzip2 -d vodka
bzip2: Can't guess original name for vodka -- using vodka.out

Obteníamos un archivo con una captura de tráfico de red:

root@wheezy-kali:~/ctf_NCN/vodka# file vodka.out
vodka.out: pcap-ng capture file - version 1.0

Que pasábamos a analizar con Wireshark:

01_vodka

Donde enseguida veíamos que se trataba de la transferencia de una imagen OpenWRT a través del protocolo TFTP.

Tras buscar como extraer el binario con el propio Wireshark nos encontramos con esto:

Que nos da a entender que la funcionalidad está implementada, pero no en la versión de Wireshark que tenemos instalada en nuestra Kali (1.10.2), por lo que tendríamos que compilar el trunk de Wireshark. Con el siguiente comando:

  • Instalaremos los paquetes necesarios para la compilación.
  • Clonaremos el repositorio de Wireshark.
  • Configuraremos y compilaremos el trunk.

apt-get install autoconf bison flex libtool libgtk2.0-dev libpcap-dev libc-ares-dev libsmi2-dev libgnutls-dev libgcrypt11-dev libkrb5-dev libcap2-bin libgeoip-dev libortp-dev libportaudio-dev qt4-dev-tools && \
apt-get build-dep wireshark && \
cd /opt/ && \
git clone https://code.wireshark.org/review/p/wireshark.git && \
cd /opt/wireshark && \
./autogen.sh && \
./configure --enable-dumpcap --enable-setcap-install --with-dumpcap-group=wireshark && \
make -j 8

Si todo ha ido bien ya podremos abrir el archivo con la última versión de Wireshark:

root@wheezy-kali:~/ctf_NCN/vodka# /opt/wireshark/wireshark vodka.out

Y exportar el archivo (File -> Export Objects -> TFTP):

02_vodka

Ahora tocaba lidiar con la imagen, por lo que instalamos el binwalk (https://github.com/devttys0/binwalk) del gran devttys0 (http://www.devttys0.com/):

apt-get install binwalk

Una vez hecho esto ya se podían observar las características de la imagen:

root@wheezy-kali:~/ctf_NCN/vodka# binwalk openwrt-wrtsl54gs-squashfs.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
32 0x20 TRX firmware header, little endian, header size: 28 bytes, image size: 1323008 bytes, CRC32: 0x6CAC483 flags: 0x0, version: 1
2296 0x8F8 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
517152 0x7E420 Squashfs filesystem, little endian, version 2.1, size: 805671 bytes, 269 inodes, blocksize: 65536 bytes, created: Wed Oct 29 18:53:25 2014

Y extraer el sistema de archivos Squashfs (por defecto en el directorio “_openwrt-wrtsl54gs-squashfs.bin.extracted”):

root@wheezy-kali:~/ctf_NCN/vodka# binwalk -e openwrt-wrtsl54gs-squashfs.bin

Una vez dentro de este ya podíamos pasar a navegar por el sistema de archivos en busca de la flag:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root# ls
bin dev etc jffs lib mnt proc rom sbin tmp usr var www

En el directorio que miramos primero (/bin) encontramos un archivo con una fecha de modificación muy cercana a la de creación del sistema Squashfs:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root# ls -lisah bin/
total 596K
3670108 4.0K drwxr-xr-x 2 root root 4.0K Oct 29 18:50 .
3670107 4.0K drwxr-xr-x 14 root root 4.0K Jan 30 2007 ..
...
3670142 8.0K -rwxr-xr-x 1 root root 4.2K Oct 29 18:52 nc
...

Por lo que parecía un buen candidato para empezar a buscar. Si abríamos el archivo con un editor de texto veíamos que se trataba de un script en bash que muestra un “Nyan cat” en ASCII Art:

#!/bin/bash
# --------------------------------------------------------------------------
# (c) 2012 BruXy Version: 1.0 http://bruxy.regnet.cz/
# --------------------------------------------------------------------------
# switch off cursor, set blue background, clear screen
echo -e "\E[?25l\E[44m\E[2J"
# Play music
#M=/tmp/cat_orig.mp3
#[ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
#while true; do mplayer $M > /dev/null 2>&1; done &
# easy way to reset terminal and exit subprocesses
trap "reset;killall nc" 2
## Nyan cat ANSI picture data, my own creation :P, size 38 x 11
# Compressed version of picture
D="H4sIAHUNPlAAA22Q2w7CIAyG730rC1IGEs3itoS7cYlLvFGf37YcPMQvo5DxpT+pMYLb/8OVSxNv
Aiq1Db9sSmG1TgKqdhXqktKtsyBW6F08gB/EcgAUG2eAeRxbryqi1hq89yvQgfrFZ6If8E7sVoet
aVqWlNjqgYGlA5ckG5r4EGqvHmgtGeWzlqwLc6dJHD8Sr/IMQadMiTxR0IDrN/RUUjDnLJOghYn9
UgtyzvTcNvvdCw/8WhWjAQAA"

Sabiendo esto vamos podíamos ir a buscar la versión original del mismo:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# wget http://bruxy.regnet.cz/linux/nyan_cat/nyan_cat.sh

Para analizar las diferencias:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# diff nyan_cat.sh nc
9,11c9,11
< M=/tmp/cat_orig.mp3
< [ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
< while true; do mplayer $M > /dev/null 2>&1; done &
---
> #M=/tmp/cat_orig.mp3
> #[ ! -f $M ] && wget http://nyan.cat/music/original.mp3 -O $M >/dev/null 2>&1
> #while true; do mplayer $M > /dev/null 2>&1; done &
14c14
< trap "reset;killall nyan_cat.sh" 2
---
> trap "reset;killall nc" 2
42c42,47
< printf "%*s" $[X*Y] BruXy
---
> file="/etc/banner"
> za="N"
> t1="C"
> drink="$(md5sum $file | grep -o ^[^\ ]*)"
> msg_="${za}${t1}${za}dead${drink}face"
> printf "%*s" $[X*Y] ${msg_}

¡Obteniendo lo que parece el código que genera la flag!

Creamos un nuevo archivo con este código (con la única modificación de la ruta del fichero, para convertirla en relativa):

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# cat vodka_flag.txt
#!/bin/bash
file="../etc/banner"
za="N"
t1="C"
drink="$(md5sum $file | grep -o ^[^\ ]*)"
msg_="${za}${t1}${za}dead${drink}face"
printf "%*s" $[X*Y] ${msg_}

¡Y lo ejecutamos  para obtener la flag!:

root@wheezy-kali:~/ctf_NCN/vodka/_openwrt-wrtsl54gs-squashfs.bin.extracted/squashfs-root/bin# chmod +x vodka_flag.txt && ./vodka_flag.txt
NCNdeadb6adec4c77a40c23e04770924d3c5b18face

Aunque tampoco pudimos resolver este reto dentro del CTF. no quiero terminar sin felicitar a los organizadores por unas pruebas de lo más originales.

¡Saludos!


Write Up 5h311 – Final CTF NCN 2014

Buenas,

Para continuar con la saga de write-up’s iniciada en el anterior post con @julianvilas, hoy os pondremos la solución a otro de los retos que tuvimos el placer de testear.

Se trata de un fichero llamado “5h311”, que al ejecutarlo se abre un servicio en local en el Puerto 6969, que la conectarnos muestra lo siguiente:

Ejecución 5h311

Parece ser un acceso por consola que permite una serie de comandos, concretamente “cat”, “echo”, “env”, “exit”, “help”, “ls”, “set” y “unset”.

Si hacemos ls encontramos que el flag se encuentra en el mismo directorio del binario, pero al hacer un “cat flag.txt” podemos observar que no disponemos de privilegios para accede .

Permission Denied

Bueno pues nos ponemos manos a la obra y abrimos el programa con IDA para ver que es lo que nos esconde.

Buscamos en IDA las ocurrencias del comando “cat” con la búsqueda de Strings (ALT+T), con la finalidad de identificar la sección de código donde se están gestionando los comandos:

String put

Como resultado, en la sección .rodata podemos observar el vector que incluye los comandos que son printados por pantalla.

comandos

Pero observando unas direcciones de memoria más abajo, se pueden observar de nuevo los comandos asignados a unos offsets, pero con la peculiaridad que aparece un nuevo comando que no nos ha listado el comando HELP, el comando “Puts”.

puts command

Miramos las Xrefs del offset correspondiente a “aPuts” (x Key):

xrefs puts

Miramos de analizar la primera ocurrencia, que parece ser que se está empleando dentro de una función.

Antes de nada un apunte, observando el programa desde la View Graph, ya se observa algo raro, como si se hubiera ofuscado con algún tipo de programa, debido a que todos los paths van a parar a un mismo punto como se observa en la siguiente imagen:

graph

Procedemos a analizar el bloque de código que emplea el offset de “puts”, y observamos que se realizan una serie de comparaciones:

puts code

Concretamente hace una comparación de dos offsets con una llamada a strcmp y verifica mediante el siguiente cmp si son iguales, en ese caso activa el ZF.

Antes de continuar refrequemos que hace el opcode “setz”:

  • The setz sets the byte in the destination operand to 1 if the Zero Flag (ZF) is set, otherwise sets the operand to 0.

Después mediante la instrucción “setz”, se setea el valor de “bl” a 1 si ZF vale 1, es decir bl valdrá 1 si el resultado del strcmp es que son iguales.

Posteriormente mediante la instrucción “test”, se modifica otra vez el ZF en función del resultado del registro bl. (Empezamos a observar algo de redundancia aquí, por lo que la hipótesis de que se ha empleado algún tipo de programa para ofuscar el código es cada vez más firme :P)

Finalmente se mueven de nuevo los dos valores comparados en el strcmp, y se ejecuta la instrucción cmovz (al parecer sin valor alguno debido a que solo se ejecuta si ZF=1, es decir, si ecx y eax ya son iguales).

Como podéis ver, una locura para al final solo acabar realizando una comparación xD Por lo que antes de ingresar en un psiquiárico, procederemos a realizar un análisis dinámico partiendo del bloque de código identificado.

Cuando el proceso recibe una conexión al puerto 6969, éste crea un nuevo proceso hijo mediante la syscall ‘clone’ y le pasa el control al mismo para que continúe su ejecución. Para poder debugear el proceso hijo sin que el padre nos moleste (al cabo de un tiempo envia un SIGALARM y nos mata el proceso), empleamos la instrucción “catch” de GDB para que, una vez cree el proceso hijo, podamos pausar su ejecución, y de esta forma poder debugear el proceso hijo con calma.

 

gdb debug

 

 

Añadimos un breakpoint a la dirección del bloque de código donde hemos observado el offset del ‘puts’, y ejecutamos la instrucción para ver que ocurre. Observamos que no  se observa ningún cambio, por lo que el flujo de ejecución no pasa por ahí. (ouch!) Continuemos con el análisis pues.

putsdoesnotork

Observando más detenidamente el código y continuando con la búsqueda de cadenas de texto interesantes como los comandos encontramos una zona de memoria donde se definen los offsets de las funciones asociadas a cada comando de la shell analizada:

commands

En la imagen se muestran los offsets de las funciones ya renombrados.

Usando la funcionalidad de cross-reference vemos que el primero de estos offsets es llamado desde otro punto del código:

xrefs

 

 

En ese punto se aprecia el acceso a este offset con un desplazamiento dinàmico con el valor almacenado en [eax*8]. Esto permite con el valor de eax recorrer la zona de memoria que contiene los punteros a las funciones de cada comando. Más tarde este offset guardado en el registro eax será llamado con call eax.

Captura de pantalla 2014-10-31 a la(s) 11.40.01

 

Tirando del hilo veremos que el valor de eax viene condicionado supuestamente por el valor del comando introducido por el usuario, mediante el offset “off_804E848”.

Captura de pantalla 2014-10-31 a la(s) 11.46.07

Vemos que este valor parece venir de la función _fgets. Aunque de momento, debido a que el flujo del código esta ofuscado con la implementación de una máquina de estados, no podemos estar seguros de todas estas conjeturas. Deberemos por lo tanto ejecutar el análisis de forma dinámica para estar seguros.

Captura de pantalla 2014-10-31 a la(s) 12.08.57

Para analizar todos los valores comentados anteriormente de forma dinámica, utilizaremos gdbserver para debuggar cómodamente  de forma remota y poder indicar los breakpoints directamente desde IDA.

GDBServer

Luego en IDA seleccionamos el Debugger de tipo GDB server y configuramos la ip y el puerto:

IDA GDB Config

 

Ya podemos a priori centrarnos en el comportamiento de los comandos que más nos interesen, en este caso ‘cat’, ‘set’, y el misterioso ‘puts’. Para ello prepararemos el entorno para debuggar y pondremos breakpoints en los puntos más interesantes.

Focalizando en las funciones cat, set, i puts vemos que todas están implementadas ofuscando el flujo del código con una máquina de estados. Por lo tanto buscaremos las llamadas mas interesantes para poner breakpoints. Para verificar que no se nos escapa nada y por donde podemos empezar a mirar, sacamos un grafo de llamadas desde cada función que nos interesa con Graphview.

Captura de pantalla 2014-10-31 a la(s) 12.27.40Captura de pantalla 2014-10-31 a la(s) 12.28.17Captura de pantalla 2014-10-31 a la(s) 12.27.57

 

 

 

 

 

 

 

 

Ponemos los breakpoints en las llamadas empleadas en cada una de las funciones anteriormente mostradas en los callgraphs (strcmp, fopen, fgets, strncpy), con la finalidad de identificar, por ejemplo, las comparaciones realizadas en cada una de las llamadas a “strcmp”,  y empezamos a jugar.

En la función “cat” observamos se emplea una llamada a fopen para abrir el fichero a leer y que el valor de dicho fichero esta hardcodeado a “flag.txt”, por lo que solo se podrá abrir un fichero con dicho nombre.

Captura de pantalla 2014-10-31 a la(s) 12.30.13

Captura de pantalla 2014-10-31 a la(s) 12.31.24

En la función “set” observamos que las variables de entorno se guardan en memoria empezando en el offset dword_804e8a8 sumando un desplazamiento de 0x100 bytes (por lo que resulta en 804e9a8) y que el numero de variables de entorno se guarda en el offset dword_804e8a4.

Captura de pantalla 2014-10-31 a la(s) 12.32.00

 

Podemos ver como en las direcciones de memoria anteriormente comentadas se almacenan las variables de entorno seteadas con el comando “SET”, (variable en 0x804e8a8 y valor en un offset de 0x100, concretamente en 0x804e9a8).

EnvVars

 

EnvVars_command

 

En la función “puts” observamos que recorre las variables definidas con set (incluso recorre las que se han “eliminado” con unset pero que aún siguen en la memoria pero sin la primera letra) y compara su valor con la cadena “puts”.

Captura de pantalla 2014-10-31 a la(s) 12.35.58

 

Si una de las variables se llama “puts” entonces compara su valor con “printf”.

Captura de pantalla 2014-10-31 a la(s) 12.36.48

 

Probamos el comportamiento creando una variable de entorno que se llame puts y que su valor sea printf y luego invocamos a puts. Como podemos ver, parece que se hemos conseguido una escalada de privilegios o algo parecido.

Captura de pantalla 2014-10-31 a la(s) 12.37.36

 

Probando ahora el comando cat con un fichero cualquiera del directorio desde donde ejecutamos la shell vemos que nos devuelve “error: permission denied”

Captura de pantalla 2014-10-31 a la(s) 12.38.58

Pero si recordamos que el valor de “flag.txt” está hardcodeado en el binario, miremos de probar pues de modificar el fichero de nuestro entorno local a dicho nombre. Volvemos a provar y ya podemos mostrar el contenido de flag.txt!

Captura de pantalla 2014-10-31 a la(s) 12.51.08

 

En este caso esta prueba no logramos resolverla dentro del tiempo del CTF. Pudimos resolverlo con calma luego desde casa 😛

Solo queda dar gracias al staff de las NCN por la originalidad de los juegos!

 

Post escrito con la colaboración de “Pau Rodriguez”, miembro activo de 0xb33r$ 🙂