Acesso LDAP anônimo dsHeuristics: como um único atributo fraco expõe todo o seu domínio

Acesso LDAP anônimo dsHeuristics no Active Directory explicado

Acesso LDAP anônimo dsHeuristics no Active Directory — se essa frase trouxe você até aqui, você já suspeita do que este artigo confirma: um único caractere em um único atributo reativa silenciosamente operações LDAP não autenticadas em toda uma floresta Active Directory, e quase nada no conjunto de ferramentas administrativas padrão avisa que isso aconteceu.

Os controladores de domínio Active Directory aceitam conexões LDAP não autenticadas por exatamente dois motivos restritos: negociar o próprio bind e consultar o rootDSE (os dados de capacidade e configuração do próprio servidor). A orientação da própria Microsoft é explícita quanto a esse limite: "operações LDAP (Lightweight Directory Access Protocol) anônimas contra o Active Directory, além de buscas e binds no rootDSE, não são permitidas" em controladores de domínio Windows Server 2003 e posteriores. Tudo além disso — pesquisar a própria árvore de diretório, ler objetos de usuário, grupo ou OU — exige um cliente autenticado.

Esse padrão é mais recente do que a maioria dos administradores imagina. Controladores de domínio baseados no Windows 2000 não suportam essa restrição de forma alguma: se presentes em uma floresta baseada no Windows Server 2003, eles simplesmente não aplicam o bloqueio de operações anônimas. Esse comportamento de bloqueio foi introduzido com o Windows Server 2003 e está vinculado ao nível funcional do controlador de domínio, não apenas à versão do sistema operacional. Todo controlador de domínio abaixo do nível funcional do Windows Server 2003 permite operações anônimas por padrão; todo controlador de domínio nesse nível ou acima dele as bloqueia por padrão.

O bloqueio é o padrão. dsHeuristics é o único atributo capaz de desativá-lo silenciosamente — em toda a floresta, para cada controlador de domínio, sem uma única caixa de seleção na interface gráfica para avisar alguém que isso aconteceu.

Como funciona — o atributo dsHeuristics

dsHeuristics é um atributo do tipo string Unicode armazenado no objeto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration sob o domínio raiz da floresta. Cada posição de caractere na string é uma heurística independente, e a ordem é fixa — caracteres só podem ser omitidos truncando a string a partir do final. Segundo a especificação de protocolo [MS-ADTS], por padrão o atributo simplesmente não existe, e o valor padrão de cada caractere que ele poderia conter é "0".

O sétimo caractere — fLDAPBlockAnonOps

O sétimo caractere é fLDAPBlockAnonOps: se estiver definido como "2", a heurística de bloqueio de operações anônimas é FALSE, ou seja, operações LDAP anônimas são permitidas. Qualquer outro valor — ou simplesmente a ausência do caractere — mantém o bloqueio em vigor em controladores de domínio no nível funcional do Windows Server 2003 ou superior.

dSHeuristics: 0000002
              ^      ^
              caracteres 1-6 nos valores padrão (0)
                     caractere 7 = 2 -> operações LDAP anônimas permitidas

O atributo não tem painel dedicado em Usuários e Computadores do Active Directory, nenhuma configuração de Política de Grupo e nenhum aviso em lugar algum das ferramentas administrativas padrão. As únicas formas de vê-lo são o ADSI Edit (adsiedit.msc) ou o ldp.exe, conectados ao contexto de nomenclatura de Configuração. Um ambiente pode passar em toda checklist que só olha configurações de GPO e ainda assim ter o acesso LDAP anônimo totalmente aberto, porque nada no conjunto de ferramentas padrão exibe esse valor a menos que alguém procure especificamente por ele.

O oitavo caractere — fAllowAnonNSPI

Uma heurística vizinha, frequentemente ignorada, fica uma posição adiante: a posição 8, fAllowAnonNSPI, controla se chamadores anônimos podem usar o método de bind RPC NSPI — o protocolo por trás do catálogo de endereços do Outlook/Exchange. É uma superfície de acesso anônimo separada, não diretamente relacionada ao LDAP, mas vale a pena verificar na mesma passada, já que vive no mesmo atributo e no mesmo ponto cego.

Não é o mesmo que RestrictAnonymous

Também vale separar isso de um controle que a maioria das checklists de hardening já cobre: o valor de registro RestrictAnonymous e a política de segurança "Acesso à rede: não permitir enumeração anônima de contas SAM e compartilhamentos". Esses controlam a enumeração anônima de SAM/RPC — um caminho de código totalmente diferente. Equipes que travaram o RestrictAnonymous e seguiram em frente costumam presumir que o LDAP está coberto pela mesma configuração. Não está; dsHeuristics é o controle que de fato rege o LDAP, e precisa ser verificado à parte — junto com as demais configurações de rede do controlador de domínio abordadas em Domain Controller LDAPS TLS Fraco, Print Spooler, Sincronização Horário Audit: Checklist de Higiene de Rede.

