{Solved} Site Hacked, Argument with Hosting Company

[dmagill]

Morning,

Sometime over the May2/4 weekend three of my CMSMS sites got hacked. The host kicked it back to CMSMS insecurities, which I find highly improbably.

To make the Hackers site stick, he/she/they had to remove a number of CMS files.

Can you safely remove most of the CMS files from within CMSMS and still have the CMS? IF that was possible I would guess the hackers uploaded their image files and then their replacement index.php, and still had some sort of control over the site till they were done... I know that If I break the CMS the CMS is broken...

To be honest this situation is ticking me off. Nothing is perfect, but I look at this and I don't see a CMSMS issue, I see a Server issue.

Thanks.

[calguy1000]

Can you safely remove most of the CMS files from within CMSMS and still have the CMS?

No.

However, you have not provided enough information to be able to tell you anything about how the user got in.

Usually you need to do indepth file and log analysis.

[dmagill]

Thanks for getting back to me Calguy1000.

At the moment I got nothing. I don't have access to my logs, nor have I gotten that many answers. This is not the first time I have had a problem with his this host but probably going to be the last. Got permission to move. The first site hacked was a Wordpress site and that was 2 months ago. I was told the server had been hardened.... hardened like butter it would seem.

My gut says they access the server and removed files. Not access the CMS.

As I get more I will post more.

Thanks again.

[Tann San]

We've had one of our client sites attacked as well. The attack is modifying several files to include JavaScript in the frontend output. The method is slightly different for each filetype but the end result is the same, for example:

JavaScript

Code: Select all

PHP

Code: Select all

By doing a search of files modified in the last 24 hours I found the files to be:

• /index.php
• /lib/xajax/xajax_js/xajax_core_uncompressed.js
• /lib/xajax/xajax_js/xajax_core.js
• /lib/jquery/js/jquery.ui.nestedSortable-1.3.4.js
• /lib/jquery/js/jquery.json-2.2.js
• /lib/jquery/js/jquery-ui.1.8.14.js
• /lib/jquery/js/jquery-1.6.2.js
• /lib/filemanager/ImageManager/newFolder.html
• /lib/filemanager/ImageManager/IMEStandalone.js
• /lib/dynamic_tabs/tabs.js
• /admin/themes/NCleanGrey/login.php
• /admin/login/php
• /admin/index.php
• /admin/header.php
• /admin/footer.php

After cleaning the files above I did a search for "CMS MS XSS" and one of the top sites has a list of known XSS exploits for version 1.11.10 along with examples of how to implement them. There's some nasty things in there though, like it seems fairly easy to add your own content to any page without being logged in. I don't think my attacker is doing this though since they are modifying the files and not stuff stored in the database, at least from what I can tell.

Some of the files modified are from an older version of CMS MS leftover from past upgrades so I'm going to clear all files from the site and then do a fresh upload of the latest CMS, then manually add the module files, images etc so that way I know everything is 100% the latest version and naughty-hacker-code free, you know, besides that developer backdoor you guys hid in every CMS MS install out there

This is the 2nd time in two days the same files have been modified which is why I'm going to do the brute force method above. Unfortunately the client had the server logs set to rotate when they hit 10MB which was less than a days worth of the access log. After the 2nd attack I persuaded them to increase that so it would record about 3 days worth of the log so hopefully I can see what the bad-person is accessing and in which order.

I figured the first big step in solving my problem is to let you know about the exploits on that page. I'll give it a few days to see if you are going to fix them all quickly and if not then I will have a go myself. I don't really feel like I have much choice as we've got quite a few client sites that use CMS MS so I now have a bit of my brain worrying they will be next!

I know you're busy with the v2 betas but I hope you can still spend some time squashing these exploits.

[Jo Morg]

Please don't post the code here.

[Tann San]

Why, what possible harm could it do? It's 1-3 lines of code with a small identifier comment above and below. I thought at the very least anybody else with this problem that searches for a snippet would find this thread and know it wasn't just them, I changed the link in the code to a made up one. Without the code to show the problem all my post really says now is "here are some files that were modified" but it no longer shows what was added to them so it's pretty useless.

[Jo Morg]

Sorry for the lack of explanation, before.
This forum has been blacklisted more than once for having samples of hackers code in it. So better not post samples. Sorry.
Also, the list of files that have been modified is plenty, as you can always compare with the original ones to check for hacked attempts.

[Tann San]

ah now I see why you were quick to remove the code

I've replaced the modified files with their originals for now, I'm off to lunch and then I'm going to spend a few hours doing the total file replacement I described before.

Do you or does anybody have any suggestions as to what I can do? I'm going to get the client to increase the backup schedule so it's easier to restore the site but this will get tedious if they keep coming back and doing it each day.

One thing that is really weird and kinda bugging me is that there is also a web shop in a subdirectory and that doesn't appear to of been touched at all. I would of thought that would be a much tastier target than the CMS. I mean, if they have gotten filesystem access to modify files in the CMS then I don't understand why they haven't also modified files in the shop. The client is using that fact to say "well it's clearly not the shop, it's the CMS" but I don't see it that way. If it was me being naughty then I'd of found an exploit with the shop but not actually tampered with the shop so whichever sucker (me) has to fix this looks in the wrong place. Then I hear the word echoed in my head "paranoia...paranoia...paranoia"

I'm hoping the access and error logs will give me a better idea of what's going on.

[Jo Morg]

I'm hoping the access and error logs will give me a better idea of what's going on.

That would be great.

Do you or does anybody have any suggestions as to what I can do? I'm going to get the client to increase the backup schedule so it's easier to restore the site but this will get tedious if they keep coming back and doing it each day.

Well the link you provided seems to have quite a long list, but (it seems) that all them need something an attacker usually can't or shouldn't get hold of:
a: a valid session id;
b: a clear path to the admin url;
c: a clear path to the install script;

Check this for tips: http://docs.cmsmadesimple.org/general-i ... ring-cmsms
Also make sure there are no other vulnerable scripts on the same server, that might give an attacker an access point.
HTH

[dmagill]

Thought I would followup and then close this thread.

Everything got hacked. At first there was the mandatory, 'It wasn't me!', by the host and then as more and more came out he had to step back from his self serving platform and accept the blame.

CMSMS, Joomla!, Wordpress and old fashion HTML websites had been hacked.

I got no access to any logs and the information coming my way has been slim and none.

We are in the process of building a new home for our sites.

Thanks everyone for taking the time, and I wish I had better news.

David

[Tann San]

As to my problem, it took a bit of threatening and hostage taking but we eventually convinced the "server expert" to enable logging so we could see what was happening at the time of the attacks. From what I can tell, all the file modifications had been done via FTP. After chasing it up the site owner confessed that they had fired one of their admins a few months earlier in some really ugly incident and then they didn't change all the passwords.

[dmagill]

Wow... That is pretty responsible behaviour on their part 0_o.

We are a simple beast of a company. We don't like something, we stop using it, and take the hit for the move. No stress or anything =-)

Thanks!