Resources:
.NET Reflector homepage
Reverse Engineering to Learn .NET Better
SQLCMD and SQL overview README!

The purpose of this lab is to gain appreciation of how a single security flaw can compromise a whole infrastructure -- and learn how to do it!

Part 1: Reverse Engineering a .NET Application

Before we access the targeted SQL server, we must extract sensitive information from a compiled, closed-source .NET database application.  We will use a free utility called .NET Reflector to do this.  Reflector will take a compiled .NET assembly (executable, DLL file, etc.) and reveal its internal structure and, in some cases, some very sensitive information.  A direct link to the latest version of Reflector as of 6/5/09 is here:

http://downloads.red-gate.com/reflector.zip

The application is stand-alone, so you just need to extract the .exe from the archive after downloading it.  Extract it somewhere convenient (desktop).

Next, we will use it on our database application.  The application can be found here:

http://sleipnir.cs.csubak.edu/~ntoothma/cs340/Application.exe

Open up Application.exe in Reflector.  You'll notice a new assembly namespace exists in the list!  Start exploring.  You're looking for a connection string, an unencrypted string that contains all of the information necessary to access the backend database on the SQL server.  Left alone after initialization, this piece of information will never be encrypted, even for release builds (in addition to debug builds) in Visual Studio!  If this is not resolved, then we can easily exploit the target database.

For further elaboration on where to look, I will describe the typical construction of a .NET database application to aid in the search.  Once you have the connection string, we can move on and begin messing around with the database.

Part 2: Accessing the database

Now that we have the connection string, we can use a Microsoft tool called SQLCMD (not to be confused with sqlcmd, though it's probably just as effective!) to gain command-line access to the SQL Server and a particular database residing on it.  Please consult the SQLCMD intro for detailed information on how to use it.

Through normal use of the provided .NET database application, the end user can never see a table's primary key.  Furthermore, they are limited to access of only one record at a time, and only under the database's built-in constraints.  We will bypass these obstacles to acquire and modify records on the database itself.

Using SQLCMD, log into the database with the information in the connection string from part 1.  You must insert a new record into the Person table containing only your first and last name.  Since the Person table's primary key is generated automatically at every request for insertion, a raw insertion of your info will not work.  Lucky for us, the DBA made a handy dandy stored procedure that will not only insert the record, but return to you your brand-new unique primary key!

Search for and execute the stored procedure using the tips in the SQLCMD guide linked above.  When you are finished, email the following information to donna@cs.csubak.edu, C.C. to ntoothma@cs.csubak.edu

Part 1:
The Connection String and the location where you found it (provide both function name and the class that it belongs to)

Part 2:
The primary key generated at the time of your personal record insertion.