How can I proctect my .NET application against 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

Have a look at this thread....it might help you and give you insight....another thing, you can certainly check out EasyHook, and intercept the API createRemoteThread and find out if the DLL is one of the unauthorized ones.... have a look at this thread that explains how to block against dll injection

Answer 2

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 3

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 4

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 5

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.