El artículo de hoy lo escribo por algunas razones, las cuales comentaré en breve. El punto para reflexionar es: ¿Qué es un bypass de UAC? Para muchos una técnica desprestigiada en un Ethical Hacking, para otros una vía a tener en cuenta en la obtención de privilegios o la obtención de una shell en un nivel de integridad alto de Windows. Puedo equivocarme en lo que comente en este artículo o puede que tengas otra visión, pero vamos a ir viendo y matizando ciertos aspectos que cubren a esta técnica.
 |
| Figura 1: Cuando un Bypass de UAC en Windows es un "Bug" o una "Feature" |
Lo primero, y seguramente más importante, ¿Es una vulnerabilidad? Para Microsoft no es una vulnerabilidad, es una opción de configuración. Y, técnicamente, es cierto. Es decir, si cambias la configuración por defecto del UAC, la inmensa mayoría de los bypasses conocidos dejan de funcionar. El mecanismo de UAC funciona, solo que depende de su configuración.
 |
| Figura 2: Máxima Seguridad en Windows Gold Edition |
Por supuesto, si lo que quieres es aplicar Máxima Seguridad a tu Windows, esto es algo que se aplica en primer paso. Es decir, quitar la configuración por defecto y aplicar la que exige a todos los binarios la confirmación UAC, y no permite el autoelevado. Vamos un poco más allá para entenderlo. ¿Cómo nos protegemos de los bypasses de UAC? Vamos primero a ver la GPO, para lo que buscamos:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
Ahí encontraremos uno de los motivos por los que los bypasses de UAC funcionan. Como se puede ver en la imagen, se pedirá consentimiento, por parte del UAC, solo a los procesos que no sean binarios de Windows. Realmente, hay un mayor detalle en esto que comentaré a continuación.
Aparte de ser un "binario de Windows", que esto no es más que se encuentre firmado por Microsoft, éste debe ser además un binario con una directiva en el Manifest con "Auto-Elevate" con valor "True". Es decir, le están diciendo al sistema que el binario, aparte de estar firmado por Microsoft, éste tiene una especie de "carnet especial" o "pase especial" y que no debe rendir cuentas al UAC.
 |
| Figura 3: Política para UAC para los binarios que no son de Windows |
Aparte de ser un "binario de Windows", que esto no es más que se encuentre firmado por Microsoft, éste debe ser además un binario con una directiva en el Manifest con "Auto-Elevate" con valor "True". Es decir, le están diciendo al sistema que el binario, aparte de estar firmado por Microsoft, éste tiene una especie de "carnet especial" o "pase especial" y que no debe rendir cuentas al UAC.
Por último, otra de las comprobaciones que hace el sistema es que el binario se esté ejecutando en una ruta "privilegiada", por ejemplo, System32. Si recordamos el bypass de UAC de Mocking Directory Trusted, gracias a un fallo de interpretación de una de las APIs internas del sistema se podía "saltar" esta protección.
Desde el punto de vista del pentesting tenemos que tener en cuenta algunas cosas también. Lo que parece más lógico, pero que a veces la gente puede no entender bien es que, para pasar a un nivel de integridad alto, debes de estar en otro nivel de integridad, inferior se entiende.
 |
| Figura 4: Libro de Hacking Windows |
Desde el punto de vista del pentesting tenemos que tener en cuenta algunas cosas también. Lo que parece más lógico, pero que a veces la gente puede no entender bien es que, para pasar a un nivel de integridad alto, debes de estar en otro nivel de integridad, inferior se entiende.
En el caso de un bypass de UAC debes partir desde un nivel de integridad medio. Por esta razón, el módulo de Metasploit, cuando se hace cualquier bypass de UAC de forma automática, nos muestra los diferentes chequeos, entre ellos el nivel de integridad actual.
Como se puede observar, una de las cosas que se chequean es el nivel de integridad. Si estuviéramos en un nivel de integridad alto y no nos hubiéramos dado cuenta, sería una cosa muy extraña, porque demostraríamos no tener el control de lo que hacemos, pues ya estaríamos "elevados", por lo que no tendría sentido realizar esta operación. Puede que nuestro proceso no se encuentre en un nivel de integridad medio y estemos más abajo, tendremos problemas también. Debemos entender por qué estamos y debemos estar en este nivel de integridad.
Esto va relacionado con el tipo de usuario que debemos ser. Solo podemos ser un usuario que forme parte del grupo administradores, pero que no esté ejecutando el proceso como administrador. Esto es importante. Es otra cosa que a veces no queda clara.
 |
| Figura 5: ByPass de UAC en Metasploit |
Como se puede observar, una de las cosas que se chequean es el nivel de integridad. Si estuviéramos en un nivel de integridad alto y no nos hubiéramos dado cuenta, sería una cosa muy extraña, porque demostraríamos no tener el control de lo que hacemos, pues ya estaríamos "elevados", por lo que no tendría sentido realizar esta operación. Puede que nuestro proceso no se encuentre en un nivel de integridad medio y estemos más abajo, tendremos problemas también. Debemos entender por qué estamos y debemos estar en este nivel de integridad.
Esto va relacionado con el tipo de usuario que debemos ser. Solo podemos ser un usuario que forme parte del grupo administradores, pero que no esté ejecutando el proceso como administrador. Esto es importante. Es otra cosa que a veces no queda clara.
 |
| Figura 6: Metasploit para Pentesters Gold Edition |
Necesitamos que un usuario que tiene privilegios para realizar acciones como administrador, haya ejecutado un proceso y que no haya hecho uso de dichos privilegios para, una vez comprometido su proceso, podamos aprovechar este hecho y hacer el bypass de UAC. Puede ser lioso, pero es lógico. Si el usuario hubiera lanzado el proceso como administrador, el nivel de integridad ya sería alto, no medio.
Como se veía en la imagen anterior, el módulo de Metasploit comprueba si el usuario al que pertenece el proceso comprometido es o no es del grupo administradores. Si no es del grupo administradores, ¿Qué ocurre? Es sencillo, la política de comportamiento del UAC asociada es diferente. Tal y como se puede ver en la imagen, la acción por defecto para un usuario que no pertenece al grupo administradores es que el UAC pida credenciales.
Windows Vista, en el comienzo de la historia del UAC, utilizaba un comportamiento más estricto, pedía confirmación (Sí o No) para los administradores, independientemente de si el binario estuviera o no firmado por Microsoft o si tenía o no Auto-Elevate.
Como se veía en la imagen anterior, el módulo de Metasploit comprueba si el usuario al que pertenece el proceso comprometido es o no es del grupo administradores. Si no es del grupo administradores, ¿Qué ocurre? Es sencillo, la política de comportamiento del UAC asociada es diferente. Tal y como se puede ver en la imagen, la acción por defecto para un usuario que no pertenece al grupo administradores es que el UAC pida credenciales.
 |
