Anatomia de um ataque parte 3

Na segunda parte desta série de posts, foi descrito o processo de obtenção de acesso ao servidor sob privilégios mínimos. Para relembrar, basta clicar aqui e ler o post novamente.

Neste post, descrevemos como se deu a elevação de privilégios, novos problemas de segurança encontrados, e como foi possível saltar para servidores adjacentes.

Durante a investigação do servidor comprometido, foram encontrados alguns arquivos contendo senhas, backups compactados com permissão de leitura global, arquivos de log e depuração contendo informações que poderiam subsidiar novos ataques, então foi possível traçar vários vetores para a elevação de privilégios, entre elas citarei apenas quatro:

  • Existia uma rotina de backup em disco realizada diariamente, que armazenava o conteúdo do – entre outros – /etc em um arquivo TAR.GZ. Este arquivo estava configurado com um esquema de permissões inseguro, ou seja, era possível descompactá-lo e tomar posse do arquivo “passwd” e “shadow”, que por ventura poderia conduzir à quebra da senha dos usuários do sistema.
  • Identificar vulnerabilidades em softwares ou no kernel presente no servidor, analisando também a possibilidade de explorá-las.
  • Localizar arquivos de configuração de serviços, procurar por padrões inseguros e verificar a possibilidade de explorá-los.
  • Procurar por rotinas automatizadas e verificar a possibilidade de manipulação.

A Elevação de Privilégios

Neste caso, durante a investigação foi encontrado um log criado por uma rotina automatizada que era executada toda madrugada, o arquivo responsável pelo log possuía uma combinação de permissões insegura, ou seja, qualquer usuário poderia ler e escrever neste script, e o mesmo estava localizado em um diretório montado remotamente através da solução NFS.

Este fator possibilitou a alteração do script que era executado pelo usuário root do servidor do zabbix, garantindo a elevação de privilégios com um arquivo binário suid especialmente criado com a linguagem C.

Uma vez que obtemos o acesso root no servidor, é chegada a hora de tentar saltar para servidores adjacentes.

Viabilizando o Salto

Como foi citado anteriormente, o script pivô da elevação de privilégios estava localizado em um diretório montado remotamente através da solução NFS, isto chamou nossa atenção, pois o NFS não solicita credencial e para controlar o acesso, parte-se da premissa de que o ponto servidor e o ponto cliente são confiáveis, deste modo, o servidor realiza o controle de acesso através do ID numérico do usuário na estação cliente. Veja bem, da estação cliente.

Com isso em mente, o processo de busca teve como objetivo identificar scripts de rotina que eram executados em outros servidores, para viabilizar a navegação mesmo em diretórios e ler arquivos nas quais não nos pertencia, exploramos o comportamento de controle de acesso do NFS ao nosso favor: trocando nosso ID de usuário com um software especialmente criado para esta tarefa, escrito em linguagem C.

Uma vez que identificamos um script de rotina automatizada que poderia ser objeto de nossos testes, injetamos comandos para verificar onde o mesmo era executado e assim nos deparamos com outro problema: Os servidores onde o script era executado estavam protegidos pelo firewall, de modo que a partir da rede onde eu estava, não era possível acessá-los diretamente.

Resolvendo o Problema

Executando testes através do script de rotina em questão, identificamos que as regras eram restritivas apenas em um sentido, ou seja, os servidores onde o script era executado tinham acesso ao servidor onde eu tinha acesso e também à nossa estação de trabalho (nosso notebook).

Maravilha, para contornar então esta situação, mais uma vez a linguagem C nos salvou, criamos um programa que funciona como um BOT, onde seu comportamento é rodar em background no servidor e procurar por instruções a serem executadas, retornando o resultado para o gerente do bot.

Executando o Salto

Como eu não estaria no local no momento que o script de rotina era executado, utilizamos o servidor que havíamos comprometido como pivô para este ataque, ou seja, ele se tornaria o gerente do bot.

Com o bot sendo executado nos servidores alvo do ataque, os mesmos passaram a buscar no gerente, pelos comandos a serem executados como proposto, os mesmos se encontravam hospedados no webserver em um arquivo texto, com este processo, disparamos várias shell reversas para nosso notebook, obtendo acesso assim aos demais servidores já como privilégio administrativo.

Abaixo um diagrama demonstra o processo:

anatomyofanattack2

Comunicação 1 e 2: Alteramos o script que será rodado nos servidores membros da botnet, para que o bot seja executado. Também enviamos para o Gerente da BotNet, os primeiros comandos a serem executados.
Comunicação 3 e 4: O script é lido e então executado pelos servidores-alvo, o Bot é então executado e os mesmos passam a integrar a BotNet. Logo em seguida, os servidores escravos buscam a lista de instruções a serem executadas.
Comunicação 5 e 6: As instruções são executadas e então o retorno de cada instrução é remetida ao Gerente que a armazena, para posteriormente ser analisada.

Na próxima parte desta série de posts, a finalização do processo de intrusão.  Nesta parte, sumarizamos os problemas encontrados, e mapeamos a progressão da intrusão.

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