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.




quinta-feira, 8 de agosto de 2019

Artigo originalmente postado em 2015 em outro blog que foi descontinuado. Repostando apenas por razões históricas. Algumas informações certamente estão desatualizadas. 

Com o objetivo de dificultar análise dinâmica e depuração, diversos malwares utilizam técnicas para tentar evitar sua execução em sandbox. Essas técnicas são comumente chamadas de sandbox evasion.
As técnicas de evasão de sandbox podem ser classificadas de acordo com as seguintes categorias:
  • Interação humana. Esta categoria engloba técnicas que esperam ações específicas a serem realizadas pelo usuário. Essas ações podem ser qualquer coisa que sirva como teste de Turing. Por exemplo: movimentação e/ou clique do mouse, rolagem de página.
  • Configuração. nesta categoria estão os códigos que se aproveitam das limitações inerentes às sandboxes, como por exemplo, o tempo de execução. Um cenário contundente compreende fazer o código dormir por um tempo suficientemente longo para inviabilizar a sua execução em uma sandbox.
  • Ambiente. Nesta categoria, estão as técnicas que buscam por indícios de ambientes virtuais amplamente utilizados, como VirtualBox e VMWare. Esses indícios podem ser drivers de hardware específicos de VMs, chaves no registro, arquivos, dll, processos e etc.
No projeto open souce pafish, tem alguns bons exemplos da implementação de técnicas simples anti debugger/VM/sandbox. No trecho de código abaixo, extraído desse projeto, podemos observar uma técnica que tenta identificar o ambiente virtual a partir da existência de determinada sub-chave no registro.


Essa é uma técnica simples — e talvez por isso — seja bastante observada em alguns malwares. Assim como nesse exemplo, normalmente o que se observa durante as análises, é o acesso direto a sub-chave desejada utilizando a função RegOpenKeyEx da API do Windows®.
O monitoramento dessas chamadas à API do sistema é um ponto essencial no processo de análise dinâmica de malwares e normalmente é feito em sistemas de análise automatizadas, através de hooks. No Cuckoo Sandbox esse hook é feito através da injeção da DLL cuckoomon, que por sua vez, é responsável por interceptar e registrar as chamadas à API do sistema. Qualquer sistema de análise automática que se preze, deve realizar esse monitoramento e tentar detectar padrões de técnicas já conhecidas.
Certo dia me deparo com um malware que utilizava uma variação dessa técnica. Ele procurava por entradas no registro relacionadas com softwares de virtualização (VirtualBox e VMWare), entretanto ele utilizava a função RegOpenKeyEx apenas para abrir a chave "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall", que contém a lista dos softwares disponíveis para desinstalação. E a partir dessa lista, utilizava a função RegEnumKeyEx para procurar por indícios de virtualização, como a existência de qualquer sub-chave com a palavra "virtualbox".
Através desta abordagem, esse artefato poderia detectar se estava sendo executado em uma máquina virtual e ainda passar despercebido a olhos desatentos. Como já dito anteriormente o mais comum para essa técnica é o acesso direto às sub-chaves que denunciem a instalação da máquina virtual, utilizando a função RegOpenKeyEx.
Para fins didáticos implementei essa técnica no pafish, o código fonte pode ser observado aqui.
Ainda como fruto dessa análise foi possível produzir um patch para o cuckoomon, com o objetivo de evitar detecção a partir desta técnica.

--- cuckoomon-orig/hook_reg.c 2014-06-11 20:17:15.000000000 -0300
+++ cuckoomon/hook_reg.c 2015-02-02 15:40:52.000000000 -0300
@@ -160,8 +160,25 @@
     __inout_opt  LPDWORD lpcClass,
     __out_opt    PFILETIME lpftLastWriteTime
 ) {
-    LONG ret = Old_RegEnumKeyExA(hKey, dwIndex, lpName, lpcName, lpReserved,
+    LONG ret;
+    char *blacklist[] = {"VirtualBox","vbox", "virtualbox","VBOX","oracle","VMware",NULL};
+
+    ret = Old_RegEnumKeyExA(hKey, dwIndex, lpName, lpcName, lpReserved,
         lpClass, lpcClass, lpftLastWriteTime);
+    
+    if (ret != ERROR_SUCCESS) {
+        return ret;
+    }
+   
+    for (int i=0; blacklist[i] ; i++){
+        
+        if (strstr(lpName, blacklist[i]) != NULL) {
+            ret = Old_RegEnumKeyExA(hKey, ++dwIndex, lpName, lpcName, lpReserved,lpClass, lpcClass, lpftLastWriteTime); 
+        }
+
+    }
+
     LOQ("plss", "Handle", hKey, "Index", dwIndex, "Name", lpName,
         "Class", lpClass);
     return ret;

Dentre os argumentos passados para a função RegEnumKeyExA vamos olhar com atenção os seguintes:
  • hKey - handle para a chave do registro aberta.
  • dwIndex - O índice da sub-chave que será recuperada.
  • lpName - Um ponteiro para um buffer que recebe o nome da sub-chave recuperada.
Esse patch consiste numa blacklist com alguns nomes que podem denunciar a existência de um ambiente virtual. Desta forma, para cada chamada à função RegEnumKeyExA é realizada uma checagem a fim de verificar se a sub-chave que está recuperada (lpName) está na nossa lista. Em caso positivo, a função RegEnumKeyExA original é chamada novamente, desta vez passando o índice subsequente (++dwIndex). Ou seja, as chamadas à função RegEnumKeyExA irão "pular" as sub-chaves que contiverem strings que também estejam na nossa blacklist.
Aplicar patches para "hardenizar" o cuckoomon, e consequentemente evitar a detecção de ambientes virtuais, é uma prática quase que diária para quem usa essa ferramenta como parte do processo de análise dinâmica, já que novas técnica de detecção de ambiente virtual — e variações das já existentes — surgem quase que diariamente. Ou seja, isso foi apenas mais do mesmo, a corrida entre a detecção e o anonimato.