Amenaza

Side-Loading de DLLs con Filezilla

diciembre, 5, 2022

8 minutos de lectura

Por Jesús Domínguez del equipo Ocelot de Metabase Q

// Resumen

En días recientes, durante un ejercicio de simulación de APT, realizado por el equipo de seguridad ofensiva de Metabase Q – Ocelot – fueron evaluadas las capacidades de protección de un XDR. En este ejercicio, que forma parte del portafolio de Ocelot, se encontró que FileZilla, el popular software de transferencia de archivos vía FTP, catalogado como el mejor, es vulnerable a DLL Side-Loading o Relative Path DLL Hijacking. Al explotar esta vulnerabilidad se pudo burlar la detección en el Endpoint. En este blog, compartimos el proceso que fue llevado a cabo por Ocelot con el objetivo de que las organizaciones puedan encontrar este tipo de vulnerabilidades en sus ambientes productivos de forma proactiva.

// Encontrando la vulnerabilidad

Se nos proporcionó un equipo similar al utilizado por los empleados con todos los controles de seguridad instalados. Las características del equipo se muestran a continuación:

«`

Edición Windows 10 Pro

Versión 20H2

Instalado en ‎/‎11/‎08/2021

Compilación del SO 19042.1348

Experiencia Windows Feature Experience Pack 120.2212.3920.0

«`

El objetivo específico es encontrar binarios que tengan una implementación débil de LoadLibrary, en la cual no se indique la ruta completa del módulo DLL a cargar en memoria. El objetivo es que en su lugar, se busque en el directorio desde donde se ejecuta el programa, lo cual debería ser la ultima opción de búsqueda como se muestra en la Figura 1

Llamada vulnerable: LoadLibrary(“myDLL.dll”)
Llamada no vulnerable: LoadLibrary(“C:\Program Files\FileZilla FTP Client\myDLL.dll”)

‍El proceso de búsqueda de binarios vulnerables se automatizo con un script que realiza los siguientes pasos:

Obtiene una lista de los binarios en la terminal
Se usa dumpbin.exe para obtener una lista de los imports
Se realiza la búsqueda de “LoadLibrary.*” en los imports
Se registra qué binario tiene ese import

Como resultado de la búsqueda automática, obtuvimos una lista importante de targets, ente ellos el programa FileZilla con las siguientes propiedades:

«`
Instalador obtenido de:

https://filezilla-project.org/download.php?type=client

Nombre: FileZilla_3.56.2_win64_sponsored2-setup.exe

Arquitectura: x64

MD5: 736e6ecd0817ff84471eeadecdff44a9

Ejecutable Vulnerable

Nombre: filezilla.exe

Arquitectura: x64

MD5: bfeca8926efd4dda575763c9c4541136

«`

Para confirmar esta falla, se copió el ejecutable original a %USEPROFILE%\Documents\filezilla.exe. De esta forma, se pueden observar cuáles DLLs son vulnerables a DLL Side Loading.

Antes de ejecutar Filezilla.exe, se tiene que generar una variable de entorno que apunte al path de la aplicación, con el fin de encontrar todos los DLLs necesarios para su ejecución. Debido a la vulnerabilidad descubierta, no fue de ayuda. Ver Figura 2.

Figura 2. Generación de variable de ambiente

‍

Al monitorear la ejecución del programa vía ProcMon, se observa la DLL libfilezilla-22.dll siendo buscada en el directorio actual, y, por ende, siendo vulnerable. Ver Figura 3.

Figura 3 Búsqueda de DLL en distintos directorios

La siguiente lista muestra todas las DLL que son buscadas de esta manera y, por lo tanto, también vulnerables a DLL Side Loading:

«`‍

C:\Users\user_one\Documents\libfzclient-commonui-private-3-56-2.dll
C:\Users\user_one\Documents\wxbase30u_gcc_custom.dll
C:\Users\user_one\Documents\wxmsw30u_adv_gcc_custom.dll
C:\Users\user_one\Documents\wxmsw30u_aui_gcc_custom.dll
C:\Users\user_one\Documents\wxmsw30u_xrc_gcc_custom.dll
C:\Users\user_one\Documents\libsqlite3-0.dll
C:\Users\user_one\Documents\MPR.dll
C:\Users\user_one\Documents\NETAPI32.dll
C:\Users\user_one\Documents\POWRPROF.dll
C:\Users\user_one\Documents\libfzclient-private-3-56-2.dll
C:\Users\user_one\Documents\libfilezilla-22.dll
C:\Users\user_one\Documents\libgmp-10.dll
C:\Users\user_one\Documents\libgnutls-30.dll
C:\Users\user_one\Documents\zlib1.dll
C:\Users\user_one\Documents\WINMM.dll
C:\Users\user_one\Documents\wxmsw30u_core_gcc_custom.dll
C:\Users\user_one\Documents\libpng16-16.dll
C:\Users\user_one\Documents\wxbase30u_xml_gcc_custom.dll
C:\Users\user_one\Documents\libgcc_s_seh-1.dll
C:\Users\user_one\Documents\libstdc++-6.dll
C:\Users\user_one\Documents\libhogweed-6.dll
C:\Users\user_one\Documents\ncrypt.dll
C:\Users\user_one\Documents\libnettle-8.dll
C:\Users\user_one\Documents\NETUTILS.dll
C:\Users\user_one\Documents\SRVCLI.dll
C:\Users\user_one\Documents\NTASN1.dll
C:\Users\user_one\Documents\UMPDC.dll
C:\Users\user_one\Documents\Wldp.dll
C:\Users\user_one\Documents\TextShaping.dll
C:\Users\user_one\Documents\MSASN1.dll
C:\Users\user_one\Documents\WindowsCodecs.dll
C:\Users\user_one\Documents\profapi.dll
C:\Users\user_one\Documents\msftedit.dll
C:\Users\user_one\Documents\msvcp110_win.dll
C:\Users\user_one\Documents\apphelp.dll
C:\Users\user_one\Documents\CRYPTBASE.dll
C:\Users\user_one\Documents\msimg32.dll

«`

