如何保护.NET应用程序免受DLL劫持？

Question

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:

• What's DLL Hijacking - SO
• DLL hijacking vulnerabilities

Answer 1

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:

• While developing the application create MD5 Checksum of the dll and hardcode the hash in the application
• Everytime you start the application use the same logic to generate the MD5 Checksum of the dll file and compare it with the hardcoded one.
• You might be already aware but here is how to efficiently generate the Checksum of a file (see answer: https://stackoverflow.com/a/1177744/392850 )

Better solution:

• Generate hash of the dll, with strong Hashing algorithm and salt
• Generate RSA key value pair (private key and public key)
• Encrypt the hash of the dll with your private key
• Embed the public key, "encrypted hash" and salt in your application
• Upon application start, decrypt the "encrypted hash" with your public key
• Generate the Hash again at runtime with the same salt, and compare with the hash decrypted using the public key

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.

Answer 2

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.

Answer 3

看看这个线程 ....它可能会帮助您并为您提供见解....另一件事，您当然可以签出EasyHook ，并拦截API createRemoteThread并确定DLL是否是未经授权的DLL之一。 ...看一下这个线程 ，它解释了如何阻止dll注入

Answer 4

如果要混淆您的应用程序，则在混淆之前先使用ILMerge将DLL与EXE合并，将提供针对DLL劫持的绝对保护，还可以消除未使用的代码，并为您提供独立的EXE。

Answer 5

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?

Answer 6

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.