CMSimple_XH–Forum

Hello Community,

unfortunately this kind of sh*t happens

What to do?

• Report the attack with all details that seem worth mentioning here in the forum! On the one hand, other's might give useful additional information, and on the other hand, it might make the developers aware of existing security issues.
• investigate how the site has been hacked:
  1. Did the attacker gain access to your hoster's website configuration?
     Were any changes made in this configuration? Were you the last one who logged in?
  2. Did the attacker obtain your FTP login credentials?
     Were any modifications made, that couldn't be done through CMSimple (even in the back-end)? Typically any modifications to index.php and particularly to files that the webserver process is not allowed to write to.
  3. Did the attacker obtain the CMSimple password?
     Were logins from foreign IP addresses recorded in cmsimple/log.txt? Were modifications made, that are typically done through CMSimple's back-end?
  4. Did the attacker use a security hole in CMSimple or a plugin to manipulate the site?
     When there's no evidence, that one of the former has happened, this might be well how your site's was being hacked.
  5. Did the attacker use a security hole or even a malicious website hosted on the same server?
     That's possible, if scripts on different domains are executed by the same user (typically when PHP is run by mod_php), or you've set write permissions for files and folders for everbody (666 resp. 777), and there are no other security measures in place (such as safe mode, open_basedir).
  It's quite important to find out what has happened -- otherwise you should regard all 5 points as being happened, and act accordingly. Note, that you should be very careful when you investigate the problem to avoid being victim of follow up attacks: scan your local computer for malware; use the latest stable browser version; turn off Javascript; clear your browser cache
  Use a search engine to look for details about concrete evidence of the hack (e.g. if a file 123hack.php was created on the server, google for the file name)
• Eliminate the vulnerability resp. reduce the security risk:
  1. Change your password (use a strong password, that you don't use anywhere else). Contact your hoster about the incident, and ask, if there are additional measures you can take to avoid been hacked this way again.
  2. Change your FTP password (use a strong password, that you don't use anywhere else). Don't store the password in the FTP client.
  3. Change your CMSimple password (use a strong password, that you don't use anywhere else). Remove write permissions from all files and folders that don't need them for normal CMSimple use.
  4. Look for an appropriate security patch; otherwise report the vulnerability. If a plugin is the source, try to contact the author. If no security patch is available, remove the plugin.
  5. If every domain executes PHP as another user, set your file and folder permissions to at most 755 resp. 644. Otherwise contact your provider to prohibit access from other domains on the same server. You might consider to rent your own virtual server (VPS).
• Delete the old site completely (their might be hidden leftovers from the attack) and restore the site from a recent "clean" backup.

Any comments and additions are welcome!

Christoph

PS: See also http://www.google.com/webmasters/hacked/.

Thanks for very useful information.

through
Very useful information but unfortunately as we will stick to a cracker, (because they do not attack hackers, hackers are people who are familiar with the fields of computers, but use it in the right order) is rather wnim not win even though this information may a lot of help

@DEVELOPERS
In my opinion it would rise the security if all files that have to be only "read only" would be set to "444" or "400".
While the attacs to my domains were made, these files have been infected:
config.php, <language>.php, index.*, very seldom also adm.php, help.* and content.htm and lately also almost any <language>.js.
There have been always put readable or encrypted javascripts with IFRAMES redirecting to another URLs.
These codes have been put either just avter the first "<?php...", on the end of a file or once they were put about the line #500 (if a file has been that long). Sometime the rest of the file was cut away.

So think that a general settings for files and folders seems not to be safe anough. And here I think the setting shall be set more precise especially for special files.

Tata wrote:In my opinion it would rise the security if all files that have to be only "read only" would be set to "444" or "400".

ACK. This is explained in detail on http://www.cmsimple-xh.org/wiki/doku.ph ... ermissions (incl. the explanation about the difference between 444 and 400).

However, it would be nice, if these permission could be set automatically from some script.

cmb wrote:However, it would be nice, if these permission could be set automatically from some script.

That's exactly what I think about. But AFAIK it won't be generally possible, because of the ownership. However, if this would be possible, it would make the installing and use of CMSimpleXH for all users very safe and comfortable.
Generally - the only files the users need to edit are: template files, language files and configs. Most of them are prepared before the installation, however. I assume that only very seldom any of these files are edited online.
I have tried a procedure already (working with FlashFXP client - which aloves batch operation):
1. set all files to 444
2. set all folders to 755
3. set all ??.php, ??.js, content.htm, *.txt, *.dat to 644

and the page worked fine.

But the rights were changed by FTP. I am not sure if this will be accepted by the server if the rights would be set by a script. The ownership was an issue in the time of CMSimple 2.4.

Tata wrote:set all ??.php, ??.js, content.htm, *.txt, *.dat to 644

And what about pagedata.php?

Tata wrote:But the rights were changed by FTP. I am not sure if this will be accepted by the server if the rights would be set by a script. The ownership was an issue in the time of CMSimple 2.4.

You're right. The permissions should be changed by FTP. Changing them directly in the file system from PHP will only work, if a file is writable when it has 644, not when it has to be 666.

cmb wrote:

Tata wrote:set all ??.php, ??.js, content.htm, *.txt, *.dat to 644

And what about pagedata.php?

Of course page_data.php to 644 as well. But these files have not been infected so far by anz attack.

I have 644 for files and 755 for folders on my website, do you think these are safe enough?

Should I use 400?

cacamoto wrote:I have 644 for files and 755 for folders on my website, do you think these are safe enough?

Should I use 400?

With regard to security it's best to only give write permissions to those files which really need them. Other files should be read-only; folders usually need to be executable so their contents can be accessed.

For webservers where the file owner (usually the FTP user) is the same as the one who executes the PHP process (as in your case), folders should have 0755, read-only files 444 and writable files 644.

For details see http://www.cmsimple-xh.org/wiki/doku.ph ... ermissions.