Cómo evitar que la DLL maliciosa se use en las llamadas de LoadLibrary o DllImport (.NET)

1

Tengo una situación en la que los archivos maliciosos se copian en el directorio de instalación de algún software y el software cargará esos archivos cuando realice una llamada a LoadLibrary o DllImport (en .NET land).

Si su software se ejecuta con privilegios de administrador, una P / Invoke en una DLL maliciosa puede ejecutar cualquier código de manera elevada, usando su aplicación como un vehículo para hacerlo en su nombre.

Muchas de estas técnicas se pueden encontrar en esta pregunta: Formas de inyectar DLL maliciosas a un archivo exe y ejecutarlo

Lo que pregunto es cómo, como desarrollador de software, ¿puedes prevenir este tipo de ataque? Si quiero importar user32.dll en mi aplicación y hacer una llamada, ¿cómo puedo saber si está cargando la correcta?

En la La documentación de LoadLibrary hace alusión a este problema existente pero no explica exactamente lo que se supone que debes hacer para evitarlo a toda costa.

  

No utilice la función SearchPath para recuperar una ruta a una DLL para una llamada posterior de LoadLibrary. La función SearchPath usa un orden de búsqueda diferente al de LoadLibrary y no usa el modo de búsqueda de proceso seguro a menos que esté habilitado explícitamente llamando a SetSearchPathMode con BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Por lo tanto, es probable que SearchPath busque primero en el directorio de trabajo actual del usuario la DLL especificada. Si un atacante ha copiado una versión maliciosa de una DLL en el directorio de trabajo actual, la ruta recuperada por SearchPath apuntará a la DLL maliciosa, que luego cargará LoadLibrary.

Una solución simple como verificar si el archivo está en una ruta de búsqueda que no espera (como lado a lado con su ejecutable) no funciona muy bien porque se puede cambiar el nombre del ensamblado y poner una redirección en su lugar.

ACTUALIZACIÓN : este artículo en Dynamic-Link La seguridad de la biblioteca explica las cosas bien, sin embargo, todas estas técnicas se pueden omitir fácilmente mediante el mismo proceso copiando los archivos maliciosos. He visto redirección de DLL utilizado para redirigir al malicioso archivos también. Me temo que incluso los enfoques programáticos pueden fallar porque sus aplicaciones pueden modificarse de todos modos para seguir cargando los archivos maliciosos.

¿Todas las aplicaciones de Windows están condenadas a tener esta falla de seguridad?

    
pregunta BrutalDev 24.10.2016 - 17:14
fuente

2 respuestas

3

.NET tiene un DefaultDllImportSearchPathsAttribute puede usar por p / invocar o por ensamblaje para restringir LoadLibrary para obtener solo el DLL desde ubicaciones "seguras".

[assembly: DefaultDllImportSearchPaths(DllImportSearchPath.System32)] 
    
respondido por el Andrew Arnott 17.03.2017 - 00:41
fuente
2
Se pueden firmar

DLL y otros binarios (consulte aquí para saber cómo verificar la firma).

Si no lo están, o si no quiere ir por ese camino, pero sabe qué biblioteca debe supuestamente cargar, entonces puede verificar la suma de comprobación de la biblioteca antes de cargarla. Adquiera un bloqueo de lectura en la biblioteca y libérelo solo después de cargarlo correctamente; De esta manera, evita la pequeña posibilidad de un ataque de carrera (reemplazando la DLL después de la suma de comprobación pero antes de la carga).

Pero sí, necesita cargar la biblioteca usando la ruta completa explícita, de lo contrario, un atacante puede colocar un DLL con el mismo nombre en cualquier directorio que esté marcado antes del correcto. Entonces:

  • obtener la ruta completa
  • bloquear el archivo
  • verificar su firma
  • cargar el archivo
  • desbloquear el archivo
  • hacer espuma, enjuagar, repetir para las otras DLL
respondido por el LSerni 24.10.2016 - 17:49
fuente

Lea otras preguntas en las etiquetas