RE: protecting .NET assemblies from hackers

From: Nate A (NateA_at_discussions.microsoft.com)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 13:49:12 -0700

I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

"Nate A" wrote:

> I am at the beginning stages of writing a massive database-connected business
> management application using the .NET framework and am becoming worried
> about the security of the application upon completion.
>
> I have recently become aware of the ease at which a .NET assembly can be
> disassembled into its easily readable, underlying CLI code. I can see that it
> would not be difficult for a malicious user to disassemble, modify, and then
> recompile in CLI byte code (using the included VS.NET tools). This concerns
> me deeply since I can see how easy it would be to obtain critical information
> within the code.
>
> I looked into code obfuscation tools such as DotFuscator. As far as I can
> tell, these tools can only make your code harder to understand by renaming
> CLI metadata to more or less random names, and optionally encrypting internal
> strings (such as "salts" to use in encryption/decryption algorithms or
> passwords used to access remote data, like a database server). Apparently
> they can also slightly modify the way an algorithm operates to hide the
> details of the algorithm while maintaining the true functionality of the
> algorithm. However, algorithm hiding is not my big concern so that is
> irrelevant.
>
> This, however, fails to put my mind at ease since much can be understood
> about the code after disassembling an obfuscated assembly.
>
> For example, if one's application has a class containing methods for
> encryption and decryption of data using the .NET Framework's "Cryptography"
> namespace, a hacker needs only to look for classes that "Imports" the
> Cryptography namespace, or that make calls to members of that namespace in
> order to realize "hey, I bet this class contains the functions used for this
> applications encryption." The class may be named "a", with public members
> "a", "b" and "c" by the obfuscator, but the hacker still knows that members
> "a", "b" and "c" probably do encryption and decryption.
>
> So now let me get to a particular concern of mine dealing with my
> application and see if anyone has any suggestions.
>
> My application connects to a remote database, so let’s say a hacker wants to
> cop the database password from my app. He knows there must be a database
> password stored somewhere in the application code, registry, or an external
> settings file. WHERE it is stored is more or less irrelevant since it won’t
> be hard to find it either way. I happen to store it in a XML settings file.
> Of course the password is encrypted in the file, but once the hacker finds
> the encrypted password string, he knows that at some point in the
> application, the string will be decrypted when it needs to be sent to the
> database server to log onto the database.
>
> So once he finds the CLI code in the assembly where the encrypted password
> is fetched from the settings file, pushed onto the stack, and then a call is
> made to a method in the suspected encryption/decryption class, he has now
> figured out the method that decrypts the password and can use this to wreak
> havoc on my app.
>
> It seems to me that all the programmer has to do at this point to get the
> decrypted password is add a little CLI code after the point where the
> password is decrypted. I don't know much of the specifics of the CLI
> language, but after inspection of my disassembled code, the hacker could add
> something like:
>
> //push the decrypted string onto the stack
> ldstr "the decrypted password string returned by the 'secret' decryption
> function"
>
> //call the visual basic "messagebox" method to show him the decrypted string
> call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)
>
> Boom, there it is, the database password shown to the hacker in a MsgBox! He
> now has free reign to log into my database and delete records or replace all
> credit card numbers with "suck it!" if he wants (or whatever it is these guys
> like to do BESIDES getting laid!)
>
> So the only thing I can see that would almost guarantee that a hacker could
> not do this would be by not allowing him to modify the code, like having the
> program detect if it was modified before it was run. I'm not aware of any way
> to do this that is built into the .NET Framework, but if this exists, maybe
> someone can let me know.
>
> I also considered the possibility of calculating the .exe file's checksum,
> sending it along with the application in some form or another, and then
> having the application calculate it's own checksum each time it's run, and
> check it against the stored value and throw an error if they do not match. (I
> was hoping that the .NET framework had this kind of security built in, but I
> haven't come across it yet.) Has anyone ever tried this? Or can anyone think
> of some pitfalls of this method?
>
> So anyway, I hope this post will catch the eye of someone who knows more
> about these kinds of things than me and maybe they can point me in the right
> direction on how to secure my code considering these issues mentioned above.
>
> Thanks for taking the time to read this.
> -Nate A

Relevant Pages

  • RE: protecting .NET assemblies against hackers
    ... Your correct it's trivial to decompile the whole app including db passwords. ... > disassembled into its easily readable, underlying CLI code. ... > passwords used to access remote data, like a database server). ... > My application connects to a remote database, so let’s say a hacker wants to ...
    (microsoft.public.dotnet.security)
  • RE: general concerns regarding hacking of .NET assemblies
    ... > disassembled into its easily readable, underlying CLI code. ... > CLI metadata to more or less random names, and optionally encrypting internal ... > passwords used to access remote data, like a database server). ... > My application connects to a remote database, so let’s say a hacker wants to ...
    (microsoft.public.dotnet.security)
  • RE: protecting .NET assemblies from hackers
    ... >> disassembled into its easily readable, underlying CLI code. ... >> passwords used to access remote data, like a database server). ... >> My application connects to a remote database, so let’s say a hacker wants to ... >> figured out the method that decrypts the password and can use this to wreak ...
    (microsoft.public.dotnet.general)
  • RE: protecting .NET assemblies from hackers
    ... > disassembled into its easily readable, underlying CLI code. ... > CLI metadata to more or less random names, and optionally encrypting internal ... > passwords used to access remote data, like a database server). ... > My application connects to a remote database, so let’s say a hacker wants to ...
    (microsoft.public.dotnet.general)
  • Re: general concerns regarding hacking of .NET assemblies
    ... > management application using the .NET framework and am becoming worried ... > CLI metadata to more or less random names, and optionally encrypting ... > passwords used to access remote data, like a database server). ... in .Net to sign your assemblies with a strong name, ...
    (microsoft.public.dotnet.security)