Porqué NO conectarse NUNCA a servidores RDP a través de redes no fiables

En este artículo de GoSecure, la empresa demuestra porqué la conexión mediante el Protocolo de Escritorio Remoto (RDP) debe evitarse en redes no confiables como en hoteles, conferencias, o Wi-Fi público. Proteger la conexión con una VPN o un Remote Desktop Gateway es la única alternativa segura.

La empresa ha estudiado el protocolo por mucho tiempo y desarrollado y mantienen un completo conjunto de herramientas de ataque e intercepción de RDP llamado PyRDP. Explorando esta herramienta es fácil apreciar lo peligroso e irresponsable que es usar RDP en redes no confiables y este riesgo está mal documentado en la Web.

Introducción a la confianza en RDP

El modelo de autenticación de host remoto de RDP puede compararse con HTTPS o SSH. Con HTTPS dependemos de los navegadores para distribuir la confianza necesaria para validar los sitios. Los anclajes de confianza, autoridades de certificación en este caso, firman los sitios de destino, por lo que la criptografía es sólida. Se trata de una infraestructura de clave pública o PKI, por sus siglas en inglés.

SSH funciona bajo un modelo de "confianza en el primer uso" o TOFU (Trust on First Use) en el que se le presenta la huella digital del host la primera vez que se conecta a él. El usuario acepta esa huella y se guarda en su cliente. Si, al conectarte más tarde, la huella digital de la clave del host del servidor ha cambiado, aparecerá un mensaje de alarma indicando el peligro.

El protocolo RDP, desde la perspectiva del usuario final, expone un comportamiento similar a HTTPS con advertencias de certificado. A Microsoft le gustaría que la gente usara y confiara en PKI pero eso no se hace por defecto y es demasiado complejo para la mayoría de las organizaciones. En su lugar, presenta advertencias de certificado por defecto porque la mayoría de las veces el certificado del servidor no es de confianza. Luego está la opción "No me preguntes de nuevo para conexiones a este equipo" que, uno pensaría que actuaría como un opcional y poco claro "Confía cuando haga clic en no me preguntes de nuevo", análogo a SSH, pero eso no es exactamente así como se verá más adelante.

El problema

Aquí hay un video de demostración del ataque.

Desde hace tiempo se sabe que es posible capturar los hashes Net-NTLMv2 de los usuarios RDP. De hecho, la herramienta Responder fue la primera en soportarlo. Se implementó el mismo ataque en PyRDP el año pasado.

Desde entonces GoSecure ha descubierto que las credenciales con hash pueden ser robadas antes de que se muestre cualquier advertencia o error de certificado. Esto ocurre incluso si se ha hecho clic en "No volver a preguntarme [...]" en el error de certificado.

Microsoft reconoce que se trata de un error de diseño del protocolo y que su ingeniería no está dispuesta a solucionar el problema. Actualmente no se ofrece ningún mecanismo alternativo de autenticación segura. El viejo tratamiento de "no se arreglará, tal y como se diseñó".

¿Qué implica?

Un hash de su contraseña puede ser capturado por cualquier adversario en la ruta de red al servidor. Este tipo de hashes se denominan hashes NetNTLMv2 y son potencialmente recuperables por un atacante dependiendo de la complejidad de la contraseña, de su presencia en bases de datos públicas de contraseñas como RockYou2021 (que alberga 8.000 millones de contraseñas) y de los recursos del atacante.

Dados los riesgos y el hecho de que esto ocurre de forma indetectable (antes de los errores de certificado), aconsejamos que no se utilice RDP en redes no fiables como Wi-Fi públicas o a través de Internet sin una seguridad de transporte adicional como una VPN. En algunos contextos, la autenticación multifactor puede mitigar ese riesgo si la contraseña original es lo suficientemente fuerte.

Prevenir este ataque es complejo porque se trata de un error de diseño en un protocolo documentado públicamente con implementaciones de terceros y, este es el peor tipo de error para arreglar.

Lamentablemente, en la documentación, Microsoft no menciona ningún riesgo para el cliente y no existe ninguna hoja de ruta pública que permita a las versiones posteriores del protocolo deshacerse de estos problemas.

Fuente: GoSecure

Suscríbete a nuestro Boletín