Este Documento pretende entregar información acerca del funcionamiento de las librerías de enlace dinámico y demostrar como una mala configuración del sistema operativo Windows permite un ataque de DLL Hijacking en algunas aplicaciones vulnerables, junto a esto se desea demostrar el proceso practico del ataque y además algunos consejos para poder mitigar la vulnerabilidad a través de herramientas y configuraciones adicionales de Windows.
Según The Inquirer a finales del año 2018 Microsoft Windows termino siendo el sistema operativo más usado en PCs de escritorio1, esto nos llevaría a pensar que debería ser el sistema operativo más estable y seguro de los existentes ya que tiene un gran equipo de desarrollo trabajando en él y una empresa gigantesca respaldándolo, pero a pesar de todo esto no lo es, existe una vulnerabilidad conocida como DLL Hijacking, también conocida como Binary Planting, descubierta por H.D. Moore en 2010, si, hace 9 años, y a pesar del tiempo que ha pasado aun es explotable ya sea por la mala programación de las aplicaciones o por la baja detección de las aplicaciones anti malware o por el bajo control por defecto de Windows de las aplicaciones, afectando a muchas aplicaciones a medida y de mercado lo que la hace una vulnerabilidad aún muy peligrosa. En este documento revisaremos el por qué algunas aplicaciones pueden ser vulnerables, demostraremos como se puede reconocer si una aplicación puede ser vulnerable, como podemos explotar esta vulnerabilidad y finalmente se abordará el funcionamiento de algunas formas de mitigación y como ejecutarlas en sistemas Windows actuales.
En los sistemas operativos Windows se utilizan Bibliotecas de Enlace Dinámico, también conocidas como DLL por sus siglas en Ingles (Dynamic-Link Library), estas librerías contienen funciones o porciones de código pre compilado, que pueden ser utilizadas por una o varias aplicaciones distintas, mayormente para reutilizar código de uso común entre varias aplicaciones evitando la redundancia de código o simplemente para hacer más fácil la actualización de las aplicaciones remplazando solo algunos pequeños archivos, el uso de las DLLs supuso una gran mejora en la programación y esto ayudo a masificar su uso, siendo actualmente un estándar en programación el empaquetado de funciones similares, del mismo negocio o de la misma capa de software.
Como ya mencionamos las DLL son usadas por aplicaciones, si la ruta absoluta de la DLL no está definida en la aplicación se utilizara el orden de búsqueda definido por Microsoft[4] en el siguiente orden hasta que la DLL pueda ser cargada:
- EL directorio actual desde donde se ejecuta la aplicación.
- El directorio donde está la aplicación.
- El directorio especificado por el parámetro lPathName.
- El directorio del sistema, se usa la función GetSystemDirectory para obtener la ruta a este directorio, el nombre de este directorio es System32.
- El directorio del sistema de 32 bits llamado SysWow64.
- El directorio de Windows usando la función GetWindowsDirectory para obtener la ruta.
- Los directorios definidos en la variable de entorno PATH.
Ahora que sabemos cómo funciona el llamado de las DLLs en Windows podemos darnos cuenta que si logramos determinar en cuál de las rutas antes mencionadas está físicamente la DLL verdadera, podemos inyectar una DLL en alguna de las rutas de búsqueda anteriores a esta y asi lograr que la DLL maliciosa sea encontrada antes que la DLL.
Variables de estudio
Las variables involucradas en este estudio son:
- La aplicación que llama a la DLL es nuestra variable dependiente ya que esta nos ayudara a ver el efecto del experimento.
- La DLL modificada será nuestra variable independiente puesto que esta es la que afecta el funcionamiento de la aplicación explotada.
- Las mitigaciones o medidas tomadas para corregir el efecto de la variable independiente serán nuestra variable interviniente.
Aplicaciones Vulnerables: Una aplicación es vulnerable si utiliza el flujo definido por defecto por Windows y no encuentra la DLL en alguno de los primeros intentos, ya que, en algún lugar del flujo, antes que se encuentre la DLL, podemos poner la DLL falsa con el código malicioso que queremos ejecutar, no todas las aplicaciones son vulnerables ya que si la aplicación explicita la ruta directa de la DLL solo ira a buscar a esa ruta y también si la aplicación está instalada en una ruta segura, como por ejemplo en la ruta definida en la variable de entorno de Windows %PROGRAMFILESs% se deberá tener privilegios elevados para remplazarla, también se puede usar el valor del registro de Windows SafeDllSearchMode para especificar que use las rutas seguras donde buscar las DLL, en estos 3 casos la aplicación pierde su vulnerabilidad.
DLL Modificada: primero debemos saber cuál es la DLL candidata a reemplazar o modificar ya que no todas las DLLs son reemplazables se debe monitorear la ejecución de la aplicación y detectar que DLLs no encuentra en primera instancia y donde fue buscada, se debe evaluar si la ruta donde fue buscada sin éxito por la aplicación necesita permisos elevados para escribir si es así entonces esta DLL no servirá a menos que antes de inyectar la DLL se logre escalar privilegios en el sistema para poder acceder a escribir en rutas seguras del sistema, por el contrario si la ruta de búsqueda fallida es accesible por el usuario actual entonces esta es la DLL que estamos buscando y sobre ella debemos trabajar para inyectar nuestro código.
Métodos de Mitigación: lo primero que se debe realizar es habilitar el modo de búsquedas de DLL segura, para forzar a las aplicaciones a buscar DLLs en directorios con mayores restricciones como por ejemplo la ruta definida en la variable de entorno de Windows %SYSTEMROOT% para ser usadas antes que en los directorios locales de DLLs como por ejemplo el directorio del usuario actual, se recomienda usar herramientas de auditoria capaces de detectar oportunidades de DLL Hijacking en sistemas empresariales y corregirlas, se debe identificar y bloquear software potencialmente malicioso que pueda ser ejecutado a través de DLL Hijacking reconociéndolo con listas blancas de software.
Método de Análisis y explotación de una aplicación
Para este caso de estudio utilizaremos la aplicación PuTTY que en su versión 0.65 fue vulnerable a este tipo de ataques, luego de instalarla procederemos a analizarla, para esto utilizaremos una aplicación de monitoreo de procesos llamada Process Monitor de Sysinternals de ahora en adelante ProcMon,, esto nos permitirá saber que DLL es secuestrable, cuando identifiquemos la DLL debemos averiguar que métodos o funciones de ella se están utilizando para poder falsificarlos en nuestra DLL maliciosa esto lo realizaremos con una herramienta llamada Ghidra desarrollada por la NSA y luego utilizaremos Visual Studio 2019 para crear nuestra DLL maliciosa, hecho esto procederemos a suplantar la original con la nuestra y veremos cómo se comporta.
Análisis de la aplicación
ProcMon queda a la escucha de todos los procesos en ejecución en Windows, por lo que la información recolectada es abrumadora y se hace engorroso enfocarse en la aplicación en estudio si no se filtran los resultados primero, para configurarlo correctamente se debe abrir la configuración de filtro (Ctrl + L) y agregar por lo menos estos 3 filtros:
- Process Name is Putty.exe then Include
- Result ends with NOT FOUND then Include
- Path ends with .dll then Include
Una vez aplicada esta configuración procedemos a capturar los procesos y luego a ejecutar PuTTY para ver que nos muestra ProcMon
En el resultado de ProcMon podemos apreciar que PuTTY busca la DLL WINMM.DLL en el directorio donde está la aplicación primero, al no encontrarla la busca en segundo lugar en la ruta de las DLLs de 32 bits donde si la encuentra y procede a cargarla, aquí podemos obtener dos datos importantes para nuestro ataque:
- Que DLL debemos reemplazar.
- Y donde debemos ubicarla, en el primer directorio de búsqueda sin éxito.
Ahora debemos saber cuál es el método o función que está tratando de usar y para esto usaremos Ghidra abrimos la herramienta y cargamos la aplicación PuTTY.exe, luego hacemos doble clic en putty.exe y comienza a analizar el ejecutable, una vez finalizado el análisis observamos en el apartado Symbol Tree y expandimos la carpeta Imports para luego buscar la carpeta de la DLL winmm.dll, si la expandimos, voila, nos muestra la función que utiliza PuTTy de esta DLL la función se llama PlaySoundA y con esto obtenemos el tercer y último dato necesario para nuestro ataque: la función a falsificar en nuestra DLL maliciosa.
Construcción de la DLL maliciosa
Con los datos obtenidos previamente podemos falsificar la DLL utilizada por PuTTy, para esto vamos a abrir Visual Studio 2019 y crear un nuevo proyecto del tipo Dynamic-Link Library en C++ y en el nombre de la solución le ponemos el nombre de la DLL winmm, una vez creado el proyecto abrimos el archivo dllmain.cpp y agregamos la función PlaySoundA donde agregaremos nuestro código malicioso, en este caso solo ejecutaremos una consola de comandos, finalmente generamos la DLL.
Suplantación de la DLL y prueba de funcionamiento
Con la DLL ya generada procedemos a depositarla en el directorio de la aplicación, que es donde falla en localizarla por primera vez antes de buscarla en el directorio del sistema. Hecho esto ejecutamos PuTTY y esperamos el resultado monitoreando con ProcMon, y asi podemos observar que PuTTY encuentra nuestra DLL antes que la de Windows ejecutando nuestro código malicioso y a la vez ejecutando el cmd de Windows
Atacando a una Víctima Remotamente
Un atacante podría reemplazar una DLL por otra maliciosa, pero esto no sería una ataque de DLL Hijacking ya que lo define a esta vulnerabilidad es aprovecharse de las rutas de búsquedas de DLL de Windows, una víctima incluso podría ser atacada remotamente y el atacante no necesitaría tener acceso a la máquina para esto, existen múltiples casos de abuso en que se podría ejecutar esta vulnerabilidad remotamente, como ejemplo dos, en ambos casos debe interactuar la víctima:
- Un atacante encuentra esta vulnerabilidad en un lector de archivos PDF por ejemplo y planta la DLL en una carpeta compartida de su máquina junto a un PDF cualquiera, si la victima hace doble clic sobre el PDF directamente en la carpeta remota, la aplicación vulnerable usada por la víctima para leer PDF buscara en primer lugar la DLL en el directorio remoto donde se invocó a la aplicación encontrando la DLL maliciosa y ejecutando la función envenenada.
- Otro caso se puede dar cuando el atacante comprime ambos archivos del ejemplo anterior en un zip y lo comparte con la victima que tiene instalado el lector de PDF vulnerable, generalmente los usuarios acostumbran a descomprimir completo los archivos y luego va al directorio descomprimido y ejecuta el PDF que está acompañado de la DLL maliciosa, ejecutando esta DLL ya que está en la ruta de ejecución de la aplicación vulnerable.
Mitigaciones de la Vulnerabilidad
Lo importante de conocer una Vulnerabilidad es que te da la oportunidad de saber cómo defenderte de ella o mitigarla de alguna forma, este caso no es la excepción, la primera mitigación viene de parte de los desarrolladores, un desarrollador no debería confiar en el orden de búsqueda de Windows, lo primero que debería hacer es llamar a las DLL explícitamente por su ruta segura, y además generar DLLs con Strong name, una forma de firmar con un certificado la DLL para que las aplicaciones no carguen o usen DLLs Falsificadas, de esta forma no recae en Windows la responsabilidad fallida de asegurar la confiabilidad de las DLL. Un segundo punto de mitigación en el que si tiene parte el usuario es mantener las aplicaciones actualizadas, las empresas desarrolladoras de software reaccionan relativamente rápido a este tipo de vulnerabilidades porque es fácil de corregir esto hace que salgan rápidamente versiones corregidas de las aplicaciones vulnerables. Es súper importante instalar las aplicaciones y/o DLLs en directorios seguros como Program Files o Windows. Una forma de evitar estas vulnerabilidades también es por ejemplo si le comparten algún tipo de documento, imagen u otro tipo de archivo para visualizar y viene junto a una DLL, sería una buena idea deshacerse de esa DLL antes de abrir el archivo directamente desde la ruta ya que podría estas envenenada. Existen también herramientas de auditoria capaces de detectar este tipo de ataques como por ejemplo PowerSploit que contiene módulos para explorar un sistema en busca de aplicaciones con esta vulnerabilidad. Herramientas que tengan la capacidad de auditar y bloquear DLLs desconocidas, como AppLocker. Windows no busca la DLL si esta está configurada en la lista de DLLs conocidas, se puede revisar las DLLs conocidas en la siguiente Clave del registro de Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs. Habilitar el SafeDllSearchMode, aunque Sistemas Windows mayores a Windows 2012 viene activado por defecto, se puede verificar en el registro de Windows o en las políticas de Grupos.
Conclusiones
La primera vez que se detectó esta vulnerabilidad fue en el año 2010, hace nueve años, y tuvo mucha difusión, y hasta el día de hoy siguen reportándose aplicaciones vulnerables, como por ejemplo sin ir más lejos el 25 de Febrero de este año se reportó una vulnerabilidad de DLL Hijacking sobre la aplicación Sublime Text 3 versión 3.1.1 build 3176 en sistemas de 32 bits, un editor de texto ampliamente utilizado como este es lo que se necesita para comprimir un archivo de texto junto a una DLL envenenada, enviarlos a una víctima y verlos datos sensibles de ese usuario esparcidos por la internet o toda la red empresarial comprometida, es muy fácil inyectar código extremadamente malicioso en una dll, y el ataque puede ejecutarse tan silenciosamente que puede pasar desapercibido por mucho tiempo. Pero como vimos no es tan complicado tomar las precauciones necesarias para mitigar los riesgos de esta vulnerabilidad, incluso con herramientas automatizadas y algunas configuraciones, es más, con los datos mostrados podemos auditar nosotros mismos las aplicaciones que usamos en nuestro entorno empresarial y personal.
Es de suma importancia la concientización de seguridad en una empresa y en nuestro entorno, ya vimos que solo ejecutando un archivo en una ruta compartida podemos caer en las garras del DLL Hijacking, ya sabemos que una cadena es tan fuerte como su eslabón más débil y en Seguridad de la información ese eslabón débil es el error humano, podemos automatizar, configurar, hardenizar, y blindar nuestra compañía pero si un usuario cualquiera ejecuta archivos de origen dudoso o abre correos de remitentes desconocidos sin precaución alguna puede comprometer todos nuestros activos de información.
Recomendaciones
Se debe capacitar periódicamente a los usuarios
a reconocer archivos maliciosos, correos de dudosa procedencia, como reconocer
paginas seguras, la repetición periódica de información hace más fácil la
asimilación de esta por las personas, se repite y se repite hasta que queda en
la memoria muscular. Es nuestra herramienta más valiosa, menos costosa y a la
vez la línea de defensa más vulnerable