Web Application Fuzzing And Positive Validation - Part Two

by Prasanna Kanagasabai and Kartikeya Puri

Part Two:


MSSQL
1. Use profiler
You can use profiler for MSSQL server to see what is hitting the database. Profiler is a very nifty tool that monitors and records the events on a SQL server. Amongst a multitude of things, SQL profiler also records the queries that are attempted on the server including T-SQL events. When you are fuzzing certain input points in the application, it helps to see how your inputs arrive at the backend on the database.

At times you may have the application in test setup, while running on a SQL express edition. Unfortunately MS does not provide a profiler for such a setup. Fortunately for us, there is a third paty tool that can make your life a bit more easy. The tool is called (strangely) sqlprofiler by AnjLab and can be found here(https://sites.google...te/sqlprofiler/). As per the site, this tool is tested for SQL Server 2005 & 2008 (express edition). I have tested it for Express Edition of SQL Server 2005 with good success rate.
For the demo purpose we used Mcafee Hacme Bank which storing data on a SQL 2005 database, we used the above mentioned freeware tool Anjlab SQL profiler to see what is hitting the database and what and how or query is being executed on the database.

As you would notice in our SQl test that got executed included the comment we purpose added with the fuzz text. This gives us a idea the procedure which executed. This would give us the ideas were the exact vulnerability exists.

2. SQL Traces
Another way of finding the same information is by using SQL traces. This will be a great alternative to using profiler as you can save the resulting trace in a (.trc) file or a table. A tester can use sp_trace_setfilter to select only those SQL events that are of interest to him. You can have a batch job running in your fuzzer that checks for the traces table constantly while sending the malicious requests. This could be a lifesaver in some of the larger enterprise environment where multiple types of testing may be carried out simultaneously to meet unrealistic deadlines.

Oracle
1. Use v$ view
Oracle does not provide you with a convenient point and click tool. However it does provide multiple ways of getting the information that our tester wants. One of the most interesting one is using the V$ views. One of the most common view that one can query is v$sql. Following are some of the queries that the tester can use to see what successful queries are running on the database at that instant.

select * from v$sql where sql_text like '%myfuzzer_1234%' order by LAST_ACTIVE_TIME DESC;
select * from v$sqltext where sql_text like '%myfuzzer_1234%';
select * from v$sqlarea where sql_fulltext like '%myfuzzer_1234%' order by LAST_ACTIVE_TIME DESC;

However on a fairly busy DB environment you should be quick with these queries. V$SQLAREA and V$SQL will have queries in them as long as they are in shared memory (I am sure it’s same for v$sqltext). In my experience I found success with v$sql in all my test cases. Another thing to note is that it will only show you the successful queries and not the attempts that might have gone wrong due to falling short on some silly syntax, nor the queries with bind variables. To achieve this, we can enable traces on the session of the user we are interested in or on the whole database. Following statement will help you set traces on:
sql>ALTER SESSION SET SQL_TRACE = TRUE;
A DBA or SYS user can enable traces on a specific session as well with the following commands:
sql>DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid,serial#,true);
Where SID and Serial# will need to be obtained from v$session view, for the session that you are interested into, typically the fuzzing session. Your fuzzer can query the resulting trace file to find the issues

2. Use error trigger
One way of finding the cases where the fuzzed values could have been passed to database unsuccessful is to create a trigger on the database that records certain error conditions. This is a trick that I am really thankful for to Alexander Kornburst of Red Database Security. You can get the error trigger creation script from here(http://www.red-datab...ror_trigger.sql) or create your own if you like writing plsql. During the fuzz operation, you will be querying this table over and over again for your fuzz values.
sql> select * from system.oraerror where stmt like ‘%myfuzzer_1234%’;

Conclusion
The biggest hurdle with fuzzing web applications is to find a good way of analyzing the results. As web applications are increasing in popularity and their general acceptance is increasing it is opening new avenues for the penetration testers and hackers alike. Hopefully some of the methods discussed here could help you build better fuzz scripts and methods to validate the results too.
References
1. Constricting the Web. BlackHat Presentation. -- http://www.gdssecuri...e_web_final.pdf
2. Red Database Security -- http://www.red-database-security.com/
3. Wikipedia


Part One:

Authors
Prasanna Kanagasabai
Independent security researcher, Secures applications for corporates, enjoy programming.

Kartikeya Puri
Works in Information Security Team of a Large Financial institution in the Middle East, Photography is his next biggest passion.