DLL Hijacking: Identificando programas vulnerables con Process Monitor

Hace unos días revisábamos lo que es una DLL y en qué consistían los ataques de DLL Hijacking. En esta ocasión, atendiendo a los conceptos explicados en el artículo anterior, vamos a comprobar cómo se puede buscar si un programa es vulnerable a este ataque y, en el próximo artículo,  cómo poder explotarlo. 

Figura 1: DLL Hijacking: Identificando programas vulnerables con Process Monitor

En este artículo de hoy en concreto vamos a trabajar con la última versión de Slack que en el momento de escribir el artículo es la 4.15.0, que es una de las aplicaciones más utilizadas en estos tiempos de teletrabajo en los equipos Windows de las empresas, y puede ser un buen objetivo para atacar en un Hacking a sistemas Windows y redes Microsoft.

Identificando oportunidades de DLL Hijacking

Para buscar un programa vulnerable a DLL Hijacking vamos a hacer uso de Process Monitor (procmon), una herramienta capaz de monitorizar en tiempo real un gran número de eventos relacionados con los procesos del sistema. Hemos visto en varios artículos cómo esta herramienta se puede utilizar para revisar los niveles de integridad de los procesos o para encontrar y explotar UAC Bypass:

- Cómo ownear Windows 7 y Windows 10 con el nuevo bypass de UAC

- Bypass de UAC en Windows 10 con DLL Hijacking vía SystemPropertiesAdvanced.exe

- Fileless 3: Otro bypass de UAC en Windows 10

Lo que nos interesa en este caso es que, seleccionando los filtros adecuados, podemos listar las DLL que un proceso intenta cargar, la rutas en la que se buscan esas DLL y si éstas se han encontrado con éxito o no en esos directorios.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Ahora que ya sabemos lo que debemos buscar, conviene recordar que la finalidad del DLL Hijacking es, generalmente, la de elevar privilegios o generar persistencia en el sistema. Esto ya nos da una pista sobre qué programas nos pueden interesar más:

• Si la intención es la de elevar privilegios parece razonable buscar programas que se ejecuten por un usuario con privilegios de administrador o servicios que se ejecuten como “NT AUTHORITY/SYSTEM”. Si se carga una DLL cuyo payload genere una shell, ésta tendrá los mismos privilegios que el usuario que levantó el proceso.

• Si lo que se pretende es generar persistencia, la estrategia sería buscar programas que se ejecuten de forma habitual (como un navegador de Internet) y programas configurados para ejecutarse automáticamente cuando se inicia el sistema. Algunos de los programas que yo he visto que con frecuencia se configuran para iniciarse con el sistema son: Microsoft Teams, OneDrive, Skype, Dropbox y Slack.

En este caso, vamos a trabajar con Slack y vamos a filtrar en procmon todas aquellas DLL que la aplicación intenta cargar, pero no encuentra en el directorio donde las busca. Para ello, tras ejecutar procmon abriremos la pestaña “filter” (ctrl+L) y añadiremos estos tres filtros:

1. Primer desplegable “Process name”, segundo desplegable “is” y “slack.exe”.
2. Primer desplegable “Path”, segundo desplegable “ends with” y “.dll”.
3. Primer desplegable “Result”, segundo desplegable “is” y “NAME NOT FOUND”.

Nuestro filtro debe quedar así:

Figura 3: Filtro para la búsqueda de DLLs no encontradas por Slack

Tras aplicar el filtro en procmon y ejecutar Slack aparecerá la lista de DLLs que cumplen estos criterios que se puede ver en la Figura 4. De todas estas DLLs las más interesantes son aquellas que se han buscado en el propio directorio de la aplicación. Ahora hay comprobar si en dicho directorio contamos con permisos de escritura, lo que en nuestro caso se cumple, para depositar ahí una DLL maliciosa.

Figura 4: Lista de DLLs no encontradas por Slack

Es importante aclarar que en este punto vamos “a ciegas”, es decir, no hemos hecho ningún análisis del binario. Para nosotros slack.exe es una caja negra; no sabemos cómo carga cada DLL, qué funciones de esa DLL utiliza o qué hará el programa si se encuentra con una DLL inválida o si no consigue importar función alguna de esa DLL.

Figura 5: Ejemplo de DLL "vacía"

Desde este momento el trabajo que nos queda por hacer es bastante manual; hay que ir comprobando para cada DLL si existe una oportunidad real de secuestro o "Hijacking". Esto puede hacerse introduciendo en el directorio de la aplicación una DLL “vacía” (sin ningún payload), tal y como aparece en la figura anterior. Basta con renombrar esa DLL vacía con el nombre de la DLL legítima a la que pretendemos suplantar.

Figura 6: Máxima Seguridad en Windows Gold Edition

Una vez hecho esto, deberíamos eliminar los filtros de procmon que habíamos creado anteriormente y crear un filtro con el nombre de la DLL con la que estamos trabajando. Si al ejecutar Slack de nuevo comprobamos en procmon que el resultado para esa DLL ha cambiado de “NAME NOT FOUND” a “SUCCESS” entonces puede haber una oportunidad para el hijacking. 

Figura 7: Resultado para USERENV.DLL antes de introducir la

DLL "vacía" en el directorio de la aplicación

También puede ocurrir que el programa no se inicie correctamente o que su ejecución se rompa. Esto es normal y no debe preocuparnos, hay que entender que está cargando una librería que no exporta ninguna función. Lo importante es detectar signos de que la DLL vacía se ha cargado. En la Figura 7 y la Figura 8 se puede ver la comparación de los resultados de procmon para USERENV.dll al introducir una DLL vacía en el directorio de la aplicación.

Figura 8: Resultados para USERENV.dll después de introducir la

DLL "vacía" en el directorio de la aplicación

El siguiente paso para descubrir si esto puede traducirse en un DLL Hijacking será introducir un payload en nuestro DLL para que se ejecute cuando Slack lo carga. Este tema es algo más complejo que simplemente introducir el código del payload en la DLL y vamos a ver el porqué en el siguiente artículo.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda