Siguiendo con el tema de mi anterior post sobre Dll Load Hijacking, me he decidido a escribir un segundo post, mucho mas técnico que el anterior, solo para desmentir algunas de las cosas que se están diciendo por ahí, y aclarar todo el tema. Si no sabes de que va esto, pero te interesa, te recomiendo que leas el primer post sobre el tema.
Tal como expliqué, el Dll Load Hijacking consiste en conseguir que una aplicación cargue una DLL (que podría ser maliciosa) en el momento en que la aplicación abre un fichero. O dicho de otra forma, tu abres un fichero png con photoshop, y el photoshop carga una DLL que hay al lado del png, y que es maliciosa.
Si se dispone del escenario correcto, se puede conseguir ejecutar código en el sistema de la víctima, solo con que abra un fichero doc, odt, png, o cualquier otro inofensivo fichero de datos.
Mucha gente a favor de microsoft, está argumentando que este problema de seguridad, no es culpa de windows, sino de las aplicaciones vulnerables, en mi ejemplo el photoshop. Sin embargo la realidad es bien distinta, y aunque esté habiendo un poco de campaña tanto para quitarle peso a este asunto, como para limpiar la cara de Microsoft, la verdad acaba saliendo siempre a relucir.
En primer lugar, es importante comprender de donde viene el agujero de seguridad. A día de hoy, se han encontrado en unos días ya cientos de aplicaciones vulnerables, lo cual levanta sospechas de que la culpa no es de esas aplicaciones, sino del propio windows, ¿verdad?
Indagando un poco sobre el tema, he encontrado la función de marras que ha liado todo este jaleo, se trata de SetDllDirectory. Pero para entender esta función, primero hay que entender bien el tema de las Dll.
Cuando un programa en windows intenta cargar una Dll, existen una serie de rutas donde intentará encontrar el fichero (al estilo $PATH), setDllDirectory permite agregar un directorio mas donde windows buscará las Dll, de forma que un developer puede poner todas sus dll en un directorio y llamar a setdlldirectory pasándole la ruta de ese directorio, y hasta ahí todo parece perfecto. Veamos la definición de la función:
BOOL WINAPI SetDllDirectory( __in_opt LPCTSTR lpPathName );
Pues si, es así.
Si leemos un poco mas en la MSDN, vemos que:
After calling SetDllDirectory, the DLL search path is:
- The directory from which the application loaded.
- The directory specified by the lpPathName parameter.
- The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
- The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
- The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
- The directories that are listed in the PATH environment variable.
Es decir, antes de llamar a SetDllDirectory, las Dll se empezaban a buscar en el punto 3. hasta el punto 6. Para un developer que está haciendo una aplicación es muy útil poder agregar un directorio mas, en el punto 2. Sin embargo, fijaros en el punto 1, SetDllDirectory no solo agrega una ruta mas para encontrar la Dll, sino que además, agrega también la ruta del directorio de trabajo desde el que se ha lanzado la aplicación!.
Que pasa entonces si la aplicación, que es la aplicación asociada para abrir ficheros png, al iniciarse necesita cargar ‘hola.dll’? Que si el desarrollador utiliza SetDllDirectory en algún sitio, el primer lugar donde se irá a buscar hola.dll es al lado del fichero png que hemos abierto, que podrías estar por ejemplo, en un pen drive, en una unidad compartida…etc.
Explotar esto es tan fácil como poner la dll que el programa irá a buscar al lado del fichero de datos asociado con el programa. Cuando el usuario haga click en el fichero, por ejemplo un png (o cualquier otro), se ejecutará el programa, que llamará a SetDllDirectory y luego empezará a cargar las Dll, cargando así nuestra Dll maliciosa que hay al lado del fichero png, doc, o lo que sea.
Para mas inri, nuestra Dll maliciosa podría estar oculta, y ni siquiera la vería el usuario.
Esto es especialmente grave, debido a que si ahora cambian la función, miles de aplicaciones dejarán de funcionar, por que la utilizaban. Si no la cambian, miles de aplicaciones son a día de hoy vulnerables, y el pobre usuario de windows no podrá ni abrir un png de un pen drive, sin que le tiemble la mano.