Recentemente foi disponibilizado os autos de investigação da PF da invasão ocorrida no TSE em abril de 2018.

Sem entrar em um discurso politico, me prendendo somente a temática de segurança da informação, analisei os detalhes do incidente que são contados no relatório e resolvi trazer pontos de lições aprendidas.

DOWNLOAD do documento

Resumo do ataque (bem resumo mesmo)

O documento inicia falando sobre comprometimento de um web server do Rio Grande do Norte e movimentação para servidores de outras regionais. Foram feitos diversos scans de rede, depois é citado a máquina da regional TRE-AP foi acessada com um usuário que deveria estar desativado e com senha de fácil dedução. O documento segue dizendo que houve a utilização de uma webshell para comprometer uma das máquinas. Também é mostrado um acesso a uma máquina utilizando o Teamviwer. O documento segue citando que o webshell foi instalado em outras máquinas. Em seguida é citado que existia uma VPN destinada a uma empresa de manutenção de centrais telefônicas. na sequencia, é falado sobre tentativas de acesso a portas Oracle e também de scans de rede focados nas portas 80, 443, 8080, 8081, 8180, 21 e 3389. Depois é citado que foram identificados ataques a procura de fragilidades no PHP. Na sequencia é falado sobre acesso ao ILO, software da HP para gerenciamento de máquinas.

Mais para frente o documento fala sobre obtenção de senhas que não eram triviais e de uma suspeita de obtenção da base do AD com posterior quebra das senhas. O atacante cita que obteve acesso por vários meses na infra do TSE e que ele percebeu nas trocas de e-mail que cortaram o acesso a VPN, porém ele manteve o acesso. Foi identificado um servidor que fazia a compilação do código fonte das urnas utilizando jenkins sem senha.

Lições

Diante do resumo que fiz acima, alguns pontos que podemos destacar como lições que podemos tomar na ótica de segurança:

Usuário legado – Importante sempre estar fazendo sanitizações em usuários locais e na base do AD. Se possível evitar a utilização de usuário local, já que é algo difícil de gerenciar. Aconselho utilizar em ambiente Windows o LAPS da Microsoft para gestão de usuários administradores locais e de suas credenciais. Além disso para o AD pode-se fazer buscas periódicas em atributos como de “lastlogon”, estipular um prazo que se adeque ao se negocio, mas uma sugestão seria algo em torno de 7 meses, já que podem ter mulheres grávidas que se afastam pelo período de 6 meses e emendam férias. Passado esse timming, pode-se criar algum tipo de script ou processo manual para bloqueio do usuário e movimentação para uma quarentena. Caso você tenha um poder ferramental ou investimentos, uma ferramenta de gestão de identidades conseguiria lidar bem com esse processo.

Senha de Fácil dedução – Senha seja ela fácil ou difícil, por si só é um conceito que não dá mas para ser usado como único fator. É importante que se utilize o conceito de duplo fator de autenticação. Uma recomendação é que minimamente sistemas externos tenham 100% implementado 2FA para autenticação. Contas de serviço/robôs e afins que não podem digitar um 2FA, podem entrar numa regra condicional com IP de origem bem amarrado para que somente essas exceções possam interagir externamente sem 2FA. Obviamente o ideal é ter 2FA em tudo, mas partindo de estratégias por etapas, acredito que essa parte de fechar bem os acessos e sistemas externos já seja uma boa estratégia.

Scan de rede – Este ponto é um que vejo uma dificuldade maior nas empresas em geral para mitigar. Minha sugestão que uma das coisas que pode jogar ao seu favor é o seu endpoint, isso mesmo seu antivírus. Existem muitas soluções de antivírus que possuem a feature de detectar e barrar scans de rede e que funcionam perfeitamente. Outro ponto, na verdade até mais adequado, é o próprio firewall com módulos de segurança corretamente configurados. Uma ferramenta de IPS/IDS também ajuda nesse assunto. Scans de rede devem ser permitidos somente de servidores com essa função, como por exemplo o pessoal de gestão de vulnerabilidades.

Webshell – Importante aqui alguns processos. Um deles é a realização constante de pentest que assegurem que não sejam possíveis de serem feitos upload de arquivos maliciosos. Outra camada importante de proteção é o próprio endpoint que deve ter a capacidade de detectar a inserção desse tipo de arquivo. WAF seria uma camada adicional que pode ajudar também nessa temática.

