Aprovechando la vulnerabilidad MS15-078 + DLL Hijacking (II)

En este post vamos a cubrir qué es el DLL hijacking y cómo podemos identificar posibles aplicaciones vulnerables, con el fin de realizar un ataque de escalada de privilegios.

Los conceptos básicos son simples: cuando una aplicación carga dinámicamente una DLL sin especificar un nombre de ruta de acceso completa o ha sido compilada por los desarrolladores con una DLL que ya no está en esa carpeta, Windows intenta localizar las DLLs siguiendo una estructura de carpetas predefinidas en un orden predeterminado, que es el siguiente:

1. Directorio desde donde se inicializa la aplicación
2. Directorio (C:\Windows\System32)
3. Directorio (C:\Windows\SysWOW64)
4. Directorio de Windows (C:\Windows)
5. El directorio de trabajo actual (CWD)
6. Directorios en la variable de entorno PATH (sistema, luego usuario)

Si un atacante gana el control de uno de los directorios de las rutas de búsqueda de DLLs, como hicimos en el post anterior aprovechando la vulnerabilidad MS15-078, puede añadir una DLL maliciosa en una carpeta superior a la carpeta de donde las carga habitualmente.

Por ejemplo, imaginemos que tenemos una aplicación que no especifica las rutas completas: SecurityArtwork.exe, que se inicializa en ‘C:\Program Files\SAW\’ y carga una dll ‘blog.dll’ del directorio ‘C:\Windows\SysWOW64’. Si nosotros añadimos nuestra DLL maliciosa en ‘C:\Windows\System32’ cuando se ejecute la aplicación SecurityArtwork.exe cargará primero nuestra DLL debido que está una carpeta “por encima” de la carpeta en la que se encuentra la DLL legítima.

Nuestro objetivo es por tanto realizar DLL hijacking sobre algún servicio o aplicación que tenga privilegios de SYSTEM, para que John pueda conseguir esos privilegios que lleva deseando tanto tiempo. En nuestro caso, hemos identificado un servicio SUService.exe (IBM Notes Smart Upgrade Service) que se inicia con privilegios de SYSTEM.

Ilustración 1: Services.msc

Si vemos sus propiedades:

Ilustración 2: Propiedades del servicio

Con el fin de identificar qué DLLs carga y qué acciones realiza la aplicación, cambiaremos a nuestra cuenta de administrador para reiniciar el servicio y monitorizarlo.

Las herramientas que utilizaremos son las siguientes:

• Process Monitor.
• Process Explorer.

Lo primero que haremos será abrir Process Explorer para identificar qué DLLs son cargadas por el servicio.

Ilustración 3: Process Explorer

Lo segundo será abrir nuestro Process Monitor. Presionamos CTRL + L para modificar las reglas de filtrado y añadimos las que nos interesan.

• Process name is: SUService.exe -> #Nombre del servicio por el que queremos filtrar
• Operation is: CreateFile -> #Crea o abre archivos
• Result is: NAME NOT FOUND -> #Nos interesa que solo nos muestre los archivos que no ha encontrado

Ilustración 4: Procmon

En la siguiente ilustración, tras reiniciar el servicio SUService.exe desde services.msc, vemos que el ejecutable intenta cargar varias DLLs que no se encuentran desde la carpeta donde se ha inicializado (‘C:\Program Files (x86)\IBM\Notes\’). Entre esas DLLs que no encuentra hay una llamada UXTHEME.dll, que como imagináis es la que utilizaremos para realizar nuestro ataque de DLL hijacking.

Ilustración 5: UXTHEME.dll

En el siguiente post veremos cómo aprovechar estas dos vulnerabilidades juntas para obtener privilegios de SYSTEM desde un usuario no privilegiado.