CMS Made Simple Forums

Today we would like to announce a fix for an important security vulnerability that was detected in all running versions of CMS Made Simple.

Today, the CMSMS Dev team became aware of a serious vulnerability in our software. Apparently the News module shipped with all versions of CMS Made Simple were open to SQL injection attacks that would return the hashed versions of all administrator passwords, allowing the hacker to gain administrative access to the website if those hashes could be reverse engineered.

We have released CMS Made Simple version 1.9.4.2 with fixes to the News module to address this vulnerability, and we encourage all users to upgrade their sites as soon as possible. Additionally, out of courtesy, we have patched the 1.6 series of CMSMS, and released a version 1.6.10 for those users that are forced to use PHP 4 based servers. Both versions of CMS Made Simple can be downloaded from our download page.

At this time CMS Made Simple 1.9.3 and above are supported by the dev team. Please ensure that you have upgraded your CMSMS install to the latest development version before requesting supoort for a difficulty with CMSMS.

Again, we thank you for your support and encourage you to upgrade to CMSMS 1.9.4.2 as soon as possible.

71 successful files the other 2,681 failed saying "No Such Directory Exists". Any ideas?

Is this an issue with all previous releases? Or only for 1.9.4.1.

Silly question: If the News module is installed, but isn't being used, is the installation safe?

it's an issue in ALL versions of CMSMS (well going back a long way anyways... ).

And if you have uninstalled (or deactivated) the News module than this will not effect you. If however you have it installed, and are just not using it on any page, then your site is still vulnerable.

Hi Robert

Can we just replace the news module rather than update everything or will this not work.

Specifically CMSMS 1.8.1

Is reverse engineering the hashed passwords easily achieved?

Many thanks

Nik

There are many online reverse md5 dictionaries... I'm surprised what I find there sometimes... Dictionary words or common phrases are a big no-no.

Cheers Wishbone

Well I can't tell what my users passwords are, but they dont have admin access anyway.

I was just hoping for a simpler solution than upgrading everything and preying the other modules are still happy.

I wonder if other users are charging their clients for the time on making updates such as this on older installs of cmsms?

Nik

For 1.10, it would be nice to have more robust separation between unauthenticated (public) website access and authenticated (editor/designer/admin) CMS access.

My sites use Apache configs for a little extra security:-

• 1. /admin is renamed, and only visible from HTTPS. Hopefully 1.10 will offer this as a supported feature.
• 2. HTTPS uses Apache .htaccess for pre-authentication. Not ideal, but it offers an extra layer of protection.

Two of the issues that remain are:-

• 1. My config does not prevent SQL injection against publicly-accessible files like news.php. (I started looking at mod_rewrite rules but they didn't trigger when I tested them.)
• 2. Some PHP files under /lib, /plugins and /modules are only for authenticated users - but there's no easy way to identify those files and hide them from public access.

My wish list for 1.10:-

• 1. All PHP files for authenticated users should be stored under /admin (or renamed admin folder). That is, some of the files now in /lib, /plugins, /modules would need to move, so that the attack surface is reduced.
• 2. Unauthenticated vs. Authenticated access should use different SQL login credentials. So if an attacker gets SQL injection into the public website, he can't see the CMSMS password hashes.
• 3. Maybe, have some mod_rewrite rules in the sample configs showing how to block SQL injection by unauthenticated users.

But maybe these changes are too expensive to make now. Often real life places limits on free time for geeking!

Keep up the great work,

- Martin

Just noticed this security message. My site was compromised. Basically they added a stack of php pages advertising all sorts of products then spammed. Not very nice to be used by the bad guys, but glad the problem is sorted.

The files seemed to be added on the 23/6 and 24/6 and there were hundreds.

Upgraded to latest now, so hopefully life will be peaceful.

cheers, shaun.

Here is a little more info and a couple of questions:
They apparently used a script labeled r.b superpack 1.4

I had 750 *.php files and one log file in modules/search/domain/ which seem to sell stuff and spam. The domain .htaccess file was edited and a few of these sections were added:
RewriteEngine on^M
RewriteBase /^M
RewriteCond %{DOCUMENT_ROOT}/modules/Search/(domain_name_edited)/%{REQUEST_URI}.php -f^M
RewriteRule ^(.*)$ /modules/Search/(domain_name_edited)/$1.php [L]^M

Also some error lines like:
ErrorDocument 404 http://xxxxxxxxx.ru/grammar/index.php

and lots more RewriteCond for search engines

The ^M's are just windows carriage returns, since I am on unix with mainly unix edited files I am trying to search for more of these to see if there are other newly edited files.

I will download a default hash and see if that helps find backdoors or other files.

Has anyone else recovered from this successfully?

Would anyone like to see the files they left on the server?

Any thoughts on where to look for edited files or database changes?

Do you think this is recoverable or is a complete wipe called for?

thanks, shaun

This is why regular verified backups are important.

Fastest and easiest way to fix a site is to wipe all of the files and the database.. and restore from a recent, known good backup