DLL Hijacking: otra forma de explotar aplicaciones en Windows

Desde hace unos días hay mucho revuelo concerniente a la publicación de HD Moore (creador de Metasploit) sobre la ejecución de código a través de DLL Hijacking. Prácticamente todos los blogs de seguridad han mencionado el tema y ya se subieron más de 20 exploits en Exploit Database para aplicaciones como Power Point, Firefox, Visio, Groove, Winamp, Google Earth, Photoshop y muchas más!

De qué trata DLL Hijacking y por qué afecta a tantas aplicaciones? Realmente es algo muy simple. DLL Hijacking se aprovecha de la forma en que se buscan las librerías dinámicas (DLL) en el filesystem cuando un programa intenta cargarlas utilizando la función LoadLibrary. Lo que hace un atacante es crear una librería dinámica propia, que se llame igual a alguna de las que carga un dado programa cuando intenta abrir un determinado tipo de archivo. Como al momento de abrir el archivo (por ejemplo un pps) el directorio de trabajo es el del archivo, si el atacante planta su librería ahí, el programa cargará esa en lugar de la original... gualá!!!

Este ataque tiene sentido cuando tenemos archivos compartidos. Supongamos que tenemos un servidor de archivos basado en CIFS (o SMB, los clásicos shares de Windows) donde distintas personas pueden leer y escribir. Ahora supongamos que Malicioso crea un pps en el servidor y le dice a Josesito "mira la presentación que puse en tal directorio". A su vez, Malicioso crea una librería dinámica que sabe que Power Point intentará cargar al abrir el pps. Si Josesito no es desconfiado y es lo suficientemente curioso, abrirá la presentación directamente desde el servidor de archivos (por experiencia, todos hacen eso, nadie copia las cosas a su disco). Al hacer esto, el Power Point de Josesito cargará la librería creada por Malicioso en lugar de la original, permitiendo a Malicioso ejecutar lo que quiera con los permisos de Josesito!

Para jugar un rato, descarguen alguno de los exploits que figuran en la sección Local Exploit de Exploit Database. Muchos traen la explicación de cómo compilar las librerías, pero les comento que pueden hacerlo con el gcc para Windows de la siguiente forma:

gcc -shared -o <nombre-libreria-hijack>.dll <codigo>.c

Entonces, es un problema de Windows? nop, esta vez Windows se salva. El problema es de las aplicaciones que no especifican correctamente el path a sus librerías. Como pueden ver en el manual de la función Load Library, ésta toma como parámetro el nombre de una librería y la carga en memoria. Si no se especifica path a la misma, la función realiza una búsqueda estándar, es decir, se busca la librería en directorios predeterminados. El orden de búsqueda depende de si "Safe DLL search mode" está activo o no. La clave de registro que activa/desactiva el modo safe se encuentra en HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode (en XP y 2000 SP 4 viene deshabilitado por default).
Si SafeDllSearchMode está habilitado, el orden de búsqueda es el siguiente:

1. El directorio desde donde se carga la aplicación.
2. El directorio de sistema.
3. El directorio de sistema de 16-bit.
4. El directorio de Windows
6. Los directorios que están listados en la variable de entorno PATH.

Si SafeDllSearchMode está deshabilitado, el orden es el siguiente:

1. El directorio desde donde se carga la aplicación.
2. El directorio actual.
3. El directorio de sistema.
4. El directorio de sistema de 16-bit.
5. El directorio de Windows
6. Los directorios que están listados en la variable de entorno PATH.

Este orden de búsqueda estándar se puede alterar utilizando la función LoadLibraryEx o bien con SetDllDirectory, con las cuales especificamos dónde buscar primero.

Como se darán cuenta, esta vulnerabilidad afecta a toda aplicación que no explicite el path a sus librerías, y por ello es que debe haber cientos o miles de aplicaciones perjudicadas.

Ahora, si es algo tan simple, cómo es que nadie lo descubrió antes? Bueno, si lo hicieron, en F-Secure dicen que se publicó sobre esta vulnerabilidad hace como 10 años, pero ahora surgió el revuelo porque HD Moore publicó un kit que permite encontrar rápidamente aplicaciones vulnerables. Pueden leer y descargar el kit en Exploiting DLL Hijacking Flaws y Better, Faster, Stronger: DLLHijaAuditKit v2.

Si bien mencioné que el exploit tiene sentido desde shares de Windows, otras formas de utilizarlo es desde archivos comprimidos, pen-drives, y WebDav (extensión de MS para HTTP en IIS).

MS publicó hace unos días un advisory para administradores donde explican algunas medidas a tomar para minimizar los riesgos. Entre las soluciones provisionales proponen:

- Deshabilitar la carga de librerías desde WebDAV y shares remotos.
- Deshabilitar el servicio WebClient.
- Bloquear los puertos 139 y 445 usando firewall. Claro que esto los dejará sin los shares...

Por supuesto que deberán estar atentos a los parches que publiquen los distintos proveedores para solucionar este problema.
También publicaron una guía para programadores sobre lo que pueden hacer para proteger sus aplicaciones contra el DLL Hijacking. Básicamente las recomendaciones son:

- Especificar el path completo a la librería siempre que sea posible.
- Usar DLL Redirection o un manifest para asegurarse de que están utilizando la DLL correcta.
- Asegurarse de que "safe DLL search mode" esté habilitado.
- Eliminar el directorio actual del path de búsqueda llamando la función SetDllDirectory con un string vacío ("").
- No usar la función SearchPath para obtener el path de una librería a menos que "safe process search mode" esté habilitado.
- No asumir versión de sistema operativo basados en lo retornado por LoadLibrary.

Espero haberlos iluminado un poco sobre el tema y sobre todo espero que los programadores tomen conciencia de este tipo de ataque a la hora de programar.