You have not selected any currencies to display

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

41


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

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



Source link

Los comentarios están cerrados.