sábado, 18 de abril de 2020

HackTheBox - Mango machine walkthrough



TL;DR

The first foothold was to find a specific VHOST and the applicacation running into that. Then dumpping two users' credentials exploiting a NoSQL Injection vulnerability into the login form of that application. The next step was to use a one credential to login over SSH and the other one to move laterally to another user and get the user flag.
The root flag comes running the binary jjs that was with setuid and setgid setted up and also has grant to the user run arbitrary commands .



O ponto inicial foi encontrar um VHOST específico e a aplicação e por tanto uma aplicação específica. Em seguida, recuperar as credenciais de dois usuários que explorando uma vulnerabilidade de injeção NoSQL no formulário de login dessa aplicação. A próxima etapa foi usar uma credencial para efetuar login no SSH e a outra para mover-se lateralmente para outro usuário e obter a flag user.txt


O flag roote veio através da execução do programa jjs que estava com setuid e setguid definidos e que permitia execução de comandos arbitrários.








Passo a passo 

Inspecionando o certificado SSL foi possível recuperar um suposto e-mail válido admin@mango.htb e um virtual host staging-order.mago.htb e então um formulário de login. 

Depois de realizar fuzzings nesse formulário percebeu-se que ele era vulnerável a ataques de NoSQL Injection 





Criado um script para recuperar os usuários e senhas do banco de dados da aplicação,  este script foi inspirado no how to do projeto PayloadsAllTheThings no github.




Após executar tal script e recuperar as credenciais dos usuários mango e admin, o proximo passo foi validar se tais credencias seriam validas em outros serviços além da aplicação web, haja vista que a reutilização de senhas/credenciais é uma prática basteante comum. Esse teste verificou que seria possível obter acesso a máquina atraves do serviço SSH utilizando a as credencias do usuário mago. Apesar do usuário admin não ter acesso através do serviço SSH, foi verificado que serio possível personificá-lo utilizando o comando su e a sua senha recuperada da aplicação web. Este usuário deu acesso a flag user.txt

Como de costume, após obter acesso a um host procurou-se por todo tipo de informação que ajudasse a mover-se lateralmente ou escalar privilégios, o utilitários LinEnum e linpeas automatizam parte desse processo. 


Esse processo identificou que  o executável jjs tinha como seu dono o usuário root e grupo dono admin além de possuir setuid¹setgid definidos. Essa combinação de fatores cria o cenário onde podemos executar esse binário sobre o contexto do usuário root



De acordo com a documentação da Oracle o jjs executa o engenho Nashorn que por sua vez trata-se de um engenho JavaScript desenvolvido em Java. Após uma leitura rápida da documentação dessa engine foi criado um script capaz de receber um comando como aguento e executá-lo usando o jjs, ou seja sobre o contexto do usuário root.

#!/usr/bin/jjs
print($EXEC($ARG[0]));





O próximo passo foi utilizar esse script para adicionar uma chave SSH pública no authorized_keys do usuário root garantindo assim a persistência do acesso. 


Recomendações:



  • Correção do ponto vulnerável a ataques de NoSQL Injection


Detecção 


  • Qualquer configuração básica de um WAF deve ser capaz de detectar explorações de NoSQL Injection. No ModSecurity isso é coberto pela regra OWASP CRS 942290

Referencias:

1. setuid (abreviação de "set user ID upon execution", que significa, "definir ID de usuário sob execução" ) e' um parâmetro de direitos de acesso do Unix que permitem que usuários rodem um executável com as permissões do dono do executável.



domingo, 12 de abril de 2020

HackTheBox - Traverxec machine walkthrough


TL; DR


O ponto inicial foi a exploração da execução remota de código no servidor http Nostromo por meio de um path traversal  (CVE 2019-16278). Investigando no sistema de arquivos da máquina, encontramos um diretório "privado" dentro do diretório do usuário. Lá havia um backup da .ssh do usuário, incluindo a chave privada. Depois de recuperar a senha dessa chave, o acesso foi garantido usando as credenciais desse usuário. Esse usuário tinha a capacidade de executar o comando journalctl  utilizando sudo (ou seja no contexto do usuário root) sem solicitar a senha (sudo nopasswd), abusar desse binário foi o caminho para o root.





Passo a passo

O processo de enumeração revelou  um servidor web em execução na porta 80 e a porção  server das respostas HTTP do servidor revelavam que era um nhttpd (Nostromo Web Server) versão 1.9.6. Ao pesquisar por tal software e versão descobriu-se que o mesmo era afetado por um path traversal que conduzia a uma execução remota de código de acordo com o CVE 2019-16278. O primeiro passo foi confirmar que tal vulnerabilidade seria explorável nesse contexto e obter um exploração funcional.





Após confirmar a exploração e depois de obter uma interface de comando (shell) adequada na máquina, começou-se a pesquisar no sistema de arquivos do host procurando arquivos interessantes e terminamos na configuração do servidor da web Nostromo.







O arquivo de configuração revelou que o diretório home do usuário estaria publicado e accessível pelo servidor web, no entanto, apesar de termos encontrado um ".htpasswd" configurado, não havia um ".htaccess" adequado configurado.

Esse arquivo de configuração também revelou que todos os usuários poderiam ter um diretório "público" em sua pasta pessoal e que este séria acessível pelo através do servidor web, significando que o usuário do serviço httpd (www-data) deveria ter pelo menos acesso de leitura nesse diretório.
Nesse diretório público, encontramos um backup das chaves SSH do usuário David . Como a chave privada estava criptografada, usamos o sshng2john.py para converter esta chave em um formato que pudêssemos usar como input para o john  e depois realizar um ataque de dicionario contra essa chave utilizando a wordlist  "rockyou.txt". Esse ataque revelou que a senha dessa chave era hunter 


Essa chave SSH nos deu acesso à máquina como David. No diretório pessoal do usuário, havia uma pasta bin com um script bash chamado "servers-stats.sh". O conteúdo desse script revelou que seria possível executar o comando journalctl usando sudo. Depois de confirmar isso e perceber-se que não era solicitado a senha  do usuário (sudo nopasswd).



O journalctl pode ser explorado de tal maneira a permitir a execução arbritario de comandos, isso é possível por que tal executavvel chama ao fim de sua execuao o programa pager padrão, que normalmente é o "less". O comando less exibe a saída na tela do usuário e aguarda a entrada do usuário assim que o conteúdo for exibido. Isso pode ser explorado executando um comando shell.



/usr/bin/sudo /usr/bin/journalctl -n5 -unostromo.service


Após journalctl terminar sua execução ele chamara less o qual podemos executar !/bin/ bash e então obter uma interface de comandos







Recomendações



  • Mantenha seus softwares atualizados;
  • Não deixe seu backup em diretórios acessíveis por outros usuários;
  • Não use senha fraca na sua chave privada SSH;
  • Você pode adicionar o parâmetro  "--no-page" no journalctl para evitar chamar pager  no final de execução sua execução.


Detecção


  • Qualquer WAF deveria ser capaz de detectar payloads de ataques de path traversal.