Cómo construir un módulo para uac-a-mola framework

Ya hemos hablado con anterioridad sobre "uac-a-mola framework" para explicaros que es un entorno que permite investigar, detectar, explotar y mitigar bypasses de UAC. Hoy quería mostraros cómo de fácil es construir un módulo para uac-a-mola, y como veréis es realmente sencillo. Antes de empezar, quería hablar de la experiencia Black Hat Europe de 2017, en la Arsenal, que vivimos con la herramienta y las buenas sensaciones que nos dejaron.

Figura 1: Cómo construir un módulo para uac-a-mola framework

Fue emocionante ver presentando sus herramientas, y sus versiones, a la gente de Dradis Framework, ModSecurity 3.0.0, Reflector extensión de Burp Suite, DET y su Data Exfiltation Toolkit, Tinfoleak, Exploit Pack, OWASP ZAP, Datasploit, XSSER o Patrick Wardle con su Objective-See’s Mac Security Tools, entre otros muchos. Fue para mi compañero Santiago y yo, un verdadero honor compartir sitio con tanta herramienta mítica y con tanto investigador. Allí estábamos nosotros, sin dejar en el olvido a nuestro compañero Álvaro Nuñez-Romero y el DirtyPi.

Figura 2: uac-a-mola en el GitHub de ElevenPaths

Hoy, empiezo el año hablando mostrando cómo de fácil es construir un módulo para uac-a-mola, ya que es una de las cosas que más llamaron la atención. Esto, junto a la posibilidad real que ofrece uac-a-mola de mitigar un bypass y las diferentes herramientas que se tienen a mano para poder investigar nuevos bypasses.

Template: Construye tu propio módulo

Para crear un módulo, ya sea orientado a la investigación, a la detección y explotación o a la mitigación se puede partir de una plantilla que tiene el siguiente aspecto:

• Una sección orientada a la importación de módulos. Se utilizará from module import Module, al menos. Todo lo que sea necesario importar irá en la parte superior. Nosotros también hemos utilizado diferentes comentarios en la parte superior del módulo, para que cualquiera de un simple vistazo puede conocer sobre el módulo. 

• La clase comienza en “class CustomModule(Module):”. La clase tendrá un constructor y un método run_module. Hay que decir que luego cada uno puede implementar más métodos complementarios, pero al menos tendremos el constructor y el método run_module. El método run_module será invocado cuando el usuario ejecuta el comando “run” desde la consola de uac-a-mola.

• Dentro del módulo podremos hacer uso de un diccionario dónde se almacenan las opciones que el usuario ha ido configurando en el módulo. En este caso, a través de “self.args”.

• En el constructor se inicializa el módulo y se rellenan dos estructuras: information y options. La primera es simplemente administrativa, rellenando información que será mostrado cuando se ejecute el comando “show” en uac-a-mola. Es decir, meteremos información como el autor, el nombre del módulo o la descripción. La segunda es una estructura ya que iremos añadiendo los diferentes atributos u opciones de los que constará el módulo, es decir, las opciones que definirán el propio módulo.

Figura 3:  Plantilla de un módulo de uac-a-mola

Antes de continuar, os dejo una imagen sobre el código del constructor, el cual será muy similar en cualquier módulo que vosotros os animéis a realizar.

Figura 4: Constructor del módulo 

Como se puede ver, la estructura information es un diccionario sencillo. Por otro lado, la estructura options es un diccionario, el cual tiene una explicación un poco más extensa. La key es el nombre del atributo como se puede ver, por ejemplo, en el caso de binary en la imagen anterior. La palabra binary es una opción que será configurable por el usuario a través del comando “set binary”. El valor de la clave es una lista con tres elementos:

• El primer elemento de la lista indica el valor por defecto del atributo. 

• El segundo elemento de la lista indica la descripción del atributo. 

• El tercer elemento de la lista indica si el atributo es obligatorio o no.

Ahora hablaré sobre el método run_module, el cual implementa las acciones que queremos que haga el módulo. En este caso, vamos a ejemplificar con un módulo de tipo de explotación o de bypass de UAC. Si estuviéramos en el caso de la mitigación las acciones serían desde el punto de vista de la fortificación, lógicamente.

Una de las acciones que deberemos llevar a cabo al comenzar la implementación, y que es muy recomendable, es el uso de variables locales para las opciones introducidas por el usuario. Por ello, utilizaremos el diccionario de opciones a través de self.args, como se puede ver en la imagen.

Figura 5: Declaración de variables locales con self.args

En el código anterior, también se puede ver cómo, mediante el uso de self, estamos invocando otros métodos que son del módulo que estamos creando.

Figura 6: Métodos creados en el módulo

Como he dicho anteriormente, se pueden crear otros métodos para hacer más limpio el código del módulo y simplificar su lectura por parte de otros usuarios.

¿Qué hace el módulo?

El módulo que hemos ido mostrando tiene una finalidad y es utilizar un DLL Hijacking a través de la aplicación wusa.exe para conseguir el bypass de UAC, por ejemplo, el de WinSxS, aunque sería extensible, de forma sencilla, a otros bypasses de UAC basados en DLL Hijacking. El módulo, en primera instancia, recoge los valores configurados por el usuario para, posteriormente, comenzar con el algoritmo para este bypass:

1. Crea una estructura de carpetas que contienen la DLL maliciosa. Esta estructura será la que se almacene en c:\windows\system32. Por ejemplo, se puede utilizar con el binario compmgmtlauncher.exe, por lo que la estructura de carpetas quedaría algo similar a compmgmtlauncher.exe.Local\x86_microsoft.windows.common-controls_[ID…]\[nombre de la DLL].

2. El segundo paso ya tiene que ver con la creación del fichero CAB. Este fichero es necesario, como se explica en el artículo dedicado a ello, porque la aplicación wusa.exe extrae la información y la copia en rutas protegidas desde ficheros CAB. Se crea el fichero DDF para generar el fichero CAB, con la información necesaria dentro del fichero DDF. 

3. Se utiliza el método make_cab para generar el fichero CAB.

4. Se utiliza el método run_wusa para ejecutar a wusa.exe y llevar a cabo la extracción de las carpetas contenidas en el fichero CAB y alojarlas en \Windows\System32. 5. Se eliminan los ficheros temporales utilizados para llevar a cabo el bypass.

A continuación, os dejamos un video de ejemplo, para que podáis ver lo fácil del proceso con uac-a-mola y cómo hacerlo manualmente a través, por ejemplo, de un script de Powershell.


Figura 7: Vídeo ejemplo
También, queríamos dejaros el paper de uac-a-mola framework para que podáis entender mejor todo lo que tiene el framework y las posibilidades que éste ofrece.

Figura 8: UAC Bypass & Research with UAC-A-Mola

Por último, queríamos dejaros el video del Cybercamp 2017 dónde se habló de uac-a-mola framework.


Figura 9: Conferencia en CyberCamp 2017 sobre UAC-a-Mola

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y Hacking Windows, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths