We have a .NET 3.5 application with registered extensions. How can we protect it against DLL Hijacking attacks?
Because of legacy & design problems strong naming/signing is not an option right now
Extra Information if you don't know what DLL Hijacking is:
I had came across similar issue, I had ended up writing my own logic for verifying the dll. For me I was just using that dll in LGPL fashion (I can't modify the dll), but wanted to make sure that my application uses the genuine dll (not the hi-jacked one).
Simple solution:
Better solution:
If you have any certificate from trusted CA like verisign, you can use that certificate instead of using RSA key value pair.
This way even if someone replaces your dll with cracked dll, the hash will not match and your application will know the Hijacking attempt.
This approach could is better than only giving dll a strong name because, may be strong name verification can be disabled by running
SN -Vr HijackedAssembly
Hope this helps you, or someone who wants to understand how digital signature things work internally.
Robert,
In fairness to Jim's question about "what kind of design would that be". By answering, instead of just saying "it is what it is" you could give us insight into the constraints our suggestions/solutions must fall within.
Put another way, without knowing why the legacy code prevents you from doing it the "right way" it's hard to provide ideal workarounds to your problem.
Unless your architecture prevents the MD5 checksum idea suggested by Vishalgiri, I'd suggest taking his advice. Again though, without knowing what application(s) call these DLLs and why they can't be signed, it's hard to know if this will work for you.
My idea might be a lot simpler, but can you not adjust your application to preload the DLL from a predefined location? For example, only allow it to load from the BIN folder of your main applicaton, and failing that - never try again?
See this link on how to load from a distinct path: http://www.chilkatsoft.com/p/p_502.asp
This may be faster than writing all the MD5 checksum code. Even though I like that idea as well.
如果要混淆您的应用程序,则在混淆之前先使用ILMerge将DLL与EXE合并,将提供针对DLL劫持的绝对保护,还可以消除未使用的代码,并为您提供独立的EXE。
Couldn't you include the dll as a resource and write it out to where you want at run time then load the dll into the assembly? I did this once because we wanted to distribute as one .exe but I think it would also solve this problem, wouldn't it?
If you have folder/data access priveledges, you could write code to proactively go and look in the same places Windows looks for your .DLL prior to calling your own .DLL (or search the whole drive), and you could compute a CRC check for your legit DLL, or other pattern match to compare your legit.DLL on located, matching DLL files, and thus make sure no one else has hijacked you (placed a file in a location that would be searched prior to your own location - or even any location). This could take some research into the methodology under different versions of Windows for the various orders of searches. Then, if you find a hijacking attempt, you could take some action, depending on how sure you are that someone is trying to hijack your DLL... Rename the faker.DLL, delete it, notify the user, notify admin, don't call your DLL, etc.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.