Dragonfly CMS v9 ⇒ Security v9 :: Archives ⇒ [Fixed]DragonflyCMS 9.0.6.1 search exploit :: Archived ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum Index ⇒ Security v9

Archived ⇒ [Fixed]DragonflyCMS 9.0.6.1 search exploit

I see there still isn't any patch for this. If you are running a vulnerable site you should patch the search module.

I do not know if the dev's have released a patch for search module, but this is a pretty trivial fix.

Here is the report:

Posted on Bugtraq - Aug 10, 2006 by Dark Team


## HeLiOsZ - Dark End Team - Internet Security Team ## Dragonfly CMS 9.0.6.1 and prior XSS

## IRC: darkend.sytes.net #darkend , darkend.sytes.net & www.darkend.org ## Rish : Medium ## Type : web applet

## Creator: www.cpgnuke.com/

## Exploit:
- The vuln is in the search section,it don't validate the imput.
To exploit this vuln you simply need an Internet Browser,you must only use a cookie
logger to get the Portal cookies.
To know if it is vulnerable: <script>alert('This is an XSS Vulnerability')</script>

## Dork: Interactive software released under GNU GPL, Code Credits, Privacy Policy


One simply needs to ensure javascript does not run (or runnable) via the search page form. Removing <script> should disallow javascript from being executed.

General disabling of javascript in your browser will have no affect on this.

Proper sanitization of search form fields would also correct this.

I did not fully inspect the downloads to see if there was a patch that wasn't mentioned in this forum. But I'm surprised this still hasn't been addressed. This has been a known issue for a long time.

Enjoy and hope you don't get hacked Smile

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}

To follow up I noticed this site is not running a vulnerable search module. So maybe there is a update I'm not aware of?

If so maybe we can get a link added to this thread for others still running 9.0.6.1

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}

Around line 100 where it says:
OpenTable(); echo '<div class="genmed">'._SEARCHRESULTS.': '.$query.'</div>'; CloseTable();
Change $query to $the_query

Looking at the code, I don't find any other variables that aren't sanitized.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Unix / 2.0.46 (Red Hat) / 0.9.7a / 4.1.9-standard / 4.3.2 / 9.0.6.1

spacebar wrote
Around line 100 where it says:
OpenTable(); echo '<div class="genmed">'._SEARCHRESULTS.': '.$query.'</div>'; CloseTable();
Change $query to $the_query

Looking at the code, I don't find any other variables that aren't sanitized.


No I didn't see anyothers either as it was pretty trivial, but more importantly, I don't see a 'patch' for it in downloads.

Then someone may respond to the bugtraq post with the patch update.

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}

I've added it to the original SF1 files,

Here is the official 9.0.6.1 SF1 branch file:
dragonflycms.org/cvs/h...hp?b=9.5.2
DJ Maze wrote
To get the full branch use:
$ CVSROOT=:pserver:anonymous@dragonflycms.org:/cvs $ cvs -q checkout -r Df-9_0_6_1-SF1 -P html

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Hi yer

Can you let me know what page you want changed on line 100 for this please cheers Tim

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
MySQL Version 5.0.45 PHP Version 5.2.6 apache is 1.3.41 Dragonfly 9.2.1 Windows 7

radio --> the search module's index.php

SEARCH the WIKI
How to Port for Dragonfly

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/Apache/MySQL 4.1.22/PHP 4.4.6/9.1.2.1

Jeruvy,

Thanks for bringing this to light, much appreciated.

Mac

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1

Does this apply to the 9.1.0.8 CVS branch? It appears it might, but that CVS wasn't updated. Just curious which branches we should be patching. Smile

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.4.32 / Apache 1.3.37 / MySQL 5.0.16 / PHP 5.2.2 / Dragonfly CVS

CVS will be updated shortly - I prioritized my limited time on 9.0.6.1, the most important one Smile

(and I had a damned power failure as well)

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):

Ok, so we should be good if we replace
/modules/Search/index.php
with
dragonflycms.org/cvs/h...hp?b=9.5.2

correct?

Also, how can I get these exploit notices emailed to me?

Thank you

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/1.3/4.1/4.4.4/9.1.2.1

For the record, the only variable not being checked was what displayed the person's search string to himself on the string. No vulnerable variables were passed to the DB, so my thought is the person could only mess himself up.

It wasn't a real bad vulnerability. Am I right?

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Unix / 2.0.46 (Red Hat) / 0.9.7a / 4.1.9-standard / 4.3.2 / 9.0.6.1

spacebar wrote
For the record, the only variable not being checked was what displayed the person's search string to himself on the string. No vulnerable variables were passed to the DB, so my thought is the person could only mess himself up.

It wasn't a real bad vulnerability. Am I right?


It creates an XSS exploit condition. A user can post a URL with javascript included in the query, and then run that javascript in the sandbox of any user who clicks on that URL.

I won't give details, however this could, for example, allow a malicious user to steal any account, including admin login provledges. So it's pretty bad.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux 2.4.27/1.3.33/4.0.21-log/4.3.10/9.0 RC1

KitFox wrote
spacebar wrote
For the record, the only variable not being checked was what displayed the person's search string to himself on the string. No vulnerable variables were passed to the DB, so my thought is the person could only mess himself up.

It wasn't a real bad vulnerability. Am I right?


It creates an XSS exploit condition. A user can post a URL with javascript included in the query, and then run that javascript in the sandbox of any user who clicks on that URL.

I won't give details, however this could, for example, allow a malicious user to steal any account, including admin login provledges. So it's pretty bad.


I think you're wrong because the DB selects were using a different variable. This non-sanitized variable was only used to display to the screen, other variables hit the Database.

I know about the xss methods, but for personal knowledege, I still fail to see what a person could have done with this other than display to themselves the exploit.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Unix / 2.0.46 (Red Hat) / 0.9.7a / 4.1.9-standard / 4.3.2 / 9.0.6.1

All times are UTC
All content of this website is copyrighted by the Creative Commons NC-SA
The logos and trademarks used on this site are the property of their respective owners
We are not responsible for comments posted by our users, as they are the property of the poster.
Our server runs on 2 × 2.4 Ghz @ 60% with 2048 MB RAM with no accelerators do not click
Interactive software released under GNU GPL, Code Credits, Privacy Policy