CVE-2022-26923: Conozca su vulnerabilidad AD

El 10 de mayo de 2022, se reveló y parcheó una vulnerabilidad en Active Directory (AD) y Active Directory Certificate Services (AD CS). Esta vulnerabilidad de AD puede conducir a una escalada de privilegios. En las instalaciones predeterminadas de AD CS, un usuario con pocos privilegios puede explotar la vulnerabilidad solicitando un certificado de autenticación y utilizándolo después para hacerse pasar por otra cuenta de equipo, lo que da lugar a una toma de control total del dominio. ¿De qué trata esta vulnerabilidad de AD? Siga leyendo para obtener una guía completa sobre CVE-2022-26923.

¿Qué conduce a esta vulnerabilidad de AD?

AD fue lanzado por primera vez en 1999 por Microsoft como un sistema centralizado de gestión de identidades consistente en un conjunto de procesos y servicios. AD contiene varios protocolos que pueden utilizarse para la autenticación y autorización de identidades en una empresa. Por lo general, AD se utiliza para gestionar fácilmente usuarios, grupos y ordenadores dentro de una empresa. Desde entonces, AD se ha convertido en el sistema de gestión de identidades más popular, utilizado para gestionar las identidades en la gran mayoría de las empresas.

En Windows Server 2008, Microsoft introdujo AD CS, que ofrecía la posibilidad de crear y gestionar fácilmente certificados de infraestructura de clave pública (PKI). Estos certificados pueden utilizarse para la firma digital, la protección de protocolos y la autenticación.

Cuando se utilizan certificados de AD CS para la autenticación dentro de un entorno AD (PKINIT), se abren muchas vías de ataque nuevas, que incluyen tanto configuraciones erróneas como vulnerabilidades. En junio de 2021, Will Schroeder y Lee Christensen publicaron un whitepaper en el que detallaban varios errores de configuración que podrían dar lugar a una escalada de privilegios. Algunas de estas configuraciones erróneas estaban predeterminadas en AD CS en el momento de la instalación y pueden dar lugar a una toma de control total del dominio. Estas configuraciones erróneas son independientes de la vulnerabilidad descrita en este artículo.

Lecturas relacionadas

• Seguridad de Active Directory: Principales riesgos y mejores prácticas

Escalada de privilegios con la vulnerabilidad AD CVE-2022-26923

CVE-2022-26923 es una vulnerabilidad de escalada de privilegios descubierta por Oliver Lyak. La explotación se basa en dos acciones principales:

1. Cambio del dNSHostName para que coincida con el de otra cuenta de equipo.
2. Solicitar un certificado para la cuenta del ordenador, utilizando una plantilla configurada con el SubjectAltRequireDns

El indicador SubjectAltRequireDns para plantillas de certificado significa que los certificados solicitados utilizando esta plantilla tienen un certificado Asunto que coincida con el atributo dNSHostName de la cuenta AD solicitante.

Ambas acciones son posibles en una instalación por defecto de AD y AD CS.

Al solicitar un certificado utilizando una cuenta de equipo que tiene el mismo dNSHostName que otra cuenta de equipo, los atacantes pueden autenticarse como la cuenta de equipo objetivo y escalar privilegios. Esta vulnerabilidad puede utilizarse para atacar cualquier equipo activo dentro de AD.

Cambio de la cuenta de máquina dNSHostName

En una instalación AD por defecto, cualquier Usuario Autenticado puede añadir cuentas de máquina. Esta acción se rige por la siguiente configuración:

• En Añadir estaciones de trabajo al dominio en la directiva del controlador de dominio, que define a quién se conceden privilegios para agregar cuentas de equipo al dominio (establecido en Usuarios autenticados de forma predeterminada; Figura 1).

• La dirección ms-DS-MachineAccountQuota en la cabecera del contexto de nomenclatura (NC), que define el número de cuentas de equipo que los usuarios con pocos privilegios pueden añadir (establecido en 10 por defecto; Figura 2)

