Anatomia de um ataque parte 2

Na primeira parte desta série descrevemos a estrutura envolvida, o software vulnerável, o vetor do ataque e o problema encontrado.  Para relembrar, basta clicar aqui e ler a primeira parte desta série de posts.

 

Obtendo Credenciais

Para a exploração da possível vulnerabilidade de SQL Injection, seria necessário obter uma credencial válida na aplicação, como o webserver não estava com SSL habilitado, um novo vetor poderia ser possível: Man-in-the-Middle, onde o atacante se posiciona logicamente entre o computador do alvo e o servidor (poderia ser o servidor do zabbix, neste caso foi o gateway da rede em questão) passando a capturar toda a comunicação entre as pontas, filtrando o conteúdo para encontrar credenciais. Foi necessário investir algum tempo na identificação de estações de trabalho do departamento de TI, para então disparar um ataque direcionado. O resultado foi a obtenção de uma credencial válida nesta aplicação.

Ataque

Depois de testar a aplicação com as instruções maliciosas, foi constatado que a vulnerabilidade estava sem correção, portanto o vetor de ataque estava determinado e aparentemente o trabalho seria simples, um SQL Injection me daria acesso à base de dados da aplicação que monitora ativos da rede e por si só este fato seria recompensador, atingindo assim a primeira meta.

O que melhorou a perspectiva do ataque foi o fato de que o usuário do banco de dados utilizado era também o usuário administrador do SGDB, ou seja, o usuário root do – neste caso – MySQL Server, que rodava no mesmo servidor da aplicação.

Esta combinação é interessante da perspectiva do atacante e possibilitou a amplificação do ataque, por que temos acesso às funcionalidades FILE do MySQL, que permitem interação com o sistema de arquivos (ler, escrever e criar arquivos) com o privilégio do usuário em que o SGDB está rodando.

Uma vez que temos acesso administrativo ao SGDB, o objetivo passou a ser obter a execução de comandos no servidor, para isso identificamos um diretório onde qualquer usuário poderia escrever e estava mapeado pelo webserver, provavelmente usuários da aplicação faziam uploads de imagens ou outros itens, portanto havia necessidade de escrita em um dos diretórios. O que fizemos, foi então criar um arquivo com a linguagem PHP especificamente para viabilizar a execução de comandos no servidor, ainda com privilégios mínimos, o mesmo do webserver neste caso id=33 (www-data), ou seja, conseguimos dois tipos de acesso diferentes: execução de comandos com privilégios do usuário www-data, leitura e escrita de arquivos no filesystem com privilégios do usuário MySQL.

Na terceira parte deste artigo, descreveremos como foi obtida a elevação de privilégios e o salto para outros servidores, revelando novos problemas encontrados.

Navegue entre as partes deste artigo através dos links abaixo:

Parte 1 | Parte 2 Parte 3 | Parte 4

Postado por: Douglas dos Santos

Consultor de segurança da informação.

Leave a Reply