Saltar al contenido

Ocultar Malware usando ataques de precarga de DLL

¿Cómo se da este fallo?

Cuando un programa desarrolla llamadas a DLL sin definir específicamente el PATH o son llamadas que intenta acceder a PATHS que un usuario con no muy buenas intenciones podría cambiar.
Si queremos acceder a más información podemos acceder al siguiente enlace:
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?
Según lo establecido por Microsoft, la precarga insegura de DDL es lo siguiente:
“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?
Si queremos detectar esta falla en un programa, lo único que será necesario que hagamos es emplear la herramienta procmon de Windows Sysinternals: 
http://technet.microsoft.com/es-es/sysinternals/bb896645.aspx
Cuando la descarguemos, tendremos que efectuar una prueba con, para lo cual vamos a tener que abrir procmon y filtrar el proceso “pidgin”:
Luego tendremos que proceder a ejecutar pidgin y corroborar que aparecen las distintas llamadas que efectúa pidgin cuando se ejecuta. Una vez completado lo anterior, vamos a tener que volver a filtrar, pero ahora vamos a buscar por resultado “PATH NOT FOUND” y también vamos a filtrar el path por los string que incluyan la palabra “DLL”.
Si seguimos los pasos de forma correcta, deberíamos ver todas las llamadas a DLL que se efectuaron a paths que no existen:
Lo único que resta es crear el directorio y plantar la DLL para que pidgin lleve a cabo la ejecución. Así vamos a poder plantar un programa malicioso sin que nadie lo note.
PoC
Para las PoC vamos a emplear Dropbox y pidgin, como un ejemplo de como utilizar estas llamadas no seguras se puede ocultar el “código malicioso” dentro de una DLL que es llamado cada vez que se ejecuta cualquiera de los 2 programas.
Los pasos que tendremos que seguir son:
Dropbox
  • Descargar la siguiente dll: http://www.binaryplanting.com/demo/windows_address_book/wab32res.dll
  • Poner dentro de %APPDATA%Dropboxbin con el nombre ntmarta.dll
  • Ejecutar Dropbox
Pidgin*
  • Crear el siguiente Path %USERPROFILE%.gtk-2.02.10.0engines
  • 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: El problema de pidgin viene por el uso de gtk y no del mismo pidgin.
Imágenes de la PoC
Una vez ejecutemos pidgin veremos la siguiente pantalla:
Con dropbox:
 
Tal y como podemos ver, el fallo puede ejecutarse en el contexto del usuario y en el caso de Dropbox, la DLL se ejecuta cada vez que el ordenador se inicie, ya que Dropbox crea un registro para que se ejecute en cada oportunidad en que iniciamos la PC.
Encontrar el malware puede convertirse en una tarea realmente compleja, ya que desde el comienzo el programa que llama a esta DLL es un programa benigno que se instala por el mismo usuario y las librerías que llama se encuentran dentro de su path, por lo que dando un primer vistazo, no debería dar indicios de que se trata de una llamada maliciosa.
]]>