Con esta configuración predeterminada, cualquier cuenta con pocos privilegios puede crear fácilmente hasta 10 cuentas de equipo en el dominio utilizando el cmdlet New-MachineAccount de Powermadpara añadir una cuenta de equipo denominada LowPrivComputer(Figura 3).

La lista de control de acceso discrecional (Dacl) para esta nueva cuenta de equipo muestra que la cuenta del creador tiene el permiso de escritura validada en el nombre de host DNS(Figura 4).

Por lo tanto, el atributo dNSHostName puede ser modificado por la misma cuenta que lo creó, simplemente utilizando el cmdlet Set-DomainObject de PowerView(Figura 5).

Plantilla de certificado con el indicador SubjectAltRequireDns

En una instalación predeterminada de AD CS, varias plantillas de certificado tienen el indicador SubjectAltRequireDns activado. Por ejemplo, la plantilla Máquina se utiliza por defecto para inscribir cuentas de ordenador para la autenticación de certificados. El cmdlet Get-DomainCertificateTemplate de PowerView se utiliza para ver el atributo msPKI-Certificate-Name-Flag de la plantilla Machine(Figura 6).

Utilizando la cuenta de máquina creada anteriormente, es posible solicitar un certificado utilizando esta plantilla para la cuenta LowPrivComputer con el dnshostname modificado(somethingelse.f105-d01.lab). Para ello, se utiliza la herramienta Certipy de Python(Figura 7).

Abusos de la vulnerabilidad AD CVE-2022-26923

Como ya se ha mencionado, este método puede utilizarse para escalar privilegios dentro de un dominio AD. Una ruta de ataque común es apuntar a un controlador de dominio (DC). Tras crear la cuenta de equipo(LowPrivComputer), los atacantes cambian primero el atributo dNSHostName de la cuenta por el mismo que el del DC(F105-D02-DC01.f105-d01.lab), como se muestra en la Figura 8.

Para esta ruta de ataque, es necesario borrar el contenido del servicePrincipalName (SPN). Cuando se actualiza el atributo dNSHostName, cualquier entrada SPN también se actualiza para coincidir con el nuevo nombre. Esto entra en conflicto con las entradas SPN para la cuenta genuina(F105-D01-DC01), y el cambio falla.

Tras el cambio de dNSHostName, se puede solicitar un certificado para este nuevo nombre(Figura 9).

Una vez recuperado el certificado, es necesario volver a cambiar el dNSHostName(Figura 10) para que cuando se utilice el certificado y el DC busque el nombre del cliente, sólo haya una coincidencia (la cuenta de DC auténtica).

Ahora, es posible autenticarse como la cuenta del ordenador DC. Rubeus proporciona un modificador /getcredentials para el comando asktgt que utiliza una solicitud de usuario a usuario (U2U). Cuando se proporciona un certificado para la autenticación, se puede recuperar el hash NT de las cuentas solicitantes gracias a los datos de credenciales NTLM_SUPPLEMENTAL_CREDENTIAL PAC PAC_INFO_BUFFER(Figura 11).

Este hash NT se puede utilizar para autenticarse posteriormente como el DC (utilizando pass-the-hash o overpass-the-hash) o se pueden falsificar Silver Tickets.

Variaciones de la trayectoria de ataque

Aparte de la ruta de ataque mostrada en los ejemplos anteriores, se pueden utilizar varias variaciones ligeras para explotar esta vulnerabilidad de AD.

En primer lugar, un atacante con cierto control sobre un objeto informático existente no necesita la capacidad de crear una cuenta informática. La figura 12 muestra que la cuenta de usuario con privilegios bajos tiene la capacidad GenericWrite sobre el objeto informático DatabaseServer.

Con este privilegio, un atacante puede borrar los SPN y cambiar el atributo dNSHostName para que coincida con el de la cuenta de otro equipo(Figura 13).

Dos cosas merecen destacarse aquí:

