| Groups | Blog | Home |
dotnet security : general concerns regarding hacking of .NET assemblies
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
This post is the exact same as the one above. Msdn said it wasn't able to
post it, but I guess it did anyway ; ) [quoted text, click to view] "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
[quoted text, click to view] "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 [quoted text, click to view] > 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 >
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. [quoted text, click to view] "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 > > > >
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. [quoted text, click to view] "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
Hi Joe
Could you point me to the chapter on storing secrets in Writing Secure Code please, that you mentioned. Thanks! Kind regards Rahul [quoted text, click to view] "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:u7w5YmFvEHA.1308@TK2MSFTNGP09.phx.gbl... > 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
Rahul,
if you open that page: http://www.amazon.com/gp/reader/0735617228/ref=sib_db_rdr/102-4660620-1622554#reader-link and click on Table of Contents link you will see that Protecting Secret Data is chapter 9 of part II of this book (starting on page 299). -Valery. http://www.harper.no/valery [quoted text, click to view] "Rahul Kumar" <rahul.kumar.remove_it@sage.remove_it.com> wrote in message
news:%23pT8GOMvEHA.2192@TK2MSFTNGP14.phx.gbl... > Hi Joe > > Could you point me to the chapter on storing secrets in Writing Secure > Code > please, that you mentioned. Thanks! > > Kind regards > > Rahul > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote > in message news:u7w5YmFvEHA.1308@TK2MSFTNGP09.phx.gbl... >> 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
Thanks a lot Valery!
[quoted text, click to view] "Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
news:%23uCifhMvEHA.3916@TK2MSFTNGP10.phx.gbl... > Rahul, > if you open that page: > http://www.amazon.com/gp/reader/0735617228/ref=sib_db_rdr/102-4660620-1622554#reader-link > and click on Table of Contents link you will see that Protecting Secret Data > is chapter 9 of part II of this book (starting on page 299). > > -Valery. > http://www.harper.no/valery > > "Rahul Kumar" <rahul.kumar.remove_it@sage.remove_it.com> wrote in message > news:%23pT8GOMvEHA.2192@TK2MSFTNGP14.phx.gbl... > > Hi Joe > > > > Could you point me to the chapter on storing secrets in Writing Secure > > Code > > please, that you mentioned. Thanks! > > > > Kind regards > > > > Rahul > > > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote > > in message news:u7w5YmFvEHA.1308@TK2MSFTNGP09.phx.gbl... > >> 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) > >> >> >
Hello,
I have almost the same security problem, and I've reciently found that Strong Names could be easily removed from the assembly, so the hacker is able to modify the code and run the modified application without any problem, and this disturbs me. Here is the link that explais why Strong names are unuseful. http://www.codeproject.com/dotnet/NeCoder03.asp Is there any other way to protect our assemblies? will VS2005 include any aditional security feature for assemblies? P.D: I use MC++ in mixed mode. Thank you very much. [quoted text, click to view] > 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 Jacobo Rodríguez Villar TyphoonLabs Lead Programmer
Yes the strong name can be removed and then the assemblies could be hacked
(you can deter ordinary hackers by using obfuscators), but NO ONE can steal your identity (of course if you have guarded your provate key properly). And your identity is your public key. So the bottom line is, you must deploy your assembly in such a way that the .net framework would only allow such assemblies to execute which have strong names (or digital certificates) of trusted s/w publishers. I think the software publishers along with the .Net system administrators who set the CAS policies, can work together to achieve a sustainable protection for the code. As far as protecting your code from somebody stealing it is concerned, the most agreeable solution to that is using a licensing mechanism for your code/product. HTH, Rahul [quoted text, click to view] "Jacobo Rodriguez Villar" <skdjf@sdkjf> wrote in message news:eIgpe4KyEHA.2572@tk2msftngp13.phx.gbl... > Hello, > > I have almost the same security problem, and I've reciently found that > Strong Names could be easily removed from the assembly, so the hacker is > able to modify the code and run the modified application without any > problem, and this disturbs me. > Here is the link that explais why Strong names are unuseful. > http://www.codeproject.com/dotnet/NeCoder03.asp > > Is there any other way to protect our assemblies? will VS2005 include > any aditional security feature for assemblies? > > P.D: I use MC++ in mixed mode. > > Thank you very much. > > > > 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 > -- > Jacobo Rodríguez Villar > > TyphoonLabs Lead Programmer > > http://www.typhoonlabs.com
Strong names are not security related! Stop relying on them for security
reasons and view them only for the purposes they were invented at the first place - versioning. period. There are plenty ways of stealing private key. Watching spreading rate of malware and spyware suggests that stealing private key from personal computer is trivial task at least on 90% of installed Windows base (refer to the recent publications with claims* that at least 90% of Windows users have spyware running on their computers). That will fall even to the script kiddies. If we go further - very few could actually handle their private keys good (if you ask me - I can't handle my private keys). For handling private keys well (like for example Verisign or Microsoft handles their pks) you would need tempest protected hardware setup in highly electromagnetically isolated location guarded with strong locks and live guards. Electromagnetic radiation, processor heat, power consumption, operation timing and even sound produced by processor - all that was shown to be able leaking private keys to adversaries. No system may be considered secure as long as it doesn't mitigate known security threats. And strong names used for security reasons do nothing with regards to key management and key revocation protocols. Leaving key management and key revocation protocols for in-house implementation would inevitably lead to security weaknesses. -Valery. http://www.harper.no/valery [*] Even so I refer to 90%, but I believe that claim is quite questionable, but even halving it to 45% still presents quite threatening picture. P.S. I have several "strong names " related posts in my blog - if you interesting you can simply search my blog for strong names. [quoted text, click to view] "Rahul Kumar" <rahul.kumar.remove_it@sage.remove_it.com> wrote in message news:O8Mib$uyEHA.2896@TK2MSFTNGP10.phx.gbl... > Yes the strong name can be removed and then the assemblies could be hacked > (you can deter ordinary hackers by using obfuscators), but NO ONE can > steal > your identity (of course if you have guarded your provate key properly). > And > your identity is your public key. So the bottom line is, you must deploy > your assembly in such a way that the .net framework would only allow such > assemblies to execute which have strong names (or digital certificates) of > trusted s/w publishers. I think the software publishers along with the > .Net > system administrators who set the CAS policies, can work together to > achieve > a sustainable protection for the code. > > As far as protecting your code from somebody stealing it is concerned, the > most agreeable solution to that is using a licensing mechanism for your > code/product. > > HTH, > Rahul > > "Jacobo Rodriguez Villar" <skdjf@sdkjf> wrote in message > news:eIgpe4KyEHA.2572@tk2msftngp13.phx.gbl... >> Hello, >> >> I have almost the same security problem, and I've reciently found that >> Strong Names could be easily removed from the assembly, so the hacker is >> able to modify the code and run the modified application without any >> problem, and this disturbs me. >> Here is the link that explais why Strong names are unuseful. >> http://www.codeproject.com/dotnet/NeCoder03.asp >> >> Is there any other way to protect our assemblies? will VS2005 include >> any aditional security feature for assemblies? >> >> P.D: I use MC++ in mixed mode. >> >> Thank you very much. >> >> >> > 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 >> -- >> Jacobo Rodríguez Villar >> >> TyphoonLabs Lead Programmer >> >> http://www.typhoonlabs.com > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |