Cuándo un Bypass de UAC en Windows es un "Bug" o una "Feature"

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.

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.

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.

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.

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. 

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:

 “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.

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.

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

Figura 15: Contactar con Pablo González

Hackear Windows 7 & 2008 R2 con Eternalblue y Doublepulsar de #ShadowBroker usando #Metasploit

El pasado viernes 14 de Abril - viernes santo en España - The Shadow Brokers publicó una gran cantidad de herramientas pertenecientes al Arsenal de la NSA. Se puede encontrar dichas herramientas en el repositorio de Github de misterch0c.

Figura 1: Hackear Windows 7 & Windows Server 2008 R2 con
ternalblue y Doublepulsar de ShadowBroker usando Metasploit

Mi compañera en ElevenPaths Sheila A. Berta (@UnaPibaGeek) publicó en Exploit-DB un paper, también con versión en inglés, en el que se explica cómo explotar la vulnerabilidad Eternalblue & Doublepulsar para obtener una Shell apoyándose en Powershell Empire para lograr, posteriormente, un Meterpreter de Metasploit. Gran trabajo, sin duda, de Sheila.

Figura 2: Explotar Eternalblue & Doublepulsar para obener una shell

de Empire/Meterpreter en Windows 7/Windows Server 2008 R2

Sheila formuló una pregunta interesante en su paper y es: ¿Por qué Eternalblue & Doublepulsar? La respuesta es sencilla, ya que entre los exploits que se publicaron, Eternalblue es el único que se puede utilizar para atacar sistemas Windows 7 y Windows Server 2008 R2 sin necesidad de autenticación. Por lo que, Eternalblue es el exploit que nos permitirá aprovecharnos de un fallo de seguridad en el protocolo SMB para que, posteriormente, Doublepulsar pueda inyectar remotamente, por ejemplo, una DLL, ya que existen otras posibilidades.

Figura 3: Lista de exploits para Windows publicados por Shadowbroker

Dichoe esto, el pasado jueves mis compañeros Sheila y Claudio Caracciolo (@holesec) me preguntaron por la posibilidad de hacer una migración del exploit Eternalblue que es utilizado en Fuzzbunch en el leak a mi querido Metasploit. El gusto por la seguridad y por la tecnología nos puede y nos pusimos de forma rápida y ágil manos a la obra en ElevenPaths.

Tras revisar paso a paso el trabajo de Sheila, empecé a hacer mis pequeñas pruebas. El pasado jueves no sabíamos bien qué cosa hacía el exploit de Eternalblue, y observando Fuzzbunch vimos que lo único que hacen es lanzar el binario contra un target concreto. No tenemos el código del exploit para poder portarlo completamente. Entonces, el plan era migrar la configuración de los binarios y la ejecución de éstos para que desde Metasploit se pudiera hacer. Manos a la obra.

FuzzBunch: Loader de binarios

Analizando FuzzBunch te das cuenta que se genera una serie de ficheros XML asociados a un proyecto en curso y que esos ficheros XML son los que tienen los parámetros y opciones con las que se lanzan los binarios, en este caso, exploits o payloads. El primer objetivo era entender bien los archivos XML, ver qué era lo necesario y poder ejecutar el binario sin utilizar FuzzBunch.

De los tres ficheros XML que se generan, acabé viendo que el importante es el de InConfig o configuración de entrada, ya que es el que el exploit lee para poder ejecutarse. En la imagen siguiente puede verse como, al lanzar el binario por sí solo, no se encuentra el fichero XML de configuración y el exploit no es lanzado. Sin embargo, cuando le ponemos el fichero XML correctamente, el binario es lanzado con la configuración indicada en el archivo de configuración InConfig.

Figura 4: Ejemplo sn y con el fichero InConfig.xml

En la siguiente imagen, se puede ver el contenido del fichero InConfig.XML para Eternalblue. En él se indican los tipos de datos, las posibilidades y los valores que tienen los atributos o variables.

Figura 5: Contenido de InConfig.XML

Analizando esto llegamos a una conclusión: Podríamos hacer un módulo de Metasploit que implemente la configuración del XML de Eternalblue, posteriormente el de Doublepulsar que será muy similar, generar una DLL con el Payload que el usuario elija en Metasploit y lanzar ambos binarios, el exploit y el paylaod.

Otro problema: ¿Windows?

Por el camino surgió otro problema, y es que el exploit Eternalblue y Doublepulsar son binarios para Windows. Le pregunté a Sheila y ella me contestó "¿Quién utiliza Metaspoit en Windows?". Con la boca chica pensé en confesar que yo algunas veces (te toca torear en pelear en el campo de batalla que te toca), pero ella estaba en lo cierto, generalmente Metasploit se utiliza en sistemas Linux. Además, nosotros queríamos hacerlo con nuestro querido Kali Linux.

La respuesta aquí no se hizo esperar, nos tocaría tirar de Wine para que el módulo de Metasploit lo utilice y pueda lanzar los binarios con sus configuraciones. Hay que tener en cuenta que para que el módulo funcione correctamente en sistemas Kali Linux tenemos que tener instalado Wine con compatibilidad para binarios de 32 bits.

Detectar víctimas vulnerables a Eternalblue

El pasado martes 17 de Abril se publicó un módulo auxiliary de Metasploit que permite detectar en una red si alguno de los equipos es vulnerable al CVE-2017-010, es decir, a Eternalblue. Decidí probar el módulo y ver un poco cómo estaba hecho y la sensación es que la liberación del código del exploit está muy cerca.

Figura 6:  Uso del modulo auxiliary (cve-2017-010) en Metasploit

Si eres un personal de IT te recomendamos que apliques los parches de seguridad para esta vulnerabilidad lo antes posible las máquinas de tu empresa o dominio, ya que es una vulnerabilidad crítica que podría ser explotada por cualquiera, al no requerir la interacción por parte del usuario, solamente disponer de conectividad con la máquina.

Nuestro módulo para Metasploit: eternalblue_doublepulsar o eternal11

La historia del nombre del módulo nos daría para otro artículo entre Sheila y yo, pero baste decir que le pusimos eternal11. El algoritmo utilizado para este caso os lo dejo aquí en un sencillo pseudocódigo:

• Disponemos de un SKELETON del fichero XML de Eternalblue. Este SKELETON contiene una serie de palabras clave, por ejemplo %RPORT%, %RHOST%, %TIMEOUT%.

Figura 7: Skeleton.XML de Eternalblue

• Cada vez que invocamos la función exploit este fichero es copiado con el nombre Eternalblue-2.2.0.xml, el cual es el que utiliza el binario para leer los valores.

• Una vez copiado el fichero con el nombre original, se sustituye en el fichero las palabras clave por los valores que el usuario introduzca en los atributos de Metasploit. Por ejemplo, si el usuario configura RHOST apuntando a la dirección 10.0.0.10, el campo %RHOST% del fichero XML será sustituido por la dirección IP real. Así ocurre con todos los campos. 

• Ocurre igual con el XML de Doublepulsar. Tenemos un SKELETON dónde se irán sustituyendo los valores, en este caso los valores personalizables son: %RHOST%, %RPORT%, %TIMEOUT%, %TARGETARCHITECTURE%, %DLLPAY%, %PROCESSINJECT%. 

• A continuación, se genera una DLL con el Payload que se haya setteado con Set PAYLOAD. La DLL se almacenará dónde se indique en el atributo PathDLLInjection del módulo. 

• Después, se lanzan los binarios: primero Eternalblue y después Doublepulsar.

El módulo desarrollado tiene las siguientes opciones avanzadas:

• TargetArchitecture: Podrá elegirse entre x86 y x64. Le indica a Doublepulsar la arquitectura dónde inyectará la DLL. 

• PathEternalBlue: Indica la ruta dónde se encuentra el binario de Eternalblue. Hay que recordar que el sistema, si estamos en Linux, debe contar con Wine. Por otro lado, hay que tener cuidado con las dependencias que tiene el binario, librerías en x86 o x64, tienen que ser accesibles por el binario, y por Wine en el caso de Linux. 

• PathDoublePulsar: Indica la ruta dónde se encuentra el binario de Doublepulsar. 

• PathDLLInjection: Indica la ruta dónde se almacenará la DLL. Además, este path se incluirá en el XML de Doublepulsar para que el binario sepa de dónde cargarla. • NameDLL. Nombre que se le dará a la DLL. Por defecto es eternal11.dll. 

• ProcessInject: Proceso en el que se hará la inyección de la DLL.

Y por fin, cuando lancemos el módulo contra un sistema vulnerable al CVE-2017-010 de Windows 7 o Windows Server 2008R2 veremos algo parecido a esto que podéis ver en la imagen siguiente.

Figura 8: Explotación con éxito del módulo de eternal11 sobre un Windows vulnerable

Ha sido divertido pasar unas horas locas trabajando en esto e intentando hacer un módulo que pueda ayudar a auditar los sistemas Microsoft dónde Eternalblue sigue presente. En el siguiente vídeo tienes una demostración de este módulo funcionando.

Figura 9: PoC de explotación de Eternalblue y Doublepulsar con Metasploit

Y también la tienes disponible la PoC para los equipos Windows 7 y Windows Server 2008 R2 en versiones x64, que también funciona, como podéis ver en este vídeo.

Figura 10: PoC de explotación de Eternalblue y Doublepulsar con Metasploit
sobre Windows 7 y Windows Server 2008 R2 en versiones x64.

Actualiza lo antes posible todos tus sistemas Microsoft Windows vulnerables y protégete de las amenazas que han surgido con este leak de exploits. Quiero agradecer el trabajo de mi compañera Sheila A. Berta y como viene en la descripción del módulo:

“** THIS IS AN INTEGRATION OF THE ORIGINAL EXPLOIT, IT'S NOT THE FULL PORTATION**”

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