La nota detonante ha sido este documento en el cual se reporta una vulnerabilidad que afecta a la aplicación iTunes. Básicamente el problema consiste en la posibilidad de ejecutar código de forma remota, "invitando" a un usuario a abrir con iTunes un archivo inofensivo, ya sea desde una unidad local, una carpeta compartida o una unidad usb. Este archivo se acompaña de una librería específica requerida por la aplicación vulnerable. Cuando la aplicación procede a la apertura del archivo realiza la carga en memoria de esta librería en lugar de la original. ¿Cómo es esto posible?
La explicación técnica es bastante sencilla. Cuando una aplicación de Windows carga de forma dinámica una librería sin especificar la ruta completa, Windows busca esta librería siguiendo un orden específico. Las funciones encargadas de realizar la carga de la librería son LoadLibrary y LoadLibraryEx. Este es el orden de búsqueda del archivo DLL de estas dos funciones:
1. El directorio desde el que se cargó la aplicación
2. El directorio del sistema
3. El directorio del sistema de 16 bits
4. El directorio de Windows
5. El directorio de trabajo actual
6. Los directorios enumerados en la variable de entorno PATH
Si consultamos la documentación oficial de Microsoft vemos que se recomienda no utilizar la función SearchPath para obtener la ruta completa al archivo DLL al utilizarla posteriormente para llamar a LoadLibrary. Esta recomendación se basa en el hecho de que la función SearchPath usa un orden de búsqueda diferente de los archivos, comenzando por el directorio de trabajo. La forma más sencilla de evitar este problema es llamar previamente a la función SetDllDirectory pasándole como parámetro una ruta en blanco, eliminando así el directorio actual del orden de búsqueda por defecto de los archivos DLL.
Verificando la vulnerabilidad.
Unas pruebas rápidas en un entorno controlado son suficientes para comprobar cómo es bastante fácil encontrar aplicaciones vulnerables y cómo explotar esta vulnerabilidad.
Nuestro conejillo de indias será el archivo GRPCONV.EXE incluido en Windows XP, esta aplicación es el conversor de grupos para el Administrador de programas de Windows.
La siguiente es una captura de pantalla de Windbg (debugger) en la cual se aprecia la carga de la librería imm.dll desde el directorio de trabajo en el cual se abre un archivo grp.
La librería imm.dll original que carga la aplicación, se ha sustituido por otra que en realidad es un exploit a medida, el cual proporciona una shell a otro equipo de pruebas con dirección IP 172.17.1.89.
¿Cual ha sido la respuesta de Microsoft?
La siguiente actualización de seguridad proporciona una nueva entrada del registro de Windows CWDIllegalInDllSearch, que permite a los administradores controlar la ruta de búsqueda de las dlls cargadas por las aplicaciones. Mediante esta nueva entrada es posible definir lo siguiente, ya sea para cada aplicación o para todo el sistema:
- Quitar el directorio de trabajo actual de la ruta de búsqueda de la biblioteca.
- Impedir que una aplicación cargue una biblioteca desde una ubicación de WebDAV.
- Impedir que una aplicación cargue una biblioteca desde un WebDAV o desde una ubicación UNC remota.
Es curioso cómo una vulnerabilidad que fue descubierta por Georgi Guninski en el año 2000, y que en su momento (2001) fue activamente explotada por el gusano Nimbda, vuelve a ponerse de actualidad. Pues sí, me temo que no se trata de algo nuevo. Esta era precisamente una de las técnicas que utilizaba Nimbda para propagarse mediante la copia de la supuesta librería riched20.dll en directorios con archivos .doc.
No hay comentarios:
Publicar un comentario