Acceso LDAP anónimo dsHeuristics enumeración Active Directory: cómo un único atributo débil expone todo su dominio

Acceso LDAP anónimo dsHeuristics enumeración Active Directory explicada

Acceso LDAP anónimo dsHeuristics enumeración Active Directory — si esta frase le trajo hasta aquí, ya sospecha lo que este artículo confirma: un solo carácter en un solo atributo reactiva silenciosamente las operaciones LDAP no autenticadas en todo un bosque de Active Directory, y casi nada en el conjunto de herramientas de administración estándar le avisará de que ha ocurrido.

Los controladores de dominio de Active Directory aceptan conexiones LDAP no autenticadas solo con dos propósitos muy concretos: negociar la propia unión (bind) y consultar rootDSE (los datos de capacidad y configuración propios del servidor). Las indicaciones de Microsoft son explícitas sobre este límite: «las operaciones LDAP (Lightweight Directory Access Protocol) anónimas hacia Active Directory, distintas de las búsquedas y uniones a rootDSE, no están permitidas» en controladores de dominio Windows Server 2003 y posteriores. Cualquier cosa más allá de eso — buscar en el propio árbol del directorio, leer objetos de usuario, grupo u OU — requiere un cliente autenticado.

Ese comportamiento predeterminado es más reciente de lo que la mayoría de los administradores asume. Los controladores de dominio basados en Windows 2000 no admiten en absoluto esta restricción: si están presentes en un bosque basado en Windows Server 2003, sencillamente no aplican el bloqueo de operaciones anónimas. Este bloqueo se introdujo con Windows Server 2003 y está vinculado al nivel funcional del controlador de dominio, no solo a la versión del sistema operativo. Todo controlador de dominio por debajo del nivel funcional de Windows Server 2003 permite las operaciones anónimas de forma predeterminada; todo controlador de dominio en ese nivel o superior las bloquea de forma predeterminada.

El bloqueo es el valor predeterminado. dsHeuristics es el único atributo capaz de desactivarlo silenciosamente — para todo el bosque, en cada controlador de dominio, sin una sola casilla en una interfaz gráfica que avise a nadie de que ha ocurrido.

Cómo funciona: el atributo dsHeuristics

dsHeuristics es un atributo de tipo cadena Unicode almacenado en el objeto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration bajo el dominio raíz del bosque. Cada posición de carácter en la cadena es una heurística independiente, y el orden es fijo — los caracteres solo pueden omitirse truncando la cadena desde el final. Según la especificación del protocolo [MS-ADTS], por defecto el atributo no existe en absoluto, y el valor predeterminado de cada carácter que podría contener es "0".

El séptimo carácter — fLDAPBlockAnonOps

El séptimo carácter es fLDAPBlockAnonOps: si se establece en "2", la heurística de bloqueo de operaciones anónimas es FALSE, lo que significa que las operaciones LDAP anónimas están permitidas. Cualquier otro valor — o que el carácter sencillamente no esté presente — mantiene el bloqueo activo en los controladores de dominio con nivel funcional Windows Server 2003 o superior.

dSHeuristics: 0000002
              ^      ^
              caracteres 1-6 en su valor predeterminado (0)
                     carácter 7 = 2 -> operaciones LDAP anónimas permitidas

El atributo no tiene panel dedicado en Usuarios y equipos de Active Directory, ni configuración de Directiva de grupo, ni ningún aviso en ninguna parte de las herramientas de administración predeterminadas. Las únicas formas de verlo son ADSI Edit (adsiedit.msc) o ldp.exe, conectados al contexto de nomenclatura de Configuración. Un entorno puede pasar cada elemento de una checklist que solo revisa configuraciones de GPO y aun así tener el acceso LDAP anónimo completamente abierto, porque nada en el conjunto de herramientas estándar expone este valor a menos que alguien lo busque específicamente.

El octavo carácter — fAllowAnonNSPI

Una heurística vecina, frecuentemente pasada por alto, se encuentra un carácter más allá: la posición 8, fAllowAnonNSPI, controla si los llamantes anónimos pueden usar el método de unión RPC NSPI — el protocolo detrás de la libreta de direcciones de Outlook/Exchange. Es una superficie de acceso anónimo separada, no relacionada directamente con LDAP, pero merece revisarse en la misma pasada ya que vive en el mismo atributo y en el mismo punto ciego.

No es lo mismo que RestrictAnonymous

También conviene distinguir esto de un control que la mayoría de las checklists de hardening ya cubren: el valor de registro RestrictAnonymous y la directiva de seguridad «Acceso de red: no permitir la enumeración anónima de cuentas y recursos compartidos SAM». Estos gobiernan la enumeración anónima SAM/RPC — una ruta de código completamente distinta. Los equipos que bloquearon RestrictAnonymous y siguieron adelante suelen asumir que LDAP queda cubierto por la misma configuración. No es así; dsHeuristics es el control que realmente rige LDAP, y debe verificarse por separado — junto con las demás configuraciones de red del controlador de dominio tratadas en Auditoría TLS Débil LDAPS, Spooler Impresión, Sincronización Horaria del Controlador de Dominio: Checklist de Higiene de Red.

