La pandemia del virus COVID-19 ha cambiado radicalmente el modelo de trabajo del personal de muchas organizaciones de forma voluntaria-obligatoria, “premiando” a la mayoría con la condición de “remotos”, y algunos, incluso de “trabajadores remotos”.
Si antes de la "megaepidemia" los empleados realizaban sus tareas laborales desde la oficina utilizando la infraestructura corporativa controlada por el departamento de TI de la empresa, entonces, durante el autoaislamiento, la parte del "león" del trabajo de oficina comenzaba a realizarse desde dispositivos domésticos utilizando el Protocolo de escritorio remoto (RDP). Popular, como el propio sistema operativo de MS, pero, como lo demuestra la lista de vulnerabilidades, no es el protocolo más seguro. Hablaremos sobre cómo proteger su RDP de ataques externos.
Lamentablemente, para considerar las características de cada una de las vulnerabilidades a las que me gustaría llamar su atención, definitivamente un artículo no me basta, por lo que en este me limitaré a los detalles del ciclo de vida de uno de los últimos.
RDP viceversa
En 2018, en el curso de una investigación sobre la seguridad del Protocolo de escritorio remoto, los especialistas de Check Point Research descubrieron múltiples vulnerabilidades en tres clientes populares diseñados para trabajar con él:
- Cliente RDP de Microsoft / Mstsc.exe
- rdesktop
- FreeRDP
En total, se descubrieron 25 vulnerabilidades, incluidas críticas, incluidas aquellas que permiten a un atacante cambiar la dirección habitual de comunicación y atacar un equipo cliente, es decir, realizar un ataque mediante una conexión RDP inversa (ataque RDP inverso).
En el cliente RDP de Microsoft, esta vulnerabilidad acechaba en el portapapeles compartido entre el cliente y el servidor. Lo cual, al usar el búfer durante la conexión, permitió al servidor con el exploit "incluir" sus propios archivos en el proceso de intercambio iniciado por el usuario. Y la funcionalidad del ataque transversal de ruta es determinar el "destino final" del archivo en cualquier lugar del equipo cliente. Por ejemplo, sin notificaciones innecesarias, envíe un archivo ejecutable (minero, programa de cifrado) a la carpeta de inicio de la computadora del usuario para iniciarlo en el próximo reinicio del sistema.
Demostración de la vulnerabilidad de Check Point Research
El hecho fue informado a Microsoft (MSRC) el 16 de octubre de 2018. Ante lo cual, el 17 de diciembre de 2018, el destinatario respondió:
“Gracias por su presentación. Determinamos que su hallazgo es válido pero no cumple con nuestro estándar de servicio. Para obtener más información, consulte los Criterios de mantenimiento de seguridad de Microsoft para Windows (https://aka.ms/windowscriteria) ".
“Gracias por enviar su solicitud. Hemos determinado que su hallazgo es válido pero no cumple con nuestro nivel de servicio. Para obtener más información, consulte Criterios de servicio de Microsoft para Windows (https://aka.ms/windowscriteria) ".
Como resultado, esta vulnerabilidad no recibió su ID y parche para su corrección. una fuente
HyperRDP
Después de la publicación de información sobre esta vulnerabilidad, los empleados de Check Point Research comenzaron a recibir muchos comentarios y preguntas, uno de los cuales despertó un interés genuino y los llevó a volver a investigar más y observar la vulnerabilidad desde un "ángulo diferente", a saber: ¿puede la vulnerabilidad del cliente de Microsoft RDP ser utilizado en Microsoft Hyper-V?
Como resultado de un estudio adicional, resultó que en el corazón de la GUI para administrar VM: el administrador de Hyper-V, la tecnología RDP se usa en secreto, en sesiones extendidas de las cuales, así como en las propiedades del escritorio remoto, es posible habilitar un portapapeles compartido. ¡Y como resultado, la misma vulnerabilidad está presente!
Demostración de una vulnerabilidad en Hyper-V de Check Point Research
Los empleados de Check Point Research hablaron sobre esto en su blog, así como en la conferencia Black Hat USA 2019 .
Presentación de vulnerabilidad en Black Hat USA 2019
Y, por supuesto, informó MSRC . Esta vez, Microsoft abrió un ticket y en octubre de 2019 lanzó un parche para corregir esta vulnerabilidad, que recibió la identificación: CVE-2019-0887 . una fuente
Maneras inescrutables
Después de analizar la efectividad del parche, cuando los expertos de Check Point Research estaban a punto de asignar a la vulnerabilidad el estado "cerrado", un usuario de Mac OS RDP Client los contactó con información sobre el comportamiento del cliente después de instalar el parche desde MS.
En el proceso de creación de prototipos del modelo de conexión RDP con este cliente, quedó claro que el parche en sí tiene agujeros de seguridad que le permiten evitar la protección y recrear el exploit original. Esto fue informado al MSRC .
En febrero de 2020, Microsoft se recuperó y lanzó un parche para corregir esta vulnerabilidad CVE-2020-0655., que, según los expertos de Check Point Research, no ha resuelto por completo el problema de los ataques de recorrido de ruta, en particular, para la API de Windows. Microsoft anunció sobre este "conjunto" aún no se ha pronunciado sobre esta situación. una fuente
Y qué…
Como puede notar el lector astuto, se requiere un servidor RDP comprometido para llevar a cabo con éxito este tipo de ataque. Y puede "conseguirlo" de tres formas:
- Crea el tuyo propio y hazlo pasar por legítimo
- Accede al existente y comprometelo
- Híbrido
Una opción relativamente segura, con un costo óptimo y una velocidad de aprovisionamiento en la realidad actual sería "hacerse cargo" de un servidor en la nube o VPS / VDS alquilado a un proveedor de servicios. Y hay tres razones principales para esto:
- Cada servidor virtual alquilado que ejecuta Windows ya es un servidor RDP de forma predeterminada
- Cada servidor virtual alquilado que ejecuta Windows, por regla general, ya tiene una cuenta RDP con derechos de administrador y un único inicio de sesión para todos los usuarios.
- Como regla general, el acceso RDP al servidor virtual se realiza a través del puerto TCP disponible en la dirección IP pública: 3389.
En realidad, este puerto "que sobresale" es probablemente el "trapo rojo" para un atacante cibernético que quiere apoderarse de algún servidor virtual, obteniendo una contraseña para él usando un método simple de fuerza bruta automatizado. O como también se le llama ataque de fuerza bruta.
Como referencia: un ejemplo de un aumento en el número de ataques de la familia Bruteforce.Generic.RDP, febrero - abril de 2020 de Kaspersky Lab.
una fuente
... más lejos
Para no convertirse en víctima de las situaciones anteriores, puede, por supuesto, cambiar la configuración de la cuenta y los puertos RDP estándar, bloquear los intentos de conexión no autorizados utilizando el firewall de Windows o programas de terceros como IPBAN , usar cifrado y certificados, y mucho, mucho más. Pero para mí, la forma más fácil y rápida de asegurar una conexión RDP a un servidor recién creado es permitir el acceso RDP solo desde hosts de una red confiable.
En RUVDS, esto requiere tres simples pasos:
- Combine un servidor virtual con computadoras que necesitan acceder a él a través de RDP con una red privada virtual. Estoy usando - ZeroTier
- :
.
:
—
— . — ZeroTier.
— RDP- . . - RDP- IP- .
Sobre esto quiero despedirme y aconsejarle que controle el "estado" de la conexión RDP de su servidor virtual. Porque, desde CVE-2020-0655, han aparecido tres vulnerabilidades más con funcionalidad de ataque RDP inverso.
