0

In order to defend my products against sideload attacks, I would like to verify that the DLLs that I load into the the application, are really the DLLs that I expect, and not a compromised DLL with the same name.

I've considering generering hashes of all DLLs on build, and verifying a DLLs hash every time it's loaded/accessed.

What's the best way to do this? Are there tools I can just plug into my applications, or do I need to write something myself?

Squazz
  • 3,912
  • 7
  • 38
  • 62
  • 7
    Isn't this what assembly signing is for? – 500 - Internal Server Error Dec 19 '22 at 09:49
  • @500-InternalServerError Just because a DLL is signed, I guess it can still be replaced by another signed DLL. Right? Or am I missing something here? – Squazz Dec 19 '22 at 10:24
  • My understanding is that if you referenced a signed/strong named library, it only accepts that exact library & version that it was compiled with. But I can't find a reference to the exact rules. But what are you protecting against? If you install your application in the program files folder only administrators should be able to place files there. And there is little you can do to defend against an administrator. – JonasH Dec 19 '22 at 10:31
  • @JonasH that is what I'm hoping. But I can't find any definity answer to that. Hence my question ;) Regarding protecting myself against an administrator, then no I can't protect myself against an admin replacing my entire program, but I should be able to protect my app against replacement of a DLL – Squazz Dec 19 '22 at 10:39

1 Answers1

3

If someone has enough permissions to insert custom DLL into your process, then has enough permissions to modify your binaries and patch (crack?) your dll/exe and skip your check.

TcKs
  • 25,849
  • 11
  • 66
  • 104
  • 1
    That depends a lot on how and where it's done - e.g. if the external binaries are fetched from a private artifactory on compile, an attacker could have access to that alone, overriding binaries that are included in the build process. The custom part of the code might never be stored there. – Johny Skovdal Dec 23 '22 at 14:28
  • 1
    Or it's a worm trying to do it, replacing a well known NuGet package, and hoping that someone would "call home". – Johny Skovdal Dec 23 '22 at 14:29