Managing the insider threat through code obfuscation

[dana at vulscan.com (Dana Epp)]

There are no absolutes here. Obfuscation has its place. I use Xenocode's Obfuscator for my .NET code. I do not do it to 
try to hide bad code from intense scrutiny from potential attackers. I do it to hide business logic from the looky-loos 
who have tools like Reflector and may want to blatently rip it off. (which has happened before)
 
Weighing my risks accordingly, I expect that once the byte code is converted to native instructions on the target 
system, that any competent person can easily look at the disassembly and do their bidding. If they are gods with 
disassemblers, all the power to them. But they can do that with any code on the system, be it driven from bytecode 
converted to native or directly linked with the linker. So the threat level is the same at that point.
 
Obfuscation is just another layer of defense for business logic from what I would consider 'layer one' attackers. 
Depending on the tools you use it can work, and work well. It's designed to mitigate against a certain type of threat. 
However, anyone with enough patience, a copy of Gary and Greg's "Exploiting Software" and a copy of IDA Pro will be 
able to break the shackles of such tools and get deep into the bowels of the executing code. Nothing is going to stop 
that.
 
Now let's look at your original example of being able to get a great deal of information about the internals of 
databases etc. The reality is that such information shouldn't be IN the application in the first place. When possible 
secrets like db passwords should use the native operating system's security mechanisms (ie: Trusted connections, 
Windows Authentication, DPAPI etc when working on Windows) to store and manage credentials. Rather that concatinating 
query strings (which are harder to obfuscate btw) try to use things like stored procedures (where appropriate) that 
keeps the db structure on the server while at the same time giving another layer of validation control for input. I 
know I am preaching to the choir here. 
 
My point is that no matter what the language is, and what the threat is you are expecting to mitigate against, 
different tools can do different things. Obfuscation has it's place. As does a deep hole, some cement and a shovel. You 
can dig your own bunker however you see fit. How strong you make it depends on what sort of attack you are fretting 
about.
 
---
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

________________________________

From: sc-l-bounces at securecoding.org on behalf of Kenneth R. van Wyk
Sent: Thu 12/15/2005 7:09 AM
To: Jose Nazario
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] Managing the insider threat through code obfuscation



On Thursday 15 December 2005 09:26, Jose Nazario wrote:
> if the person can develop exploits against the holes in the code, what
> makes you think they can't fire up a runtime debugger and trace the code
> execution and discover the same things?

Nothing makes me think that at all; in fact, I was quite skeptical of the
various product claims, which is why I wanted to hear about others'
experience with them.

Cheers,

Ken
--
KRvW Associates, LLC
http://www.KRvW.com
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20051215/4e39806a/attachment.html