Implementación de protección ampliada para la autenticación (EPA) en un servicio

Artículo
10/25/2023

Característica	Se aplica a
EPA	Todos los sistemas operativos Windows admitidos
Modo de auditoría de EPA	Windows Server 2019 Windows Server 2022 Windows Server 23H2

¿Cuál es el problema?

Hay una clase de ataques en los servicios autenticados que se denominan ataques de reenvío. Estos ataques permiten a los adversarios omitir la autenticación y actuar como otro usuario. Dado que se trata de ataques al servicio y no al propio protocolo de autenticación, es el servicio autenticado el que debe impedir los ataques de reenvío.

¿Cómo funcionan los ataques de reenvío?

Cuando un servicio o aplicación llama a la API AcceptSecurityContext para autenticar un cliente, pasa un blob de datos recibidos de la llamada del cliente a InitializeSecurityContext. El protocolo de autenticación es responsable de comprobar que el blob proporcionado se originó en el usuario indicado. AcceptSecurityContext no puede hacer ninguna aserción sobre la autenticidad del resto del mensaje de la aplicación que no ha visto.

Un error de seguridad común en las aplicaciones es tratar el tráfico de una aplicación como autenticado después de una autenticación correcta del blob del protocolo de autenticación interno. Esto suele ocurrir con aplicaciones que usan TLS para su protocolo de conexión. TLS normalmente no usa certificados de cliente. Proporciona al servidor garantías de integridad y confidencialidad, pero no de autenticación. La autenticación interna proporciona autenticación de cliente, pero solo para su blob. No autentica el canal TLS ni el resto del protocolo de aplicación que contiene.

Para ejecutar un ataque de reenvío, un atacante inserta un blob de autenticación desde un origen con una solicitud diseñada por él. Por ejemplo, un atacante puede observar el tráfico de autenticación en la red e insertarlo en su propia solicitud al servidor. Esto permite al atacante obtener acceso al servidor como cliente desde el tráfico de autenticación capturado.

El concepto clave aquí es que los mensajes de autenticación SSPI están diseñados para exponerse en la conexión; no se espera que se mantengan en secreto. Esto difiere de muchos esquemas de autenticación basados en web que usan tokens de portador que siempre se mantienen confidenciales dentro de los canales TLS.

¿Cuál es la solución?

La solución de preferencia es usar la clave de sesión del protocolo de autenticación para firmar o cifrar (MakeSignature, EncryptMessage) otro tráfico. Dado que la clave de sesión se deriva criptográficamente durante el intercambio del protocolo de autenticación, se garantiza que los datos autenticados y cualquier tráfico protegido por esa clave provienen del cliente autenticado.

Esto no siempre es una opción. En algunos casos, el formato del mensaje del protocolo de la aplicación viene determinado por estándares diseñados para tokens de portador. En este caso, la protección ampliada para la autenticación (EPA), también conocida como enlace de canal, puede protegerse contra el reenvío a través de un canal TLS/SSL.

¿Qué es EPA?

EPA enlaza criptográficamente la clave de sesión TLS a la clave de sesión del protocolo de autenticación, lo que permite a TLS proporcionar la misma autenticación de cliente que la clave del protocolo de autenticación. Para obtener más información, consulte Información general sobre la protección ampliada para la autenticación.

enlace del servicio

La segunda parte de EPA se denomina enlace de servicio. A diferencia del enlace de canal, este no proporciona al servicio garantías criptográficas y actúa como defensa del último recurso donde no es posible el enlace de canal. Este mecanismo permite al servidor llamar a QueryContextAttributes para recuperar el atributo SECPKG_ATTR_CLIENT_SPECIFIED_TARGET que contiene el nombre que el cliente autenticado pasó a InitializeSecurityContext.

