CPGNuke Dragonfly 9.0.6.1 remote commands execution through arbitrary local inclusion

Posted February 9th, 2006 @ 0212am by rgod @ autistici.org




There are two ways to inject arbitrary code in dragonfly resources:

i) in cpg_error.log, poc:

this works with $error_log = true in error.php (not the default)
some problems with spaces, converted as %20 so this way works with
allow_short_open_tag = On in php.ini

ii) uploading a malicious .png file in modules/coppermine/albums/userpics/
dir. We will search for a php[some hex values].tmp file, you have to supply
valid credentials with upload rights to do that...by default, any user can
upload

however you can try manually including some database file or Apache log... use
your imagination

POC's removed

I am not a security expert, but it seems like this is completely dependant upon the user not following install.txt step #8

Quote::

#8 --- After installing, delete install.php and the /install directory!

It looks like it tries 3 different things. The first 2 require install.php and the error log enabled.

If those fail, then it tries a Coppermine exploit.

install.php

Code::

if (empty($currentlang) || ($currentlang != 'english' && !file_exists(BASEDIR."install/language/$currentlang.php"))) { $currentlang = 'english'; }

change into

Code::

if (empty($currentlang) || !preg_match('#^[a-z_]+$#', $currentlang) || ($currentlang != 'english' && !file_exists(BASEDIR."install/language/$currentlang.php"))) { $currentlang = 'english'; }

error.php fixed
dragonflycms.org/cvs/h....php?g=9.8

Excellent work, is there a new archive ready for download.

To my reading of this, yes IF the install.php is LEFT on the server, AND the person deals with the insecure error.php AND/OR [edit: corrected] can upload malicious PNG's (trivial) then this exploit will work.

Of course the thing to keep in mind is since the install.php does not delete itself, it's up to the user who may not be aware, nor read documents fully or perhaps may not understand and be afraid to delete files.

Just to add...a good idea would be in cmsinit.ini to check for the presence of the install dir, and load a page instead of main to remind the user to delete this. Prevent them from using the site proper while it exists.


Cheers!

I'm not reading it that way. I think the image upload is a seperate exploit from the error.php and install.php exploits.(hopefully I'm wrong though).

Mainly because of these lines.

PHP:

if (eregi("HiMaster!",$HtMl)) {echo "Exploit succeeded...<br>";die;} else {echo "STEP 2 failed..., trying STEP 3...";} #STEP 3 -> If STEP 2 failed, trying to upload a malicious .png file -> firstly login to retrieve a cookie # and prepare an album to upload pictures in if ($ULOGIN=="") {die("I need a valid username to launch STEP 3...");}

Yes, the install.php is mandatory. The error.php and/or the malicious upload can cause the exploit. Sorry I wasn't clearer.

Jeruvy wrote:

Yes, the install.php is mandatory. The error.php and/or the malicious upload can cause the exploit. Sorry I wasn't clearer.

Sometimes I like being wrong. Thanks!

The coppermine uploading is still worked on.
This is an highly sophisticated script to get around server issues like open_base_dir and safe_mode that are cause by terrible server admins.

If we reverted to the original coppermine upload system this exploit is not there but will fail to work on many servers that are badly setup.

this thread dealing with a similar exploit to PhpGedView may be of interest https://sourceforge.net/forum/forum.php?thread_id=1411249&forum_id=185166

basically the exploit involved multiple attempted sign ins which were invaid, and therefore failed. The failed attempts contained code snippets which were written to an unprotected error log as a normal process of the software.

One the critical code had been loaded it was called by another command and the run code enabled the hacker to then install foreign files and scripts on the server.

Fortunately the exploit was only possible on a limited number of older versions running in index mode, without a database.

I'm sure the PhpGedView Devs will help with any inquiries if they can

Here are the official 9.0.6.1 SF1 branch files:
dragonflycms.org/cvs/h...hp?b=9.6.2
dragonflycms.org/cvs/h...p?b=9.12.2
dragonflycms.org/cvs/h...p?b=9.15.2
dragonflycms.org/cvs/h...p?b=9.19.2

To get the full branch use:

Code::

$ CVSROOT=:pserver:anonymous@dragonflycms.org:/cvs $ cvs -q checkout -r Df-9_0_6_1-SF1 -P html

Or wait till i get all other exploits we found in there.

[edit]
Also added a previous found XSS fix in there
[/edit]

Thanks for your incredibly fast work DJ!

Jeruvy wrote:

Just to add...a good idea would be in cmsinit.ini to check for the presence of the install dir, and load a page instead of main to remind the user to delete this. Prevent them from using the site proper while it exists.

I kinda like this idea -- but maybe just a section of the main admin page (where it usually tells you you have the most current version of DF) would be enough of a reminder....

DJMaze wrote:

Here are the official 9.0.6.1 SF1 branch files: dragonflycms.org/cvs/h...hp?b=9.6.2 dragonflycms.org/cvs/h...p?b=9.12.2 dragonflycms.org/cvs/h...p?b=9.15.2 dragonflycms.org/cvs/h...p?b=9.19.2 To get the full branch use: Code:: $ CVSROOT=:pserver:anonymous@dragonflycms.org:/cvs $ cvs -q checkout -r Df-9_0_6_1-SF1 -P html Or wait till i get all other exploits we found in there. [edit] Also added a previous found XSS fix in there [/edit]

Just to be clear.. we use these files to patch the existing 9.0.6.1 release? Thanks for the fast work!