mitigación CVE-2018-0886 para un servidor RDP no parcheable

5

Un cliente de Windows 10 actualizado se está conectando a un host de Windows 10 RDP que se atasca en 1511 (el host no se puede actualizar y 1511 no está disponible para recibir parches, como la mitigación CVE-2018-0886 ).

¿Qué es exactamente la exposición en internet público? ¿Hay otra forma de mitigar la exposición que no sea la instalación de un parche de software?

Específicamente: mi entendimiento es que CVE-2018-0886 requiere una configuración de hombre en el medio para iniciar un ataque. Si el cliente y el host están conectados a proveedores de confianza, ¿todavía deja una oportunidad para un MITM (nodos intermedios entre los proveedores)?

También: al iniciar una conexión RDP, a menudo hay un mensaje para aceptar un certificado (como se muestra en this question ), y parece que vuelve a aparecer de vez en cuando entre el mismo par de cliente y host. Esto me sugiere que el host RDP está generando y volviendo a generar periódicamente un certificado autofirmado, que me parece que es el punto en el que un MITM puede insertarse. ¿Existe algún procedimiento mediante el cual el host pueda generar un certificado de larga duración (incluso si es autofirmado) que se pueda transferir a un cliente (mediante una conexión segura) para que se mantenga la relación de confianza (no se solicite confiar en un autofirmado)? cert sobre una conexión cuestionable)? Y, al hacer esto, ¿no mitiga la vulnerabilidad CVE-2018-0886 sin tener que hacer ningún parche?

    
pregunta Zenilogix 19.06.2018 - 05:39
fuente

1 respuesta

0

Los certificados no van a salvarte. La única mitigación que conozco son los parches.

Permítame citar a la gente que descubrió este CVE: enlace

La explotación de la vulnerabilidad de retransmisión NTLM fue posible debido a la forma en que se implementa RDP. Echemos un vistazo al proceso:

  1. Negociación sobre capacidades (generalmente se elige CredSSP)
  2. TLS está establecido
  3. La autenticación de capa de red (NLA) se lleva a cabo utilizando CredSSP
  4. El cliente verifica el certificado, mostrando una advertencia si necesario

Las credenciales se envían en el paso 3 mencionado anteriormente, y el certificado se verifica en el paso 4. Ouch. Esto significa que una aplicación basada en el certificado es demasiado tarde; para cuando se da cuenta de que el certificado es incorrecto, ya ha enviado las credenciales.

No estoy seguro de lo que está pasando con la nueva solicitud de certificado.

    
respondido por el Daniel Bungert 19.06.2018 - 17:25
fuente

Lea otras preguntas en las etiquetas