Si su organización ya bloqueó la firma LDAP, tenga en cuenta que la firma y dsHeuristics protegen frente a cosas distintas: la firma impide la manipulación y el relay en una conexión ya autenticada; dsHeuristics decide si una conexión necesita autenticarse en absoluto. Corregir una no hace nada por la otra.

Qué obtiene un atacante con esto

Cuando fLDAPBlockAnonOps está desactivado, un cliente LDAP anónimo puede realizar cualquier operación que la lista de control de acceso (ACL) de un objeto permita para el principal «Anonymous Logon» / «Everyone» — sin necesidad de credenciales, ni siquiera una cuenta de invitado con privilegios bajos. En la práctica, esto corresponde a las ACL de objeto predeterminadas de la mayoría de los dominios sobre usuarios, grupos y unidades organizativas, lo cual basta para recorrer todo el árbol: nombres de usuario, pertenencias a grupos, estructura de OU, y a menudo atributos descriptivos como puestos de trabajo o campos de descripción de texto libre que terminan conteniendo más de lo que deberían.

Ese es exactamente el perfil que la guía conjunta de CISA, la NSA y socios internacionales sobre detección y mitigación de compromisos de Active Directory señala repetidamente: la enumeración de directorio no autenticada es un paso estándar de reconocimiento previo al compromiso, porque entrega al atacante la lista de usuarios del dominio, las pertenencias a grupos y el diseño de las OU antes de un solo intento de autenticación — y antes de que una sola alerta de inicio de sesión fallido tenga motivo alguno para dispararse. Herramientas públicas creadas específicamente para esto, como Windapsearch, asumen exactamente este escenario: apuntar a un controlador de dominio sin credenciales y ver qué revela una unión anónima antes de gastar una sola contraseña adivinada. Es un vector de exposición no autenticada entre varios en Active Directory — vea también Transferencia de Zona DNS Active Directory Actualización Dinámica Insegura: Detección y Remediación para una ruta de exposición comparable en el lado DNS.

Confirmar la exposición con una prueba de unión directa

La forma directa de confirmar la exposición es probarlo:

# Sin -D (bind DN) ni -w (contraseña) => unión simple anónima
ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" \
  "(objectClass=user)" sAMAccountName

Si esto devuelve objetos de usuario en lugar de una respuesta de error de operación / derechos de acceso insuficientes, el acceso LDAP anónimo está habilitado en ese controlador de dominio.

Detección

Leer el atributo directamente es la comprobación más fiable, ya que no depende de que el registro de auditoría esté habilitado en ningún sitio. La prueba de unión es la segunda más fiable, porque refleja lo que un cliente realmente experimenta en lugar de lo que la configuración afirma. Las señales del registro de eventos son complementarias, no primarias: ayudan a confirmar que la exposición fue utilizada, no solo que está presente.

Si el registro de auditoría de estas categorías aún no está habilitado en sus controladores de dominio, esa es una brecha previa que conviene cerrar primero — vea Brechas de configuración de la política de auditoría de Active Directory para las categorías que la mayoría de los entornos dejan desactivadas antes de necesitar los registros.

Remediación

Paso 1 — Leer antes de escribir

Anote primero la cadena dsHeuristics completa existente — modificarla a ciegas arriesga alterar una heurística no relacionada de la que puede depender otra aplicación o proceso.

Paso 2 — Corregir el séptimo (y octavo) carácter

Establezca el séptimo carácter en 0 (o elimínelo por completo si es el carácter final) para restaurar el bloqueo predeterminado de operaciones anónimas. El cambio se replica en todos los controladores de dominio del bosque y surte efecto sin reinicio. Ya que está ahí, revise el octavo carácter (fAllowAnonNSPI) y restablézcalo salvo que exista una dependencia documentada de una libreta de direcciones heredada de Exchange/Outlook que realmente necesite uniones NSPI anónimas. No dé por hecho que RestrictAnonymous ya cubre alguno de los dos — es un control distinto para una ruta de protocolo distinta, así que verifique dsHeuristics de forma independiente incluso en entornos que se consideran ya reforzados.

Paso 3 — Volver a probar

Vuelva a ejecutar la misma prueba de unión anónima con ldapsearch / ldp.exe usada para la detección. Ahora debería devolver un error de operación o una respuesta de derechos de acceso insuficientes, no objetos del directorio. Si el acceso LDAP anónimo es genuinamente necesario para una aplicación heredada específica, acótelo a nivel de red (una regla de firewall hacia el origen específico) en lugar de dejar el valor de dsHeuristics abierto, para todo el bosque, a cualquier cliente no autenticado.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec lee el atributo dsHeuristics directamente desde el contexto de nomenclatura de Configuración y señala dos comprobaciones relacionadas: ANONYMOUS_LDAP_ACCESS cuando se confirma que las operaciones LDAP anónimas son accesibles, y DS_HEURISTICS_LDAP_SECURITY cuando el propio atributo está establecido en un valor que debilita la seguridad LDAP — de modo que la mala configuración se detecta en el origen y no solo después de que el tráfico de enumeración aparezca en los registros. Para una cobertura más amplia de las configuraciones que la mayoría de los entornos deberían revisar primero, vea Endurecimiento Active Directory: qué bloquear primero y cómo validarlo y ¿Cuáles son las configuraciones incorrectas de seguridad de Active Directory más comunes?