How can I proctect my .NET application against DLL Hijacking?

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.