Bastionado de sistemas Windows: autenticación de red
Contar con profesionales capacitados e implicados con el bastionado de sistemas ofrece la posibilidad de disponer de implementaciones seguras y evita las configuraciones erróneas
El bastionado de sistemas o hardening exige dedicación. Y conocimiento. Una combinación indispensable para sortear la mala configuración que tantas veces nos hemos encontrado en las compañías.
Una mala configuración que no es ni mucho menos nueva. Vaya por delante que este artículo no intenta descubrir la rueda. De hecho, hablaremos del uso de herramientas que otras personas ya han desarrollado, así que el mérito no es mío.
En esta ocasión, queremos poner el foco sobre el uso de RDP. Una utilidad que todos los sysadmin usan cada día pero que, debido a diferentes casuísticas, no está bien configurada en muchas ocasiones.
Un entorno muy habitual es el de la compañía que hace ya más de un lustro disponía de equipos obsoletos (XP, 2003 por ejemplo, que no tenían la opción de autenticación por red previa al RDP (NLA)) en su red. Y estos convivían con sistemas operativos más modernos: W7, W10, W2012…
Debido al ecosistema amplio del que disponían, la manera por defecto de conectarse a sus equipos vía RDP era no tener habilitada una opción que en Windows 10 está habilitada por defecto. Se trata de la autenticación por red para RDP (NLA):
Esta opción requiere que el usuario que se conecta vía RDP se autentique de forma segura antes de que se establezca una sesión con el servidor. Así, se minimizan ataques DOS, permite inicio de sesión único y mitiga vulnerabilidades del RDP. Todo son ventajas.
Existen diferentes ataques al protocolo RDP, como el conocido Bluekeep, y en el futuro seguramente habrá muchos otros.
En este artículo vamos a analizar la picaresca de utilizar herramientas públicas como Seth, que nos ayudan a realizar un ataque tipo MITM para hacernos con las credenciales de usuarios que utilizan RDP. Como por ejemplo, un Sysadmin que se conecta de vez en cuando al DC de la compañía.
Supongamos el siguiente escenario. Un usuario malicioso o un insider quiere hacerse con credenciales válidas del Sysadmin.
El usuario malicioso o insider realiza tareas previas de descubrimiento para determinar cuáles son las máquinas a atacar. Para ello, necesita saber la IP del DC y la IP de la máquina del Sysadmin. Esto lo hará con nmap, netdiscover… incluso con uso de ingeniería social.
El insider podría incluso forzar el bloqueo de diferentes cuentas de usuarios para generar incidencias dentro de la propia compañía para obligar al Sysadmin a conectarse al DC para ver el estado de las cuentas.
En una máquina Linux hace uso de la herramienta Seth, pasando simplemente los siguientes argumentos:
● Interfaz de red a utilizar.
● IP máquina atacante.
● IP de la máquina del Sysadmin.
● IP de la máquina objetivo (DC).
https://github.com/SySS-Research/Seth
El envenenamiento a nivel de red se produce. Y además se hace un downgrade CREDSSP, se presenta un certificado falsificado, de manera que el Sysadmin introducirá sus credenciales y aceptará el certificado (el emisor es aparentemente el propio DC):
En el momento en el que el Sysadmin lo acepta, el atacante obtiene las credenciales en texto… En ese punto se deberían analizar todos los detalles del certificado para poder verificarlo pero… ¿Algún Sysadmin lo hace?
Y ahora ya solo queda buscar el momento oportuno para hacer magia con el propio RDP u otras herramientas tipo CrackMapExec, PStools… Aquí la imaginación es libre.
Las conclusiones
Hay que destacar la importancia de conocer las diferentes opciones de bastionado de sistemas y seguridad que ofrece Windows.
Cuando una opción nos habla acerca de autenticación, cifrado… antes de deshabilitarla sin pensar debemos investigar las implicaciones y analizar los posibles riesgos. En el caso de RDP, sin ir más lejos, son muchos.
Las actualizaciones que el fabricante ofrece o las configuraciones de seguridad predeterminadas representan otra variable importante a tener en cuenta. Al igual que no usar protocolos o características de los mismos que sean obsoletas, como es el caso de RDP.
Contar con personal implicado y dedicado al bastionado de sistemas como tarea continua ofrece la posibilidad de disponer de implementaciones seguras. Un activo muy valioso dentro de los servicios de ciberseguridad.
También la capacidad de detectar configuraciones inseguras o erróneas. Dotando a la compañía de sistemas más seguros y confiables, evitando amenazas presentes y futuras.
Pero lo peor que puede pasar en una compañía es tener Sysadmins conformistas.
Profesionales que solo se preocupen de que las cosas funcionen. Pero que en realidad no saben cómo funcionan. Profesionales que, en su día a día, hacen suyo aquel dicho del sabio:
¿Qué es peor, la ignorancia o el desconocimiento?
Juzguen ustedes.
Descubre nuestro trabajo y nuestros servicios de ciberseguridad y nuestros servicios de bastionado de sistemas