NOTA: Esta vulnerabilidad también se encontró en la versión de 32 bits de FileZilla, dejamos como ejercicio para las personas que lean el blog, implementar el ataque en esa versión.

// Implementación del ataque

Se decide implementar el ataque con la DLL libfilezilla-22.dll (ver Figura 4), una vez seleccionada la librería, se inspecciona para poder extraer los exports que esta ofrece y hacer una carga sin problemas al momento que el ejecutable la carga en memoria.

Figura 4. Se observa la DLL en su ruta original

‍Usamos CFF Explorer para inspeccionar los exports de la DLL (Ver Figura 5), obteniendo una lista de los mismos. Ver Apéndice A para consultar la lista completa.

Figura 5. CFF explorer para obtener todos los exports de la DLL

// Obteniendo ejecución de código en nuestro DLL

Con los exports listados ya podemos empezar nuestra DLL maliciosa, para lo que utilizamos Visual Studio Community.

Cuando una DLL es cargada en memoria lo primero que llama es el DllMain, siendo este el Entry point de la misma. Esto pasa cuando es cargada o descargada de memoria por LoadLibrary o FreeLibrary, respectivamente. https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain

Ejemplo de DllMain:

// dllmain.cpp: Define the entry point in the DLL application
#include "pch.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Al momento de cargar la DLL, se ejecuta el caso DLL_PROCESS_ATTACH, donde pusimos nuestro código malicioso, que es la llamada de una función de reverse shell obtenida de https://github.com/dev-frog/C-Reverse-Shell/blob/master/re.cpp Con unas ligeras modificaciones realizamos la conexión a nuestro C2.

Una vez implementada nuestra DLL maliciosa, y, cumpliendo todos los exports necesarios, procedimos a compilar la misma y obtener el DLL final para la explotación de esta vulnerabilidad. Se puede ver el código completo en el Apéndice A.

// Explotación

Finalmente, nuestra DLL está lista para ponerse a prueba, por lo que seguimos los siguientes pasos:

Mostramos el directorio de instalación original de FileZilla y de libfilezilla-22.dll
Se muestra el funcionamiento normal de FileZilla sin ningún comportamiento malicioso
Se realiza la copia del FileZilla Original a %USERPROFILE$\Documents\filezilla.exe
Se realiza la copia de la DLL maliciosa a la misma ruta %USERPROFILE$\Documents\LibFilezilla-22.dll
FileZilla es ejecutado en este nuevo directorio y por lo tanto, cargando la DLL maliciosa
La conexión a nuestro C2 via reverse shell es ejecutada exitosamente

La explotación de la vulnerabilidad se puede ver en el siguiente video:

// Recomendaciones

Siempre hay medidas de seguridad que se pueden tomar para prevenir este tipo de ataques por lo que recomendamos:

Hacer pentests de manera proactiva y recurrente, tratando de encontrar binarios vulnerables a DLL Side-Loading
Actualizar el software regularmente para incluir parches que remedien vulnerabilidades de DLL Side-Loading
Poner en práctica una política para regular la instalación de software, aceptando únicamente los que provengan de fuentes aprobadas por el equipo de seguridad
Probar los Tiempos de Detección (TTDs) y de respuesta (TTRs) del Blue Team para este tipo de ataques con ejercicios de simulación APT. Pide una demo hoy en contact@metabaseq.com.

Acerca de Metabase Q

Metabase Q protege a las organizaciones contra pérdidas financieras y daños a su reputación a través de su enfoque de ciberseguridad inteligente. Mediante análisis y auditorías continuas, Metabase Q calibra la ciberdefensa que emite y provee seguridad efectiva, permitiendo a las organizaciones crecer e innovar sin preocuparse por las ciberamenazas. 10 de las compañías más grandes en América Latina, agencias gubernamentales y más de 80% de las transacciones financieras en México confían en Metabase Q para proteger sus sistemas y datos ante ciberataques. El equipo de ciberseguridad ofensiva de Metabase Q, Ocelot, tiene reconocimiento mundial, está dedicado a transformar la ciberseguridad en la región. La inteligencia sobre amenazas, la investigación y las habilidades ofensivas de Ocelot potencian las soluciones de Metabase Q.

Para saber más de Metabase Q, de Ocelot, su equipo de seguridad ofensiva, y de su oferta de Security-as-a-Service visite el sitio web: https://www.metabaseq.com/.

contact@metabaseq.com
‍+1 (628) 225-1281
‍+52 55 2211 0920