Hace ya unos meses desde que se publicó el artículo "Qué es una DLL y en qué consiste el DLL Hijacking" en el que os hacia una introducción a la razón e la existencia de las bibliotecas de enlace dinámico y al concepto de DLL Hijacking, el ataque que tiene lugar cuando un auditor o un ciberdelincuente tienen la capacidad de suplantar una de estas bibliotecas por otra con código malicioso. Después de explicar los conceptos a nivel teórico se publicaron otros dos artículos más sobre el tema: "Identificando programas vulnerables con Process Monitor" y "Cómo explotar una vulnerabilidad de DLL Hijacking en Slack".

En el primero de ellos hablaba sobre cómo analizar programas para dar con DLLs que no son encontradas en las carpetas donde el programa las busca, lo que podría dar lugar a un caso de DLL Hijacking si se disponía de permisos en dichos directorios para depositar la DLL maliciosa. En el segundo artículo pasábamos a la acción y os demostraba cómo se podría realizar el ataque haciendo uso del mecanismo DLL Proxy.

Figura 2: Máxima Seguridad en Windows Gold Edition de Sergio de los Santos en 0xWord

Hoy, dentro de las investigaciones de Hacking & Hardening en Windows, continuamos con la serie dedicada al DLL Hijacking para presentaros una herramienta que he desarrollado durante mi paso por el equipo de Ideas Locas de Telefónica y que estará disponible en GitHub como herramienta Open Source, por lo que os animo a probarla y colaborar para hacerla mayor y mejor.

Adventure of Dinamyc Link Library (aDLL)

aDLL nació de la idea de automatizar todo el proceso de búsqueda de las DLL que importa un programa para saber cuáles de todas ellas pueden dar lugar a un ataque de DLL Hijacking. Algo así como lo que se hace habitualmente con Procmon pero a través de terminal y con la posibilidad de analizar de golpe varios ejecutables. Para detectar DLL candidatas a un caso de DLL Hijacking simple lo primero que se necesita conocer es cuáles son las DLL que cargará el programa que estamos analizando. Si recordamos las formas que tiene un programa para cargar una DLL sabemos que existen tres formas principales: en load-time, en run-time y mediante delay-load. 

La vinculación de DLL en load-time y delay-load es llevada a cabo por el Linker y las DLL en run-time por llamadas a las funciones LoadLibrary / LoadLibraryEx durante la ejecución de un programa. En el esquema anterior se muestra el funcionamiento general de aDLL para “extraer” todas las DLL que un programa intenta cargar en memoria.

DLL Implícitas y formato PE

A las DLL importadas por el Linker las llamamos de Vinculación Implícita y pueden encontrarse en la información almacenada por el propio binario. Como el objetivo de este artículo no es hacer una descripción del formato PE32/PE32+ que es el que tienen hoy en día los archivos del tipo Portable Ejecutable (PE) de Windows como son los ejecutables y las DLL. Basta con saber que la estructura que tiene un binario ya compilado está estandarizada de forma que esos bytes que forman el binario están organizados en secciones que contienen toda la información que el loader de Windows necesita para ejecutar ese binario correctamente.

Utilizando un lenguaje de bajo nivel como C/C++ podemos cargar un ejecutable como imagen en la memoria, es decir, como un mapa de bits. Con la imagen cargada en memoria se pueden recorrer los bytes mediante punteros (la dirección de la memoria de esos bytes) extrayendo y analizando la información que nos interese. Para calcular con exactitud la dirección de la memoria a la que queremos acceder se debe conocer muy bien cómo está organizado el formato PE y las estructuras de datos que lo forman.

Figura 4: Hacking Windows: "Ataques a sistemas y redes Microsoft" de Pablo González, Carlos García y Valentín Martín.

aDLL carga la imagen del binario en memoria y busca directamente en la IMPORT TABLE del binario para extraer los nombres de las DLL que se cargaran en load-time y en la DELAY IMPORT NAME TABLE para extraer los nombres de las delay-load DLLs. Una vez “extraídos” los nombres de éstas DLL se almacenan en un buffer para su posterior análisis.

DLL explícitas y Microsoft Detours

Microsoft Detours es una biblioteca diseñada para interceptar llamadas de un programa a la API win32 con la finalidad de que los programadores puedan analizar y debuggear su código. El proceso de interceptar funciones en un proceso de un programa que se está analizando se conoce como hook de una función y tiene lugar cuando se “captura” la función y se desvía el flujo de ejecución normal del programa para que podamos inyectar código antes de que esa función haga su return.

aDLL hace uso de la biblioteca Detours para extraer el nombre de las DLL cargadas por las funciones LoadLibrary, que son las que llamamos DLL de vinculación explícita. Para ello se utilizan las funciones de Detours para generar una nueva DLL con hooks a las funciones LoadLibrary y se crea un nuevo proceso del programa analizado en el que se inyecta esa DLL con los hooks. Cada vez que se “captura” una función LoadLibrary se extrae el nombre o ruta de la DLL que el programador pasó como parámetro a la función (y también las FLAGS que se hayan usado con LoadLibraryEX) y se escriben los datos extraídos en un fichero temporal que luego será leído por el proceso principal de aDLL.

Análisis de las DLL

Una vez que se ha analizado el ejecutable y se han extraído las DLL que importa, aDLL filtra todas aquellas DLL que pertenecen a la lista de Known DLLs (no se buscarán en disco y no darán lugar a un Hijacking) y, de momento, también se filtran las DLL que pertenecen al Api Set schema debido a la complejidad que supone la resolución de la redirección de estas DLL virtuales a la DLL física que contiene sus funciones, y también se filtran aquellas DLL que hacen uso del sistema side by side assembly.

Para aquellas DLL que no han sido filtradas se analizan junto a la FLAG con la que hayan sido importadas si la hubiera y se replica el mecanismo de búsqueda de Windows para conocer la ruta de los directorios donde la DLL será buscada y no encontrada. En la siguiente figura se demuestra cómo aDLL analiza un binario vulnerable a DLL Hijacking, se trata de la versión 2.0.3 de utorrent publicada en exploit-db.

Figura 5: Análisis de la versión 2.0.3 vulnerable de utorrent

Para aquellas DLL que sí son encontradas aDLL dispone de la opción “-r” para hacer una búsqueda recursiva de las dependencias que son importadas a su vez por esa DLL. Una vez se tiene una lista de DLLs no encontradas para el programa analizado, con la opción “-a” aDLL comprobará automáticamente para cada DLL en la ruta en la que no ha sido encontrada si da lugar a un Hijacking, lo que se consigue copiando una DLL maliciosa con el nombre de la DLL legítima en dicha ruta. Si la ejecución de la DLL maliciosa tiene lugar se generará un fichero temporal y aDLL comprobará la creación de ese fichero como demostración de que el Hijacking ha tenido éxito.

Figura 6: Test automático de Hijacking

En los vídeos aparecen distintos casos de uso de la herramienta, cómo el análisis de múltiples ejecutables y un ejemplo de análisis automático en utorrent en el que se selecciona una DLL cuyo payload genera una reverse shell de Meterpreter.

Figura 7: PoC lista de DLLs implícitas en un binario de Windows

Figura 8: PoC análisis de DLLs candidatas a ser vulnerables a DLL Hijacking con addl

Espero que te animes a probar la herramienta y en cuanto esté publicada en el GitHub, eres libre de mejorarla y ampliarla, que nos encantará.

Saludos,