Alik Levin's : Code Inspection

Security Code Review – Use Visual Studio Bookmarks To Capture Security Findings

alikl — Thu, 24 Jan 2008 16:38:46 GMT

How to streamline the process of capturing security flaws during security code review? How to save time and avoid switching between the tools? How to stay focused?

In this post I will show my simple technique to capture security flaws using Bookmarks in Visual Studio.

Create bookmark folders. Hit Ctrl + K and then Ctrl + W to bring Bookmarks window up. Create 10 folders according to security frame categories:

Focus on one category. Grab security checklist document you created using Guidance Explorer. Choose one category from the security frame, Authentication for example, and inspect the code manually. Do not pay attention to anything else on your way but Authentication issues. One category a time.

Bookmark security bugs. Once you find security bug hit Ctrl + K and then Ctrl +K again. You just created the bookmark. Drag it into the appropriate folder in Bookmarks window. Move on. When you finish the inspection using your checklist you should have something like this:

Copy to the report in one run. Just run through the bookmarks and paste the findings to your final report. One run. Mechanical work. Done. Peace of mind.

My related posts

Use DIR Command To Generate List Of Files And Store It In File

alikl — Sat, 01 Dec 2007 17:16:50 GMT

DIR /S /B /A:-D

I use simple DIR command to generate file lists. It serves me in many scenarios. For example, I use it to generate .Net assemblies list when I conduct preliminary scan as part of code inspection process. Here are the explanations to the switches:

/S - search sub folders
/B - bare format, no summaries and headings
/A:-D - no directories, files only

To save generated list of files into text file simply add >C:\myfileslist.txt. The resulting command would look as follows:

DIR /S /B /A:-D *.DLL >C:\myfileslist.txt

My related posts:

XSSDetect Public Beta now Available!

alikl — Wed, 24 Oct 2007 23:21:32 GMT

XSSDetect public beta is now available for download on MSDN.

Overview

