Page 1 of 1
SQL Injection and fix
Posted: Mon Jan 14, 2008 1:11 am
by domdorn
Hi!
Sorry, don't have much time to search the forum, because it's quite late and I have to get up early.
There is a possible SQL-Injection in the file
modules/TinyMCE/content_css.php
around line 110.
the code there is:
Code: Select all
102 $db=pg_connect("host=".$config['db_hostname']." dbname=".$config['db_name']." user=".$config['db_username']." password=".$con
103 if ($name != '')
104 $sql="SELECT css_text, css_name FROM ".$config['db_prefix']."css WHERE css_name = '" . pg_escape_string($name) . "'";
105 else
106 $sql="SELECT c.css_text, c.css_id, c.css_name FROM ".$config['db_prefix']."css c,".$config['db_prefix']."css_assoc ac
107 WHERE ac.assoc_type='template' AND ac.assoc_to_id = ". pg_escape_string($templateid) ."
108 AND ac.assoc_css_id = c.css_id AND c.media_type = '" . pg_escape_string($mediatype) . "'
109 ORDER BY ac.create_date";
110 $result=pg_query($db, $sql);
with a URL like this one
http://www.yourhostname.com//modules/Ti ... *%22This*/
it is still possible to alter the SQL-Query to something like this
SELECT c.css_text, c.css_id, c.css_name FROM cms_css c,cms_css_assoc ac WHERE ac.assoc_type='template' AND ac.assoc_to_id = -1/**/UNION/**/SELECT/**/username,1,password/**/FROM/**/cms_users/*"This*/ AND ac.assoc_css_id = c.css_id AND c.media_type = '' ORDER BY ac.create_date
because field assoc_to_id in table cms_css_assoc is of type integer,
I highly recommend to change the lines
Code: Select all
34 if (isset($_GET["templateid"])) $templateid = $_GET["templateid"];
to
Code: Select all
34 if (isset($_GET["templateid"])) $templateid = intval( $_GET["templateid"] );
which change the executed query to something _really_ safe, at least from the $templateid point of view
SELECT c.css_text, c.css_id, c.css_name FROM cms_css c,cms_css_assoc ac WHERE ac.assoc_type='template' AND ac.assoc_to_id = -1 AND ac.assoc_css_id = c.css_id AND c.media_type = '' ORDER BY ac.create_date
Sorry to post this here, but I really dont have much time and if I wouldn't have postet it now, I surely would have forgotten to report it.
greetz,
dominik
Re: SQL Injection and fix
Posted: Mon Jan 14, 2008 8:24 am
by RonnyK
Dominik,
there was a Vulnerability in 1.2.2. There has been a fix, resulting in CMSMS version 1.2.3.....
Are you referring to version 1.2.2?
Ronny
Re: SQL Injection and fix
Posted: Mon Jan 14, 2008 7:29 pm
by Ted
Yeah, this was the exact fix we put into 1.2.3...
Re: SQL Injection and fix
Posted: Mon Jan 14, 2008 8:10 pm
by domdorn
hmm... i've patched my installations before reporting this issue...
the
modules/TinyMCE/content_css file in cmsmadesimple-diff-1.2.2-1.2.3.tar.gz still has this flaw...
if you put a
echo $sql;
after line 109 and call the page
http://www.yourhostname.com//modules/Ti ... *%22This*/
you can see that the sql-code get's into the query... you have to test with a postgresql installation, to see the sql...
Code: Select all
SELECT c.css_text, c.css_id, c.css_name FROM cms_css c,cms_css_assoc ac WHERE ac.assoc_type='template' AND ac.assoc_to_id = -1/**/UNION/**/SELECT/**/username,1,password/**/FROM/**/cms_users/*"This*/ AND ac.assoc_css_id = c.css_id AND c.media_type = '' ORDER BY ac.create_date
pg_escape_string, mysql_real_escape_string etc. just throw some special characters out of the input, but as you can see, it's still possible to put sql code into the query.
With a little fine tuning, i'm sure it's possible to succeed in exploiting this vulnerability...
if you specify that $templateid is an integer with $templateid = intval($_GET["templateid"]); all except the (signed) integer value gets thrown away.
Sorry for the bad grammar... please apply the fix
Greetz,
Dominik
Re: SQL Injection and fix
Posted: Tue Jan 15, 2008 4:15 pm
by Pierre M.
Hello,
I'm not in the dev team I can't say if official 1.2.3 is at risk.
But for all CMSms sites using
URL filtering this should stop the bad requests before they reach PHP hence CMSms :
Code: Select all
RewriteEngine On
# Might be needed in a subdirectory
#RewriteBase /
# URL Filtering helps stop some hack attempts
#IF the URI contains UNION
RewriteCond %{QUERY_STRING} UNION [OR]
#OR if the URI contains a *
RewriteCond %{QUERY_STRING} \*
#then deny the request (403)
RewriteRule ^.*$ - [F,L]
Beware my typos and such (don't forget [OR]s). Adapt to your site. Try before you deploy. Hope it helps.
Pierre M.
Re: SQL Injection and fix
Posted: Wed May 07, 2008 5:53 pm
by nwcon
I too still have the SQL injection issue. I originally installed cmsms with version 1.2.3 and used the diff upgrade to 1.2.4...never used 1.2.2.
Requesting /modules/TinyMCE/content_css.php?templateid=-1/**/UNION/**/SELECT/**/username,1,password/**/FROM/**/cms_users/*
spit out users and hashed passwords.
I'm not sure if I'm at fault (some configuration issue i.e. mod_rewrite rule?), but manually applying the intval fix on line 34 of TinyMCE content_css.php solved the problem. I also setup URL filtering.
Regards,
nwcon
Re: SQL Injection and fix
Posted: Mon May 12, 2008 3:26 pm
by Pierre M.
My star-in-QS excluding URL rewrite rule gives a 403 to http://.../cmsmsfolder/test.html?someparam=a*star
It should work whatever the CMSms version behind mod_rewrite.
Test it against your "dangerous" http request.
Pierre M.
Re: SQL Injection and fix
Posted: Mon May 12, 2008 4:06 pm
by nwcon
Yes, I have the following rewrite rule in place now:
RewriteCond %{QUERY_STRING} \*
RewriteRule ^.*$ - [F,L]
I protects but it doesn't really appear to _solve_ the problem in TinyMCE. I followed the CMSMS Security guide and added several url filters that use mod_rewrite.
I feel safer now, but I'm still perplexed why my install had this vulnerability. I've tested two other sites, both running cmsms 1.2.4, one hosted on GoDaddy and one hosted internally on their IIS web server. Both of these installs redirect to the admin control panel when requesting the 'bad' URL.
Interestingly, I checked the latest version of cmsms, 1.2.4, and the content_css.php file in TinyMCE doesn't have the intval fix on line 34. So, I can only guess that the fix for this vulnerability was somewhere else. I haven't had much time to try and find the patch or changes that fixed the sql injection vulnerability in TinyMCE, but I would be interested to see what the actual patch contains.
When I get a chance, I will test a fresh install using the 1.2.3 tarball I originally downloaded. Then I'll do a diff upgrade and test that.
Regards,
nwcon
Re: SQL Injection and fix
Posted: Mon May 12, 2008 4:20 pm
by Pierre M.
Hello again,
nwcon wrote:
Yes, I have the following rewrite rule in place now:
RewriteCond %{QUERY_STRING} \*
RewriteRule ^.*$ - [F,L]
It protects ...(snip)
Cool. Thank you for your feedback.
nwcon wrote:
...Both of these installs redirect to the admin control panel when requesting the 'bad' URL.
I don't understand : Isn't this statement incompatible with the previous one : "yes... It protects" ?
Do you mean the above rewrite rule is defeated by some URL ? which URL ?
nwcon wrote:
...I checked the latest version of cmsms, 1.2.4, ... doesn't have the intval fix on line 34.
I don't know about the code. May be the fix is on another line. To make life easier to the Dev Team please report precisely the CMS+rewriterule+badrequest combination.
Pierre M.
Re: SQL Injection and fix
Posted: Mon May 12, 2008 4:42 pm
by nwcon
Pierre,
Pierre M. wrote:
I don't understand : Isn't this statement incompatible with the previous one : "yes... It protects" ?
Do you mean the above rewrite rule is defeated by some URL ? which URL ?
When I request the 'bad' url on a current cmsms install (not my own), I'm redirected to the cmsms admin login page for that install. I'm not logged in, but I'm sent to the admin portal instead of getting any kind of error response. On the godaddy install, I know the only rewrite rule used is for pretty urls, specifically
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA]
Pierre M. wrote:
I don't know about the code. May be the fix is on another line. To make life easier to the Dev Team please report precisely the CMS+rewriterule+badrequest combination.
First, I would like to do some more testing to see if in fact the issue is with a rewrite rule or combination with pretty urls, etc. If I can narrow the issue down to a specific configuration that allows the exploit, then I can provide the dev team with useful information.
Regards,
nwcon
Re: SQL Injection and fix
Posted: Mon May 12, 2008 7:54 pm
by nwcon
I'm glad to report I found the cause of my concern...a big Duh on my part.
I was actually using the following to test the SQL Injection exploit
/modules/TinyMCE/content_css.php?templateid=-1/**/UNION/**/SELECT/**/username,1,password/**/FROM/**/cms_users/*
Without being logged into the admin control panel of cmsms, this request resulted in being redirected to the admin panel to actually _login_. Probably normal behavior.
Without realizing it, I had previously logged into my cmsms admin control panel and subsequently navigated away from the page without properly logging out. Also, I hadn't closed my browser yet, so my cmsms login was still active. I had then tested the exploit, which surprisingly spewed forth my cmsms username and hashed password. However, after properly logging out of the cmsms admin panel or closing all instances of my browser, I could no longer use the sql injection exploit. I was redirected to the cmsms admin control panel to login again.
However, this sql injection technique can still be used by other cms users (even a user with very restricted permissions) to obtain the username and password hashes. Thus a basic cmsms user could potentially gain Admin credentials by using this exploit. Again, the intval fix on line 34 of content_css.php in TinyMCE fixes this as well.
Regards,
nwcon
Re: SQL Injection and fix
Posted: Tue May 13, 2008 2:45 pm
by Pierre M.
nwcon wrote:
I was actually using the following to test the SQL Injection exploit
/modules/TinyMCE/content_css.php?(very_bad_query_string...)
Without being logged into the admin control panel of cmsms, this request resulted in being redirected to the admin panel to actually _login_. Probably normal behavior.
Hmm... when using the star-excluding filtering rewriterule above (even without pretty URLs), the "normal behaviour" is a good 403 right in the face of the attacker before it even reaches the PHP layer.
Pierre M.
Re: SQL Injection and fix
Posted: Tue May 13, 2008 4:11 pm
by nwcon
When using the rewrite rule, I do get the 403 error. Without the rewrite rule, I'm redirected to the admin login page.
Regards,
nwcon