Se a sua organização já reforçou a assinatura LDAP, note que a assinatura e o dsHeuristics protegem contra coisas diferentes: a assinatura impede adulteração e relay em uma conexão já autenticada; o dsHeuristics decide se uma conexão precisa se autenticar. Corrigir um não faz nada pelo outro.

O que um atacante ganha com isso

Quando fLDAPBlockAnonOps está desativado, um cliente LDAP anônimo pode executar qualquer operação que a lista de controle de acesso (ACL) de um objeto permita ao principal "Anonymous Logon" / "Everyone" — sem exigir credenciais, nem mesmo uma conta convidada de baixo privilégio. Na prática, essas são as ACLs padrão da maioria dos domínios em usuários, grupos e unidades organizacionais, o que basta para percorrer toda a árvore: nomes de usuário, associações de grupo, estrutura de OUs e, com frequência, atributos descritivos como cargos ou campos de descrição em texto livre que acabam contendo mais do que deveriam.

Esse é exatamente o padrão que a orientação conjunta da CISA, da NSA e de parceiros internacionais sobre detecção e mitigação de comprometimentos do Active Directory destaca repetidamente: a enumeração de diretório não autenticada é uma etapa padrão de reconhecimento pré-comprometimento, porque entrega ao atacante a lista de usuários, as associações de grupo e a estrutura de OUs do domínio antes de qualquer tentativa de autenticação — e antes que qualquer alerta de logon malsucedido tenha motivo para disparar. Ferramentas públicas construídas especificamente para isso, como o Windapsearch, partem exatamente desse cenário: apontar para um controlador de domínio sem credenciais e ver o que um bind anônimo revela antes de gastar uma única senha adivinhada.

Confirmando a exposição com um teste direto de bind

A forma direta de confirmar a exposição é testar:

# Sem -D (bind DN) e sem -w (senha) => bind simples anônimo
ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" \
  "(objectClass=user)" sAMAccountName

Se isso retornar objetos de usuário em vez de um erro de operação ou de acesso insuficiente, o acesso LDAP anônimo está habilitado nesse controlador de domínio.

Detecção

Ler o atributo diretamente é a verificação mais confiável, pois não depende de o log de auditoria estar habilitado em nenhum lugar. O teste de bind é o segundo método mais confiável, porque reflete o que um cliente de fato experimenta, e não o que a configuração afirma. Os sinais de log de eventos são complementares, não primários: eles ajudam a confirmar que a exposição foi usada, não apenas que estava presente.

Se o log de auditoria dessas categorias ainda não estiver habilitado em seus controladores de domínio, essa é uma lacuna de pré-requisito que vale a pena fechar primeiro — veja Lacunas na Configuração da Política de Auditoria do Active Directory para as categorias que a maioria dos ambientes deixa desativadas antes de precisar dos logs.

Correção

Etapa 1 — Ler antes de escrever

Primeiro, anote a string dsHeuristics completa existente — modificá-la às cegas arrisca alterar uma heurística não relacionada da qual outra aplicação ou processo pode depender.

Etapa 2 — Corrigir o sétimo (e o oitavo) caractere

Defina o sétimo caractere como 0 (ou remova-o inteiramente se for o caractere final) para restaurar o bloqueio padrão de operações anônimas. A alteração é replicada para todos os controladores de domínio da floresta e entra em vigor sem reinicialização. Enquanto estiver lá, verifique também o oitavo caractere (fAllowAnonNSPI) e redefina-o, a menos que haja uma dependência legada documentada de Exchange/Outlook para o catálogo de endereços que realmente exija binds NSPI anônimos. Não presuma que o RestrictAnonymous já cobre algum dos dois — é um controle diferente para um caminho de protocolo diferente, então verifique o dsHeuristics de forma independente, mesmo em ambientes que se consideram endurecidos.

Etapa 3 — Testar novamente

Execute novamente o mesmo teste de bind anônimo via ldapsearch / ldp.exe usado na detecção. Ele agora deve retornar um erro de operação ou de acesso insuficiente, não objetos de diretório. Se o acesso LDAP anônimo for genuinamente necessário para uma aplicação legada específica, restrinja-o na camada de rede (uma regra de firewall para a origem específica) em vez de deixar o valor de dsHeuristics aberto para toda a floresta a qualquer cliente não autenticado.

Como a EtcSec detecta isso

A auditoria de Active Directory da EtcSec lê o atributo dsHeuristics diretamente do contexto de nomenclatura de Configuração e sinaliza duas verificações relacionadas: ANONYMOUS_LDAP_ACCESS, quando se confirma que operações LDAP anônimas estão acessíveis, e DS_HEURISTICS_LDAP_SECURITY, quando o próprio atributo está definido com um valor que enfraquece a segurança do LDAP — de modo que a configuração incorreta é capturada na origem, e não apenas depois que o tráfego de enumeração aparece nos logs. Para uma cobertura mais ampla das configurações que a maioria dos ambientes deveria verificar primeiro, veja Endurecimento Active Directory: o que bloquear primeiro e como validar e Quais são as configurações incorretas de segurança do Active Directory mais comuns?