Si bien el Protocolo de Escritorio Remoto (RDP) es una forma conveniente y eficiente de acceder a sistemas remotos, si no se administra adecuadamente, puede ser vulnerable a algunos ataques, como los ataques Man-In-The-Middle causados por el uso de Trust on First Use. (TOFU) modelo. En esta publicación de blog, analizaremos por qué RDP TOFU es un mal modelo de seguridad y por qué las organizaciones deberían usar certificados SSL en su lugar.
El modelo Trust on First Use (TOFU) es un modelo de seguridad que se utiliza en algunos protocolos, incluido RDP. En el modelo TOFU, el usuario acepta la identidad del sistema remoto (normalmente un certificado autofirmado) la primera vez que se conecta a él. Después de la primera conexión, el sistema del usuario almacena en caché la identidad del sistema remoto y el usuario no necesita verificar manualmente la identidad del sistema remoto nuevamente en conexiones posteriores.
El modelo RDP TOFU tiene varios fallos de seguridad que lo convierten en una mala opción para el acceso remoto seguro. El primer y más crítico defecto es que el usuario no tiene forma de verificar la identidad del sistema remoto la primera vez que se conecta a él. Esto deja al usuario vulnerable a ataques de intermediario (MITM). En un ataque MITM, un atacante intercepta la conexión entre el sistema del usuario y el sistema remoto haciéndose pasar por el servidor remoto, engañando al usuario para que acepte la identidad del atacante como la identidad del sistema remoto.
Este tipo de ataques se utilizan generalmente para obtener la identidad del usuario (robar sus contraseñas, o incluso tokens existentes), o para robar información confidencial que el usuario carga en el endpoint pensando que es el endpoint real. Además, el atacante puede instalar un malware de puerta trasera en el sistema del usuario, lo que le permite acceder al sistema del usuario en cualquier momento en el futuro.
Además, seamos honestos, nadie lee la advertencia TOFU, todos hacemos clic ciegamente en aceptar. (Por ejemplo, ¿notaste que en la imagen de arriba el nombre DNS del certificado no coincide con la dirección IP a la que nos estábamos conectando)?
RDP existe desde hace más de 25 años, es posible que se pregunte por qué esto se está convirtiendo en un problema mayor en lugar de desaparecer. Esto es por dos razones:
1) En aquel entonces, la mayor parte de RDP se realizaba bajo la misma red que estaba protegida por un fuerte firewall, lo que hacía muy difícil para un atacante realizar un ataque Man-In-The-Middle ya que físicamente tendría que estar en la misma red que la víctima.
2) La segunda razón es que la forma en que Microsoft resolvió este problema fue permitiendo a las organizaciones enviar certificados RDP a máquinas unidas a un dominio a través de objetos de política de grupo (GPO), lo que facilita exigir que todas las máquinas unidas a un dominio tengan certificados confiables para sus conexiones RDP. Sin embargo, con el paso a la nube, muchas organizaciones están migrando a una arquitectura sin dominio, lo que significa que debemos encontrar una nueva forma de emitir certificados para estas máquinas sin dominio.
Como ocurre con muchos otros problemas de ciberseguridad, la solución es sencilla: PKI. Sin embargo, como se mencionó anteriormente en el blog, se vuelve más complicado cuando los dispositivos no están unidos a un dominio, para solucionar este problema existen dos posibles soluciones:
1) Using win-acme to create Remote Desktop Services (RDS) certificates (If you are using ADCS, your CA doesn’t support the ACME protocol; however, you can use EZCA’s ACME for ADCS connector or create your own EZCA CA with ACME support.
2) Si no desea alojar su propio servidor ACME, puede hacerlo completamente sin servidor utilizando cliente de certificado de EZCA, una herramienta de línea de comandos de código abierto. que permite la rotación automática de certificados mediante el uso de tareas programadas y las API de EZCA.
Si desea obtener más información o hablar con un experto en PKI sobre cómo automatizar su distribución SSL en Azure, puede hablar con un experto en PKI de forma GRATUITA. Estamos aquí para ayudarlo en su viaje sin contraseña y garantizar que su PKI esté configurada de manera adecuada y segura.
