RE: protecting .NET assemblies from hackers

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

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

if you do not want to store any significant info on your application, you can
try exposing a web service or a remote class..

"Nate A" wrote:

> I actually have to store the database password somewhere outside the assembly
> because it can be changed by the user. It is encrypted where it is stored
> however. But even if I were to not allow the user to change the password and
> just have the pasword somewhere in code like
>
> Dim pass as string = "mypass"
>
> This could be easily read by opening the .exe in a hex editor or
> dissasembling it. So one thing to do here is use a code obfuscator to encrypt
> this string in code. But obfuscator encryption is easily breakable since the
> decryption method is included in the code by definition. That's why I need
> some kind of protection that can actually detect if the .exe file has been
> modified, e.g. by computing it's checksum and comparing it to what it's
> supposed to be.
>
> The problem with having different database accounts that restrict access to
> operations on certain tables is that my application is to be used by people
> who have varying degrees of access (managed by the application). This access
> will range from very limited--users who only have access to a few forms that,
> in turn, modify data on the database--to full acess--access to forms that can
> edit data on basically every table in the database. So with this in mind, the
> "master" db password would still have to be stored somewhere on the
> application, which doesn't improve the situation.
>
> "Allan" wrote:
>
> > interesting.. but why would you store an administrator password again in your
> > config file? maybe you can create a new database user and give that user only
> > the access necessary. permissions on stored procedures most probably.. then
> > do not allow that user to do anything else..
> >
> > there are other levels of security you can implement. do not put all the
> > burden in your application. if it is a web application, maybe you can use
> > other methods of security like domain authentication or using ssl. or
> > limiting access to certain ip addresses.
> >
> >
> > "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: Application security question
    ... you want to implement security. ... So you are protecting the database from direct querying and altering ... login credentials for the database from the application. ... Why encrypt the password? ...
    (comp.lang.java.programmer)
  • Re: if I encrypt key data why do I want or need SSL?
    ... I could encrypt the ... external sources beyond the control of my security. ... name DLL responsible for all security aspects, ... Web Services use the same approach, none of my web service will do anything ...
    (microsoft.public.dotnet.security)
  • Re: SSN encryption
    ... >> We want to encrypt social security numbers in a database. ... address and SSN are always excluded. ... exposed if there were a breakdown in the other security precautions. ...
    (sci.crypt)
  • Re: Which is more secure RC2 or RC4 ?
    ... same database temporarily, until the order is approved manually and the ... obviously there are a LOT of security related issues that arise ... itself in order to decrypt the information, ... meaning if I encrypt the information using AES and a password driven ...
    (sci.crypt)
  • Re: web parts security
    ... ok we are trying to develop web parts that logon to our web service. ... service interacts with the database on our database server. ... security which manages the permissions for all users to the database. ... I was thinking of using code access security for the ...
    (microsoft.public.sharepoint.portalserver.development)
Loading