Aragog

Harry Potter Series 1 | Difficulty: Easy | OS: Linux

Last updated 5 months ago

Aragog

Harry Potter Series 1 | Difficulty: Easy | OS: Linux

Walkthrough - Youtube Habemus Shell

Scanning

sudo nmap -sS -Pn 10.0.0.11

Services and Versions

sudo nmap -sS -Pn -p 22,80 -sV 10.0.0.11

Exploration

Port 80 - Http

Começamos interagindo com o primeiro serviço que normalmente em CTF é utilizado, que são as páginas WEB.

Vamos realizar um Fuzzing para encontrarmos novos diretórios, e vamos aproveitar e inserir extensões comuns de arquivos como php, html e txt;

feroxbuster -u http://10.0.0.11/ -w /usr/share/wordlists/dirb/big.txt -t 200 -x php,html,txt -n

Acessando a página /blog/, vemos que ela não conseguiu carregar a página de maneira correta, faltando os elementos visuais.
Observe que temos nessa página má carregada algumas informações bem interessantes, já informando que se trata de um CMS bem conhecido, que é o Wordpress.
Analisando a response pelo Burp, podemos verificar que ele tenta chamar o domínio http://wordpress.aragog.hogwarts

Então vamos vincular esse nome ao ip do host, no nosso arquivo /etc/hosts para poder resolver esse nome que o server espera

Podemos agora fazer um ping no domínio, para ver se ele esta respondendo para o ip que determinamos.

E agora que esta tudo certo, podemos chamar então o site com esse domínio e vamos ver que todo efeito visual da página estará montado, facilitando ainda mais saber que se trata de um CMS Wordpress.

Existe uma ferramenta muito utilizada para nos ajudar a enumerar um site com Wordpress, ela se chama WPScan. Iremos utilizar essa ferramenta para enumerar versão, plugins vulneráveis, temas vulneráveis, etc.
Obs: essa ferramenta fica extremamente mais eficaz se você entrar no site deles e criar uma chave de api para utilizar. Pois, ela irá pegar informações bem mais novas sobre as vulns que surgiram depois.
Vamos iniciar atualizando o nosso wpscan

wpscan --update

Vamos agora enumerar (-e) todos os plugins (ap) de forma agressiva, e para ser mais rápido iremos utilizar um thread (-t) de 200.

wpscan --url http://wordpress.aragog.hogwarts/blog/ -t 200 -e ap --plugins-detection aggressive

Após a execução, a ferramenta identificou alguns plugins que estão desatualizados. Um deles é o wp-file-manager, que esta na versão 6.0 e segundo a ferramenta a versão mais nova é a 8.0
Atualizações normalmente vem para corrigir problemas e não apenas para trazer novas features.

Uma rápida pesquisa no Google, podemos ver que há um exploit público para a versão desse plugin.

Analisando o exploit, podemos entender melhor o que ele irá fazer para explorar essa vulnerabilidade.
Ele está realizando um upload de um arquivo .php que terá um parâmetro vulnerável a RCE chamado ?cmd
E também irá salvar esse arquivo em wp-content/plugins/wp-file-manager/lib/giles/if_it_works.php

Vamos então fazer o clone desse repositório para nossa máquina para utilizar esse exploit.

git clone https://github.com/ircashem/wp-file-manager-plugin-exploit

Vamos executar o exploit diretamente onde temos o nosso wordpress, ou seja, em /blog/

python3 exploit.py --url http://wordpress.aragog.hogwarts/blog/

Observe que mesmo ele informando que não está vulnerável e nem nos mostra a página que precisaríamos acessar caso tivesse dado certo. Porém, como lemos o exploit e entendemos o que ele esta fazendo, podemos ir direto para o caminho que vimos no código.
E assim que entramos não temos um status code 404 de página inexistente. Pelo contrário, temos uma página toda em branco.
Como lemos e entendemos bem o exploit, vimos que essa página precisa de um parâmetro cmd que será o nosso entry point para um RCE.

Observe que se colocarmos o parâmetro e passar para ele um comando, conseguimos executar códigos remoto no servidor. Caracterizando uma falha de Remote Code Execution (RCE).

?cmd=id

Uma visão pelo Burp do mesmo comportamento.

