RE: general concerns regarding hacking of .NET assemblies
From: Nate A (NateA_at_discussions.microsoft.com)
Date: 10/26/04
- Previous message: Nate A: "protecting .NET assemblies against hackers"
- In reply to: Nate A: "general concerns regarding hacking of .NET assemblies"
- Next in thread: Rahul Kumar: "Re: general concerns regarding hacking of .NET assemblies"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 26 Oct 2004 11:13:05 -0700
This post is the exact same as the one above. Msdn said it wasn't able to
post it, but I guess it did anyway ; )
"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
>
- Previous message: Nate A: "protecting .NET assemblies against hackers"
- In reply to: Nate A: "general concerns regarding hacking of .NET assemblies"
- Next in thread: Rahul Kumar: "Re: general concerns regarding hacking of .NET assemblies"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
