Eyes
#easy #HackMyVM #Linux #eJPT #eWPT
Reconhecimento de Rede
Descoberta de Hosts Ativos
O primeiro passo foi identificar os hosts ativos na rede local. Para isso, utilizei a ferramenta netdiscover, que realiza uma varredura ARP passiva. Este método é eficaz para descobrir dispositivos que estão na mesma sub-rede, uma vez que a comunicação ARP é comum entre dispositivos conectados.
O scan revelou que a máquina alvo estava no IP 10.0.2.11. Esse foi o meu ponto de partida para os próximos passos.
Verificando a conectividade via Ping
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.
Varredura de Portas e Serviços
Em seguida, executei um escaneamento de porta no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. Usei a ferramenta rustscan para verificar todas as portas (1-65535) no alvo.
A varredura revelou os seguintes serviços:
21/tcp: FTP (vsFTPd 3.0.3) - Acesso anônimo permitido
22/tcp: SSH (OpenSSH 7.9p1)
80/tcp: HTTP (Nginx 1.14.2)
Explorando o Serviço FTP
O serviço FTP na porta 21 permitia acesso anônimo, ou seja, era possível acessar os arquivos sem necessidade de autenticação. Com isso, foi possível listar os arquivos e baixar um deles para análise.
Acessando o FTP:
Ao listar os diretórios, encontrei um arquivo interessante chamado index.php:
Baixando o arquivo:
Analisando o Arquivo PHP
Depois de baixar o arquivo index.php, o próximo passo foi analisá-lo. Ao abrir o arquivo, ficou evidente uma vulnerabilidade de Inclusão de Arquivo Local (LFI). O código PHP recebia um parâmetro via GET e o incluía diretamente no código, sem qualquer tipo de sanitização.
A linha vulnerável é a que faz o include do parâmetro fil3 sem nenhuma validação, possibilitando assim a exploração de LFI para acessar arquivos arbitrários no servidor.
Explorando o Serviço HTTP
Depois de identificar que o serviço HTTP estava ativo na porta 80, utilizei a ferramenta WhatWeb para obter mais informações sobre o servidor web e outras possíveis tecnologias em uso.
O comando acima foi usado para explorar o alvo. O WhatWeb retornou que o servidor em execução era o Nginx, versão 1.14.2.
Acessando a página no navegador, vemos que ela reflete o texto "Here my eyes...", sendo o mesmo texto do arquivo .php analisado, indicando que aquele arquivo no FTP do alvo seja o mesmo utilizado na aplicação web, logo, podendo conter a mesma vulnerabilidade de LFI que observamos no código.
Local File Inclusion (LFI)
Para explorar a vulnerabilidade de LFI encontrada no arquivo index.php, usei o comando curl para acessar arquivos sensíveis no servidor. O primeiro arquivo que tentei acessar foi o /etc/passwd, que contém informações sobre os usuários do sistema.
O comando acima acessou o arquivo /etc/passwd e mostrou o conteúdo, confirmando que a vulnerabilidade de LFI era explorável.
Esse arquivo revelou que havia uma usuária chamada monica, com um diretório /home/monica, sugerindo que essa conta poderia ser o próximo alvo para uma escalada de privilégios.
Para verificar quais usuários têm shells válidas, filtrei as linhas que terminam com sh.
Com essa informação, pude confirmar que tanto o root quanto a usuária monica têm shells válidas.
LFI para RCE via FTP Log Poisoning
Sabendo que havia uma vulnerabilidade de LFI, explorei a técnica de log poisoning para transformar essa vulnerabilidade em execução remota de código (RCE). O objetivo era injetar um código PHP malicioso nos logs do FTP e, em seguida, acessá-los via LFI para obter uma shell reversa.
Primeiro, verifiquei se os logs do FTP estavam acessíveis via LFI.
Confirmando que o arquivo de logs era acessível, o próximo passo foi injetar um payload PHP nos campos de login do FTP. Isso permitiria que o código PHP fosse registrado no log, onde seria executado quando acessado via LFI.
Conectei-me ao FTP e, nos campos de nome de usuário e senha, injetei o seguinte payload PHP: <?php system($_GET['cmd']); ?>.
Apesar da falha no login, o payload foi registrado no arquivo de log, permitindo sua execução através do LFI.
Acessando os Logs e Executando Comandos
Para verificar se o payload PHP foi executado com sucesso, usei o LFI para acessar os logs e passei o comando whoami como parâmetro.
A resposta indicou que o comando foi executado com sucesso e que o servidor estava rodando como o usuário www-data.
Obtenção de uma Shell Reversa
Com a execução remota de comandos confirmada, meu próximo passo foi obter uma shell reversa para ter controle total sobre a máquina. Para isso, utilizei o netcat para enviar uma conexão reversa para minha máquina de ataque.
Primeiro, configurei o meu listener com netcat:
Em seguida, executei o seguinte comando no alvo através da LFI para iniciar a conexão reversa:
No meu listener, recebi a conexão:
Agora, com uma shell na máquina alvo como o usuário www-data, o próximo passo seria investigar o sistema para identificar possíveis vetores de escalada de privilégios e avançar na exploração da máquina.
Upgrade da Shell
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
bashatravés do comandoscript, que abre uma sessão interativa mais apropriada, logo após, colocamos em background comCTRL+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:
Escalada de Privilégios
Agora que temos uma shell interativa estável, podemos explorar o sistema para escalar privilégios. Vamos começar inspecionando o diretório /opt.
Ao analisar o código do arquivo ls.c, percebemos que ele contém uma vulnerabilidade de buffer overflow:
O programa usa gets() para capturar a entrada do usuário, o que permite um ataque de buffer overflow, pois essa função não limita o tamanho da entrada.
No arquivo note.txt temos uma mensagem de "monica", afirmando estar preparando uma nova versão deste programa.
Testando o programa, vemos que há um input pro usuário onde inserimos um nome que é refletido, logo em seguida a funcionalidade de listar o diretório é executada, apresentando a listagem no output.
Buffer Overflow (Segmentation Fault)
A nível de POC, usamos o python para gerar um conjunto de 100 caracteres "a" para vermos como o programa se comporta ao receber isto como input.
Ao colocar estes caracteres como input, vemos que é quebrada a funcionalidade do programa, dando um aparente erro.
Ao colocar 200 caracteres "a", vemos que o programa incorre num erro especifico de "Segmentation fault".
Com isto, vamos explorar a falha enviando um padrão controlado para identificar o offset, para saber em que ponto ocorre a falha de segmentação:
Injetando esse padrão podemos ver em qual parte está quebrando a aplicação (c1Ac).
Dessa forma podemos ver o offset que no caso é 64.
Significa que podemos enviar 64 bytes (ou 64 caracteres "a") e em seguida injectar um comando, que por sua vez seria executado e controlado pelo usuário monica.
Agora temos controle sobre o executável e obtemos acesso como o usuário monica.
Portanto, podemos obter um console bash como monica e assim ler a user flag.
Obtendo Root via Bzip2
Conforme exibido ao usar o comando sudo -l, monica pode executar o binario bzip2 como qualquer usuário, inclusive root, sem precisar fornecer uma senha.
Inclusive, podemos conferir técnicas de escalada de privilégio relacionadas a este binário no GTFobins:
https://gtfobins.github.io/gtfobins/bzip2/
A princípio, vamos utilizar o bzip2 para ler o arquivo id_rsa do root e assim obter acesso como root via SSH:
Copie o conteúdo da chave privada id_rsa, salve em um arquivo na máquina atacante e altere as permissões:
Conecte-se ao alvo via SSH como root:
Por fim, podemos capturar a 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.
Atualizado