Ocultar malware usando ataques de precarga de DLL

Esta prueba de concepto que voy a explicar hoy, no es para nada algo nuevo, hace tiempo que se conoce y, que además se ha usado para atacar tanto empresas como usuarios. Es un tipo de ataque que, normalmente pasa bastante desapercibido. Ya que, no es las primeras cosas que se pone uno a investigar. Es por eso que, bien usado puede ser un quebradero de cabeza para un analista forense que le toque investigar el caso.

¿Cómo se da este fallo?

Ocurre cuando un programa hace llamadas a DLL sin definir bien el PATH o son llamadas que intenta acceder a PATHS que un usuario malintencionado podría modificar.

*Podéis encontrar más información aquí:

http://blogs.technet.com/b/seguridad/archive/2010/08/24/aviso-de-seguridad-de-microsoft-2269637-liberado.aspx

¿Qué es la precarga insegura de DLL?

Pues según Microsoft, la precarga insegura de DLL es:

“Cuando una aplicación carga dinámicamente una biblioteca de vínculos dinámicos (DLL) sin especificar una ruta de acceso completa, Windows intenta encontrar la DLL buscando en un conjunto bien definido de directorios. Si un atacante obtuviera el control de uno de los directorios, podría obligar a que la aplicación cargara una copia malintencionada de la DLL en lugar de la DLL que se esperaba. Estos ataques, conocidos como “ataques de precarga de DLL”, son habituales en todos los sistemas operativos que admiten la carga dinámica de bibliotecas DLL compartidas. El efecto de tales ataques podría ser que un atacante ejecutara código en el contexto del usuario que ejecuta la aplicación.”

*Fuente: http://support.microsoft.com/kb/2389418/es

¿Cómo detectar una llamada insegura de DLL?

Para poder encontrar este fallo en un programa, basta con usar la herramienta procmon de Windows Sysinternals: http://technet.microsoft.com/es-es/sysinternals/bb896645.aspx

Una vez descargada vamos a realizar la prueba con pidgin. Para ello abrimos procmon y filtramos por el proceso “pidgin”:

Ejecutamos pidgin y comprobamos que realmente aparecen las diferentes llamadas que hace pidgin al ejecutarse. Una vez ejecutado volvemos a filtrar, esta vez buscaremos por el resultado “PATH NOT FOUND” y filtraremos también el path por todo aquel string que contenga la palabra “dll”.

De esta manera deberán aparecer todas las llamadas a DLLs que han sido realizadas a paths inexistentes:

Ahora solo falta crear el directorio y plantar la DLL para que pidgin la ejecute y de esta manera poder plantar un programa malicioso de manera “silenciosa”.

PoC

Para las siguientes PoC he usado Dropbox y pidgin como un ejemplo de cómo usando estas llamadas inseguras he podido ocultar un “código malicioso” dentro de una DLL el cual es llamado cada vez que se ejecuta uno de estos 2 programas. Los pasos son los siguientes:

Dropbox

• Descargar la siguiente dll: http://www.binaryplanting.com/demo/windows_address_book/wab32res.dll
• Poner dentro de %APPDATA%\Dropbox\bin con el nombre ntmarta.dll
• Ejecutar Dropbox

Pidgin*

• Crear el siguiente Path %USERPROFILE%\.gtk-2.0\2.10.0\engines\
• Descargar la siguiente dll:
• http://www.binaryplanting.com/demo/windows_address_book/wab32res.dll
• Copiar la dll dentro de la carpeta que hemos creado en el paso 1
• Cambiar el nombre de la DLL a libwimp.dll
• Ejecutar Pidgin

*Nota: Cabe destacar que el problema de pidgin viene por el uso de gtk y no del mismo pidgin.

Y aquí las imágenes de la PoC

Y una vez ejecutemos pidgin veremos la siguiente pantalla:

 Lo mismo pasa con dropbox:

Como se puede observar el fallo se puede ejecutar dentro del contexto del usuario y en el caso de Dropbox, esta DLL se ejecutaría cada vez que se iniciara el pc debido a que Dropbox crea un registro para que se ejecute en cada inicio del ordenador.

Esto desde el punto forense podría implicar complicaciones a la hora de encontrar el malware debido a que de entrada, el programa que llama a esta DLL es un programa benigno instalado por el mismo usuario y las librerías que llama están dentro de su path… por lo que a primera vista no debería parecer una llamada “maliciosa”…

Artículo cortesía de @NaxoneZ

Etiquetas: contribuciones , dll injection