XSSDetect is a static code analysis tool that helps identify Cross-Site Scripting security flaws found within Web applications. It is able to scan compiled managed assemblies (C#, Visual Basic .NET, J#) and analyze dataflow paths from sources of user-controlled input to vulnerable outputs. It also detects whether proper encoding or filtering has been applied to the data and will ignore such "sanitized" paths.

Related resources:

My related posts:

XSS? - Do not Make Me Laugh, We Use WinForms

Enjoy

Visual Studio 2005 As General Code Search Tool

alikl — Wed, 06 Jun 2007 00:50:51 GMT

Visual Studio 2005 has powerful search capabilities. One of my favorites is "Find in Files".

Just hit Ctrl+Shift+F (more shortcuts - My Favorite Shortcuts).

Essentially it uses FindStr utility that sits in System32 folder and comes for free with Windows OS. FindStr is a command line utility and those who like typing would prefer it, but those who like UI would go for Visual Studio. There is no need to open project - just fire up Visual Studio and hit Ctrl+Shift+F.

I discussed different searching options I practice here - Security Code Inspection - Eternal Search For SQL Injection , but I thought FindStr and its utilization in Visual Studio deserves special attention.

The best part I like is that after hitting "Find All" button I am presented with list of all files that matched the search criteria and the match itself, so I can quickly evaluate what I got in my net. Once I smell something fishy I hit the file and it opens in the very same Visual Studio for detailed inspection. I think it is very handy.

Enjoy.

Security Code Inspection - Eternal Search For SQL Injection

alikl — Sat, 31 Mar 2007 23:04:00 GMT

Here are couple of techniques I used for searching hints of SQL Injections in .Net apps.

The basic approach is described here http://msdn2.microsoft.com/en-us/library/ms998399.aspx. It is basically split into two major parts - preliminary scan and the detailed scan. The keyword is hotspot - find hotspot and investigate it accordingly. Hotspot can be something around SQL injection or XSS. I personally like calling it hints rather hotspot.

Here are some techniques I used during preliminary scan to find hints for SQL Injection:

Code Inspection - First Look For What To Look For

This technique allows to dump all the strings from compiled assemblies. It is very useful when looking for sensitive data in it but along the way one can recognize funny things:

that can provide some hints for further investigation.

ILDASM and FindStr are our friends with this technique. Resulting dump can be investigated using ... Outlook 2007 - Security .Net Code Inspection Using Outlook 2007:

Look inside source code

This techniques assumes you one knows what to look for - it can be hints gathered from previous step or just finding all instances of OdbcCommand, OleDbCommand, OracleCommand, SqlCommand, SqlCeCommand usage.

FindStr is of great help here and the syntax would look like : FindStr /S /M /I /d:c:\projects\yourweb "SqlCommand" *.cs

from http://msdn2.microsoft.com/en-us/library/aa302437.aspx

FindStr uses the following command-line parameters:

/S — include subdirectories.
/M — list only the file names. No actual matches displayed.
/I — use a case insensitive search.
/D:dir — search a semicolon-delimited list of directories. If the file path you want to search includes spaces, surround the path in double quotes.

Incase where Visual Studio is at hand same result (I presume FindStr is used under the cover) can be achieved by pressing ctrl+shift+f. This command brings up "Find In Files" dialog box:

and the result is:

(file and the string match == FindStr /S /I /d:c:\projects\yourweb "SqlCommand" *.*)

Looking at the match one can decide to look further into it or not.

Use FxCop's ReviewSqlQueriesForSecurityVulnerabilities

Run FxCop with ReviewSqlQueriesForSecurityVulnerabilities rule checked:

Do not include any other checks - FxCop consumes tones of memory, and it may be a problem with large projects that include many DLL's.

Seems like FxCop approach is most efficient since it knows how to get hold on those hints where XXXComand object is used and CommandText property includes string that was built dynamically.

Do not fall in trap of false positives and false negatives - tools are great but the best tool is between your ears

False positives - it is situation when the tool finds the issue but from detailed inspection it is not. For example, FxCop spots the code like this:

string sql = "SELECT NAME, DESCN FROM PRODUCT WHERE NAME ='" + searchCriteria + "'"

SqlCommand cmd = new SqlCommand(sql, con);

Is it a problem? Depends where searchCriteria value comes from - if it is user controlled then YES, otherwise not [sure].

False negatives - it is situation where the tool does not find anything but the problem actually exists and only manual detailed scan can reveal it.

While false positives just consume more energy while manually inspecting the findings, false negatives leave bad stuff undiscovered, which is I think worse.

Conclusion

While tools are vital and usually boost the productivity when inspecting the code for security vulnerabilities, it is important to have right set of expectations from those tools - what it can and what it cannot do. Remember the best tool is between your ears (original version by JD)

Enjoy

Performance Gain - Security Risk

alikl — Tue, 27 Mar 2007 17:26:31 GMT

Reposted from Performance Gain - Security Risk

Good intention for better performance may lead to flawed design and bring in more security risks.

Consider the following ASPX page:

Here is why it cannot be accessed:

When trying to navigate there you get:

Great, love URL authorization!!

Now let's examine another ASPX page:

When navigating to this page you surprisingly get this:

The reason for that is when using Server.Transfer the request to the second page does not go through the whole ASP.NET pipeline which includes URL Authorization module

Security part is here http://msdn2.microsoft.com/en-us/library/ms998375.aspx

Performance part is here http://msdn2.microsoft.com/en-us/library/ms998549.aspx

Performance and Security has never been good friends - fortunately we have J.D. who is bridging the two letting us enjoy both.

Enjoy

Security .Net Code Inspection Using Outlook 2007

alikl — Mon, 26 Mar 2007 17:04:54 GMT

In my previous post, Code Inspection - First Look For What To Look For, I've described how to look for sensitive data and hints in the compiled assemblies. The other challenge I was looking to solve is boosting my productivity. So with little magic of scripting (more magic here Scriptomania - Scripting Tools and Utilities) and generous help from my friend DIR (more here Security Deployment Inspection Using Office.) I've accomplished task of scanning all directories, and dumping all the strings into text files, like this:

All I had to do is go over each and every text file and look for funny things (depicted in Code Inspection - First Look For What To Look For). Pretty annoying: double click, scroll down, move to "Seen" folder - no marking and categorization or follow up capabilities - WAIT A MINUTE!!! Does not it sound like Outlook? So I dragged all the text files into my new shiny Outlook 2007 getting all the goodies it provides:

1. Move through items using up and down arrow using left hand.

2. Scroll the text in preview pane using mouse wheel by right hand.

3. Tag and categorize.

4. Everything else Outlook provides.

5. AND OF COURSE USING INSTANT SEARCH IS A REAL PLEASURE:

Enjoy

Code Inspection - First Look For What To Look For

alikl — Wed, 21 Mar 2007 00:13:56 GMT

Reposted from Security Code Inspection - First Look For What To Look For for further reuse on this blog.

I found it extremely productive to first look for strings in the code. But what strings to look for? And how to look for the strings? Looking into the source files?

My good friend FindStr is of great help here:

So first let's find what to look for:

Ildasm.exe secureapp.dll /text | findstr ldstr

This is what I've got using it:

Wouldn't it trigger you think of authorization data doing roundtrip thus vulnerable to tampering and elevation of privileges?

Wouldn't it trigger you think there is some custom authentication mechanism that potentially could be vulnerable thus enabling identity spoofing?

Wouldn't it trigger you think.....

So once you have these strings you use same FindStr to find actual files to inspect:

findstr /S /M /I /d:c:\projects\yourweb "StringOfInterestGoesHere" *.cs

Cheers

Good Chance For Canonicalization Attack When Using Path.Combine()

alikl — Fri, 16 Mar 2007 01:31:00 GMT

In my previous post, .Net Assembly Spoof Attack, I've described potential DLL hijacking/spoof attack when using reflection for dynamically loaded assemblies.

Today I was reviewing some project where I stumbled on exactly such case. One thing that caught my eyes was that path to reflected DLL, the one to be loaded dynamically was built like this:

static void Main(string[] args)
{

string dllName = Console.ReadLine();

   while (!dllName.Equals("exit"))
   {
      string path = @"C:\DLLS\"

      //BUILD FULL PATH TO ASSEMBLY TO LOAD DYNAMICALLY USING Assembly.LoadFrom
      string fullDllPath = Path.Combine(path, dllName);

      Console.WriteLine("FULL PATH IS: " + fullDllPath);

      dllName = Console.ReadLine();
   }
}

Let me run it and see what happens if I provide expected DLL name say, alikl.dll:

And now let's provide something less expected like Z:\XACKER\ATTACK.DLL:

It means that if we supply full path as second parameter to Combine method it will ignore the first parameter.

How to validate?

1. Check the path for goodness using Path.GetFullPath() comparing result to "C:\DLLS" in our case

2. Sign your assembly and explicitly check it's evidence - example is here .Net Assembly Spoof Attack

More resources:

Canonicalization Lab (includes code and video by Keith Brown)

How To: Protect From Injection Attacks in ASP.NET

Enjoy

.Net Assembly Spoof Attack

alikl — Mon, 12 Mar 2007 22:51:00 GMT

To be honest I am not sure about the name of such attack, but in the nutshell it is attack where the original good code is replaced by bad one with the same interface but very bad implementation - may be Trojan DLL? Anyway...

My Australia based teammate Rocky posted sometime ago coolest screencast - Assembly Hijacking. He calls it hijacking. Go see it, very cool.

The final verdict was to sign the assemblies with SNK which is almost always a good idea to do. This should definitely prevent such attack he demonstrated. To "Evaluate Whether You Need Strong Names" check on the following in referenced article:

You need to add your assembly to the global assembly cache.
You want to prevent partial trust callers.
You want cryptographically strong evidence for security policy evaluation. <-- this one is for our case

Lately I stumbled on another post Assembly Load Contexts Subtleties that "focus on Assembly.Load and Assembly.LoadFrom" which discusses dynamic assembly and types invocation.

I thought to myself "What role SNK plays in this case?"

None

Dynamically loaded assembly is not checked for its evidence. That means that all applications that use reflection to load assemblies dynamically are vulnerable to such attack - regardless if there is SNK in place or not.

What to do to prevent such attack when using reflection?

1. Do sign with SNK your assemblies.

2. Use Full Assembly Names When You Dynamically Load Assemblies

The code you should find there will look like this:

public static StrongName GetStrongName(Assembly assembly)
{
   if(assembly == null)
      throw new ArgumentNullException("assembly");

   AssemblyName assemblyName = assembly.GetName();
   // get the public key blob
   byte[] publicKey = assemblyName.GetPublicKey();
   if(publicKey == null || publicKey.Length == 0)
      throw new InvalidOperationException(String.Format("{0} is not strongly named", assembly));
   StrongNamePublicKeyBlob keyBlob = new StrongNamePublicKeyBlob(publicKey);

   // create the StrongName
   return new StrongName(keyBlob, assemblyName.Name, assemblyName.Version);
}

And here is the check itself:

//LOAD ASSEMBLY DYNAMICALLY
Assembly assembly = Assembly.LoadFrom("ReflectedDll.dll");

//GET STRONG NAME FOR THE LOADED ASSEMBLY
StrongName sn = GetStrongName(assembly);

StrongName myStrongName = null;

//GET CURRENT APPDOMAIN STRONG NAME
IEnumerator enumerator = (IEnumerator)AppDomain.CurrentDomain.Evidence.GetEnumerator();
enumerator.Reset();
while (enumerator.MoveNext())
{
   if (enumerator.Current.GetType().Equals(typeof(StrongName)))
      myStrongName = (StrongName)enumerator.Current;
}

if (!sn.PublicKey.Equals(myStrongName.PublicKey))
{
   throw new ApplicationException("SPOOFED!!");
}

//OK, STRONG NAME IS COOL, LETS RUN IT FURTHER

In the world of provider design pattern (abstract factory – GoF definition) where assemblies get loaded dynamically one should pay closer attention to this.

Enjoy