Teamviwer – Aqui a minha sugestão é: quais ferramentas de acesso remoto você permite em sua empresa? Depois de definido quais, em que redes você o permite? A utilização de ferramentas como essa se não forem bem implantadas trazem grande risco. Sugiro regras fortes de firewall bloqueando todas essas ferramentas e liberar somente em redes especificas, garantindo além disso que somente usuários com alto privilegio possa ter a capacidade de instalação em servidores e em estações também.

Software de gerenciamento de servidores – Tome cuidado com softwares como Ilo e IDRAC principalmente. O IDRAC é algo manjado em testes de invasão, onde a maioria dos atacantes vão tentar de cara a famosa senha padrão root-calvin. Se possível faça single sign on nessas plataformas e garanta um login corporativo com 2FA ou então minimamente certifique-se que nenhuma senha de fácil dedução ou padrão está sendo utilizada.

Base do AD – Neste ponto não foi claro que realmente houve obtenção da base do AD, até acho que podem ter sido utilizado outras técnicas como obtenção de senha em memória, já que quebra de senha exigiria tempo e se a sena fosse realmente muito boa como foi citado, exigiria bastante tempo. Existe também a possibilidade de obtenção da senha em texto claro nas famosas anotações, arquivos txt ou as famosas planilhas com diversas senhas anotadas. Se prendendo a temática de replicação da base do AD, aqui um ponto é que para tal ação é necessário ter um usuário Domain Admin. Um chefe meu me falou uma vez uma frase que eu tomo como um mantra: Domain Admin você tem que conseguir contar na palma de uma mão, se passar disso tem algo errado. Enterprise e Schema Admin então não deveria ter ninguém inserido nunca. Para isso siga muito estritamente o conceito de menor privilégio possível. Só se eleve quando necessário. Outra lição é , servidores de AD, devem ser estritamente protegidos, com acessos muito restrito e dificultados, de preferência com regras de acesso a nível de firewall bem restrita. Outra sugestão é, faça ao menos 1 vez ao ano ataques de força bruta contra a sua base! Eu já fiz um post sobre isso por aqui.

Outros pontos – Foi citado por exemplo uso de um jenkins aberto, importante que que o processo de gestão de vulnerabilidades seja efetivo e que sempre busque essas falhas, as que vejo mais comuns são FTP com acesso anônimo, telnet, RDP com guest habilitado, mongodb sem senha, ELK sem senha.

Também foi falado sobre uma VPN que foi utilizada, a qual era destinada a uma empresa terceira. Minha sugestão, quanto mais flores para cuidar mais complexo fica seu jardim! Menos as vezes é mais, no meu ponto de vista uma arquitetura bacana é uma VPN única para tudo com as devidas regras para cada publico que nela se conecta, assim você tem uma coisa só pra cuidar. Você vai ter regras específicas de acessos para funcionários, outras para administradores e outras para terceiros e demais.

Segregação de rede é muito importante, inclusive na temática de ransomware que tem crescido em larga escala, nesse tipo de ataque, segregação de rede é uma das grandes camadas de proteção. No caso do TSE uma segregação de rede mais adequada teria evitado ou pelo menos dificultado a movimentação lateral.

Outro ponto é resposta de incidentes efetiva. Foi citado que foi feito a derrubada da VPN mas que o acesso foi mantido pois não era por ali que o hacker estava entrando. Para isso é necessário como primeiro passo se investir em um time sólido e com conhecimento, além disso ter o ferramental adequado e logs além de um bom SIEM para uma boa analise e uma resposta rápida. Pessoas, processos e ferramentas, isso vale para tudo!

O conceito de jump server também merece ser citado. Pelo documento parece que houve muita movimentação lateral com acesso RDP direto de um lugar ao outro. Importante ter uma arquitetura com conceito de jump server, onde usuários só podem acessar a rede de servidores a partir de servidores específicos. Tendo investimento, ferramentas de gerenciamento de acessos são grandes aliados (EX: Cyberark ou senha segura).

Por último mas não menos importante: Tenha bons processos de gestão de vulnerabilidades e pentest implementados!

E por fim…

Meu intuito no post não é apontar defeitos na rede do TSE ou de sua equipe, mas sim a partir da analise do ocorrido o que podemos tirar de melhorias que outras empresas que tenham problemas parecidos possam refletir. Diversos pontos fiz explicações mais rápidas, mas é bom eu explicar que foi um resumo de ações, existem diversas outras estratégias que demandaria um texto muito longo.