<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>Re: [SC-L] Managing the insider threat through code obfuscation</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText19839 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>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)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.
</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature71975 dir=ltr>
<DIV><FONT face=Arial color=#000000 size=2>
<DIV dir=ltr><FONT face=Arial size=2>---</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Dana Epp</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>[Blog: <A
href="http://silverstr.ufies.org/blog/">http://silverstr.ufies.org/blog/</A>]</FONT></DIV></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sc-l-bounces@securecoding.org on behalf of
Kenneth R. van Wyk<BR><B>Sent:</B> Thu 12/15/2005 7:09 AM<BR><B>To:</B> Jose
Nazario<BR><B>Cc:</B> Secure Coding Mailing List<BR><B>Subject:</B> Re: [SC-L]
Managing the insider threat through code obfuscation<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Thursday 15 December 2005 09:26, Jose Nazario wrote:<BR>>
if the person can develop exploits against the holes in the code, what<BR>>
makes you think they can't fire up a runtime debugger and trace the code<BR>>
execution and discover the same things?<BR><BR>Nothing makes me think that at
all; in fact, I was quite skeptical of the<BR>various product claims, which is
why I wanted to hear about others'<BR>experience with
them.<BR><BR>Cheers,<BR><BR>Ken<BR>--<BR>KRvW Associates, LLC<BR><A
href="http://www.KRvW.com">http://www.KRvW.com</A><BR>_______________________________________________<BR>Secure
Coding mailing list (SC-L)<BR>SC-L@securecoding.org<BR>List information,
subscriptions, etc - <A
href="http://krvw.com/mailman/listinfo/sc-l">http://krvw.com/mailman/listinfo/sc-l</A><BR>List
charter available at - <A
href="http://www.securecoding.org/list/charter.php">http://www.securecoding.org/list/charter.php</A><BR></FONT></P></DIV>
</BODY>
</HTML>