| Figura 7: Selección de opción de pedir credenciales |
Windows Vista, en el comienzo de la historia del UAC, utilizaba un comportamiento más estricto, pedía confirmación (Sí o No) para los administradores, independientemente de si el binario estuviera o no firmado por Microsoft o si tenía o no Auto-Elevate.
Figura 8: Configuraciones de los Modos UAC en Windows 7¿Era más seguro? A priori, y basándonos en este artículo, sí. Pero las quejas llegaron. Los usuarios no estaban preparados para ello y se rebajaron algunas configuraciones. Esto fue en Windows 7, si no recuerdo mal, que puedo recordarlo mal.
Y un bypass de UAC entonces, ¿dónde tiene sentido?
Yo siempre digo en las clases o en los cursos/talleres que un bypass de UAC se enseña en local, pero su aplicación tiene sentido en remoto. Es decir, por motivos de divulgación y educación se puede enseñar en local todo el proceso de lo que ocurre, no solo quedaros con se lanza un módulo de Metasploit y listo, eso es la automatización y está bien, una vez que se conoce qué ocurre por detrás.
Y un bypass de UAC entonces, ¿dónde tiene sentido?
Yo siempre digo en las clases o en los cursos/talleres que un bypass de UAC se enseña en local, pero su aplicación tiene sentido en remoto. Es decir, por motivos de divulgación y educación se puede enseñar en local todo el proceso de lo que ocurre, no solo quedaros con se lanza un módulo de Metasploit y listo, eso es la automatización y está bien, una vez que se conoce qué ocurre por detrás.
Miramos con ProcMon y Proccess Explorer lo que ocurre, se estudian diferentes técnicas: Environment Injection, DLL Hijacking, Fileless… O jugamos con nuestro querido UAC-A-Mola y vemos qué cosas se pueden hacer.
Figura 9: UAC-a-Mola: Bypassing UAC using Fileless techniques
Pero a la hora de poner en práctica o de utilizar en un Ethical Hacking solo tiene sentido en remoto, porque si tienes un usuario que cumple los requisitos del bypass de UAC y tienes acceso físico te vale ejecutar:
Figura 9: UAC-a-Mola: Bypassing UAC using Fileless techniques
Pero a la hora de poner en práctica o de utilizar en un Ethical Hacking solo tiene sentido en remoto, porque si tienes un usuario que cumple los requisitos del bypass de UAC y tienes acceso físico te vale ejecutar:
"botón derecho -> Ejecutar como administrador"
Bien, pero ¿cómo hacemos eso en remoto? Es complejo. Vamos a tener una shell remota con la que podemos ver fácilmente si tenemos la posibilidad de utilizar técnicas de bypass de UAC y si estamos en ese caso, ¿cómo se aplican? ¿Ejecutas botón derecho -> admin? No. No puedes. Aquí es dónde tiene todo el sentido del mundo las técnicas de bypass de UAC.
Desde una shell invocarás a un binario que cumple las tres necesidades comentadas anteriormente, previamente habrás preparado el camino para que la ejecución de dicho binario desemboque en que el nuevo proceso haga uso de tu código, y como ese proceso se estará ejecutando en un nivel de integridad alto, tu código también se ejecutará en el mismo nivel de integridad.
Desde una shell invocarás a un binario que cumple las tres necesidades comentadas anteriormente, previamente habrás preparado el camino para que la ejecución de dicho binario desemboque en que el nuevo proceso haga uso de tu código, y como ese proceso se estará ejecutando en un nivel de integridad alto, tu código también se ejecutará en el mismo nivel de integridad.
Ahí tenemos el bypass, porque gracias a las características del binario, el UAC dejará ejecutarlo. Y en esto se resume. Hemos hablado mucho en este blog sobre diferentes bypasses de UAC, cómo han ido evolucionando las técnicas, cómo a veces se simplificaban y ahí están los artículos
Para mí: ¿Qué no es un bypass de UAC?
Si desde la GUI de cualquier binario se puede ejecutar código, pero no se puede hacer a través de una consola, para mí no es un bypass de UAC efectivo. Puede que, técnicamente se haga un bypass de UAC, porque evitemos que se ejecute el UAC y se ejecute un código nuestro. ¿Nos aporta algo más que darle al botón derecho -> "ejecutar como administrador"? Eso es lo que nos tenemos que preguntar, es decir, ¿podremos utilizarlo?
Aquí tenemos una bifurcación: bypass de UAC efectivo para el pentesting o bypass de UAC que prueba un concepto, pero no es efectivo para el pentesting. Como ejemplo podemos utilizar algunos ejemplos con interfaces gráficas.
Técnicamente, lo que veremos ahora consigue hacer que un CMD se ejecute y no salte el UAC. Sabemos que cuando se intenta ejecutar una CMD con privilegio, el UAC saltará para confirmación del usuario o petición de credenciales en el caso de un usuario que no sea del grupo administradores. Tenemos que pensar, ¿se puede usar en un pentest? Eso es más complejo. Lo primero es utilizar un binario de los que sabemos que ejecutan en un nivel de integridad alto sin que el UAC salte, por ejemplo, el eventvwr.exe en Windows 10.
Desde aquí, todo lo que sea código que se ejecute heredará el nivel de integridad alto, por lo que podemos ir al menú "Help". La opción "Help Topics" nos muestra la ayuda del visor de eventos. Pinchando con el botón derecho en la parte donde se muestra el texto se puede ver una opción que es "View Source".
Al ejecutar "View Source" se ve un bloc de notas con un texto. Claro, si analizamos el bloc de notas con Proccess Explorer podremos ver que el notepad.exe se ejecuta en un nivel de integridad alto. Aquí ya tenemos lo que buscamos, si abrimos un cuadro de diálogo tenemos la posibilidad de ejecutar lo que se quiera.
Abrimos el cuadro de diálogo y buscamos en System32 el binario del CMD. En vez de abrirlo sobre el notepad.exe, botón derecho y abrir el cmd.exe. Ahí lo tenemos. ¿Podríamos haberlo hecho a través de una shell? Si encontramos la forma de hacer que todo esto se pueda hacer desde una línea de comandos, tendríamos, desde mi opinión, un bypass de UCA efectivo, si no, simplemente hemos demostrado o enseñado que hay código que puede ser ejecutado sin que el UAC salte, pero no termina de ser efectivo en un pentesting o en un Ethical Hacking.
En la siguiente imagen de Process Explorer se puede ver el nivel de integridad y cómo desde el mmc.exe (abierto con eventvwr.exe directamente) sin que el UAC salte, porque es un binario que cumple las condiciones comentadas anteriormente, se van abriendo diferentes procesos hasta llegar a una cmd.exe.
Para mí: ¿Qué no es un bypass de UAC?
Si desde la GUI de cualquier binario se puede ejecutar código, pero no se puede hacer a través de una consola, para mí no es un bypass de UAC efectivo. Puede que, técnicamente se haga un bypass de UAC, porque evitemos que se ejecute el UAC y se ejecute un código nuestro. ¿Nos aporta algo más que darle al botón derecho -> "ejecutar como administrador"? Eso es lo que nos tenemos que preguntar, es decir, ¿podremos utilizarlo?
Aquí tenemos una bifurcación: bypass de UAC efectivo para el pentesting o bypass de UAC que prueba un concepto, pero no es efectivo para el pentesting. Como ejemplo podemos utilizar algunos ejemplos con interfaces gráficas.
Técnicamente, lo que veremos ahora consigue hacer que un CMD se ejecute y no salte el UAC. Sabemos que cuando se intenta ejecutar una CMD con privilegio, el UAC saltará para confirmación del usuario o petición de credenciales en el caso de un usuario que no sea del grupo administradores. Tenemos que pensar, ¿se puede usar en un pentest? Eso es más complejo. Lo primero es utilizar un binario de los que sabemos que ejecutan en un nivel de integridad alto sin que el UAC salte, por ejemplo, el eventvwr.exe en Windows 10.
 |
