Nota: Este artigo foi publicado pela primeira vez na edição de Julho de 2021 do boletim informativo mensal Network Security, e apareceaparece aqui com a permissão do editor.
Recuar 21 anos no tempo até à viragem do milénio seria uma experiência
estranha, tendo em conta o mundo em que vivemos hoje. Mesmo pondo de lado a pandemia de Covid-19
e os seus impactos ainda por revelar, a vida mudou imenso
nas últimas duas décadas.
No ano 2000, o Spotify, o Facebook, o Instagram e o Uber não existiam, enquanto o Netflix (lembram-se do aluguer de DVD e CD por assinatura?) e a Amazon eram uma novidade. A Internet ainda era uma novidade e o iPhone só surgiria daqui a sete anos. A lista poderia continuar, mas a questão é que o desenvolvimento tecnológico no mundo das TI acelerou exponencialmente nos últimos 20 anos.
Apesar desta evolução, uma inovação fundamental prevaleceu, em grande parte inalterada, durante todo este período.
Leitura relacionada
Ponto de dor
Na década de 1990, os directórios eram um grande problema administrativo de TI para as empresas. O mundo do trabalho era suportado por uma série de pequenos directórios que tornavam a partilha de dados e ficheiros importantes uma tarefa complicada e trabalhosa. Para aceder a ficheiros partilhados, os utilizadores tinham de iniciar sessão em cada sistema de ficheiros individual, com várias credenciais, software e aplicações necessárias.
Com a introdução do Windows NT em meados da década de 90, a Microsoft já tinha ajudado muitas empresas a adoptar o conceito de "domínio", permitindo a junção de vários sistemas num círculo de confiança, reduzindo efectivamente a segmentação das identidades dos utilizadores em directórios separados. No entanto, embora o Windows NT tenha permitido à Microsoft entrar com êxito nos centros de dados das empresas, as limitações de escalabilidade inerentes aos domínios do Windows NT implicavam a criação e gestão de vários directórios de domínios em diferentes regiões geográficas, com relações de confiança entre eles para partilhar o acesso dos vários utilizadores de uma empresa. Esta situação tornou-se cada vez mais difícil à medida que não só as empresas, mas também os seus sistemas de TI, se juntavam ao movimento da globalização.
O Microsoft Active Directory (AD) foi, na altura, uma tecnologia revolucionária, lançada originalmente com o sistema operativo de servidor Windows 2000 e que continua a suportar grande parte do mundo de trabalho hiperligado que habitamos na era moderna.
Foi, em muitos aspectos, inovador. As empresas globais podiam escalar os seus directórios, deixando de ter de depender de muitos domínios pequenos e difíceis de gerir. De facto, existiam outros directórios que lutavam para oferecer as mesmas vantagens às empresas. O Novell eDirectory, por exemplo, era amplamente utilizado. No entanto, o Microsoft AD prevaleceu sobre todos os outros por uma razão fundamental: era aberto.
Aberto ou seguro?
"Aberto", no caso dos serviços de directório, significa "legível por qualquer pessoa", o que ainda hoje é a predefinição em qualquer configuração do AD, pelo menos para o utilizador autenticado, ou seja, qualquer utilizador que tenha iniciado sessão num computador com a sua conta do AD. A Novell optou por um caminho mais seguro com o eDirectory, exigindo que os administradores concedam especificamente permissões de leitura a todas as secções necessárias para utilizadores e aplicações, acrescentando um obstáculo operacional à integração de novas aplicações.
Esta abertura - que era a maior força do Microsoft Active Directory há 21 anos - tornou-se, no entanto, a sua fraqueza mais preocupante.
Aquando do seu lançamento, foi muito aclamado devido à sua capacidade de se integrar facilmente com as aplicações e de fornecer um início de sessão único em todo o ambiente empresarial, reduzindo assim o incómodo da gestão de palavras-passe e da gestão de directórios com uma autenticação de grande alcance. É devido a esta abertura e facilidade de integração que o AD continua a ser uma peça fundamental da infra-estrutura de 90% das empresas. De facto, é utilizado em tão larga escala que a maioria das aplicações empresariais actuais nem sequer tem o seu próprio directório, dependendo antes da autenticação do utilizador no Windows.
No entanto, esta abertura também criou vulnerabilidades.
Delegação sem restrições
Veja-se, por exemplo, as funcionalidades específicas do Kerberos. O Kerberos é um protocolo de autenticação de redes informáticas que funciona com base numa estrutura de bilhetes para permitir que os nós que comunicam através de redes empresariais forneçam a sua identidade uns aos outros de forma segura. Era um protocolo altamente seguro para a sua época, o que o significado do seu nome enfatizava: Na mitologia grega, Kerberos é um cão de três cabeças que guarda os portões do Submundo para impedir a saída dos mortos.
Uma capacidade especial que o Kerberos oferecia era a de delegação, que funcionava para garantir que um utilizador que acedesse a uma aplicação num sistema só poderia aceder a informação especificamente partilhada (frequentemente um ficheiro ou dados específicos numa base de dados) com essa aplicação noutro sistema, impedindo o acesso a outros dados. Do ponto de vista técnico, isto era conseguido pelo facto de o utilizador ser representado pela aplicação enquanto esta acedia ao outro serviço em nome do utilizador. A aplicação - ou melhor, o servidor que aloja a aplicação - foi "delegada" para utilizar a autenticação Kerberos de outra pessoa - ou seja, foi-lhe concedido o direito de reencaminhar o bilhete Kerberos do utilizador para outro sistema como se o utilizador estivesse a aceder directamente a esse outro sistema. Com a introdução do AD em 2000, era possível configurar a delegação Kerberos apenas de uma forma "sem restrições", o que significa que a aplicação podia transmitir o bilhete Kerberos do utilizador para qualquer outro sistema.
Actualmente, isto tornou-se obsoleto devido a formas muito mais seguras e simples de partilhar dados. Mas as definições de delegação sem restrições ainda prevalecem num número significativo de sistemas, muitas vezes porque o potencial impacto não é compreendido pelos operadores do AD ou pelos proprietários do objecto de servidor específico escolhido para ser configurado desta forma. Os piratas informáticos actuais podem utilizá-las para se fazerem passar por qualquer utilizador do AD em qualquer outro computador. Combinando isto com o conhecimento de que um pirata informático pode utilizar qualquer conta AD sem privilégios para ler quase todos os atributos e objectos no AD, incluindo as respectivas permissões, permitindo-lhes encontrar contas de computador em qualquer domínio de uma floresta AD configurada com delegação sem restrições, fica-se com uma ideia da razão pela qual a abertura predefinida do AD se tornou uma vulnerabilidade.
Na pior das hipóteses, o intruso poderia obter acesso a esse sistema e, além disso, descobrir que os controladores de domínio ainda têm o serviço de impressão (spooler) em execução. Por defeito, o serviço de impressão está sempre ligado em qualquer servidor Windows -deve ser desactivado pelos administradores de TI em qualquer servidor que não precise dele, mas muitos não o fazem. No nosso cenário, um hacker pode então invocar um controlador de domínio para se autenticar no computador com a delegação sem restrições e utilizar o chamado bug da impressora para invocar um pedido de autenticação do controlador de domínio para o computador capturado. Embora não haja nada para imprimir, através deste processo um agente de ameaça pode proteger o bilhete Kerberos de um controlador de domínio e, assim, ter comprometido o seu domínio e floresta AD.
A delegação restrita é um pouco mais segura, mas continua a ser atacável.
Oportunidade para os agentes de ameaças
Há mais exemplos de como o cão de três cabeças perdeu alguma da sua força protectora ao longo do tempo. Foram descobertos e documentados publicamente cada vez mais vectores de ataque contra o AD, permitindo assim que os cibercriminosos os utilizassem durante o seu percurso de ataque contra o AD.
Outro bom exemplo são os nomes principais de serviço (SPN), que são a forma como um cliente Kerberos identifica exclusivamente uma instância de um serviço para um determinado computador de destino Kerberos (por exemplo, uma base de dados SQL) e também ajuda a localizar a conta de serviço relacionada (por exemplo, a conta de serviço SQL), que é utilizada pelo próprio serviço para autenticar no AD.
Este mecanismo permite que os utilizadores utilizem o Kerberos para autenticação numa base de dados SQL em vez de autenticarem com o protocolo NTLM menos seguro e tornou-se o padrão para integrar a autenticação AD para implementações SQL na maioria das empresas. A desvantagem é que os investigadores de segurança descobriram que os próprios SPNs são facilmente atacáveis através das informações que transmitem durante a autenticação Kerberos para o serviço - nomeadamente o hash da palavra-passe da própria conta de serviço - mesmo que o requerente não proceda à autenticação no serviço.
Esse hash está agora sujeito a tentativas de cracking offline, com as quais uma variedade de ferramentas disponíveis publicamente, como o John the Ripper, tem todo o gosto em ajudar.
Devido à abertura do AD, um intruso consegue facilmente encontrar SPNs privilegiados no ambiente (pense num SPN ligado a uma conta de administrador de domínio), criando outro vector de ataque fácil, capaz de ser manipulado para fornecer privilégios elevados e visibilidade total. Esta combinação de controlo e visibilidade pode ser incrivelmente perigosa. Quando se tem as permissões mais elevadas, tem-se controlo total e pode-se derrubar uma empresa e pedir um resgate.
Mas também é possível usá-lo para reconhecimento antes disso. "Quais são as contas privilegiadas? Quais são as vulnerabilidades que eu posso perseguir?" Para os agentes de ameaças, o Active Directory funciona como um mapa, destacando pontos de fraqueza no ambiente. Uma vez na sua rede, um hacker utilizará o AD para procurar e visar os seus dados importantes, extraí-los, encriptá-los e pedir-lhe um resgate. E muitas empresas simplesmente não estão preparadas para essa eventualidade. Isto cria um conflito. Dispõe de cópias de segurança adequadas para recuperar rapidamente toda a sua empresa, incluindo o Active Directory, sem pagar um resgate?
Para muitos, a resposta é não - são forçados a pagar o resgate e os piratas informáticos avançam para outro alvo igualmente desprevenido, criando um ciclo vicioso.
O exemplo da SolarWinds
Então, com que frequência é que o AD é utilizado desta forma pelos agentes de ameaças? A violação da SolarWinds, também conhecida como Solorigate, é um dos exemplos recentes mais infames, em que o AD foi fundamental para um ataque em grande escala à cadeia de abastecimento que afectou dezenas de milhares de organizações de alto nível, incluindo organismos governamentais dos EUA. A própria SolarWinds é um dos principais fornecedores mundiais de soluções de TI, sendo a sua ferramenta de gestão de redes Orion um dos principais softwares que estas organizações utilizaram para assegurar, manter e proteger as suas próprias redes. No ataque da SolarWinds, os piratas informáticos conseguiram injectar com êxito um cavalo de Tróia no software Orion, que depois se propagou através de um mecanismo de descarregamento periódico que os clientes da empresa tinham instalado. Tendo começado em Março de 2020, este ataque patrocinado pelo Estado e o seu trojan só foram descobertos em Dezembro desse ano.
Tratou-se de um ataque altamente malicioso que afectou inúmeras empresas da Fortune 500 e organismos governamentais de importância vital nos EUA. Mas como é que um ataque tão poderoso à cadeia de fornecimento pôde acontecer? É aqui que entram o AD e as fugas no local.
A SolarWinds tinha criado um serviço de federação entre os seus próprios serviços de directório no local e a nuvem, onde geria o seu código de software Orion. Neste tipo de configuração, a nuvem deposita total confiança no serviço de federação para provar correctamente a identidade de um utilizador, permitindo-lhe iniciar sessão com a sua identidade local, frequentemente associada a uma solução de autenticação multifactor (MFA) de terceiros.
Ao inscrever-se desta forma e ao receber um token de federação devidamente assinado, o seu fornecedor de serviços de computação em nuvem confia em si com a autenticação e, em seguida, autoriza os utilizadores autenticados, fornecendo-lhes acesso aos recursos de computação em nuvem solicitados.
No caso do ataque à SolarWinds, os intrusos conseguiram utilizar esta federação em seu benefício para aceder furtivamente ao código-fonte do Orion alojado na nuvem, roubando o certificado de assinatura do token. Foi o primeiro ataque deste género que se sabe ter utilizado uma linguagem de marcação de acesso seguro dourado (SAML). A federação ocorre através de protocolos como o SAML, utilizado para transmitir um token de segurança a essa parte de confiança. Mas como é que o intruso obteve este certificado de assinatura de token?
Voltamos ao ponto em que ocorreu a violação: o certificado de assinatura de token foi protegido pela conta de serviço para serviços de federação do AD, que é hospedada como qualquer outra conta no AD local. Assim que os agentes da ameaça obtiveram acesso ao AD local e à conta de serviço do ADFS, tinham uma forma de ler o certificado e utilizá-lo para criar o seu próprio token SAML para obter acesso aos recursos da nuvem da SolarWinds. Como resultado, a cadeia de eventos mostra que a segurança do Active Directory foi um dos principais pontos fracos no caminho de ataque dessa grande violação.
De facto, este é um excelente exemplo de uma empresa que acreditou que os seus sistemas de computação em nuvem eram seguros quando não o eram, devido ao AD e à sua dependência no local. Embora a nuvem estivesse separada, a confiança entre os sistemas locais vulneráveis e a nuvem fornecia acesso à rede, criando uma ponte que os agentes da ameaça podiam utilizar para invadir os recursos da nuvem da empresa.
Enfrentar os desafios
Do ponto de vista da segurança, o AD é a fonte de muitas dores de cabeça. A Microsoft não investiu numa actualização relacionada com a segurança do AD desde 2016, apesar de este sistema de identidade central ainda ser utilizado por 90% das empresas actualmente.
A solução mais fácil seria erradicar o AD, mas isso simplesmente não vai acontecer. É uma solução antiga, mas não vai desaparecer tão cedo com tantas empresas e centenas de milhares de aplicações de linha de negócio que ainda dependem desta tecnologia. Dito isto, não é uma causa perdida e há medidas que as empresas podem tomar para garantir a sua protecção.
Na verdade, trata-se de um processo - a implementação de protocolos de protecção adequados, começando pelo reconhecimento e compreensão de potenciais vulnerabilidades. Realize uma sessão de brainstorming e pergunte a si próprio: "O que aconteceria se os sistemas críticos fossem abaixo?"
As empresas podem resolver as interrupções de serviço operando com centros de dados duplos ou com uma solução híbrida de centro de dados e nuvem, mas devem ir mais longe e considerar o que pode acontecer se um sistema crítico como a gestão de identidades ficar comprometido. Dedique algum tempo a compreender as dependências de todas as suas aplicações empresariais. E explore as dependências entre o seu processo de autenticação e a nuvem. Com um sistema de autenticação baseado na federação, pode ficar em maus lençóis muito rapidamente.
Depois de compreender estas dependências, pode começar a identificar, compreender e dar prioridade às vulnerabilidades a abordar. Deve ser um processo holístico que não deixe nenhuma pedra por virar no caminho para alcançar a preparação total. Se um barco tiver uma fuga e não tiver o equipamento para a reparar, o barco afunda-se. Da mesma forma, se apenas se detectar um dos vários buracos que estão a verter, o barco afunda-se na mesma.
É fundamental que uma empresa compreenda de forma abrangente todas as vulnerabilidades potenciais para as resolver e preparar-se conforme necessário. O ataque da SolarWinds serve como uma importante curva de aprendizado, demonstrando os efeitos catastróficos que podem ocorrer quando um ataque baseado em AD é realizado. Dado o ambiente de ameaças crescente e cada vez mais complexo, nunca foi tão importante abordar as vulnerabilidades baseadas no AD como agora.
