Muchas eran las quejas de los usuarios sobre UAC (User Account Control) cuando fue introducido por Microsoft en Windows Vista, pero lo cierto es que desde que se rebajó el nivel de seguridad en Windows 7, Windows 8, Windows 8.1 y Windows 10, son constantes las pruebas de concepto de nuevas formas de utilizar la opción de autoElevate para saltarse UAC, lo que hace que sea bastante inútil en su configuración por defecto.
La semana pasada hablamos sobre una nueva forma de hacer bypass de UAC para Windows 7/8/8.1 en el que además se mostraba cómo encontrar aquellos binarios “potencialmente” débiles que encajen con las condiciones para hacer un bypass de UAC, por medio de la opción de autoElevate de la que se habla en la intro de este artículo.
Figura 2: PoC de laa nueva forma de saltarse UAC publicada la semana pasada
Hoy, como explica Enigma0x3 en su artículo sobre los AppPaths y la posibilidad de utilizarlos para hacer un bypass de UAC, Microsoft parece tener un interés renovado en este tipo de técnicas y va parcheando poco a poco. Quizá la aparición de una técnica para hacer bypass de UAC en Windows 7 publicada por Wikileaks en el famoso Vault7 ayuda a que, cada vez más, se tome en serio.
Como he mencionado en otros artículos, el proyecto UACMe proporciona una serie de métodos de bypass de UAC, algunos de los cuales no están parcheados y son aplicables en versiones como Windows 10. Hoy hablaremos de una nueva forma que ha publicado Enigma0x3 en su blog, el cual es uno de los miembros más activos en la búsqueda de este tipo de debilidades o configuraciones débiles del UAC en Windows.
Como se ha comentado en otros artículos relacionados con el bypass, como por ejemplo el de Fileless, el de wusa.exe y CompMgmtLauncher.exe o el de Ole32.dll y .NET, la tecla siempre está en la localización de los binarios firmados por Microsoft que son elevados automáticamente, gracias a la directiva autoElevate de su manifest.
Figura 5: Bypass de UAC con Fileless
En el caso del binario sdclt.exe, éste se eleva automáticamente según se indica en el manifest. Existe una diferencia, en este caso, entre el binario en Windows 10 y en Windows 7. En el caso de Windows 10, el binario se auto-eleva, pero en el caso de Windows 7 la directiva requestedExecutionLevel en el manifest se encuentra establecida como “AsInvoker”, lo que impedirá la auto-elevación cuando se inicia desde un proceso de integridad media. Esto es un dato curioso, ya que en Windows 10 sí nos funcionará.
PoC UAC Bypass con sdctl.exe
Analizando el binario se ve como sdclt.exe utiliza una ventana de panel de control para embeberse. En otras palabras, ejecuta un fichero llamado control.exe. ¿De dónde saca la ruta de este binario? La ruta la obtiene del registro, por lo que monitorizando las acciones que se realizan en el registro de Windows se puede encontrar una operación deseada para nosotros ya que la clave:
Visto esto, ¿qué ocurre si nosotros escribimos un valor modificado por nosotros en esa clave del registro? Lo más probable es que podamos invocar un binario y viendo que sdclt.exe está siendo ejecutado un nivel de integridad algo ya tendremos el bypass de UAC.
Las llamadas a HKCU que genera un proceso ejecutado en un contexto de alta integridad son especialmente interesantes. Cuando un proceso elevado está interactuando con la rama HKCU de un usuario, puede fallar en cualquier instante, dando la posibilidad de que el proceso ejecute cualquier cosa, dando lugar a la ejecución en un contexto privilegiado.
En el caso de sdclt.exe, éste busca la ruta de la aplicación de control.exe en la rama HKCU. Si nosotros escribimos la ruta que no se encuentra y, por ejemplo, ponemos la siguiente ruta:
Según se explica en Enigma0x3 y se puede comprobar hay que tener en cuenta que esta técnica no permite parámetros, lo cual significa que para ejecutar código arbitrario debemos situar un binario en disco, lo cual hace más fácil que un antivirus detecte este tipo de técnicas. Enigma0x3 ha colgado en su Github un script que simplifica el proceso y enseña cómo aprovecharse de esta técnica.
En la imagen superior, se puede ver como conseguimos un interfaz de comendos cmd.exe con privilegio o ejecutada en un contexto de integridad alto. Podemos escribir un fichero en C:\ que solo está permitido a este tipo de procesos. En el vídeo siguiente se puede ver la prueba de concepto funcionando completamente.
¿Cómo remediar los bypasses de UAC? Existen diferentes formas, pero una principal es fortificar el sistema Microsoft Widndows y establecer el nivel de UAC en “Siempre notificar”, cuando se intente ejecutar un proceso en un contexto de integridad alto que requiera los permisos de administración. De esta forma, el usuario o víctima se dará cuenta, ya que el UAC siempre notificará y ningún binario será auto-elevado. En resumen, una nueva técnica que aporta otra forma de lograr ejecutar con privilegio en un entorno Windows.
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: Windows 10 (Otro) bypass (más) de UAC usando AppPaths y SDCTL.EXE |
La semana pasada hablamos sobre una nueva forma de hacer bypass de UAC para Windows 7/8/8.1 en el que además se mostraba cómo encontrar aquellos binarios “potencialmente” débiles que encajen con las condiciones para hacer un bypass de UAC, por medio de la opción de autoElevate de la que se habla en la intro de este artículo.
Figura 2: PoC de laa nueva forma de saltarse UAC publicada la semana pasada
Hoy, como explica Enigma0x3 en su artículo sobre los AppPaths y la posibilidad de utilizarlos para hacer un bypass de UAC, Microsoft parece tener un interés renovado en este tipo de técnicas y va parcheando poco a poco. Quizá la aparición de una técnica para hacer bypass de UAC en Windows 7 publicada por Wikileaks en el famoso Vault7 ayuda a que, cada vez más, se tome en serio.
 |