Por ejemplo, imagine que un servicio reside detrás de un equilibrador de carga de terminación TLS. No tiene acceso a la clave de sesión TLS y solo puede determinar desde el enlace de canal que la autenticación del cliente estaba pensada para un servicio protegido con TLS. El nombre proporcionado por el cliente debe ser el mismo que el que usó para validar el certificado de servidor TLS. Al comprobar que el cliente se autentica con un nombre que coincide con el certificado TLS del servidor del equilibrador de carga, el servicio adquiere una elevada confianza en que la autenticación procede del mismo cliente que el canal TLS.

En este artículo no se explica cómo se admite el enlace de servicio. Consulte Procedimiento para especificar un enlace de servicio en la configuración para obtener más información.

¿Cómo se admite EPA?

Al aplicar EPA, los servicios pueden observar que los clientes no se autentican debido a problemas de compatibilidad. Por tanto, hemos creado un modo de auditoría de EPA donde los servicios pueden habilitar la auditoría, lo que proporciona a los administradores controles para observar cómo responden los clientes antes de aplicar EPA.

Entre los servicios de Microsoft que admiten el modo de auditoría, se incluye:

LDAP

Nota:

A continuación encontrará los pasos opcionales para habilitar la funcionalidad de auditoría de EPA. Tenga en cuenta que habilitar la funcionalidad de auditoría de EPA sin aplicar EPA no protege contra ataques de retransmisión. Se recomienda que los servicios que decidan habilitar primero EPA en modo de auditoría, más adelante tomen medidas para corregir clientes incompatibles y, finalmente, apliquen EPA estrictamente para evitar posibles ataques de retransmisión.

Nota:

No es necesario que los enlaces de canal pasados a AcceptSecurityContext sean enlaces de solo auditoría para obtener los resultados de auditoría. Los servicios pueden ejecutar el modo de auditoría mientras siguen aplicando EPA.

Remoto

Use QueryContextAttributes(TLS) para obtener enlaces de canal (rellene único o punto de conexión).
Llame a InitializeSecurityContext y pase enlaces de canal en SECBUFFER_CHANNEL_BINDINGS.

Servidor

Use QueryContextAttributes(TLS), como en el cliente.
(Opcionalmente) Se convierte en solo auditoría mediante una llamada a SspiSetChannelBindingFlags.
(Opcionalmente) Agregue el búfer de resultados de enlace de canal a los búferes de salida para ASC.
Especifique el nivel de EPA y otras configuraciones llamando a AcceptSecurityContext con SECBUFFER_CHANNEL_BINDINGS.
(Opcionalmente) Use marcas para controlar el comportamiento en casos de esquina:
- ASC_REQ_ALLOW_MISSING_BINDINGS: no produce errores en los clientes que no dicen nada en absoluto, como los dispositivos antiguos de terceros. Los clientes informados que no han obtenido SECBUFFER_CHANNEL_BINDINGS enviarán un enlace vacío en lugar de nada.
- ASC_REQ_PROXY_BINDINGS: un caso inusual para los equilibradores de carga de terminación TLS. No tenemos un SECBUFFER_CHANNEL_BINDINGS para pasar, pero aún queremos exigir que los clientes coloquen la solicitud en un canal TLS. Esto es más útil con enlaces de servicio para asegurarse de que el cliente también estaba colocando solicitudes en un canal TLS para el que el certificado del servidor coincide con nuestro nombre.

¿Cómo se aplica EPA?

Una vez que un servicio admite EPA, los administradores pueden controlar el estado de EPA desde la auditoría hasta el cumplimiento completo. Esto proporciona a los servicios las herramientas para evaluar la preparación de su ecosistema para EPA, corregir dispositivos incompatibles y aplicar EPA progresivamente para proteger su entorno.

Los siguientes atributos y valores se pueden usar para aplicar varios niveles de EPA en su entorno:

Nombre	Descripción
Ninguno	No se realiza ninguna validación de enlace de canal. Este es el comportamiento de todos los servidores que no se han actualizado.
Permitir	Todos los clientes que se han actualizado deben proporcionar información de enlace de canal al servidor. No es obligatorio para los clientes que no se han actualizado. Esta es una opción intermedia que permite la compatibilidad entre aplicaciones.
Requerir	Todos los clientes deben proporcionar información de enlace de canal. El servidor rechazará las solicitudes de autenticación de los clientes que no lo hagan.

