Se tem acompanhado este blogue, sabe que, há cerca de dois anos e meio, comecei a falar sobre o papel precário da Política de Grupo na postura de segurança de uma empresa típica. Muitas, se não a maioria, das lojas de AD utilizam a GP para efectuar o reforço da segurança nos seus computadores de secretária e servidores Windows. Isto inclui tudo, desde ajustar as definições do SO para desactivar o NTLMv1 ou mexer no Controlo de Contas de Utilizador (UAC), até controlar quem pode iniciar sessão em que máquinas e que grupos do AD têm acesso privilegiado em que ambientes de trabalho e servidores. Tudo isto é armazenado em GPOs que, por predefinição, são "legíveis em todo o mundo" por qualquer utilizador autenticado. Este facto já é verdade há muito tempo - desde 2000, quando o AD e o GP foram lançados - mas só se tornou mais visível como um potencial problema de InfoSec nos últimos anos, em grande parte devido a ferramentas como o Bloodhound, o PowerView e o Grouper, que revelam o facto de estas informações poderem ser utilizadas para realizar todo o tipo de maldades.
Desde então, concentrei-me sobretudo no lado defensivo da equação e, principalmente, nas recomendações para reduzir a legibilidade dos GPOs relacionados com a segurança para impedir que um atacante descubra facilmente a postura de segurança de uma organização. No entanto, mais recentemente, passei algum tempo a pensar em oportunidades para uma utilização mais destrutiva dos GPOs - aproveitando as definições existentes nos GPOs editáveis para executar várias tarefas maléficas num ambiente. Uma vez que os GPO têm frequentemente impacto na maioria, se não em todos, os utilizadores e computadores de uma organização, é um mecanismo de distribuição de malware muito eficiente, como ilustrei numa publicação do blogue há algum tempo. Estes tipos de ataques, que injectam definições maliciosas num GPO, dependem da capacidade do atacante para obter permissão de escrita num GPO, nomeadamente na parte SYSVOL do GPO onde a maioria (mas não todas) das Extensões do Lado do Cliente (CSE) do GP armazenam as suas definições. Naturalmente, também é necessário compreender o formato das definições da área de política que se pretende afectar para a poder sequestrar e, por uma vez, a forma como a Microsoft abordou o desenvolvimento de CSEs é uma vantagem neste caso, uma vez que praticamente todas as áreas de política utilizam um esquema e uma estrutura de dados diferentes para armazenar as suas definições. Um ponto para a inconsistência arquitectónica!
Três maneiras de causar problemas
Enquanto pensava no GP e nas suas fragilidades, cheguei à conclusão de que existem (pelo menos) três vias principais para um atacante utilizar o GP para os seus objectivos nefastos. Nomeadamente,
- Aproveitar o acesso de leitura excessivamente permissivo nos GPOs para aprender sobre a postura de segurança de uma organização - quem tem acesso privilegiado, onde, etc. Como mencionei, escrevi no blog ue sobre este assunto extensivamente e forneci sugestões sobre como o mitigar.
- Aproveitar o acesso de escrita demasiado permissivo nos GPOs para injectar definições maliciosas nos GPOs existentes. Falo sobre isto abaixo na secção intitulada "Delegação de GPO". O New-GPOImmediateTaskcmdletdo PowerView é um exemplo perfeito da utilização desta abordagem para injectar uma tarefa agendada num GPO para executar código arbitrário.
- Aproveitar caminhos externos que são referenciados em GPOs e têm acesso de gravação excessivamente permissivo. Esta é uma variação do número 2 e eu realmente percebi o poder dessa ideia enquanto testava e colaborava com @mikeloss em seu excelente utilitário Grouper2 mencionado acima. O Grouper2 procura coisas "interessantes" nos GPOs, que podem incluir tudo, desde políticas de Grupos Restritos que concedem acesso privilegiado a Senhas de GPP persistentes até, mais interessante para mim, referências a executáveis externos, scripts ou instaladores. Passo mais tempo a falar sobre estes caminhos externos abaixo na secção intitulada "Caminhos externos", mas @mikeloss merece realmente o crédito por me ter despertado para esta questão.
Delegação do GPO
Vamos falar mais sobre o ponto 2 acima. A forma como a delegação de GPO funciona é conceder a utilizadores, computadores ou grupos, vários níveis de acesso a um GPO, normalmente no GPMC a partir do separador "Delegação" num determinado GPO, ou utilizando o PowerShell, e essas permissões (que incluem Ler, LerAplicar, "Editar Definições" e "Editar Definições, Eliminar e Modificar Segurança") são imprimidas no objecto correspondente do Contentor de Política de Grupo (GPC) baseado no AD e na pasta com o nome GUID no Modelo de Política de Grupo (GPT) (ou seja, SYSVOL). Obviamente, as permissões do AD não mapeiam 1-1 para as permissões do sistema de ficheiros NTFS, mas se olhar para ambas as partes de um GPO no ACL Editor, verá permissões muito semelhantes (ver abaixo).
Portanto, como invasor, é necessário obter acesso de gravação ao GPT de um determinado GPO (ou, em alguns casos, ao GPC) para comprometer esse GPO. Obviamente, isso não é impossível, especialmente se o invasor conseguir se elevar a uma função de administrador que possa ter permissões de edição em um GPO. Mas, na perspectiva de um defensor, sublinha a importância de ter um controlo apertado sobre as delegações de GPO. As permissões de edição ou criação de GPO devem ser delegadas a um pequeno número de administradores de sistema, e esses responsáveis pela segurança devem ser tratados como administradores de "Nível 0", dado o potencial impacto em todo o ambiente que uma alteração maliciosa de GPO pode ter. Mais preocupante ainda, se um atacante conseguir acesso de escrita, por exemplo, ao GPT, pode ser muito difícil detectar estas alterações maliciosas se o atacante estiver a modificar os ficheiros de definições directamente, em vez de passar por ferramentas de gestão de alterações de GPO estabelecidas, como o GP Editor. Essencialmente, tem de procurar alterações no sistema de ficheiros no GPT para conseguir detectar a maioria destas alterações indesejadas, mas dado que as alterações legítimas do GPO geram notificações de alteração do GPT, também tem de conseguir filtrar as alterações maliciosas e válidas do GPO para encontrar as que lhe podem causar dores de cabeça. A boa notícia é que, se um atacante tiver de adicionar novas definições de área de política líquidas (ou seja, tem de chamar um CSE diferente de um que já tenha sido implementado) a um GPO, as suas hipóteses de ser detectado aumentam. Isto porque, para que um cliente (servidor ou estação de trabalho) processe uma nova definição de área de política de GPO, têm de ocorrer várias alterações no GPC (por exemplo, versionNumber incrementado e CSE ExtensionGUIDs adicionados correctamente ao GPC) para que o cliente tenha conhecimento dessas definições, o que torna mais difícil para um administrador com uma quantidade decente de auditoria de GP em vigor não se aperceber da adulteração. Quanto às áreas de política que são mais propícias a este tipo de manipulação, veja o excelente post de @_wald0 "A Red Teamer's Guide to GPOs and OUs" para alguns exemplos de caminhos de política que podem ser manipulados com bons resultados. Este ponto também defende a manutenção de GPOs que implementam áreas de política altamente "exploráveis", extra bloqueadas. Resumindo: bloqueie quem pode editar esses GPOs!
Caminhos externos
Isto leva-me ao meu último fascínio (#3 acima), que é a utilização de referências de "caminho externo" nos GPOs para contornar a limitação imposta pelos administradores no #2 acima. O que quero dizer com caminhos externos? Bem, na verdade, qualquer referência encontrada num GPO, que aponte para um executável, script, pacote MSI ou outro ficheiro que "faça algo" quando chamado, que exista fora das localizações normais de GPC e GPT (Sysvol). Por que eles são interessantes? Porque, mesmo que esteja a bloquear o acesso de escrita aos GPOs, tal como sugeri no ponto 2, poderá ter scripts, executáveis e pacotes MSI espalhados pelos servidores de ficheiros em toda a sua rede, com diferentes graus de controlo de acesso, que estão a ser chamados e executados pelos mesmos GPOs bloqueados que pensava serem tão seguros. Assim, um atacante que não consiga obter acesso de escrita a um GPO, pode usar o seu acesso de leitura (como o #1 acima) para procurar esses caminhos externos referenciados e tentar substituir esses scripts, exes e MSIs pelas suas próprias versões maliciosas (esta tarefa é de facto o que o Grouper2 torna muito mais fácil). Da próxima vez que o GPO for processado por um cliente, esse ficheiro malicioso é executado pelo GPO, que não tem conhecimento disso. Exemplos de áreas de política que normalmente podem fazer referência a caminhos externos (ou seja, caminhos fora do GPC e GPT) incluem:
- Scripts de arranque/desligamento e de início/fim de sessão
- Instalação do software GP (ficheiros MSI)
- Preferências do GP Tarefas programadas
- Preferências do GP Impressoras (com Impressoras TCP/IP, pode especificar um caminho externo para o cliente descarregar controladores de impressora - óptimo!)
- Atalhos das Preferências do GP, para atalhos que existem em locais de execução automática como o Arranque
- Ficheiros de Preferências do GP, onde existem ficheiros que podem ser copiados de localizações externas arbitrárias para a execução automática ou outras localizações de ficheiros locais "facilmente executáveis".
Para ser honesto, há provavelmente mais locais deste tipo escondidos no GP (e eu continuo a procurar...). Os que estão acima são os mais óbvios.
Então, porque é que tem de se preocupar com estes caminhos externos? Bem, pense nisso: o problema de impedir a adulteração indesejada de GPOs, conforme descrito no item 2 acima, é limitado. Só tem de se preocupar com a delegação nesses GPOs para manter o controlo desse tipo de comportamento. Mas, quando tem GPOs que referenciam código executável em partilhas de ficheiros externas, tem agora de alargar o seu âmbito de preocupação a CADA UMA DESSAS LOCALIZAÇÕES DE FICHEIROS! Quantos de vocês podem ter a certeza da gestão de permissões em partilhas de ficheiros aleatórias no vosso ambiente (quanto mais nos vossos GPOs)? Assim, se um GPO estiver a chamar um ficheiro executável ou um instalador que exista numa partilha insegura, os seus GPOs tornam-se veículos de distribuição inadvertidos para qualquer porcaria aleatória com que um atacante possa substituir esses executáveis. E, claro, uma vez que não há verificação de CRC ou outra verificação de validade efectuada no GP, está à mercê de quaisquer ficheiros que lá existam (uma atenuação a isto é o facto de nem todas as áreas de política executarem automaticamente os seus payloads a toda a hora. Por exemplo, se uma máquina já tiver recebido uma implementação de software através da política de Instalação de Software, não voltará a implementar esse MSI malicioso em circunstâncias normais. Mas qualquer máquina nova receberá o pacote malicioso, é claro).
Então, qual é a conclusão para este caso? Para além de proteger as delegações de GPO, primeiro, descubra onde estão as referências de caminho externo no seu ambiente e, em seguida, PROTEJA OS SEUS CAMINHOS EXTERNOS!!!!
Resumo
Espero que isto forneça algum alimento adicional para a reflexão sobre a protecção do seu ambiente GP e, portanto, de todo o seu ambiente Windows. Se hoje em dia depende do GP para configurar os seus sistemas Windows, não posso deixar de salientar a importância, do ponto de vista da InfoSec, de garantir que esses GPOs estão protegidos e que tudo o que é externo é tratado como "dentro do mesmo domínio de interesse" e igualmente protegido. Portanto, para resumir os itens de acção aqui:
- Bloqueie o acesso de leitura a GPOs críticos e relacionados com a segurança para garantir que não revela a sua postura de segurança
- Bloquear o acesso de escrita a todos os GPOs para garantir que não são cooptados como um vector de ataque
- Bloquear o acesso de escrita a todos os caminhos externos referenciados por GPOs
Darren
