SQL Injection and fix

[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

[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

[Ted]

Yeah, this was the exact fix we put into 1.2.3...

[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

[Pierre M.]

Hello,

http://www.yourhostname.com//modules/Ti ... *%22This*/

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.

[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

[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.

[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

[Pierre M.]

Hello again,

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.

...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 ?

...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.

[nwcon]

Pierre,

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]

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

[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

[Pierre M.]

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.

[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