Re: general concerns regarding hacking of .NET assemblies

From: Rahul Kumar (rahul.kumar.remove_it_at_sage.remove_it.com)
Date: 10/27/04 

Date: Wed, 27 Oct 2004 09:22:53 +0100

"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
>

Relevant Pages

  • Re: general concerns regarding hacking of .NET assemblies
    ... >> CLI metadata to more or less random names, and optionally encrypting ... >> passwords used to access remote data, like a database server). ... >> Of course the password is encrypted in the file, but once the hacker finds ... > in .Net to sign your assemblies with a strong name, ...
    (microsoft.public.dotnet.security)
  • 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)
  • SQLClientPermission problem
    ... The database is on Machine 1. ... Both machines have SQL Server 2005 Express installed. ... assemblies on my local intranet signed with my strong name. ...
    (microsoft.public.dotnet.security)
  • Re: AES Questions From Another Dummy.
    ... C++ rand() is typically not recommended. ... Encrypting so several people can read it makes me think public-key crypto.. ... The other extreme would be to have everything in the database encrypted using ...
    (sci.crypt)
  • Re: SQLClientPermission problem
    ... The database is on Machine 1. ... SqlClientPerrmission exception when opening the database connection. ... assemblies on my local intranet signed with my strong name. ...
    (microsoft.public.dotnet.security)