CPG Dragonfly™ CMS

Jeruvy · Joined: Apr 23, 2004 Posts: 1433 Location: Canada

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

Quote:

## 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

Jeruvy · Joined: Apr 23, 2004 Posts: 1433 Location: Canada

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

spacebar · Joined: Sep 28, 2005 Posts: 413 Location: Providence

Around line 100 where it says:

PHP:


	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.

Jeruvy · Joined: Apr 23, 2004 Posts: 1433 Location: Canada

spacebar wrote:

Around line 100 where it says:

PHP:


	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.

Phoenix · Joined: Apr 19, 2004 Posts: 8729 Location: Netizen

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:

Code:

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

radiogetswild · Joined: Apr 22, 2004 Posts: 685 Location: UK

Hi yer

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

tuta · Joined: Jun 29, 2004 Posts: 465 Location: Houston

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

macavity · Joined: Jun 23, 2004 Posts: 179

Jeruvy,

Thanks for bringing this to light, much appreciated.

Mac

Beldak · Joined: Jun 15, 2005 Posts: 78 Location: Edwards AFB, CA

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

Phoenix · Joined: Apr 19, 2004 Posts: 8729 Location: Netizen

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)

madmax · Joined: Oct 01, 2004 Posts: 49 Location: n/a

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

spacebar · Joined: Sep 28, 2005 Posts: 413 Location: Providence

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?

KitFox · Joined: Jan 04, 2005 Posts: 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.

spacebar · Joined: Sep 28, 2005 Posts: 413 Location: Providence

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.

CPG Dragonfly™ CMS

DedicatedNow