CGI generic sql injection

Question

I was scanning a site with Nessus when the following vulnerability was reported:

CGI Generic SQL Injection

Nessus says that:

"An attacker may exploit this flaw to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system."

So I continued reading and found out that the vulnerability sits in this piece of code:

Using the POST HTTP method, Nessus found that :

The following resources may be vulnerable to SQL injection :

The '_codeTextBox' parameter of the /LoginTeacherForm.aspx CGI :

/LoginTeacherForm.aspx [loginButton=Login&_VIEWSTATE=dDwtMTU2NDIxMDkwN Ts7Pg%3d%3d&btnChangePassword=Wijzig%20Pincode&_pinCodeTextBox=&_codeTex tBox='+convert(int,convert(varchar,0x7b5d))+']

-------- output --------

Exception Details: System.Data.SqlClient.SqlException: String or binary data would be truncated. The statement has been terminated.

But I'm wondering how an attacker could exploit this vulnerability, because when I paste that url it just gives me an error.

So my question is how would an attack be able to actually hack into the site and bypass login etc?

Answer 1

I'll start by mentioning the usual piece we do when security testing tools are used, which is that it's very important to only use them on sites which you are authorized to test. Running security tools on sites you're not authorized to test can be a criminal offence depending on your jurisdiction.

That said, I'd say that Nessus is likely reporting that based on the mention of the SQL Exception in the error message, it does imply that the SQL query on that page was modified, although I've seen false positives with that kind of error before.

In terms of how it could be vulnerable, the query behind that kind of page is likely to be a SELECT statement which compares the values supplied for login with the ones stored in the database for that user. If the page is taking the values directly from the user and putting them into the query then there's the possibility that its vulnerable.

If it is vulnerable, then an attacker can modify the SQL query being run on your site then bypassing the login is one possible outcome, along with an attacker damaging the underlying server.

A good way to test this in a non-destructive fashion might be to use the quote characters and string concatenation.

First check to see if you can reproduce the error. Enter a single ' character into the field along with valid data in the other fields in that form. If it throws an error then it's possible that its vulnerable.

Then if you have a valid value for the codetextbox field (lets say it's abcdef) try entering

abc'+'def

as the value in that field along with valid data in the other fields. If the application logs you in, it either stripped non-alpha characters (possible but it wouldn't explain your error message) or it concatenated the two strings together, which implies that you have SQL Injection.

At that point your best bet is to look at the source of the page to confirm.

Answer 2

The error System.Data.SqlClient.SqlException indicates an error in your SQL query statement. This implies that value stored in the _codeTextBox parameter is not validated or otherwised sanitized before being put into the query.

This would have varying implications depending on the query and logic surrounding its return value. It is impossible to determine the worst case scenario without a thorough understanding of the web application. Suffice it to say, this issue should be fixed by the developer. Fortunately, it is usually easy to fix once identified.

In this case, it looks like the _codeTextBox parameter is being passed to the convert function. I doubt anyone could exploit this. But, this indicates insecure coding practices that probably appear in other areas that Nessus is not aware of. Read below for more info.

I see this most often when the programmer simply concatenates the values with the SQL query string:

Unsafe Example (java) (Source OWASP)

String query = "SELECT account_balance FROM user_data WHERE user_name = "
  + request.getParameter("customerName");

try {
    Statement statement = connection.createStatement( … );
    ResultSet results = statement.executeQuery( query );
}

Since the value simply gets appended to the end of the query, the user can change query to do something nefarious like login as any user or view all transactions. In the above example, the user could change the customer name parameter to something like '' or 1=1 or worse.

Expected query:

 SELECT account_balance FROM user_data WHERE user_name = someuser

Bad query:

 SELECT account_balance FROM user_data WHERE user_name = '' OR 1=1

OWASP recommends the following defensive measures. Your situation will dictate what is appropriate:

Primary Defenses:

1. Use of Prepared Statements (Parameterized Queries)
2. Use of Stored Procedures
3. Escaping all User Supplied Input

Additional Defenses:

• Also Enforce: Least Privilege
• Also Perform: White List Input Validation

You really need to check out OWASP's site and read more about SQL injection.