viernes, 8 de diciembre de 2017

RDP Hijacking Passwordless para Windows

Compartir este artículo:
Esta técnica no es nueva, pero está de actualidad, quizá porque no había tenido todo el foco que en estas últimas semanas ha tenido por Internet. Allá por el año 2011, el genial investigador @gentilkiwi había encontrado la posibilidad de hacer un secuestro de sesión en RDP. Para algunos es una característica de Windows y no una vulnerabilidad. ¿En qué consiste esto? Esto es un trick que permite el secuestro de una sesión sin tener las credenciales. Esto se puede inferir de los trabajos de Benjamin Delpy en 2011 y de Alexander Korznikov en marzo de este año.

Si se ejecuta el binario tscon.exe como usuario SYSTEM, se puede conectar a cualquier otra sesión que haya en el equipo ejecutándose y sin hacer uso de la contraseña. No se pide, sencillamente se conecta con el escritorio en curso de dicho usuario. Sabemos que, si eres SYSTEM tienes el control total, pero la obtención de cierta información podría ser más larga que accediendo a través de tscon.exe a la sesión adecuada.

Además, hay que tener en cuenta que utilizar esta técnica podría hacernos pasar muy inadvertido, incluso en el lateral movement. Incluso, podemos conectarnos a sesiones desconectadas, es decir, usuarios que hace un tiempo, incluso días, dejaron de estar en el servidor. También se desbloquean sesiones, lo cual es realmente interesante.

¿Cómo conseguimos esto?

En la práctica es sencillo, incluso demasiado. Con el comando query podemos comprobar las sesiones abiertas en el equipo. Siempre que seamos SYSTEM, por ejemplo, lanzando el exploit contra Win32k.sys y el MS16-135 del que hablamos la semana pasada podemos aprovecharnos de este trick. Simplemente, tenemos que indicar el identificador de la sesión y el nombre de la sesión sobre la que lo utilizaremos. Hay que decir que la técnica nos funcionará hasta en Windows 10 y Windows Server 2016, lo cual hace que estemos ante una especie de Sticky Keys remoto que nos permite entrar a las sesiones.


En la imagen se puede ver como hay dos sesiones activas sobre una máquina Windows 10. Ocurriría de forma similar en un servidor, salvo que, posiblemente, serían sesiones de escritorio remoto. De esa imagen, tenemos que tener clara dos cosas, una el identificador que queremos utilizar y la segunda el nombre de la sesión con la que se quiere acceder. Al final estaremos accediendo a la sesión del usuario administrator a través de la sesión de nuestro usuario.


Cuando ejecutamos la instrucción tscon [ID] /dest:[Session Name] estaremos accediendo, sin necesidad de credenciales, a la sesión del ususario con ID, en este caso, 2. Es decir, accedemos al escritorio de dicho usuario y tenemos esos privilegios, pudiendo acceder a cualquier tipo de información. Una vez ejecutado, accedemos a la sesión del usuario Administrator, tal y como podemos comprobar si abrimos una cmd.


¿Cómo o dónde podemos explotarlo y/o aprovecharlo?

El investigador Kevin Beaumont ha publicado una serie de métodos para aprovechar este truco, sobre todo en la post-explotación. El primero de los métodos habla de utilizar Sticky Keys como un RDP backdoor. El método es sencillo, si tu ejecutas el Sticky Keys modificado para abrir un cmd.exe, tu logras un terminal como SYSTEM. En este momento podrías utilizar el método comentado anteriormente para lograr acceder a los escritorios de los usuarios conectados. El segundo método comentado es similar al de Sticky Keys, pero realizado con el binario Utilman.

Otro método, es escanear Internet, por ejemplo, con herramientas como Shodan en busca de servicios RDP activos y que estén backdoorizados con Sticky Keys o Utilman. Esto permitiría a cualquier usuario acceder a las posibles sesiones de los usuarios en el sistema. Imagina un Windows Server. En el Github de ztgrace podemos encontrar la herramienta sticky_keys_hunter, el cual nos permite cazar dichos servidores con Sticky Keys o Utilman.

El cuarto método es a través del módulo de Mimikatz. Como ya comenté al principio del artículo, el investigador @GentilKiwi tiene disponible en su herramienta la posibilidad de aprovecharse de este fallo.

Mitigaciones

¿Qué mitigaciones tenemos? Este truco funciona en Windows Server 2016, por lo que es bastante potente y, seguramente, difícil de tapar para Microsoft. Por esta razón, podemos apoyarnos en las políticas de grupo para forzar que los usuarios hagan log off cuando las sesiones están desconectadas, es decir, inmediatamente después de que el usuario se desconecte. Esto no es algo tan popular en los entornos IT y debemos valorarlo.

Otra medida de mitigación sería no exponer servicios RDP/RDS hacia el exterior que puedan unir el exterior con la intranet. Utilizar MFA o Multi-Factor Authentication también es algo importante. Otra opción es crear un dominio de invitados a los servidores RDP expuestos al exterior.

Como se puede ver, un truco muy sencillo y muy potente. Que lleva a grandes rasgos muchos años entre nosotros, pero que ha estado bastante “tapado”. ¿Lo utilizas en tus auditorías para llevar a cabo movimientos laterales?

No hay comentarios:

Publicar un comentario