• El objetivo es un sistema que no es un DC. Esta vulnerabilidad se puede utilizar para atacar cualquier sistema unido a un dominio, no solo los DC.
• Esta parte del ataque puede realizarse en DCs totalmente actualizados. Cuando la cuenta que realiza el cambio tiene permisos específicos GenericAll o GenericWrite, el dNSHostName puede modificarse para que coincida con el de otra cuenta de equipo. (Esto no es posible cuando el permiso Validated write to DNS host name se concede al creador de una cuenta de equipo).

Con dNSHostName modificado, se puede solicitar un certificado utilizando el nombre de host DNS de destino(Figura 14).

Con el dNSHostName cambiado de nuevo, como en la ruta de ataque anterior, el atacante puede ahora utilizar el certificado adquirido para autenticarse como la cuenta del equipo objetivo.

Otra diferencia entre la ruta de ataque anterior y ésta: El atacante no necesita utilizar el certificado para autenticarse en Kerberos y solicitar un ticket granting ticket (TGT) para la cuenta objetivo. El atacante puede utilizar el certificado para autenticarse directamente en algunos servicios. El siguiente ejemplo utiliza el certificado para conectarse directamente a LDAP y configurar la delegación restringida basada en recursos (RBCD) en el objeto informático de destino(Figura 15).

Tenga en cuenta que la configuración de RBCD es sólo un ejemplo de lo que un atacante puede hacer utilizando el certificado para autenticarse directamente contra los servicios. WinRM, RDP e IIS admiten la autenticación de clientes mediante certificados, por lo que existen muchas más posibilidades. Otras acciones, como la configuración de credenciales en la sombra, pueden realizarse a través de LDAP, dependiendo del entorno y los permisos de la cuenta de equipo comprometida.

Para finalizar la ruta de ataque, el atacante puede utilizar la extensión Kerberos de Servicio-para-Usuario (S4U) para obtener un ticket de servicio al sistema objetivo como usuario administrativo (siempre que el usuario administrativo no haya sido protegido contra delegación), como se muestra en la Figura 16 y Figura 17.

El atacante puede utilizar el ticket de servicio resultante para acceder al servicio en el sistema de destino como usuario suplantado. Una buena demostración es utilizar WinRM/PowerShell Remoting para obtener el valor de "whoami", que requiere un ticket de servicio para el servicio HTTP en el sistema objetivo(Figura 18).

ServicePrincipalNames

Para ambas rutas de ataque demostradas, era necesario borrar los SPNs antes de cambiar el dNSHostName. Esto podría parecer un requisito difícil de la explotación de la vulnerabilidad, pero no lo es. Usando el protocolo MS-SAMR para crear una cuenta de ordenador usando el método SamrCreateUser2InDomain, un atacante puede crear una cuenta de ordenador sin ningún SPN, simplemente usando el script de ejemplo addcomputer.py de impacketpara crear una cuenta de ordenador llamada NoSPNComputer (Figura 19).

La cuenta de equipo resultante no tiene SPNs y no requiere que se borren (ver Figura 20).

Factores atenuantes

Restringir la capacidad de los usuarios con pocos privilegios para crear cuentas de máquina, ya sea estableciendo el atributo ms-DS-MachineAccountQuota en el cabezal NC en 0 o cambiando el derecho Añadir estaciones de trabajo al usuario de dominio en la política del controlador de dominio a un grupo específico en lugar de Usuarios autenticados, reduce las rutas de ataque viables para esta vulnerabilidad. Otras acciones para reducir el potencial de explotación:

• Cambia las plantillas de certificado de "Nombre DNS" a "Nombre de usuario principal (UPN)"(Figura 21).

• Configure las plantillas de certificado para que requieran la aprobación del administrador para la inscripción(Figura 22).

DSP detección de esta vulnerabilidad AD

Como este exploit consta de sólo dos acciones obligatorias, Semperis Directory Services Protector (DSP) tiene dos oportunidades para detectarlo:

• Cuando se produce el cambio de dNSHostName
• Cuando se solicita el certificado

DSP ya recoge los datos de cambio de AD, por lo que la opción obvia es detectar un intento de explotar esta vulnerabilidad fue cuando se cambia el dNSHostName. El indicador DSP hace esto primero monitorizando un cambio en el atributo dNSHostName de una cuenta de equipo.