| Figura 10: EventViewer tiene Auto-Elevate True |
Desde aquí, todo lo que sea código que se ejecute heredará el nivel de integridad alto, por lo que podemos ir al menú "Help". La opción "Help Topics" nos muestra la ayuda del visor de eventos. Pinchando con el botón derecho en la parte donde se muestra el texto se puede ver una opción que es "View Source".
 |
| Figura 11: View Source |
Al ejecutar "View Source" se ve un bloc de notas con un texto. Claro, si analizamos el bloc de notas con Proccess Explorer podremos ver que el notepad.exe se ejecuta en un nivel de integridad alto. Aquí ya tenemos lo que buscamos, si abrimos un cuadro de diálogo tenemos la posibilidad de ejecutar lo que se quiera.
 |
| Figura 12: notepad.exe con nivel de integridad alto |
Abrimos el cuadro de diálogo y buscamos en System32 el binario del CMD. En vez de abrirlo sobre el notepad.exe, botón derecho y abrir el cmd.exe. Ahí lo tenemos. ¿Podríamos haberlo hecho a través de una shell? Si encontramos la forma de hacer que todo esto se pueda hacer desde una línea de comandos, tendríamos, desde mi opinión, un bypass de UCA efectivo, si no, simplemente hemos demostrado o enseñado que hay código que puede ser ejecutado sin que el UAC salte, pero no termina de ser efectivo en un pentesting o en un Ethical Hacking.
 |
| Figura 13: CMD.exe elevado sin UAC |
En la siguiente imagen de Process Explorer se puede ver el nivel de integridad y cómo desde el mmc.exe (abierto con eventvwr.exe directamente) sin que el UAC salte, porque es un binario que cumple las condiciones comentadas anteriormente, se van abriendo diferentes procesos hasta llegar a una cmd.exe.
 |
| Figura 14: Nivel de Integridad "High" |
Vale, pero, ¿es efectivo? Cuando se lee bypass de UAC, una de las cosas que debemos valorar es efectivo o no. Generalmente, cuando hablamos de bypass de UAC entendemos que es una vía por la que se obtiene privilegios saltándonos el UAC y nunca a través de algo gráfico, porque no habría diferencia con "botón derecho -> ejecutar como admin". El debate está servido. Tú decides.
Saludos,
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", "Pentesting con Powershell" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica. 
Para consultas puedes usar el Buzón Público para contactar con Pablo González
Para consultas puedes usar el Buzón Público para contactar con Pablo González |
| Figura 15: Contactar con Pablo González |
Related links
No comments:
Post a Comment