Bom, por algum motivo, eu não estava conseguindo um reverse shell pelo "webshell" que haviamos conseguido com o exploit, então resolvi jogar um reverse shell php bem conhecido como o PentestMonkey no alvo.

Após isso salvei ele em um arquivo na minha máquina

Subi um servidor python na minha máquina para baixar no alvo, já que eu posso executar comandos remotamente no servidor alvo, então eu posso baixar facilmente esse meu reverse shell em php.

python3 -m http.server 8081

Initial Access

Agora se deixarmos um listener com netcat na porta 443 e executarmos o nosso reverse shell diretamente na url, podemos receber a conexão do alvo.

nc -lnvp 443

Conseguimos a shell, mas ela não é muito interativa, e se fizermos um CTRL+C podemos perder a conexão também. Então vamos deixar esse shell mais interativo e seguro para não perdermos.

# Siga os passos abaixo, um por vez:

python3 -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm
CTRL + Z
stty raw -echo; fg

Encontramos a primeira Flag (horcrux)

Privilege Escalation

Agora precisamos elevar os nossos privilégios para root, para conseguirmos acessar a última flag.
Para isso, fiz um trabalho de pós-exploração, procurando informações relevantes na máquina que podiam me ajudar a elevar esse privilégio
Como eu fiz o upload de um reverse shell com nome shell.php, eu queria saber onde exatamente ele estava pra poder procurar arquivos sensíveis do wordpress.

find / -name shell.php 2>/dev/null

Encontrei o local onde o wordpress salva os arquivos !
Bom, normalmente o CMS Wordpress configura usuário e senha em um arquivo de configuração chamado wp-config.php, vamos prourar esse arquivo e ver se conseguimos obter informações relevantes.

Encontrei dentro dele um caminho para outro arquivo de configuração do wordpress chamado config-default.php, vamos até ele para ver se conseguimos o que estamos buscando.

Exatamente como pensávamos, conseguimos as credenciais para acesso ao banco de dados MySQL do wordpress. Com isso, conseguimos talvez recuperar mais informações sobre os usuários que tem nessa aplicação.

Vamos conectar ao mysql com as credenciais encontradas

mysql -u root -p 

# vai abrir um contexto para receber a senha, coloque a senha encontrada

Após conectado, vamos enumerar as databases que existem.

show databases;

Vamos agora selecionar a database que encontramos e exibir todas as tabelas que ela possui, e após isso, exibir todas as colunas dessa tabela em específico.

use wordpress;
show tables;
select * from wp_users;

Agora podemos tentar descobrir que tipo de hash é esse que é salvo a senha

hash-identifier
# passa o hash que encontramos e aperte ENTER

Agora podemos tentar quebrar esse hash para descobrir essa senha, podemos utilizar a ferramenta john para esse propósito

john --wordlist=/usr/share/wordlists/rockyou.txt hash

Bom, agora que conseguimos descobrir a senha do usuário Hagrid98, podemos tentar conectar via ssh, outro serviço que estava disponível quando realizamos o nosso escaneamento.

Agora temos acesso a um outro usuário nesse alvo, mas ainda não somos root. Precisamos escalar para root
Vamos utilizar agora uma ferramenta para análise de processos que estão sendo executados e quem o esta executando no sistema. Ele mostra em tempo real a execução, então isso irá nos ajudar muito.
A ferramenta se chama pspy, e tem versões 32 e 64 bit.

Após o download, jogue no alvo da mesma forma que fizemos anteriormente com o python.

Após o download, de permissão de execução a esse binário:

chmod +x pspy32

Execute o pspy, e verá que em um certo momento o usuário root (UID 0) executa o script que esta localizado em /opt/.backup.sh

Indo até esse script, vemos que quem é dono dele é o próprio usuário que temos no momento, o Hagrid98.
Ou seja, se podemos editar um arquivo que o root executa de tempo em tempo, podemos fazer o root executar qualquer coisa que queremos.

Analisando esse arquivo, ele simplesmente faz uma cópia recursiva de uploads do wordpress para a pasta temporária /tmp com a mesma finalidade.

Vamos editar esse script para que ele sete no binário /bin/bash o bit SUID, que quando for executado vai nos dar a permissão de usar esse binário com o uid do proprietário, ou seja, o root.