Estos atributos se pueden acoplar con la funcionalidad de auditoría para recopilar información sobre la compatibilidad de dispositivos en varios niveles de cumplimiento de EPA. Pasará la configuración deseada a SspiSetChannelBindingFlags.

Auditoría : el modo de auditoría se puede usar junto con cualquiera de los niveles de cumplimiento de EPA anteriores.

¿Cómo se interpretan los resultados de la auditoría de EPA?

Los resultados de la auditoría son un conjunto de marcas de bits:

Marca	Descripción
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	El cliente ha indicado que admite enlaces de canal.
SEC_CHANNEL_BINDINGS_RESULT_ABSENT	El cliente no ha proporcionado ningún enlace a un canal externo.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	Los enlaces de cliente indican un canal diferente al servidor.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	Error de enlace de canal debido a SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	Los canales se han enlazado correctamente.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	El cliente ha indicado el enlace a un canal externo, que pasó por medio de ASC_REQ_PROXY_BINDINGS.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Enlace de canal pasado por medio de ASC_REQ_ALLOW_MISSING_BINDINGS.

También hay definiciones para conjuntos de bits:

Marca	Descripción
SEC_CHANNEL_BINDINGS_RESULT_VALID	Se usa para probar todos los casos de SEC_CHANNEL_BINDINGS_VALID_*.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Se usa para probar todos los casos de SEC_CHANNEL_BINDINGS_NOTVALID_*.

Flujo de auditoría

Cualquier sistema operativo que admita los resultados siempre establecerá al menos un bit fuera de SEC_CHANNEL_BINDINGS_RESULT_VALID y SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

Error de enlace de canal: pruebe los bits de SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. En el caso de los enlaces que no son de solo auditoría, esto corresponde a errores de ASC con STATUS_BAD_BINDINGS o SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: tanto el cliente como el servidor conocen los enlaces de canal, pero no están de acuerdo en el canal. Este es el caso de ataque o una configuración de seguridad incorrecta que no se puede distinguir de un ataque, porque la configuración ha puesto en peligro HTTPS para inspeccionar el tráfico (por ejemplo, Fiddler). También podría ser que el cliente y el servidor no están de acuerdo en cuanto a los enlaces únicos frente a los de punto de conexión.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING se divide en dos casos:
- Con SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, significa que el cliente atestigua que conoce los enlaces de canal y dijo que no había ningún canal. Esto puede ser un ataque de reenvío desde un servicio que no es TLS, pero es probable que sea una aplicación no informada ejecutándose en el cliente que realiza TLS, pero que no informa de ello a la autenticación interna.
- Sin SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, es un cliente que no admite enlaces de canal. Todas las versiones de Windows compatibles admiten enlaces de canal, por lo que se trata de un sistema de terceros o que tiene establecido el valor del Registro SuppressExtendedProtection. Este es el caso que se convierte en SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING si pasa ASC_REQ_ALLOW_MISSING_BINDINGS.

Enlace de canal correcto: este es el caso contrario a la comprobación de errores o a la prueba de SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED es el caso correcto. La protección de seguridad funciona (o funcionaría si EPA se habilitase como solo para auditoría).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING significa que se pasó ASC_REQ_ALLOW_MISSING_BINDINGS, por lo que se ha permitido un cliente que no ha reclamado la compatibilidad con enlaces de canal. Los clientes que llegan a este caso no están protegidos y deben investigarse para ver lo que está mal. Deben actualizarse para admitir enlaces de canal, o bien debe borrarse el valor del Registro SuppressExtendedProtection una vez actualizadas las aplicaciones interrumpidas.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY es un caso especial asociado a la marca ASC_REQ_PROXY_BINDINGS que se usa cuando finaliza TLS en un equilibrador de carga en lugar de llegar al servidor. El servidor no puede comprobar si el cliente usa la misma conexión TLS, ya que se ha terminado en el equilibrador de carga. Para fines de auditoría, esto se trata igual que SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.