Amenazas de delegación: profundización en el parche de Microsoft de la vulnerabilidad KCD CVE-2020-17049
13th diciembre, 2020 Dor Segal
*****Por Dor Segal, investigador de seguridad de Silverfort*****
El 11 de noviembre de 2020, Microsoft reveló CVE-2020-17049, un nuevo Kerberos Vulnerabilidad de omisión de característica de seguridad. Si bien la vulnerabilidad en sí no se solucionará antes del 8 de febrero de 2021, Microsoft publicó parches el 8 de noviembre y el 8 de diciembre para mitigar su explotación mientras tanto. Se reveló muy poco sobre el funcionamiento interno de la vulnerabilidad, sin una prueba de concepto pública ni un análisis técnico.
Esta publicación intenta llenar parte de este vacío arrojando luz sobre la delegación de Kerberos en general y profundizando en el parche que Microsoft ha emitido para la vulnerabilidad KCD CVE-2020-17049.
Tabla de contenido
Delegación Kerberos 101
La delegación de Kerberos es uno de los conceptos más complicados de Kerberos. autenticación proceso. Esta extensión sobre el protocolo estándar fue creada originalmente para brindar servicios, y la cuentas de servicio que utilizan, acceden a los recursos sin concederles ningún tipo de permiso.
Desde su introducción inicial, la delegación ha pasado por un par de cambios importantes hasta convertirse en la delegación restringida basada en recursos que utilizamos hoy (también conocida como KCD). Entonces, antes de abordar la vulnerabilidad en sí, revisemos los diferentes tipos de delegación y sus respectivos pros y contras.
Etapa 1: delegación sin restricciones
La delegación sin restricciones se introdujo en Windows Server 2000 y fue la primera en permitir que los servicios se hicieran pasar por un usuario con permisos de acceso. Como su nombre indica, este tipo de delegación le da a un servicio el poder de utilizar las credenciales del usuario para acceder a cualquier recurso en cualquier momento.
El proceso requiere que el usuario solicite un TGT reenviable y lo adjunte al ticket de servicio. Luego, el servicio toma el TGT y lo inyecta en la caché local de lsass.exe para su uso posterior.
Hoy en día sabemos que este método es muy riesgoso porque otorga acceso ilimitado a los servicios delegados, lo que, en caso de compromiso, permitiría al atacante recolectar todos los tickets almacenados en caché y obtener acceso completo a todos sus privilegios.
Este tipo de delegación todavía existe hoy en día, principalmente para admitir la compatibilidad con versiones anteriores, y se puede detectar consultando el indicador ADS_UF_TRUSTED_FOR_DELEGATION en el atributo userAccountControl. Esta bandera también es monitoreada por Silverfort, que informa sobre servicios utilizando delegación sin restricciones.
Etapa 2: delegación restringida
La próxima generación de delegación es más limitada y permite que el servicio suplante el acceso solo a recursos definidos con el indicador "La cuenta es confidencial y no se puede delegar" en Active Directory para limitar la suplantación de usuarios específicos.
Este tipo de delegación es donde el servicio realiza la autenticación utilizando las extensiones S4U2Self y S4U2Proxy (MS-SFU).
Entonces, ¿cómo funciona?
Nuestra cuenta de servicio debe tener activado el indicador TRUSTED_TO_AUTH_FOR_DELEGATION y el atributo ms-AllowedToDelegateTo que incluye el SPN del recurso.
Un usuario se autentica como de costumbre en el servicio mediante negociación Kerberos (TGT y TGS).
Ahora esto empieza a complicarse: una cuenta de servicio delegada solicita a sí misma un TGT reenviable. Usamos este ticket para solicitar un ticket de servicio usando S4U2SELF usando el nombre de usuario suplantado para nuestro campo cname PA-DATA.
El servicio toma este ticket y lo adjunta al ticket del servicio de recursos (S4U2Proxy) con el indicador de delegación restringida.
El ticket recibido es una suplantación del usuario actual por parte de nuestro servicio.
Etapa 3: Delegación restringida basada en recursos
La principal diferencia en esta delegación es principalmente administrativa.
En lugar de permitir que al servicio se le delegue el acceso a un recurso, le damos al propietario del recurso el poder de definir qué servicio puede realizar la delegación.
Esto es configurable por PowerShell usando el PrincipalesAllowedToDelegateToAccounparámetro t o simplemente editando el atributo msDS-AllowedToActOnBehalfOfOtherIdentity
Parche de seguridad de Microsoft para CVE-2020-17049 – Análisis técnico
Las vulnerabilidades de los protocolos siempre son más difíciles de mitigar debido al soporte de compatibilidad con versiones anteriores requerido.
Comenzamos a analizar el parche de Microsoft leyendo la información publicada en el sitio web oficial.
Entendimos que la vulnerabilidad se trata de "tickets de manipulación" y está ubicada en algún lugar del proceso de delegación restringida de Kerberos.
Elegimos simular la delegación en un controlador de dominio vulnerable y reproducirla en uno parcheado para comprobar la diferencia:
El primer cambio notable se ubica en la longitud de cada paquete, podemos ver que la solicitud del ticket autofirmado (S4U2Self) es la misma pero su respuesta es 40 bytes más larga.
Esto también se aplica a la próxima solicitud y respuesta de S4U2Proxy, entonces, ¿qué ha cambiado?
Una comparación de textos no fue útil porque el texto modificado está cifrado dentro del ticket.
Después de descifrar el cifrado utilizando la tabla de claves del servicio, el texto es legible pero aún debe entenderse.
Al observar el campo AuthorizationData, podemos ver un nuevo campo Desconocido, que comienza en el desplazamiento 840 con un tamaño de 20.
¿De dónde surge este nuevo campo? ¿Cómo lo maneja KDC?
Lo que más me gusta de los protocolos es que la mayoría de ellos mantienen y actualizan RFC periódicamente, y Kerberos no es una excepción.
Visitar MS-SFU Noté que se actualizó el 11/23/2020. Cuando abrimos el documento de diferencia En la sección 3.2.5.2.2 aprendimos que hay una nueva firma que se utiliza para validar la integridad del ticket. Además, el parche de Microsoft insinúa que el primer ticket modificado es el S4U2Self.
Extrajimos más información del RFC mirando la referencia de Ticket Signature: MS-PAC 2.8.3:
"El KDC utilizará la clave KDC (krbtgt) [RFC4120], para que otros KDC puedan verificar esta firma al recibir un PAC".
“La firma del billete se utiliza para detectar la manipulación de billetes por parte de partes distintas al KDC. La firma del ticket DEBE incluirse en los tickets que no están cifrados en la cuenta krbtgt (incluido el servicio de cambio de contraseña) o en una cuenta fiduciaria”.
“correspondiente a la firma del ticket contendrá el valor 0x00000010”
El RFC de MS-PAC reveló el misterio detrás del campo desconocido en el desplazamiento 840: es una nueva firma de ticket, cifrada usando la clave krbtgt para validar su integridad.
Bronce Kerberos
El 8 de diciembre se realizó una implementación de CVE-2020-17049 Vulnerabilidad de KCD en Kerberos ataque de broca de bronce se publicó con más detalle, arrojando más luz sobre la manipulación del ticket S4U2Self.
El exploit se ocupa de descifrar y editar el bit del campo reenviable dentro de encRepPart del ticket.
Un servicio con capacidad de delegación puede producir boletos S4U2Self para todos los usuarios incluso aquellos con el indicador "La cuenta es confidencial y no se puede delegar" activado.
Este indicador establece el indicador reenviable en Falso, pero el KDC nunca valida el ticket en caso de modificación.
Palabras finales
La divulgación de una nueva vulnerabilidad siempre despierta interés entre los investigadores de seguridad. Normalmente, dicha divulgación no implica una descripción detallada de los bits y bytes implicados. Si bien esto podría tener sentido desde la perspectiva operativa, es igualmente importante aprovechar dichas divulgaciones para obtener mejores conocimientos sobre la implementación del software (en este caso, el mecanismo de delegación de Kerberos). Si el conocimiento es poder, espero que este análisis nos haya hecho un poco más fuertes.
