Security et alii

El pasado fin de semana, coincidiendo con la RootedCon, se celebraba en Guipúzcoa este encuentro anual que, entre los eventos que presenta incluye un pequeño CTF. Parte de ese CTF consiste en obtener el password para autenticarse en dos binarios, un ELF y un PE. Estos binarios fueron creados por la gente de morenops.com, y podéis descargarlos desde aquí. No os recomiendo que leais los comentarios porque dan muchas pistas sobre la solución.

AVISO: Voy a poner la solución al reto paso a paso, tratando de que sea un solucionario completo para que tanto la gente con pocos conocimientos del tema como los más expertos puedan seguirlo. No obstante, lo ideal es que trates de resolverlo por tu cuenta, y que si te atascas continues leyendo. Dicho queda.

Método para el ELF

En primer lugar decir que esta es sólo una posible solución, existen otras formas de solucionar este reto, y estaré encantado de que las dejéis en los comentarios para dar con la mejor solución. Tras descargar el binario y darle permisos de ejecución, podemos tratar de obtener algo de información acerca del mismo con la orden file.

adrian@Andromeda:~$ file tolosa2010_unix
tolosa2010_unix: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.8, not stripped

Con esto ya sabemos que, puesto que está enlazado de manera estática, un ltrace del programa no nos dará ninguna información. Sin embargo, no está stripeado, por lo que es posible que encontremos símbolos de depuración en el programa. El siguiente paso es darle permisos de ejecución y ejecutarlo un par de veces para hacernos una idea inicial de cómo funciona.

Probando lo básico

Bueno, está claro que no vale cualquier clave, ni una clave en blanco, ni una clave demasiado larga. Así que nos va a tocar currar un poco más. Lo siguiente que a mí se me ocurre es utilizar strace para averiguar qué llamadas al sistema realiza y qué señales está recibiendo el programa.