Cuando se detecta un cambio de este tipo, DSP realiza una consulta LDAP para cualquier cuenta de equipo con ese valor dNSHostName, excluyendo el nombre distinguido (DN) del objeto de la cuenta que activó la consulta LDAP. DSP marca cada resultado como un indicador de compromiso (IoC). Este indicador debería detectar cualquier intento de explotar esta vulnerabilidad, independientemente de si el ataque completo tuvo éxito. Como se muestra en la Figura 23, el IoC devuelve información que incluye:

• La cuenta que realizó el cambio
• Los DN de las dos cuentas informáticas implicadas
• El dNSHostName original de la cuenta cuyo atributo ha sido modificado
• El atributo dNSHostName de la cuenta objetivo

Otras detecciones de CVE-2022-26923

También se pueden utilizar varios eventos relevantes de Windows para ayudar a identificar intentos de explotar esta vulnerabilidad.

Borrar SPN

Cuando una ruta de ataque requiere la eliminación de los SPN de la cuenta de equipo utilizada en el ataque, se crea un evento 5136 para cada uno de los SPN configurados con el tipo de operación Valor eliminado(Figura 24).

Cambio de dNSHostName

Cuando se cambia el atributo dNSHostName, se crea un evento 4742(Figura 25).

La sección de Atributos Cambiados de este evento muestra el nuevo valor de Nombre de Host DNS(Figura 26).

Junto con el evento 4742, se crean dos eventos 5136. El primero muestra el valor original de dNSHostName y es del tipo de operación Value Deleted(Figura 27).

La segunda muestra el nuevo valor de dNSHostName y es del tipo de operación Valor Añadido(Figura 28).

Creación de ordenadores sin SPN

Como se mencionó anteriormente, los atacantes pueden crear cuentas de equipo sin ningún SPN inicial utilizando MS-SAMR. Cuando lo hacen, se crea un evento 4741(Figura 29).

En la sección Attributes de este evento, los Service Principal Names están vacíos, como se muestra en la Figura 30.

Solicitar certificado

Cuando se solicita un certificado, se crea un evento 4887 en la autoridad de certificación (CA). Este evento muestra el nombre de la cuenta solicitante(Requester). El valor del atributo dNSHostName se muestra como Asunto(Figura 31).

Corrección de vulnerabilidades de AD

Se publicó un parche para esta vulnerabilidad como parte de las actualizaciones de seguridad de mayo de 2022. Este parche introdujo algunos cambios:

• Las cuentas con el permiso Validated write to DNS host name ya no pueden cambiar el atributo dNSHostName para que coincida con el de otra cuenta en los DC parcheados. Los intentos de hacerlo provocan una violación de la restricción(Figura 32).

Nota: Como se mencionó anteriormente, incluso después de este parche, los atacantes pueden cambiar el atributo dNSHostName de una cuenta de equipo para que coincida con el de otra cuenta de equipo, incluso aunque esa acción requiera ahora permisos superiores como GenericAll/GenericWrite.

• Los certificados solicitados a las CA parcheadas contienen el nuevo OID szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1)(Figura 33).

Este campo contiene una cadena ASCII (en hexadecimal) del SID de la cuenta que solicitó el certificado. Cuando un certificado utilizado para aprovecharse de esta vulnerabilidad se utiliza para autenticarse contra un DC parcheado, se devuelve un error CERTIFICATE_MISMATCH(Figura 34).

Nota: Si este certificado se utiliza para autenticarse contra un DC no parcheado, la autenticación será exitosa y la vulnerabilidad explotable(Figura 35). Por lo tanto, es muy importante actualizar todos los DCs y CAs están actualizados con el parche correspondiente.

Más información

Para obtener más información sobre esta vulnerabilidad de AD y cómo proteger su organización, consulte las siguientes referencias y recursos.

Recursos

Más información sobre Semperis Directory Services Protector ( DSP)

Más información Purple Knight Herramienta de evaluación de la seguridad de Active Directory

Referencias

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
• https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
• https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html
• https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html