Re: protecting .NET assemblies against hackers

From: Mary Chipman (mchip_at_online.microsoft.com)
Date: 10/27/04 

Date: Wed, 27 Oct 2004 09:59:02 -0400

All of your concerns are valid, you must always assume that your
application will be attacked. The first rule is, NEVER store secrets
in your code on on the client machine. That goes for passwords,
encryption keys, connection strings or any other sensitive
information. You must always assume that an attacker has full access
to every line of your source code. Cryptography is useless if an
attacker can get hold of the private key. That being said, the only
way to assure that an attacker has no access to your source code is to
run the application as a web service.

--Mary

On Tue, 26 Oct 2004 10:47:03 -0700, Nate A
<NateA@discussions.microsoft.com> 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: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)
  • Re: embedded keys - there has to be a less vulnerable approach
    ... the database would be run on top of an encrypting file system ... > The use of an asymmetrical encryption algorithm does not seem to offer ... because the encryption and decryption ... > a hostile attacker is not a member of that small knowledgeable elite. ...
    (comp.security.misc)
  • Re: subtext search in encrypted text
    ... > database, so encryption takes place on a client host of the database. ... you could to make it more difficult for an attacker ...
    (sci.crypt)
  • [UNIX] Ultimate PHP Board Multiple Vulnerabilities
    ... Ultimate PHP Board Multiple Vulnerabilities ... If the attacker ... UBP uses an in house developed database implementation called TextDB. ... This vulnerability leads to code execution. ...
    (Securiteam)
  • 2005-Problem restoring database with encrypted columns to diff ser
    ... I need to start encrypting several fields in a database and have been doing ... OPEN MASTER KEY DECRYPTION BY PASSWORD = 'testAppleA3'; ... ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY; ... encryption by certificate test; ...
    (microsoft.public.sqlserver.security)