adrian@Andromeda:~/pre$ strace ./tolosa2010_unix
execve("./tolosa2010_unix", ["./tolosa2010_unix"], [/* 35 vars */]) = 0
[ Process PID=5364 runs in 32 bit mode. ]
old_mmap(0xc40000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0xc40000) = 0xc40000
readlink("/proc/self/exe", "/home/adrian/pre/tolosa2010_unix", 4096) = 32
old_mmap(0x8048000, 493385, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8048000
mprotect(0x8048000, 493382, PROT_READ|PROT_EXEC) = 0
old_mmap(0x80c1000, 3843, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0x78000) = 0x80c1000
mprotect(0x80c1000, 3840, PROT_READ|PROT_WRITE) = 0
old_mmap(0x80c2000, 6764, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x80c2000
brk(0x80c4000)                          = 0x9f2a000
munmap(0xc01000, 262144)                = 0
uname({sys="Linux", node="Andromeda", ...}) = 0
brk(0)                                  = 0x9f2a000
brk(0x9f2acb0)                          = 0x9f2acb0
set_thread_area(0xffac203c)             = 0
brk(0x9f4bcb0)                          = 0x9f4bcb0
brk(0x9f4c000)                          = 0x9f4c000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7775000
write(1, "\n", 1
)                       = 1
write(1, "\t[Gipuzkoa Encounter 2010 - Hack"..., 38    [Gipuzkoa Encounter 2010 - Hack It!]
) = 38
write(1, "\n", 1
)                       = 1
ptrace(PTRACE_TRACEME, 0, 0x1, 0)       = -1 EPERM (Operation not permitted)
write(1, "\tPassw0rd: \tomgz0r debugger? bye"..., 40    Passw0rd:     omgz0r debugger? bye bye...
) = 40
exit_group(0)                           = ?

adrian@Andromeda:~/pre$

Sin embargo parece que por aquí tampoco llegamos a ninguna parte. Vemos que realiza alguna reserva de memoria, que llama a uname y a write para mostrar el mensaje de bienvenida. Después hace una llamada a ptrace y nos escribe un mensaje: “Passw0rd:     omgz0r debugger? bye bye..”. Al tratar de tracear el programa y ya estar siendo traceado por nosotros, ptrace devuelve un error y el programa finaliza. Vamos a tratar de utilizar gdb para seguir un poco el funcionamiento interno del programa, con la idea de averiguar qué está pasando y de tratar de localizar la función que comprueba si una contraseña es válida o no.

adrian@Andromeda:~/pre$ gdb -q tolosa2010_unix
Leyendo símbolos desde /home/adrian/pre/tolosa2010_unix...(no debugging symbols found)...hecho.
(gdb) list
No hay tabla de símbolos cargada. Use la orden "file".
(gdb) br main
No hay tabla de símbolos cargada. Use la orden "file".
Make breakpoint pending on future shared library load? (y o [n]) y
Punto de interrupción 1 (main) pendiente.
(gdb) run
Starting program: /home/adrian/pre/tolosa2010_unix

 [Gipuzkoa Encounter 2010 - Hack It!]

 Passw0rd:     omgz0r debugger? bye bye...

Program exited normally.
(gdb) disass main
No symbol table is loaded.  Use the "file" command.

Otra cosa que falla. Está claro que al binario le pasa algo, ya que aparte de evitar la depuración, no nos encuentra el punto de entrada del binario en main. Llegados a este punto (los lectores avezados lo habrán visto antes) cabe pensar que el binario tiene algún tipo de cifrado o empaquetado. Volcaremos el binario, ya sea en hexadecimal con objdump o buscando solo las cadenas de texto con strings en busca de alguna pista como la que se ve a continuación:

adrian@Andromeda:~/pre$ hexdump -C tolosa2010_unix | head
00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  60 f1 c3 00 34 00 00 00  |........`...4...|
00000020  00 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 10 c0 00  |................|
00000040  00 10 c0 00 68 e9 03 00  68 e9 03 00 05 00 00 00  |....h...h.......|
00000050  00 10 00 00 01 00 00 00  6c 0a 00 00 6c 3a 0c 08  |........l...l:..|
00000060  6c 3a 0c 08 00 00 00 00  00 00 00 00 06 00 00 00  |l:..............|
00000070  00 10 00 00 4d a8 73 e7  55 50 58 21 08 08 0d 0c  |....M.s.UPX!....|
00000080  00 00 00 00 5a a9 08 00  5a a9 08 00 d4 00 00 00  |....Z...Z.......|
00000090  79 00 00 00 08 00 00 00  77 1f a4 f9 7f 45 4c 46  |y.......w....ELF|
adrian@Andromeda:~/pre$ strings tolosa2010_unix | head
UPX!
[]g;;
PTRh
=]<r
mnfM
F>wp
<    wD
1]>ng
FzFM
{0c;]_V

Si nos fijamos bien, encontraremos la cadena UPX!, lo que nos indica que el binario ha sido empaquetado con esta utilidad. Esto ha sido fácil, en otras ocasiones habría sido necesario detectar en el binario el código que realiza el empaquetado y tratar de deshacerlo o identificar el empaquetador. Por lo tanto instalaremos el packer, bien desde su web, bien desde el sistema de paquetes de la distribución que utilicemos. Una vez instalado procederemos a desempaquetar el binario.

adrian@Andromeda:~/pre$ upx -d tolosa2010_unix
 Ultimate Packer for eXecutables
 Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007
UPX 3.01        Markus Oberhumer, Laszlo Molnar & John Reiser   Jul 31st 2007

 File size         Ratio      Format      Name
 --------------------   ------   -----------   -----------
 567642 <-    256396   45.17%  linux/elf386   tolosa2010_unix

Unpacked 1 file.

Ahora que hemos desempaquetado el binario podemos retomar la idea de depurarlo y tratar de localizar el punto en el que verifica la clave. Vamos a ver qué sucede:

drian@Andromeda:~/pre$ gdb -q tolosa2010_unix
Leyendo símbolos desde /home/adrian/pre/tolosa2010_unix...hecho.
(gdb) br main
Punto de interrupción 1 at 0x80482c9
(gdb) run
Starting program: /home/adrian/pre/tolosa2010_unix
Breakpoint 1, 0x080482c9 in main ()
Idioma actual:  auto
The current source language is "auto; currently asm".
(gdb) list
1    /tmp/cc1PTP7g.s: No existe el fichero ó directorio.
 in /tmp/cc1PTP7g.s
(gdb) n
Single stepping until exit from function main,
which has no line number information.

 [Gipuzkoa Encounter 2010 - Hack It!]

 Passw0rd:     omgz0r debugger? bye bye...

Era de esperar que sucediera esto, pero ahora encuentra los símbolos, lo cual está bien, ya que nos va a permitir hacer esto:

(gdb) disass main
Dump of assembler code for function main:
0x080482bb <main+0>:    lea    ecx,[esp+0x4]
0x080482bf <main+4>:    and    esp,0xfffffff0
0x080482c2 <main+7>:    push   DWORD PTR [ecx-0x4]
0x080482c5 <main+10>:    push   ebp
0x080482c6 <main+11>:    mov    ebp,esp
0x080482c8 <main+13>:    push   ecx
0x080482c9 <main+14>:    sub    esp,0x14
0x080482cc <main+17>:    mov    DWORD PTR [esp],0x80a4f08
0x080482d3 <main+24>:    call   0x8048f70 <puts>
0x080482d8 <main+29>:    mov    DWORD PTR [esp],0x80a4f2f
0x080482df <main+36>:    call   0x8048d80 <printf>
0x080482e4 <main+41>:    call   0x8048273 <check>
0x080482e9 <main+46>:    mov    DWORD PTR [esp],0x80c3840
0x080482f0 <main+53>:    call   0x8048db0 <gets>
0x080482f5 <main+58>:    mov    DWORD PTR [esp],0xa
0x080482fc <main+65>:    call   0x8049110 <putchar>
0x08048301 <main+70>:    mov    DWORD PTR [esp],0x80c3840
0x08048308 <main+77>:    call   0x8048210 <balioztau>
0x0804830d <main+82>:    test   eax,eax
0x0804830f <main+84>:    je     0x804831f <main+100>
0x08048311 <main+86>:    mov    DWORD PTR [esp],0x80a4f3c
0x08048318 <main+93>:    call   0x8048f70 <puts>
0x0804831d <main+98>:    jmp    0x804832b <main+112>
0x0804831f <main+100>:    mov    DWORD PTR [esp],0x80a4f46
0x08048326 <main+107>:    call   0x8048f70 <puts>
0x0804832b <main+112>:    add    esp,0x14
0x0804832e <main+115>:    pop    ecx
0x0804832f <main+116>:    pop    ebp
0x08048330 <main+117>:    lea    esp,[ecx-0x4]
0x08048333 <main+120>:    ret
End of assembler dump.

Al principio hace unas llamadas a printf y puts para mostrar el mensaje inicial en la terminal, y despúes (main+41) realiza una llamada a la función check. Tras esto, lee lo que le pasamos como clave (gets), imprime un salto de línea (putchar 0xa) y llama a una función “balioztau” con un argumento, que es donde ha almacenado lo que hemos tecleado. En función del resultado de esa función (main+84) saltará a nuestro FAIL o al mensaje de éxito. Todos los valores de memoria que aparecen contienen las cadenas que maneja el programa, podemos verlo rápidamente:

(gdb) x/s 0x80a4f08
0x80a4f08:     "\n\t[Gipuzkoa Encounter 2010 - Hack It!]"
(gdb) x/s 0x80a4f2f
0x80a4f2f:     "\n\tPassw0rd: "
(gdb) x/s 0x80c3840
0x80c3840 <pasahitza>:     ""
(gdb) x/s 0x80a4f3c
0x80a4f3c:     "\tSuccess!"
(gdb) x/s 0x80a4f46
0x80a4f46:     "\t#EPIC FAIL"

Tal y como yo lo veo, una vez aquí tenemos dos opciones: tratar de saltarnos la protección antidepuración para poder examinar la memoria en ejecución y localizar el password válido, o desensamblar la función balioztau y comprender de manera estática qué comprobaciones hace sobre el password. Ambos métodos son muy interesantes, pero de momento expondremos el segundo, explicando además una técnica utilizada para la realización de keygens y para la ingeniería inversa en general. Veamos el código de la función balioztau:

(gdb) disass balioztau
Dump of assembler code for function balioztau:
0x08048210 <balioztau+0>:    push   ebp
0x08048211 <balioztau+1>:    mov    ebp,esp
0x08048213 <balioztau+3>:    sub    esp,0x14
0x08048216 <balioztau+6>:    mov    DWORD PTR [ebp-0x4],0x0
0x0804821d <balioztau+13>:    mov    BYTE PTR ds:0x80c17de,0x0
0x08048224 <balioztau+20>:    mov    DWORD PTR [ebp-0x8],0x0
0x0804822b <balioztau+27>:    jmp    0x8048261 <balioztau+81>
0x0804822d <balioztau+29>:    mov    edx,DWORD PTR [ebp-0x8]
0x08048230 <balioztau+32>:    mov    eax,edx
0x08048232 <balioztau+34>:    shr    eax,0x1f
0x08048235 <balioztau+37>:    add    eax,edx
0x08048237 <balioztau+39>:    sar    eax,1
0x08048239 <balioztau+41>:    mov    DWORD PTR [ebp-0x4],eax
0x0804823c <balioztau+44>:    mov    eax,DWORD PTR [ebp-0x8]
0x0804823f <balioztau+47>:    movzx  edx,BYTE PTR [eax+0x80c17c8]
0x08048246 <balioztau+54>:    mov    eax,DWORD PTR [ebp-0x4]
0x08048249 <balioztau+57>:    movzx  eax,BYTE PTR [eax+0x80c3840]
0x08048250 <balioztau+64>:    cmp    dl,al
0x08048252 <balioztau+66>:    je     0x804825d <balioztau+77>
0x08048254 <balioztau+68>:    mov    DWORD PTR [ebp-0x14],0x0
0x0804825b <balioztau+75>:    jmp    0x804826e <balioztau+94>
0x0804825d <balioztau+77>:    add    DWORD PTR [ebp-0x8],0x2
0x08048261 <balioztau+81>:    cmp    DWORD PTR [ebp-0x8],0x16
0x08048265 <balioztau+85>:    jle    0x804822d <balioztau+29>
0x08048267 <balioztau+87>:    mov    DWORD PTR [ebp-0x14],0x1
0x0804826e <balioztau+94>:    mov    eax,DWORD PTR [ebp-0x14]
0x08048271 <balioztau+97>:    leave
0x08048272 <balioztau+98>:    ret
End of assembler dump.

Con el código delante el proceso consiste en leerlo e ir anotándolo con comentarios hasta que se haya comprendido su funcionamiento. Lo primero será averiguar qué hay en la memoria en 0x80c17c8, puesto que en 0x80c3840 ya sabemos que se encuentra lo que hemos introducido en la terminal. Os recomiendo que tratéis de hacer vosotros la anotación antes de leer la mía. Tras un par de pasadas anotando deberíais tener unas anotaciones similares a estas:

anotaciones de balioztau

Os las subo también como fichero adjunto, porque ponerlas en forma de código quedaba descolocado debido al tamaño de la caja de texto. Con esto debería ser evidente qué está realizando la función y cual es el password que debemos introducir. Aún así, cuando se trata de conseguir un keygen o de hacer más claro el problema (esta función no es especialmente complicada) se procede a traducir el código a C. En primer lugar una traducción directa del ensamblador, y finalmente se refactoriza el código para obtener algo más parecido a lo que escribiría un programador. La traducción directa a C desde ese código podría ser algo como esto (la función main ha sido añadida por comodidad y para que el programa sea usable):

#include <stdio.h>
#include <stdlib.h>

char pass_valido[20] = "t_0/l=0(s?@ah:40c7k#";

int balioztau(char* pass_usuario){

unsigned int var1,var2,ret;
unsigned char *pp,*pu;
var1=0;
var2=0;
ret = 0;

pp = pass_valido;
pu = pass_usuario;

do{
var1 = var1 >>> 31; // var1 = 0;
var1 = var2 + var1;
var1 = var2/2;

if (*(pu+var1) == *(pp+var2)){
 var2 = var2 +2;
}else{
 ret =0;
 return ret;
}

} while (var2 <= 20);

ret = 1;
return ret;
}

int main(int argc, char* argv[]){
 if (argc != 2){
 printf("Uso: %s <password a comprobar>\n",argv[0]);
 exit(0);
 }
 if (balioztau(argv[1])){
 printf("WIN\n");
 }else{
 printf("FAIL\n");
 }
return 0;
}

Aquí se ve mejor que el funcionamiento consiste en recorrer la cadena en memoria (pass_valido) de dos en dos e ir comparándola con lo que ha introducido el usuario (recorrido de uno en uno). Por lo tanto, el caracter en la posición 0 del usuario se validará contra el 0 de la password, el primero del usuario contra el segundo de la password, y así hasta el final. Por tanto la password para el programa es “t0l0s@h4ck“, como se muestra a continuación:

adrian@Andromeda:~/pre$ ./tolosa2010_unix

 [Gipuzkoa Encounter 2010 - Hack It!]

 Passw0rd: t0l0s@h4ck

 Success!
adrian@Andromeda:~/pre$ ./a.out
Uso: ./a.out <password a comprobar>
adrian@Andromeda:~/pre$ ./a.out hola
FAIL
adrian@Andromeda:~/pre$ ./a.out t0l0s@h4ck
WIN

Queda como tarea vuestra pasar el código C a algo más habitual, convertir el while en un for, eliminar las variables sobrantes, los desplazamientos extraños, etc. En otra entrada veremos cómo solucionar el binario de windows, y quizá cómo solucionar este mismo parcheando el binario. Si tenéis cualquier duda o aportación ya sabéis