Venom 1
#easy #VulnHub #Linux #eJPT #eWPT
Reconhecimento de Rede
Descoberta de Hosts Ativos
Para iniciar o reconhecimento da rede, comecei com um ping sweep para identificar quais hosts estavam ativos. Usei o nmap com a opção -sn (ping scan) para realizar essa tarefa:
O scan revelou que a máquina alvo estava no IP 10.0.2.5. Esse foi o meu ponto de partida para os próximos passos.
Varredura de Portas e Serviços
Com o IP da máquina alvo em mãos, o próximo passo foi realizar um scan de portas para identificar quais serviços estavam ativos. Usei o nmap para escanear todas as portas TCP:
O scan revelou que as portas 21 (FTP), 80 (HTTP), 139 (NetBIOS), 443 (HTTPS) e 445 (Microsoft-DS) estavam abertas.
Para obter mais detalhes sobre os serviços em execução, executei um scan mais específico nas portas identificadas:
O scan revelou que os serviços encontrados eram:
Porta 21 (FTP): vsftpd 3.0.3
Porta 80 (HTTP): Apache httpd 2.4.29 (Ubuntu)
Porta 139 (NetBIOS): Samba smbd 3.X - 4.X
Porta 443 (HTTPS): Apache httpd 2.4.29 (Ubuntu)
Porta 445 (SMB): Samba smbd 4.7.6-Ubuntu
Além disso, o scan forneceu informações adicionais sobre o serviço NetBIOS/Samba, incluindo a versão do Samba e alguns detalhes sobre o sistema:
Nome do computador NetBIOS: VENOM
Sistema Operacional: Windows 6.1 (Samba 4.7.6-Ubuntu)
Workgroup: WORKGROUP
Esses detalhes foram cruciais para orientar o próximo passo na exploração da máquina.
Explorando o Servidor Web
Quando acessei o servidor web via navegador, encontrei a página padrão do Apache.
Em seguida, inspecionei o código-fonte da página e descobri um comentário contendo um hash suspeito:
Identifiquei o hash como possivelmente MD5 usando a ferramenta hash-identifier:
Com o hash identificado, usei o site Crackstation para decifrar o hash, obtendo a senha em texto claro: hostinger.
Explorando o FTP
Testando por tentativa e erro o termo "hostinger” como usuário e senha no FTP, conseguimos acesso:
Salvei essas credenciais para futuras referências:
Dentro do diretório files, encontrei um arquivo chamado hint.txt.
O arquivo hint.txt continha um domínio, o nome de usuário “dora”, dicas criptografadas, além de um desafio para de criptografar uma senha.
Salvei "dora" e a senha criptografada como possíveis credenciais úteis:
Adicionei também o domínio ao arquivo /etc/hosts para facilitar o acesso:
Acessando o Novo Domínio
Após acessar o domínio venom.box, percebi que ele resolve para um novo site, que inclui um painel de login:
Inspecionando as dicas que encontrei, notei que alguns textos estavam codificados em Base64. Decodifiquei um desses textos e obtive a dica de usar a cifra Vigenère para decodificar a senha:
Além disso, a decodificação de outro texto Base64 me levou ao seguinte site, que oferece uma ferramenta para decodificação usando a cifra Vigenère:
Utilizando o site indicado e inserindo o texto cifrado junto com a chave hostinger, obtive uma credencial potencial:
E7r9t8@Q#h%Hy+M1234
Com essa senha e o usuário dora, consegui acessar o painel de login em venom.box, e de fato obtive acesso à conta de administrador, conforme indicado pelo arquivo hint.txt:
Salvei essa informação:
Explorando o CMS Subrion
No rodapé da página, observei que o site estava rodando o CMS Subrion versão 4.2:
Examinei o código-fonte da página e confirmei que a versão do CMS é 4.2:
Pesquisei vulnerabilidades conhecidas para esta versão do CMS usando o searchsploit e encontrei várias falhas de segurança, incluindo uma vulnerabilidade de upload de arquivos:
Decidi explorar a vulnerabilidade de upload de arquivos para executar código remoto. Utilizei o script de exploração disponível para a versão 4.2.1:
O script pede uma URL base para o painel de administração, além de credenciais de usuário e senha:
Observando pelo navegador, o script busca abusar da funcionalidade de file upload, enviando assim uma webshell:
Ao executar o script com a URL do painel e as credenciais de dora, obtive sucesso na autenticação e na execução do ataque.
Com a webshell carregada, consegui executar comandos no servidor e confirmar que estava operando como www-data:
Ganho de Acesso
Depois de fazer o upload da webshell maliciosa com a funcionalidade de upload de arquivos, observei que o arquivo .phar foi carregado com sucesso:
Baixei o arquivo e verifiquei seu conteúdo. O script PHP no arquivo .phar permite a execução de comandos no sistema alvo através do parâmetro cmd:
Ao clicar com o botão direito no arquivo carregado e selecionar a opção "getsystem", verifiquei onde o arquivo estava acessível:
Para explorar a vulnerabilidade, acessei o arquivo através da URL da webshell, adicionando o parâmetro cmd para executar comandos no sistema:
Entendendo como a vulnerabilidade funciona, decidi modificar o arquivo para executar uma reverse shell. Substituí o código PHP pelo seguinte:
Isso faz com que a webshell se conecte de volta ao meu sistema na porta 443, estabelecendo uma conexão de shell reversa.
Depois de salvar as alterações, configurei meu listener para receber a conexão reversa:
Quando acessei a URL da webshell com o novo código, recebi uma conexão de shell reversa:
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
Ao ganhar acesso à máquina, verifiquei o diretório de uploads e encontrei o arquivo .phar malicioso que havia carregado:
Para cobrir meus rastros, usei o comando shred para excluir o arquivo de forma segura:
Agora que estou com o usuário www-data, verifiquei a presença do usuário hostinger no sistema:
Movimentação Lateral
Notei que a senha do hostinger é a mesma usada anteriormente. Assim, acessei a conta do hostinger com a senha hostinger:
Atualizei meu arquivo de credenciais para refletir todas as informações obtidas:
Adicionei também os usuários identificados para referência futura:
Após obter acesso ao diretório /home/hostinger, eu observei que o diretório do usuário nathan não estava acessível devido a permissões restritas:
No diretório de hostinger, encontrei o arquivo .bash_history, que continha comandos relacionados a um arquivo de backup:
Fui até o arquivo /var/www/html/subrion/backup/.htaccess, que continha uma possível senha:
Testei essa credencial e confirmei que era válida para o usuário nathan:
Atualizei o arquivo de credenciais para incluir a senha de nathan:
Com a credencial de nathan, agora posso acessar seu diretório home e encontrar a flag de usuário:
Obtendo Root
Após acessar a conta de nathan, verifiquei as permissões de sudo para entender quais comandos poderiam ser executados com privilégios de root. Descobri que nathan podia executar qualquer comando como root, com a exceção do comando /bin/su:
Como teste, utilizei sudo para iniciar uma shell com privilégios de root. Por exemplo, executei o comando whoami para verificar se realmente tinha privilégios de root:
Isso confirmou que eu tinha privilégios de root. Então, abri uma shell com sudo para executar comandos diretamente como root:
Com acesso root, pude acessar o arquivo de flag localizado no diretório /root:
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