Testing Techniques to Find the Sin

For access control issues, install the application, and check the access controls set on any objects it creates. Even better still, if you have a way, is to hook the functions that create objects, and log the access controls. This helps you catch nonpersistent objects, like temporary files, events, and shared memory sections.

For embedded secrets, the easiest thing to do is to break apart a binary file using a tool like strings (www.sysinternals.com/ntw2k/source/misc.shtml#strings); this dumps all text strings in an application, and then sees if any of these look password-ish or totally random (a key, perhaps?).

Figure 12-1 shows the output from a small binary file. Look at the string right after Welcome to the Foo application. Looks like a bad attempt at hiding a password or key!


Figure 12-1: Hiding a password in a native code C/C++ application

For applications written in .NET, such as VB.NET, J#, or C#, you can use ildasm.exe, available in the .NET Framework SDK, to perform a more in-depth analysis of an application. The following syntax helps divulge strings in the application, and some of the strings may be embedded secrets.

ildasm /adv /metadata /text myapp.exe findstr ldstr

Figure 12-2 shows that we have hit pay dirt!


Figure 12-2: Finding embedded secrets in .NET applications

The second string looks like a random key, but theres more. The third string is a SQL connection string that connects to SQL Server as sa and has an embedded password to boot! But it gets even better (or worse , depending on who you are). The last string looks like a SQL statement using string concatenation. You may have just found an application that not only is hardcoding secrets but is also committing Sin 4, SQL injection.

Another tool to use for .NET applications is Lutz Roeders Reflector for .NET at www.aisto.com/roeder/dotnet.

Finally, for Java, you could use a disassembler such as dis from www.cs.princeton.edu/~benjasik/dis. Figure 12-3 is sample output on Linux.


Figure 12-3: Finding embedded secrets in Java

Like the .NET sample, this shows some interesting data. Constant #15 is obviously a database connection string, #17 and #19 look like a username and password, and, finally, #21 looks like a SQL statement built using string concatenation. This is obviously very insecure code just waiting to be exploited. In fact, it looks like an exploit could be catastrophic. Look at the SQL statement; this code is handling credit card information!

Jad is another popular decompiler for Java, with an easy-to-use GUI named FrontEndPlus.



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net