Eliminar el cifrado vulnerable en Windows 10 rompe el RDP saliente

El escáner de vulnerabilidad de TrustWave falla un escaneo debido a una máquina con Windows 10 que ejecuta RDP:

Algoritmos de cifrado de bloque con un tamaño de bloque de 64 bits (como DES y 3DES) ataque de cumpleaños conocido como Sweet32 (CVE-2016-2183)

NOTA: En los sistemas Windows 7/10 que ejecutan RDP (Protocolo de escritorio remoto), el cifrado vulnerable que debe deshabilitarse está etiquetado como 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'.

Usando IIS Crypto (de Nartac), intenté aplicar la plantilla de "Mejores prácticas" así como la plantilla PCI 3.1, sin embargo, ambas incluyen el cifrado inseguro (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Si desactivo este cifrado, el RDP de esta computadora para muchas estaciones de Windows deja de funcionar (todavía funciona para algunos servidores 2008 R2 y 2012 R2). El cliente RDP simplemente muestra "Se ha producido un error interno" y el registro de eventos:

Se produjo un error grave al crear una credencial de cliente TLS. El estado de error interno es 10013.

Revisé el registro de eventos del servidor de uno de los servidores y vi estos dos mensajes

Se recibió una solicitud de conexión TLS 1.2 desde una aplicación cliente remota, pero ninguno de los conjuntos de cifrado admitidos por la aplicación cliente son compatibles con el servidor. La solicitud de conexión SSL ha fallado.

Se generó la siguiente alerta fatal: 40. El estado de error interno es 1205.

¿Cómo puedo solucionar la vulnerabilidad de seguridad sin romper el RDP saliente?

O, si lo anterior no es posible, ¿hay algo que pueda hacer en cada host RDP que ya no pueda conectar y que lo maneje en ese extremo?

--- Actualización # 1 ---

Después de deshabilitar TLS_RSA_WITH_3DES_EDE_CBC_SHA en la máquina con Windows 10, intenté conectarme a varios hosts RDP (la mitad de ellos falló con "Un error interno ..."). Así que comparé uno de estos hosts al que puedo conectarme con uno al que no puedo conectarme. Ambos son 2008 R2. Ambos tienen la misma versión RDP (6.3.9600, RDP Protocol 8.1 compatible).

Comparé los protocolos y cifrados TLS usando IIS Crypto para hacer "Guardar plantilla" en su configuración actual para poder comparar los archivos de plantilla. ¡Eran idénticos! Entonces, cualquiera que sea el problema, no parece ser una falta de un conjunto de chips en el host. Aquí hay una captura de pantalla de Beyond Compare en los archivos:

¿Qué podría ser diferente entre los dos hosts RDP que causa este problema y cómo solucionarlo?

IIS Crypto tiene la opción de configurar las opciones del lado del servidor (entrante) y del lado del cliente (saliente). Hay un puñado de cifrados que debe dejar habilitados en el lado del cliente para la compatibilidad.

Para hacer lo que quieras, personalmente iría con lo siguiente:

• Aplicar plantilla 3.1
• Deje todas las suites de cifrado habilitadas
• Aplicar tanto al cliente como al servidor (casilla marcada).
• Haga clic en 'aplicar' para guardar los cambios.

Reinicie aquí si lo desea (y tiene acceso físico a la máquina).

• Aplicar plantilla 3.1
• Deje todas las suites de cifrado habilitadas
• Aplicar al servidor (casilla de verificación sin marcar).
• Desmarca la opción 3DES

Reiniciar aquí debería dar como resultado el estado final correcto.

Efectivamente, solo desea deshabilitar la entrada 3DES, pero aún permite el uso saliente de dicho conjunto de cifrado.

Tuve el mismo problema, instalar el parche KB3080079 en el servidor permite la compatibilidad con tls 1.1 y 1.2.

Tenga en cuenta que para los clientes de Windows 7 deberá instalar la actualización del cliente rdp (KB2830477), de lo contrario, solo Windows 8+ podrá conectarse.

Editar (2018-09-26): descubrí que deshabilitar 3DES en 2012R2 NO interrumpe RDP pero sí interrumpe en 2008 R2. Las opciones admitidas parecen ser diferentes entre los núcleos.

Compartiré mi respuesta de un hilo de TechNet pero primero BLUF:

Conclusión predeterminada del servidor: lo más probable es que tenga alguna otra diferencia entre los sistemas. Se está conectando entre diferentes versiones del sistema operativo, un sistema tiene FIPS habilitado y el otro no, o tiene diferentes restricciones de cifrado vigentes HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Sin duda habilitar el registro SCHANNEL en el sistema que hace el trabajo para determinar qué sistema de cifrado está en uso. Me encantaría saber si de alguna manera conseguiste que RDP trabaje con un cifrado alternativo.

Copia de la publicación:

¡Lo tenemos para trabajar!

Aparentemente, 2008 y 2012 tienen problemas de sintaxis y el 2008/7 requiere un seguimiento / 168. 2012 / 8.1 / 10 no.

La clave en 2008 se ve así: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

Y la clave en 2012 se ve así: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Puedo confirmar que el uso de "Triple DES 168/168" NO deshabilita 3DES en el sistema. Puede probarlo usted mismo con un escáner de protocolo (como Nessus) o habilitando el registro de SCHANNEL:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

Entonces tendrá eventos en el registro del SISTEMA, por ejemplo;

Un protocolo de enlace de cliente SSL completado con éxito. Los parámetros criptográficos negociados son los siguientes.

Protocolo: TLS 1.0 CipherSuite: 0x2f Fuerza de intercambio: 1024

Para mí, el resultado es 0xa que Google revela como TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Cuando uso "Triple DES 168" (sin el / 168), el evento de sistema ID 36880 no aparece y la sesión RDP está bloqueada.

Según el artículo: Criptografía del sistema: use algoritmos compatibles con FIPS para el cifrado, el hash y la firma

Servicios de escritorio remoto (RDS) Para cifrar la comunicación de red de Servicios de escritorio remoto, esta configuración de directiva solo admite el algoritmo de cifrado Triple DES.

Según el artículo: "Criptografía del sistema: utilice algoritmos compatibles con FIPS para el cifrado, el hash y la firma", los efectos de configuración de seguridad en Windows XP y en versiones posteriores de Windows

Esta configuración también afecta a Servicios de Terminal Server en Windows Server 2003 y en versiones posteriores de Windows. El efecto depende de si TLS se está utilizando para la autenticación del servidor.

Si se usa TLS para la autenticación del servidor, esta configuración hace que solo se use TLS 1.0.

De forma predeterminada, si no se está utilizando TLS y esta configuración no está habilitada en el cliente o en el servidor, el canal del Protocolo de escritorio remoto (RDP) entre el servidor y el cliente se encripta utilizando el algoritmo RC4 con 128 bits longitud clave Después de habilitar esta configuración en una computadora con Windows Server 2003, se cumple lo siguiente: El canal RDP se encripta utilizando el algoritmo 3DES en modo Cipher Block Chaining (CBC) con una longitud de clave de 168 bits. El algoritmo SHA-1 se usa para crear resúmenes de mensajes. Los clientes deben usar el programa cliente RDP 5.2 o una versión posterior para conectarse.

Ambos respaldan la idea de que RDP solo puede utilizar 3DES. Sin embargo, este artículo sugiere que hay disponible una gama más amplia de cifrados: Validación FIPS 140

El conjunto de algoritmos criptográficos que utilizará un servidor de Protocolo de escritorio remoto (RDP) tiene un alcance de: - CALG_RSA_KEYX - Algoritmo de intercambio de clave pública RSA - CALG_3DES - Algoritmo de cifrado Triple DES - CALG_AES_128 - AES de 128 bits - CALG_AES_256 - AES de 256 bits - CALG_SHA1 - Algoritmo de hash SHA - CALG_SHA_256 - Algoritmo de hash SHA de 256 bits - CALG_SHA_384 - Algoritmo de hash SHA de 384 bits - CALG_SHA_512 - Algoritmo de hash SHA de 512 bits

En última instancia, no está claro si RDP puede admitir protocolos que no sean 3DES cuando el modo FIPS está habilitado, pero la evidencia sugiere que no lo hace.

No veo evidencia de que Server 2012 R2 funcione de manera diferente a Server 2008 R2, sin embargo, parece que Server 2008 R2 se basó en el cumplimiento de FIPS 140-1 y Server 2012 R2 sigue FIPS 140-2, por lo que es completamente posible que Server 2012 R2 sea compatible protocolos adicionales Notará los protocolos adicionales en el enlace de validación FIPS 140 .

En conclusión: no creo que Server 2008 R2 pueda soportar RDP en modo FIPS con 3DES deshabilitado. Mi recomendación es determinar si su sistema cumple con las condiciones para un ataque SWEET32 (más de 768GB enviados en una sola sesión) y si vale la pena eliminar la capacidad de RDP para deshabilitar 3DES. Existen otras utilidades para administrar servidores más allá de RDP, especialmente en un mundo donde la virtualización es muy común.

Aparentemente, 2008 y 2012 tienen problemas de sintaxis y el 2008/7 requiere un seguimiento / 168. 2012 / 8.1 / 10 no.

la clave en 2008 se ve así: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Gran descubrimiento Tuve exactamente el mismo problema en algunos controladores de dominio de Windows 2008 R2, curiosamente mis servidores 2008R2 miembros parecen estar bien ... y mis servidores 2012R2 también funcionan bien. Necesita descifrar la descomposición de esos DC más antiguos :)