RE: protecting .NET assemblies from hackers

From: Allan (Allan_at_discussions.microsoft.com)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 13:59:20 -0700

of course, but that only exposes problems with .net updater. unless you are
not using that..

"Nate A" wrote:

> 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 from hackers
    ... sifting though the .NET framework help regarding assembly signing. ... > 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.general)
  • 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. ... > 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: protecting .NET assemblies against hackers
    ... encryption keys, connection strings or any other sensitive ... You must always assume that an attacker has full access ... underlying CLI code. ... >passwords used to access remote data, like a database server). ...
    (microsoft.public.dotnet.security)