Re: general concerns regarding hacking of .NET assemblies

From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 10/27/04 

Date: Wed, 27 Oct 2004 14:17:26 -0500

And by all means, don't store any secrets in your code such as encryption
keys and passwords. There is a great chapter on storing secrets in Writing
Secure Code that is well worth the read, especially if you need to store
secrets anyway. The bottom line is that there is no perfect way to do it,
but there may be approaches that provide an adequate level of security.

Best of luck.

Joe K.

"Nate A" <NateA@discussions.microsoft.com> wrote in message
news:18110E27-340D-4F15-808B-44636414E7CF@microsoft.com...
> 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
>> >
>>
>>
>>

Relevant Pages

  • Re: Employer charging employee.
    ... Most of the 'secrets' were not secret at all but branded so by the ... The hard drive or encrypted so that even if the laptop was lost no ... when quantuum computers become feasible then encryption goes out the ... Cracking an encrypted drive is a brute force exercise. ...
    (uk.legal)
  • Re: Twin T Notch Anomaly
    ... There are no secrets on my page - so please ... It seems that encryption might not be offering ... folder by folder, file by file. ... So nothing is really safe then? ...
    (rec.audio.tubes)
  • RE: Resetting secrets
    ... Error Message: ... The maximum number of secrets that may be stored in a single system ... Although YOU may not have installed encryption or encrypted software on your ... they have an explanation. ...
    (microsoft.public.windows.vista.general)
  • Re: Decompiler.NET reverse engineers your CLS compliant code
    ... CLR, right? ... >> encryption may work with the clr the only thing that could unencrypt it. ... > This shouldn't be a big problem, but since all assemblies will be ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Decompiler.NET reverse engineers your CLS compliant code
    ... CLR, right? ... >> encryption may work with the clr the only thing that could unencrypt it. ... > This shouldn't be a big problem, but since all assemblies will be ...
    (microsoft.public.dotnet.languages.vb)