| Figura 3: Bypass de UAC en Windows 7 publicado en Vault7 |
Como he mencionado en otros artículos, el proyecto UACMe proporciona una serie de métodos de bypass de UAC, algunos de los cuales no están parcheados y son aplicables en versiones como Windows 10. Hoy hablaremos de una nueva forma que ha publicado Enigma0x3 en su blog, el cual es uno de los miembros más activos en la búsqueda de este tipo de debilidades o configuraciones débiles del UAC en Windows.
 |
| Figura 4: La configuración Modo Windows Vista es segura a estos ataques |
Como se ha comentado en otros artículos relacionados con el bypass, como por ejemplo el de Fileless, el de wusa.exe y CompMgmtLauncher.exe o el de Ole32.dll y .NET, la tecla siempre está en la localización de los binarios firmados por Microsoft que son elevados automáticamente, gracias a la directiva autoElevate de su manifest.
Figura 5: Bypass de UAC con Fileless
En el caso del binario sdclt.exe, éste se eleva automáticamente según se indica en el manifest. Existe una diferencia, en este caso, entre el binario en Windows 10 y en Windows 7. En el caso de Windows 10, el binario se auto-eleva, pero en el caso de Windows 7 la directiva requestedExecutionLevel en el manifest se encuentra establecida como “AsInvoker”, lo que impedirá la auto-elevación cuando se inicia desde un proceso de integridad media. Esto es un dato curioso, ya que en Windows 10 sí nos funcionará.
PoC UAC Bypass con sdctl.exe
Analizando el binario se ve como sdclt.exe utiliza una ventana de panel de control para embeberse. En otras palabras, ejecuta un fichero llamado control.exe. ¿De dónde saca la ruta de este binario? La ruta la obtiene del registro, por lo que monitorizando las acciones que se realizan en el registro de Windows se puede encontrar una operación deseada para nosotros ya que la clave:
HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe... devuelve un Name Not Found. Esto quiere decir que busca la ruta de control.exe en esta ruta, pero no la encuentra, por lo que la busca en otra ubicación.
 |
| Figura 6: Name Not Found en la invocación de control.exe |
Visto esto, ¿qué ocurre si nosotros escribimos un valor modificado por nosotros en esa clave del registro? Lo más probable es que podamos invocar un binario y viendo que sdclt.exe está siendo ejecutado un nivel de integridad algo ya tendremos el bypass de UAC.
Las llamadas a HKCU que genera un proceso ejecutado en un contexto de alta integridad son especialmente interesantes. Cuando un proceso elevado está interactuando con la rama HKCU de un usuario, puede fallar en cualquier instante, dando la posibilidad de que el proceso ejecute cualquier cosa, dando lugar a la ejecución en un contexto privilegiado.
 |
| Figura 7: Consiguiendo una consola con nivel de integridad alto |
En el caso de sdclt.exe, éste busca la ruta de la aplicación de control.exe en la rama HKCU. Si nosotros escribimos la ruta que no se encuentra y, por ejemplo, ponemos la siguiente ruta:
“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”...en el valor de la clave, obtendríamos una Powershell ejecutándose en un contexto de integridad alta, por lo que tendríamos el bypass.
 |
| Figura 8: Script de Enigma0x3 para simplificar el proceso |
Según se explica en Enigma0x3 y se puede comprobar hay que tener en cuenta que esta técnica no permite parámetros, lo cual significa que para ejecutar código arbitrario debemos situar un binario en disco, lo cual hace más fácil que un antivirus detecte este tipo de técnicas. Enigma0x3 ha colgado en su Github un script que simplifica el proceso y enseña cómo aprovecharse de esta técnica.
 |
| Figura 9: Sesión elevada tras explotación del bypass de UAC |
En la imagen superior, se puede ver como conseguimos un interfaz de comendos cmd.exe con privilegio o ejecutada en un contexto de integridad alto. Podemos escribir un fichero en C:\ que solo está permitido a este tipo de procesos. En el vídeo siguiente se puede ver la prueba de concepto funcionando completamente.
Figura 10: PoC de bypass de UAC usando AppPaths y sdctl.exe
¿Cómo remediar los bypasses de UAC? Existen diferentes formas, pero una principal es fortificar el sistema Microsoft Widndows y establecer el nivel de UAC en “Siempre notificar”, cuando se intente ejecutar un proceso en un contexto de integridad alto que requiera los permisos de administración. De esta forma, el usuario o víctima se dará cuenta, ya que el UAC siempre notificará y ningún binario será auto-elevado. En resumen, una nueva técnica que aporta otra forma de lograr ejecutar con privilegio en un entorno Windows.
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
No hay comentarios:
Publicar un comentario