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.
Eso sí, toma nota que para algunos este hack una característica del sistema operativo Microsoft Windows y no una vulnerabilidad, así que disfruta este artículo teniendo esto presente.
¿En qué consiste esto?
Esto es un "hack" que permite el secuestro de una sesión sin tener las credenciales. Este hack 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 necesitarse la contraseña. No se pide, sencillamente se conecta con el escritorio en curso de dicho usuario. En la charla de Terminal Hackplications tienes muchos trucos para lograr a ser SYSTEM en un Windows a través de Citrix y RDP del que se podrían robar luego las sesiones.
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 movimiento lateral. 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 hack. 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 usuario 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, y podemos comprobar que lo somos si abrimos una cmd, tal y como se puede ver en la imagen superior.
¿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. Además, se ha creado un módulo integrado con Mimikatz para sacar partido de este hack fácilmente, tal y como se ve en esta pequeña animación.
Otro método, es escanear Internet, por ejemplo, con hacking con buscadores haciendo consultas a servicios 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.
Como ya comenté al principio del artículo, el investigador @GentilKiwi tiene disponible en su herramienta la posibilidad de aprovecharse de este fallo. Además, en la reciente DefCON 24 del año pasado, hubo una conferencia sobre el mismo tema, llamada "Sticky Keys to the Kingdom" en la que los investigadores automatizaban el descubrimiento de estos servidores ya troyanizados con las Sticky Keys con su herramienta.
¿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 logoff 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?
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths
Figura 1: Cómo roboar sesiones RDP en Windows sin saber la contraseña |
Eso sí, toma nota que para algunos este hack una característica del sistema operativo Microsoft Windows y no una vulnerabilidad, así que disfruta este artículo teniendo esto presente.
¿En qué consiste esto?
Esto es un "hack" que permite el secuestro de una sesión sin tener las credenciales. Este hack 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 necesitarse la contraseña. No se pide, sencillamente se conecta con el escritorio en curso de dicho usuario. En la charla de Terminal Hackplications tienes muchos trucos para lograr a ser SYSTEM en un Windows a través de Citrix y RDP del que se podrían robar luego las sesiones.
Figura 2: Terminal Hackplications de Chema Alonso en Ekoparty 2011
¿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 hack. 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.
Figura 3: Dos sesiones abiertas en el equipo Windows 10. Una local y otra remota. |
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.
Figura 4: Siendo SYSTEM nos conectamos a la sesión con ID 2 |
Cuando ejecutamos la instrucción tscon [ID] /dest:[Session Name] estaremos accediendo, sin necesidad de credenciales, a la sesión del usuario 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.
Figura 5: Convertidos en Administrador de esa sesión |
Una vez ejecutado, accedemos a la sesión del usuario Administrator, y podemos comprobar que lo somos si abrimos una cmd, tal y como se puede ver en la imagen superior.
¿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.
Figura 6: Dejar el equipo "troyanizado" con las Sticky Keys para ser SYSTEM y robar sesiones |
El segundo método comentado es similar al de Sticky Keys, pero realizado con el binario Utilman. Además, se ha creado un módulo integrado con Mimikatz para sacar partido de este hack fácilmente, tal y como se ve en esta pequeña animación.
Figura 7: Módulo de Mimikatz para el robo de sesión RDP |
Otro método, es escanear Internet, por ejemplo, con hacking con buscadores haciendo consultas a servicios 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.
Figura 8: Código de Sticky Keys Hunter |
Como ya comenté al principio del artículo, el investigador @GentilKiwi tiene disponible en su herramienta la posibilidad de aprovecharse de este fallo. Además, en la reciente DefCON 24 del año pasado, hubo una conferencia sobre el mismo tema, llamada "Sticky Keys to the Kingdom" en la que los investigadores automatizaban el descubrimiento de estos servidores ya troyanizados con las Sticky Keys con su herramienta.
Figura 9: Denis Maldonado & Tim Mcguffin "Sticky Keys to the Kingdom" en Defcon 24
¿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 logoff 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.
Figura 10: PoC de explotación del RDP Session Hijacking Passwordless
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?
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths
Buenos días Chema,
ResponderEliminarantes de nada te adelanto que soy bastante novatillo en el tema de seguridad informática.
Te comento, instalé una maquina virtual con windows 10 para probar el escalado de privilegios como mostraba tu ultimo vídeo con PsExec -s \\localhost cmd
Lo he intentado hacer con el usuario estándar y al ejecutarlo me dice que no tengo permisos. Abro la ventana de línea de comandos como administrador y me pide credenciales de administrador.
¿que estoy haciendo mal?
Muchas gracias y un saludo.
Hola jose M.Carrillo lo que necesitas es ser administrador sino no podras al menos tener acceso al cmd en modo administrador saludos
ResponderEliminar