Quem trocou a minha senha?

Pouco tempo depois de eu chegar a NY, surgiram problemas sérios no DNS. A ONU usava BIND, que dependia de arquivos texto para suas zonas. Qualquer erro de digitação quebrava tudo. O risco de erro humano era enorme; e aconteceu. Havia também o número de série das zonas, que, se não fosse incrementado, fazia os servidores ignorarem alterações. O DNS e o NTP vieram parar nas minhas mãos, junto com a responsabilidade de criar uma infraestrutura redundante para esses serviços. Fiz scripts para automatizar edições, atualizar números de série, replicar zonas e reiniciar serviços de modo seguro. O uso dos scripts reduziu a incidência de erro humano e melhorou a estabilidade do sistema.

Um dia, o diretor (chefe do meu chefe) me perguntou se eu entendia de Active Directory. Respondi que não, nunca tinha administrado um. Ele me olhou com o que parecia uma mistura de preocupação e pena e me disse que eu seria o responsável pelo sistema e pelo time. E assim eu ganhei o AD do secretariado da ONU: oito domínios divididos em duas florestas, quatro ou cinco datacenters, cinquenta mil usuários espalhados pelo mundo e conexões com outras organizações. Uma estrutura complexa, antiga e cheia de ramificações.

Logo no início descobri um problema grave: mais ou menos uma vez por semana a senha de um domain admin era trocada sem explicação. Ninguém sabia por quê. Tudo indicava a presença de um adversário com privilégios altíssimos dentro do AD. Quando eu virei chefe da área, me deram um usuário domain admin. Numa segunda-feira de manhã, descobri que a minha senha fora trocada durante um fim de semana. Eu tinha certeza de que não tinha esquecido a senha. Além disso, recebi uma ligação da tesouraria perguntando por que meu usuário estava tentando acessar a máquina deles. Eu sabia que não era eu. A conclusão era óbvia: tem boi na linha, ou melhor, hacker na rede.

Iniciamos uma investigação conjunta com meu administrador, o Steve. Levantamos logs, revisamos políticas e criamos monitoramento adicional. O primeiro passo foi isolar os controladores de domínio atrás de um firewall com regras extremamente restritas. Criamos uma rede nova e movemos os servidores para lá. Configurar firewall para Active Directory é um pesadelo: algumas poucas portas fixas e dezenas de portas dinâmicas que são usadas para MS-RPC. O firewall dizia entender MS-RPC, mas não entendia muito bem. Conseguimos ao menos limitar o range dessas portas, o que já ajudou.

A situação melhorou, mas ainda havia eventos estranhos. Chamamos a consultoria da Microsoft, que confirmou a gravidade do problema. Um dos truques usados pelo atacante envolvia substituir o executável acionado pelo botão de acessibilidade na tela de login do Windows Server 2012. Esse botão permitia ao usuário acessar ferramentas como a lupa ou a dicção do que estava na tela e podia ser usado antes da autenticação. Ao clicar, o sistema chamava um executável com privilégios altos. Se o atacante trocasse o nome do executável de acessibilidade por um command.com, ganhava uma linha de comando com permissão para fazer quase tudo no servidor. Removemos a configuração dos atacantes, desabilitamos a funcionalidade e limitamos quem poderia acessar os domain controllers remotamente.

A consultoria foi categórica: depois que um atacante alcança privilégios de domain admin, nunca se tem certeza total de que ele saiu. A recomendação oficial era reconstruir o AD do zero, criar um domínio só pros domain admins e usar smart cards para autenticação, mas não havia equipe para isso. Em vez disso, trocamos todos os servidores, atualizamos versões, endurecemos políticas no firewall e, dali em diante, os acessos estranhos cessaram. Nunca tivemos prova formal de quem era o atacante, nem de por quanto tempo tiveram acesso à rede.

Havia ainda outro problema que tinha raízes numa decisão tomada lá no início da infraestrutura: usar BIND como servidor de DNS, inclusive para a infraestrutura Windows. Embora ambos usem padrões compatíveis, integrar Active Directory e BIND não é uma tarefa simples. Durante um período, o Steve vinha tendo sérios problemas de replicação entre os controladores de domínio. Ele suspeitava de DNS, mas não entendia nem de DNS nem de BIND.

Outros especialistas internos tentaram ajudar, e às vezes conseguíamos estabilizar tudo, mas o problema sempre voltava. Consegui convencer meu chefe de que precisávamos chamar a Microsoft. O consultor enviado realmente entendia de DNS e AD. Ele passou alguns dias coletando informações, mapeando a infraestrutura e reconstruindo as ligações entre os servidores. No final, conseguimos restaurar a replicação, estabilizar o ambiente e reduzir drasticamente o risco de perda de dados.