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).
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:
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.
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