EQEmulator Forums - must read for server ops: vulnerability in charmover

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- General::General Discussion (https://www.eqemulator.org/forums/forumdisplay.php?f=586)

- - must read for server ops: vulnerability in charmover (https://www.eqemulator.org/forums/showthread.php?t=29797)

must read for server ops: vulnerability in charmover

I audited the stock charmover code and found a problem. If magic quotes is disabled it is possible to inject SQL, and since the utility requires UPDATE privelages on its acct this could be pretty bad.

the two variables plugged into the sql statements that come from user input are login server name and character name. In the stock build everywhere this occur come with single quotes around them. If magic quotes are disabled it would allow a user to inject a quote to get out of that particular literal.

If you have modified your charmover and have a user passed variable that is plugged into one of your sql statements,and that variable is not surrounded by quotes, OR you have magic quotes disabled you should fix it quick. If you are not sure one way or another you need to apply something like the code below.

FYI, magic quotes escapes any escape or quote in a user passed variable. The code below will add escapes to a variable if magic quotes is off.

Code:

if(!get_magic_quotes_gpc())  $lsusername = addslashes($_POST['lsusername']); 

else $lsusername = $_POST['lsusername'];

there are SEVERAL places username and character name are pulled from the post array so check your code closely

I guess i could explain further... say you got

Code:

$name = $_POST['name'];

$sql = "SELECT * FROM table WHERE name = '$name';

if a user submits his name as (forgive my syntax on droping i know its wrong)

Code:

blahblahblah'; DROP ALL TABLES;--

then when it gets plugged into $sql you would get

Code:

SELECT * FROM table WHERE name = 'blahblahblah'; DROP ALL TABLES;--'

the -- at the end would comment out the trailing quote. If magic quotes is on, or you use the code in the first post it will add a / before any quote or /. So with magic quotes on you would get

Code:

SELECT * FROM table WHERE name = 'blahblahblah/'; DROP ALL TABLES;--'

That would cause an error and none of the sql gets executes saving your database.

I don't mean any harm to anyones database by posting this, i'm only posting it cause there is a work around, or so you can take the tool down if you are worried. Probably everyone will find that they aren't vulnerable since its default behavior, but need to be aware that when PHP6 comes out that magic quotes will be no longer there as far as i know. As far as I know the code up top will still work in php6.

Sometime in the next few week or next month I will be rewriting the tool from the ground up and including it in magelo with a good ammount of security on it. Sorry it will be slow to get out, i'm changing alot of core features of the magelo clone and want to really test it well.

Quote:

Originally Posted by airtalking (Post 180090)

I guess i could explain further... say you got

Code:

$name = $_POST['name'];

$sql = "SELECT * FROM table WHERE name = '$name';

if a user submits his name as (forgive my syntax on droping i know its wrong)

Code:

blahblahblah'; DROP ALL TABLES;--

then when it gets plugged into $sql you would get

Code:

SELECT * FROM table WHERE name = 'blahblahblah'; DROP ALL TABLES;--'

the -- at the end would comment out the trailing quote. If magic quotes is on, or you use the code in the first post it will add a / before any quote or /. So with magic quotes on you would get

Code:

SELECT * FROM table WHERE name = 'blahblahblah/'; DROP ALL TABLES;--'

That would cause an error and none of the sql gets executes saving your database.

Fortunately, PHP5 (and possibly PHP4, I can't remember where I read it to verify) doesn't allow multiple queries in 1 execution. Otherwise, any server running the older version of the Allakhazam Clone would be screwed (pretty much all of the search fields are susceptible to injection), allowing someone to give themselves equip, instant max level, max pp, etc.

However, you could attempt to discover an admin password from the account table using subqueries & a bit of trial an error.

As for a fix, I don't know that I'd recommend just depending on escaping quotes, but rather validating the actual submitted value. Specifically, since we're just looking at a name, there shouldn't be any spaces, special characters, numbers, etc. So, we could do a simple Regular Expression:

Code:

[A-Za-z]+

correct me if i'm wrong... but php just passes the string to mysql and it decides what to do with it... why would php validate database input, and I aggree the alla clone is a mess for validation.

What i've been doing in the mag clone is only allowing alpha characters in there using a php function, similar to your regex. That was the same plan I had for character name... as for username I wouldn't mind getting a list of available characters from the devs here.

yea, from php.net

Quote:

mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier .

the ease of trying to force out a password would be alot easier since the database format is open source.

Is this stuff we really want to discuss in an open forum?

Quote:

mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier .

Are they using mysql_query()? If so, what's the problem again? Your "blahblahblah'; DROP ALL TABLES;--" example is two queries?

Quote:

Is this stuff we really want to discuss in an open forum?

Yes, pretty much all vulnerabilities should be public. That way we:

a) Fix them.
b) Learn from them.
c) Get server ops to update their code.

plus the people who would use this know how to do it already most likely.

Quote:

Originally Posted by Shin Noir (Post 180101)

Are they using mysql_query()? If so, what's the problem again? Your "blahblahblah'; DROP ALL TABLES;--" example is two queries?

The problem is that it's still susceptible to injection. Although you can't just drop the database since it's running through PHP, you can still look for other pieces of data. I don't think it would be appropriate to provide a step-by-step tutorial on how to do this (there are plenty of them on the Internet already), but the idea is you can verify information from the database that you wouldn't normally have access to (mainly passwords and account names).

AndMetal is correct even with access to only 1 query there are still several things that can be abused

As a work around i came up with this function, dunno maybe it will help someone else

PHP Code:


		
			
   function bad_char_strip($doit) {

    $doit = preg_replace("/\W+/", '', $doit);

    $doit = preg_replace("/\s+/", '', $doit);

    return($doit);

    }

  $lsusername = bad_char_strip($lsusername);

  $charname = bad_char_strip($charname);