Tenemos una aplicación .NET 3.5 con extensiones registradas. ¿Cómo podemos protegerlo contra los ataques de secuestro de DLL?¿Cómo puedo proteger mi aplicación .NET contra el secuestro de DLL?
Debido a la herencia & problemas de diseño fuerte de nombres/firma no es una opción en este momento
información adicional si usted no sabe lo que es DLL Secuestro:
Si tiene privilegios de acceso a la carpeta/datos, puede escribir el código para buscar y buscar proactivamente en los mismos lugares donde Windows busca su .DLL antes de llamar a su propio .DLL (o busque en todo el disco), y puede calcular una verificación CRC para su DLL legítima u otra coincidencia de patrón para comparar su legit.DLL en archivos DLL localizados y que coincidan, y así asegurarse de que nadie más lo haya secuestrado (colocó un archivo en una ubicación que se buscaría antes de su propia ubicación, o incluso cualquier ubicación). Esto podría requerir un poco de investigación sobre la metodología bajo diferentes versiones de Windows para los distintos órdenes de búsqueda. Luego, si encuentra un intento de secuestro, podría tomar alguna medida, dependiendo de qué tan seguro esté de que alguien está intentando secuestrar su DLL ... Cambie el nombre de faker.DLL, elimínelo, notifíquelo al usuario, notifique al administrador, no lo haga. t llame a su DLL, etc.
CRC no se diseñó teniendo en cuenta la seguridad, no es la herramienta adecuada para el trabajo. Algo como SHA sería mucho mejor. – svick
Me encontré con un problema similar, había terminado escribiendo mi propia lógica para verificar el dll. Para mí solo estaba usando ese dll en LGPL fashion (no puedo modificar el dll), pero quería asegurarme de que mi aplicación utilizara el dll genuino (no el hi-jacked).
solución simple:
mejor solución:
Si tiene algún certificado de CA confiable como verisign, puede usar ese certificado en lugar de utilizar el par de valores clave RSA.
De esta manera, incluso si alguien reemplaza su dll con dll crackeado, el hash no coincidirá y su aplicación sabrá el intento de secuestro.
Este enfoque podría se mejor que sólo da DLL un nombre fuerte, porque, puede ser fuerte verificación del nombre se puede desactivar mediante la ejecución de
SN -Vr HijackedAssembly
la esperanza que esto le ayuda, o alguien que quiera entender las cosas de la firma de cómo digitales trabajar internamente
Esta técnica en realidad está en contra de la naturaleza de LGPL. LGPL requiere que cualquier dll cargado debe ser reemplazable por el usuario con su propia versión de dlls, la excepción es si todo el proyecto está bajo la (L) GPL. – mlehmk
Buen punto @mlehmk, tienes razón, según LGPL v3 sección 4.d.1, la biblioteca LGPL debe ser reemplazable por el usuario. Pero según esa misma sección, en la medida en que proporcionemos un mecanismo para que el usuario reemplace la biblioteca LGPL, estaríamos bien. Esta pregunta era sobre el secuestro de DLL, así que no ingresé a las complejidades de la licencia. – Vishalgiri
¿No pudo incluir el dll como recurso y escribirlo en el lugar que desea en tiempo de ejecución y luego cargar el dll en el ensamblado? Hice esto una vez porque queríamos distribuirlo como un .exe, pero creo que también resolvería este problema, ¿no?
Robert,
En la imparcialidad a la pregunta de Jim acerca de "qué tipo de diseño sería eso". Al responder, en lugar de simplemente decir "es lo que es", podría darnos una idea de las limitaciones en que deben caer nuestras sugerencias/soluciones.
Dicho de otra manera, sin saber por qué el código heredado le impide hacerlo de la "manera correcta", es difícil proporcionar soluciones ideales para su problema.
A menos que su arquitectura evite la idea de suma de comprobación MD5 sugerida por Vishalgiri, le sugiero que siga su consejo. Sin embargo, una vez más, sin saber qué aplicación (es) llama a estas DLL y por qué no se pueden firmar, es difícil saber si esto funcionará para usted.
Mi idea puede ser mucho más simple, pero ¿no puede ajustar su aplicación para precargar la DLL desde una ubicación predefinida? Por ejemplo, solo permita que se cargue desde la carpeta BIN de su aplicación principal, y en su defecto, ¿nunca más?
ver este enlace sobre cómo cargar desde un camino distinto: http://www.chilkatsoft.com/p/p_502.asp
esto puede ser más rápido que escribir todo el código MD5 checksum. Aunque me gusta esa idea también.
* Debido al diseño, los nombres/firmas fuertes no son una opción * - bueno, entonces su diseño hace que los ensamblajes sean vulnerables al secuestro de DLL. –
¿Qué tipo de diseño sería, sin permitir conjuntos con signo o con nombre fuerte? –
Jim es un mal diseño, razón de herencia, problemas de sistema de complementos, etc. Como un millón de otras aplicaciones del mundo real. –