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.
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.
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.
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.
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.
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)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”
 |
| Figura 1: Cómos saltarse UAC en Windows 7 & 10 usando WinSxS |
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.
 |
| Figura 3: Opción de Autoelevate a true en el binario wusa.exe |
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)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”
Me imagino que teniendo dos cuentas: una admin y otra con usuario sin privilegios, y usando esta última de forma habitual, se evita este problema, no?
ResponderEliminarSaludos.
Este comentario ha sido eliminado por el autor.
ResponderEliminarA sì es
ResponderEliminarPero un se puede saltar UAC desde algunas reglas creo o no?
ResponderEliminar