Re: general concerns regarding hacking of .NET assemblies

• Previous message: Joe Kaplan \(MVP - ADSI\): "Re: Mixing authentication type flags & By design Bug from MS ?"
• In reply to: Rahul Kumar: "Re: general concerns regarding hacking of .NET assemblies"
• Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: general concerns regarding hacking of .NET assemblies"
• Reply: Joe Kaplan \(MVP - ADSI\): "Re: general concerns regarding hacking of .NET assemblies"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 27 Oct 2004 12:09:03 -0700

Thanks Rahul. That is exactly the solution I'm looking for.

I looked into Stong Name Signing and what I am able to do is delay sign the
assembly, obfuscate it with DotFuscator, and then sign it with sn.exe. This
provides a security level I am comfortable with.

Thanks a lot for the help.

"Rahul Kumar" wrote:

>
> "Nate A" <Nate A@discussions.microsoft.com> wrote in message
> news:C9247B9A-9521-4BB4-9B6F-FE746B9DAC2A@microsoft.com...
> > 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.
> >
>
> Hi,
>
> If I have understood the issue correctly that there does exist a mechanism
> in .Net to sign your assemblies with a strong name, which will help the CLR
> detect that the code has been tampered with, before running the code. The
> code signing process (by strong name) makes a hash of all the files that
> makes up your assembly, then encrypts the hash with a private key, places
> the encrypted hash and the public key in the assembly manifest for the CLR
> to grab it verify the integrity of your assembly before executing it.(Raises
> exception if hashes don't match)
> Please let me know if this is what you wanted to know.
>
> Regards
>
> Rahul
>
>
> > 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
> >
>
>
>

• Previous message: Joe Kaplan \(MVP - ADSI\): "Re: Mixing authentication type flags & By design Bug from MS ?"
• In reply to: Rahul Kumar: "Re: general concerns regarding hacking of .NET assemblies"
• Next in thread: Joe Kaplan \(MVP - ADSI\): "Re: general concerns regarding hacking of .NET assemblies"
• Reply: Joe Kaplan \(MVP - ADSI\): "Re: general concerns regarding hacking of .NET assemblies"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]