Baseline: Uma lição importante

Caminhando junto com a evolução dos sistemas operacionais e tecnologias, as técnicas de exploração de vulnerabilidades que envolvem corrupção de memória alimentam o velho jogo de gato e rato da área de segurança da informação. Na medida em que novos mecanismos de proteção surgem, tais como pilha de memória não executável, aleatoriedade da pilha de memória, mapeamento de bibliotecas sob endereços que contém bytes nulos (ASCII ARMOR), novas metodologias de exploração são propostas, trazendo dor de cabeça para os administradores e para o time de segurança de uma organização.

Uma excelente referência sobre o assunto, contendo um timeline das técnicas de proteção e exploração pode ser encontrada no paper “Memory Errors:The Past, the Present, and the Future”, acessível clicando aqui: link para o pdf

Em meio a um teste de intrusão, identificamos uma vulnerabilidade de buffer overflow em um software desenvolvido por uma empresa terceira ao nosso cliente. O servidor era de produção e o sistema operacional era um Red Hat atualizado, o que sugeriu a necessidade da utilização de mecanismos avançados para obtermos sucesso nesta exploração, o que poderia levar algum tempo.

Dois fatores contribuíram para acelerar o processo de exploração desta vulnerabilidade:

– GDB (Gnu Debugger) instalado no servidor.
– Código fonte da aplicação (em C) disponível e com acesso de leitura para qualquer usuário no sistema operacional.

Após ler o código fonte desse software, entendemos como ele funciona e o tamanho do problema é então dimensionado.

Do ponto de vista de um atacante, o GDB oferece recursos de depuração para binários em tempo de execução, com ele é possível acompanhar como se comportam as instruções de processador e a memória do programa para então refinar a exploração, ou seja, facilita a manipulação do fluxo de execução. Outro recurso interessante do GDB que contribuiu para acelerar o processo de exploração desta vulnerabilidade foi a possibilidade de desabilitar o ASLR (randomização de áreas de memória) através do comando “set disable-randomization on” que vem habilitado por padrão (ler sobre ADDR_NO_RANDOMIZE).

Uma vez que o ASLR é desabilitado, podemos utilizar endereços fixos de memória em nosso código de exploração, facilitando o trabalho que poderá utilizar uma técnica mais simples.

O foco deste post não é explicar como a exploração ocorreu, mas mostrar a importância de se realizar uma revisão dos softwares necessários em um servidor, eliminando qualquer recurso desnecessário. Uma boa ideia é criar um Baseline para cada perfil de servidor baseado nos serviços que serão executados sobre ele e efetuar testes e auditorias periódicas nos sistemas em conformidade.

Postado por: Douglas dos Santos

Consultor de segurança da informação.

Leave a Reply