August 23, 2006

WTF? Can some .NET guru help me out?

Recently I had to figure out some VB.NET code and port it to C#. I am not much of a VB guy, but I figured I could understand some basic stuff. I am having some difficulties, and was hoping someone could explain the brain dead issue I am having. Here is the VB.NET code:

Sub Main()
Dim key_aes128 As String
key_aes128 = Chr(&H5S) & Chr(&H4S) & Chr(&H57S) & Chr(&HF0S) & Chr(&H5CS) & Chr(&HADS) & Chr(&H9AS) & Chr(&H55S) & Chr(&H5S) & Chr(&H4S) & Chr(&H17S) & Chr(&HF0S) & Chr(&H5CS) & Chr(&HADS) & Chr(&H9AS) & Chr(&H55S)
End Sub

Here is the C# code I am trying:

static void Main(string[] args)
string key_aes128;
key_aes128 = String.Format( "{0}{1}{2}{3}{4}{5}{6}{7}{8}{9}{10}{11}{12}{13}{14}{15}",
Chr(0x5), Chr(0x4), Chr(0x57), Chr(0xF0), Chr(0x5C), Chr(0xAD), Chr(0x9A), Chr(0x55),
Chr(0x5), Chr(0x4), Chr(0x17), Chr(0xF0), Chr(0x5C), Chr(0xAD), Chr(0x9A), Chr(0x55) );
static Char Chr(int i)
return Convert.ToChar(i);

You would THINK that key_aes128 would be the same. They are CLOSE.... but not actually the same. Anyone know what the heck I am doing wrong? It SHOULD result in the exact same string.

Posted by SilverStr at 03:46 PM | Comments (5) | TrackBack

August 17, 2006

Leveraging powerful data validation in SQL Server 2005

I am so pleased with deciding to go with SQL Server 2005 Express for a recent project. I recently learned about an extremely powerful feature that makes data validation in the database a breeze.

Whenever you use input from an untrusted source, it needs to be validated. Especially if it comes from or can be accessed by the user. The best way to handle this is to put an input sentry at any trust boundary, as it crosses from an untrusted to trusted border. Ultimately, the last line of defense will be the database, as that is where the final storage ends up... at least for our application.

You can easily apply CHECK constraints on fields in the database. But that is a very rudimentary method of validating the input, since you can typically only do basic checks.

Enter the fact that in SQL Server 2005, you can now enable CLR in the database, and write user-based functions in your favorite .NET language. And more importantly, you can CALL these functions AS constraints on fields in the database.

This is really impressive stuff. In my case, I wrote a generic regular expression validation function that allows me to do the deepest of validation checks on the data before its inserted. If the data fails the regex validation, the record will not be committed.

I decided to screencast the authoring of this powerful regular expression validation method. Feel free to use it yourself on your SQL Server 2005 databases. You can view the screencast here.

And remember... always assume that input is malicious until proven to be safe.

Posted by SilverStr at 11:25 PM | Comments (3) | TrackBack

August 14, 2006

Engineering secure code in small teams

I've been pretty quiet here lately as I take on an interesting project that is consuming a lot of my time. In the month of August, I have been working on "Project Anvil", an open and transparent experience where I am blogging the construction of a strong authentication server for small business... all built on the Windows stack with the smallest of teams... just me.

Why this is interesting is that I am showing how you can design more secure systems WITHOUT needing complex teams to accomplish the goals. One of the key reasons I am doing this is that I am tired of seeing micro and small ISVs (independent software vendors) complain that they cannot build a business based on quality software because they don't have the same large teams and development resources of companies like Microsoft or IBM. I shake my head when I listen to whining about how they are too small to build secure software and how that in an effort to put food on the table, they can't architect software that runs safely on our platforms of today. And I am tired of watching startups write crappy software because some VC or angel screams "get version 1 out, and worry about making it work later".

If this interests you, please consider following my progress on the Project Anvil blog. I would recommend you start from the first post, and read it in sequence. And please, feel free to comment and criticize. Challenge me, and my assumptions. I would love the opportunity to learn from your experiences as I share mine.

Posted by SilverStr at 07:51 PM | Comments (0) | TrackBack

August 08, 2006

Work around for "Threat Analysis & Modeling v2" tool least privilege install bug

So with help from Dan Sellers and Talhah Mir over at Microsoft, I finally figured out and fixed a problem I have been having with Microsoft's latest version of the "Threat Analysis & Modeling v2" tool.

It seems that a good portion of the comboboxes in the application were "blank". And it was making it impossible to complete production threat models since all the critical components needed weren't available.

Ends up, its an issue with installing the tool in a least privilege environment. And a rather funny one at that. The tool itself was written properly to handle least privilege by loading the data needed in the comboboxes from an AppLists.xml file, located in <user home directory>\Application Data\Microsoft\TAM\Temp\. Problem was, it EXPECTS that the user installed it and has the file.

In my case, I installed the tool with an administrator account, expecting it to work for both domain and nondomain limited user accounts on my laptop. There WAS a proper AppLists.xml located in that admin's directory. However, on the least privilege accounts, a default empty one was created when the original XML file could not be found. The result... all the blank comboboxes I was seeing.

The fix was simply to copy the properly populated AppLists.xml file from the admin account into the least privilege account. Walla. It all works now.

Posted by SilverStr at 11:27 PM | Comments (1) | TrackBack

August 01, 2006

A Process for Performing Security Code Reviews

So in this month's IEEE Security and Privacy magazine Michael Howard wrote an interesting article on "A Process for Performing Security Code Reviews".

It's worth the read. His insights on how to prioritize what code to review first is something I think we all can learn from. I've never seen a calculation for bug density like that before. I wonder how effective that has been in the Microsoft code base?

Happy reading!

Posted by SilverStr at 11:58 PM | Comments (0) | TrackBack

Security Model Analysis of Windows Vista

Matthew Conover, a security researcher over at Symantec, has published a new paper on the "Analysis of the Windows Vista Security Model". His paper provides an in-depth technical assessment of the security improvements implemented in Windows Vista, focusing primarily on the areas of User Account Protection and User Interface Privilege Isolation. The paper discusses these features and touches on several of their shortcomings as viewed by Symantec. It then demonstrates how it is possible to combine these attacks to gain full control over the machine from low integrity, low privilege process.

Similar to their last paper on the Vista attack surface, they seem to continue to reference older builds and offer opinions on pieces that are still being tweaked. With that said however, I found that this paper does offer some insight and critical thinking about privilege elevation in Vista. You might be interested in checking it out.

Happy reading.

Posted by SilverStr at 10:16 AM | Comments (0) | TrackBack