Thread: 'r' type SQL Injection Vulnerability

Input passed to the "Country[]" parameter in "search_result.php" isn't properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

The vulnerability has been reported in version 4.0 and prior. Other versions may also be affected.

Solution:
Edit the source code to ensure that input is properly sanitised.

http://secunia.com/advisories/16831/

Smoge note: Country uses a is a ProfilesDesc search type, and if this exploit exists, it would stand that any field using this search type could be exploited.

is this problem fixed in CLEAN?

Hmmm... could this be it?

search_result.php, line #220

Code:

$total_query_tmp .= ",$key";

change to

Code:

$total_query_tmp .= ",(int)$key";

Smoge

Of course, this has been added to the CLEAN project code.

Smoge

$total_query_tmp .= ",(int)$key";

should be?
$total_query_tmp .= "," . (int)$key;

PHP Code:

Error in /search_result.php: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'int)1,(int)3,(int)5))   ORDER BY Priority DESC, Priority DESC, Profiles.LastLogg' at line 1
Query: 'SELECT Profiles.ID, Headline, Country, Occupation, City, Sex, Sex2, ProfileType, NickName, Children, MerchantPrice, LEFT( DescriptionMe, 180 ) AS DescriptionMe, LEFT( DescriptionYou, 100 ) AS DescriptionYou, DateOfBirth, DateOfBirth2, Pic_0_addon, Pic_1_addon, Pic_2_addon, Pic_3_addon, Pic_4_addon, Pic_5_addon, Pic_6_addon, Pic_7_addon, Pic_8_addon, Pic_9_addon, Pic_10_addon, Sound, (LastNavTime > SUBDATE(NOW(), INTERVAL 5 MINUTE)) as is_onl , mem_level FROM Profiles  WHERE Status = 'Active' AND (LookingFor = 'female' OR LookingFor = 'both') AND (IF('female'='both' or 'female'='couple',1,Sex='female')) AND (IF('female'='couple',ProfileType='couple',ProfileType!='couple'))  AND (TO_DAYS(DateOfBirth) BETWEEN TO_DAYS('1945-10-17') AND (TO_DAYS('1987-10-17')+1))  AND (Country IN (-1,0))  AND (BodyType IN (-1,(int)1,(int)3,(int)5))   ORDER BY Priority DESC, Priority DESC, Profiles.LastLoggedIn DESC LIMIT 0, 10' 


Hi,

Thanks, Tester00 - I only tested this with Country - did not see it screwed up the others - I tried your adjustment to this fix - tested it, and it seems to work fine.

Everyone - If you applied my original - please update with the new.

Smoge

I think I figured out what the problem is. If you search from Extended Search form, you will see the query string as in: .....DateOfBirth_end=40&Country%5B%5D=205

Here, if you change 205 to anything that doesn't exist in $prof[countries], script will return database error.

My quick solution is to override this kind of hacks.

put this function somewhere on top of search_result.php

PHP Code:

function isCountry($arr)
{
    global $prof;
    
    $default_country = 205;

    while (list($key, $val) = each($arr))
    {
        if (!$prof[countries][$val])
        {
            $arr[$key] = $default_country;
        }
    }

    return array_unique($arr);
} 


2. find this:

case 'list':
$fval = $_GET[$fname];
if ( count($fval) > 0 && is_array($fval) )

replace with:

PHP Code:

        case 'list':
                        ### COUNTRY SECURITY ISSUE
                        if ($fname == "Country" && $_GET[Country])
                        {
                            $fval = isCountry($_GET[$fname]);
                        }
                        else
                        {
                            $fval = $_GET[$fname];
                        }

                        if ( count($fval) > 0 && is_array($fval) ) 


I just found the reported "exploit" for this - and I don't think it is an exploit at all - it simply generates a database error - it might be considered a programming issue (addressed by Tester00 below), if someone changes the URL construct and generates a database error, but not really an exploit.

Could it be carefully crafted to be an explot? Perhaps... but so could a lot of other queries. Since aeDating does not use "Union" anywhere in the code - much of this could be fixed (system-wide) with an improved db.inc.php file, that attempts to filter out such SQL queries like UNION.

Here is the original post from Security Focus:
http://www.securityfocus.com/archive/1/410776

Online Dating Software by AEwebworks - aeDating Script <= 4.0 Version

I have found Vulnerability in Online Dating Software by AEwebworks - aeDating Script <= 4.0 version which is exploitable when you are searching for your soulmate at aeDating service Software.

For example :
www.[target].com/search.php just choose one Country and click on the Search button , After having done that you can see something like this :

http://www.target.com/search_result....e&DateOfBirth_
start=18&DateOfBirth_end=40&Country%5B%5D=0

And at this instant to complete it all, all you have to do is add something of your individual choosing at the end of the link for an example UNION

http://www.target.com/search_result....e&DateOfBirth_
start=18&DateOfBirth_end=40&Country%5B%5D=0UNION

And search result:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/site/public_html/search_result.php on line 370

ERROR Database access error

Best Regards
Alex

Smoge

Originally Posted by tester00

I think I figured out what the problem is. If you search from Extended Search form, you will see the query string as in: .....DateOfBirth_end=40&Country%5B%5D=205

Here, if you change 205 to anything that doesn't exist in $prof[countries], script will return database error.

Yes, I was looking for an exploit - not a database error due to an altered URL construct... while this is something that should be fixed - it is really not a "normal" occurance unless someone is playing with the scripts URL construct in their browser.

I think that perhaps, a nice addition to the database error that ends up getting sent to the admin would be to include the IP address (or at least attempt to) of the person who generated the error.

But yes, the URL construct being shown is a "bad" thing about aeDating, and something we should consider fixing (using industry standard methods).

My opinion on future reported "exploits" is here:

Reporting Exploits

Smoge

Hey, you posted something about adding IP address to the email for AED db.inc.php so I've created the new and improved db.inc.php

It fixes this issues

1. to many connections or max connections.

Mode Level 0 Normal operation
2. All warning are surpressed in Normal mode. Minimul error reporting but provides error code to user with link to contact form.
2.1 Email the admin with IP addres, browser, cookie ID, SQL Error Traps and SQL Query String.

Mode Level 1 Debug operation
3. detailed error trap and display when in debug mode AKA VERM i.e. visual error message

Mode Level 2 Debug operation
4. A SQL Blast a full list of all sql queries done on a page. Basically it prints out all SQL Queries....I usually use this mode when debuging the search page...

You can down load this in my forum under Aedating MODS