protecting .NET assemblies from hackers

[Guest]

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

 

[Guest]

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.

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

 

[Guest]

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.

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.

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

 

[Guest]

I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

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

 

[Guest]

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

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.

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.

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

 

[Guest]

of course, but that only exposes problems with .net updater. unless you are
not using that..

I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

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

 

[Guest]

Yeah, as far as I can see in the future, updates of the program could just be
done by completely overwriting the application, since distribution size is
not really an issue becuase it will be distributed over a local network and
not over the internet.

Thanks for your suggestions.

of course, but that only exposes problems with .net updater. unless you are
not using that..

I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

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