From theall at tenablesecurity.com Thu Dec 4 16:45:23 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 4 Dec 2008 11:45:23 -0500 Subject: [VIM] E.Z. Poll v.2 (Auth Bypass) Remote SQL Injection Vulnerability Message-ID: FYI, milw0rm 7315 / BID 32562 seems to be the same issue reported by in August by t0fx and covered by CVE-2008-3590 / BID 30536 / Secunia 31368 (see also http://www.xssing.com/index.php?x=3&y=48). George -- theall at tenablesecurity.com From str0ke at milw0rm.com Thu Dec 4 19:12:12 2008 From: str0ke at milw0rm.com (str0ke) Date: Thu, 04 Dec 2008 13:12:12 -0600 Subject: [VIM] E.Z. Poll v.2 (Auth Bypass) Remote SQL Injection Vulnerability In-Reply-To: References: Message-ID: <49382B8C.1030502@milw0rm.com> Removed from the front end. Thanks George, /str0ke George A. Theall wrote: > FYI, milw0rm 7315 / BID 32562 seems to be the same issue reported by > in August by t0fx and covered by CVE-2008-3590 / BID 30536 / Secunia > 31368 (see also http://www.xssing.com/index.php?x=3&y=48). > > > George From cleeus at cs.tu-berlin.de Thu Dec 18 16:46:59 2008 From: cleeus at cs.tu-berlin.de (Kai Dietrich) Date: Thu, 18 Dec 2008 17:46:59 +0100 Subject: [VIM] Security-Basics Archive Message-ID: <200812181746.59349.cleeus@cs.tu-berlin.de> Hello .+, I'm a student of Computer Science at the Berlin Institute of Technology and am currently writing my master thesis. As a part of this work I would like to analyze the securityfocus.com "Security Basics" mailinglist with datamining techniques (what were the topics and how did they change). I wrote a mail to the moderator of the list and asked if I could get a maildir/mbox archive starting from day 1 but got no reply so far. Ofcourse I could crawl their archives but that wouldn't be very friendly. Is there anyone here who happens to have a complete maildir/mbox from this list? Or is there someone who knows someone at securityfocus.com? Thank you Kai Dietrich From dm at securityfocus.com Sat Dec 20 17:23:18 2008 From: dm at securityfocus.com (dm at securityfocus.com) Date: Sat, 20 Dec 2008 10:23:18 -0700 Subject: [VIM] [admin@bugreport.ir: chicomas <=2.0.4 Multiple Vulnerabilities] Message-ID: <20081220172318.GN26090@securityfocus.com> Just a heads up. The XSS is old and known. We have it as BID 29025. ----- Forwarded message from admin at bugreport.ir ----- From: admin at bugreport.ir Subject: chicomas <=2.0.4 Multiple Vulnerabilities To: bugtraq at securityfocus.com Date: Sat, 20 Dec 2008 10:55:49 +0330 User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) Message-ID: <20081220105549.b6ocl4209cc4wg8c at mail.amnpardaz.com> ########################## www.BugReport.ir ######################### # # AmnPardaz Security Research Team # # Title: chicomas <=2.0.4 Multiple Vulnerabilities # Vendor: http://www.chicomas.com/ # Demo: http://demo.opensourcecms.com/chicomas # Bug: Database Information Disclosure, Authorization Weakness, XSS # Vulnerable Version: 2.0.4 # Exploitation: Remote with browser # Fix: N/A # Original Advisory: http://www.bugreport.ir/index_59.htm ################################################################### #################### - Description: #################### ChiCoMaS is free web based Content Management System based on PHP & MySQL with Full featured WYSIWYG TinyMCE editor, File management with QuiXplorer, User and group administration to manage access permissions & Backup/Restore with integrated MySqlBackupPro. #################### - Vulnerability: #################### +-->Dtabase Information Disclosure POC: http://[URL]/chicomas/config.inc +-->The Latest generated Database backups POC: http://[URL]/chicomas/backup +-->Cross Site Scripting (XSS). Reflected XSS attack in "index.php" in "q" parameter. POC: http://[URL]/chicomas/index.php?q=" #################### - Solution: #################### Restrict and grant only trusted users access to the resources. Edit the source code to ensure that inputs are properly sanitized. #################### - Credit : #################### AmnPardaz Security Research & Penetration Testing Group Contact: admin[4t}bugreport{d0t]ir www.BugReport.ir www.AmnPardaz.com ----- End forwarded message ----- -- Dave McKinney Symantec keyID: E461AE4E key fingerprint = F1FC 9073 09FA F0C7 500D D7EB E985 FAF3 E461 AE4E From jericho at attrition.org Tue Dec 23 02:00:14 2008 From: jericho at attrition.org (security curmudgeon) Date: Tue, 23 Dec 2008 02:00:14 +0000 (UTC) Subject: [VIM] phpList "LFI" (OSVDB 50747 / Nessus 35259 / BID 32841) Message-ID: Below is confirmation that the recently reported "local file inclusion" is actually vulnerable to a remote file inclusion. This was discovered by Tenable during a quick examination of the 2.10.8 code base. ---------- Forwarded message ---------- From: Michiel Dethmers To: security curmudgeon Date: Mon, 22 Dec 2008 20:56:55 -0200 Subject: Re: recent vulnerability more severe than local file inclusion? (fwd) Hi, checking the php 5 docs, yes, I think you're right and with php5 it may also be a remote inclusion as the docs state "As of PHP 5.0.0, this function can also be used with /some/ URL wrappers. Refer to List of Supported Protocols/Wrappers for a listing of which wrappers support stat() family of functionality." It is the issue as you describe, with the cline variable not being initialised correctly. Michiel security curmudgeon wrote: > > > ---------- Forwarded message ---------- > From: security curmudgeon > To: phplist-developers at tincan.co.uk > Date: Mon, 22 Dec 2008 12:06:25 +0000 (UTC) > Subject: recent vulnerability more severe than local file inclusion? > > > Hello phpList developers, > > Regarding your recent announcement (http://www.phplist.com/?lid=273), > your wording implies the vulnerability is a local file inclusion > issue. However, after a cursory code examination, I believe the issue > is either a remote file inclusion (considerably more serious), or > there is potentially a second vulnerability: > > Look at admin/index.php: > > if (!ini_get("register_globals") || ini_get("register_globals") == > "off") { > # fix register globals, for now, should be phased out gradually > # sure, this gets around the entire reason that > regLANGUAGE_SWITCHister globals > # should be off, but going through three years of code takes a long > time.... > > foreach ($_REQUEST as $key => $val) { > $$key = $val; > } > } > ... > if (isset($_SERVER["ConfigFile"]) && is_file($_SERVER["ConfigFile"])) { > print ''."\n"; > include $_SERVER["ConfigFile"]; > } elseif (isset($cline["c"]) && is_file($cline["c"])) { > print ''."\n"; > include $cline["c"]; > > Regardless of PHP's register_globals, an attacker has control of > cline[c], which gets passed to an include(). 2.10.8 appears to have > fixed the issue by explicitly setting cline to an empty array after > the register_globals emulation code block. > > If I understand this correctly, is_file() works with URLs such as > //somehost/file and ftp://somehost/file, at least as of PHP 5.0.0. > > Can you please confirm? > > Brian > OSVDB.org -- Michiel -- Michiel Dethmers Tincan Limited London, Buenos Aires & Machynlleth Tel: +44 (0)1654 702413 Email: michiel at tincan.co.uk pgp: http://tincan.co.uk/michiel.asc From smoore at securityglobal.net Tue Dec 23 04:43:46 2008 From: smoore at securityglobal.net (Stuart Moore) Date: Mon, 22 Dec 2008 23:43:46 -0500 Subject: [VIM] duplicative CVE numbers on MS SQL vuln? Message-ID: <49506C82.6090303@securityglobal.net> Hi. Anyone know if today's CVE-2008-4270 (Microsoft SQL Server) is the same as the previously reported CVE-2008-5416 (Microsoft SQL Server, as disclosed by SEC Consult)? Thanks, Stuart From coley at linus.mitre.org Tue Dec 23 20:06:45 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 23 Dec 2008 15:06:45 -0500 (EST) Subject: [VIM] phpList "LFI" (OSVDB 50747 / Nessus 35259 / BID 32841) In-Reply-To: References: Message-ID: On Tue, 23 Dec 2008, security curmudgeon wrote: > Below is confirmation that the recently reported "local file inclusion" is > actually vulnerable to a remote file inclusion. This was discovered by > Tenable during a quick examination of the 2.10.8 code base. Speaking of LFI/RFI and PHP 5, does anybody have a cheat sheet of which types of attacks work against which PHP settings and versions, especially the remote ones? For example, I think some version of "allow_url_fopen" will still accept ftp:// URLs even when disabled. We run into this question every once in a while but are relatively inconsistent in CVE with how we interpret such reports. - Steve From coley at linus.mitre.org Fri Dec 26 17:25:02 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 26 Dec 2008 12:25:02 -0500 (EST) Subject: [VIM] duplicative CVE numbers on MS SQL vuln? In-Reply-To: <49506C82.6090303@securityglobal.net> References: <49506C82.6090303@securityglobal.net> Message-ID: I sent an inquiry into Microsoft early evening on Dec 23 but haven't heard back yet. - Steve On Mon, 22 Dec 2008, Stuart Moore wrote: > Hi. Anyone know if today's CVE-2008-4270 (Microsoft SQL Server) is the > same as the previously reported CVE-2008-5416 (Microsoft SQL Server, as > disclosed by SEC Consult)? > > Thanks, > > Stuart > From jericho at attrition.org Sat Dec 27 06:28:53 2008 From: jericho at attrition.org (security curmudgeon) Date: Sat, 27 Dec 2008 06:28:53 +0000 (UTC) Subject: [VIM] CVE published vs unpublished In-Reply-To: References: <200801142150.27475.noamr@beyondsecurity.com> Message-ID: From: Noam Rathaus Date: Mon, 14 Jan 2008 21:50:27 +0200 Notice the date here, i'm replying a considerable time later. Noam said: : > Can someone from CVE administrator give me an estimate how many given CVEs : > have not materialized into "anything" (never been disclosed - remained under : > review)? This is a good question. Over the years, i was curious from an OSVDB standpoint and "how many CVE do we map to" from a numeric aspect. If you look at CVE-2007-0001 to CVE-2007-3000, are we really missing 500 (arbitrary number)? Or is it a case where we're missing 300 because 200 were never published? When I got back into the grind of full time pen-testing, I was in a position to handle vulnerability disclosure. It was a shop with 20 full time consultants when I joined, every single one working 40 hour weeks or more, with *zero down time*. Imagine the vulnerabilities we found over time =) While many of us did a lot of custom application tests, that do not warrant CVE numbers, we did test COTS frequently. When I joined, no one was handling disclosure either. It was done rarely, by a consultant's own initiative, typically only for reoccuring clients. Within a year, I think I ended up requesting a dozen or so CVEs from Steve (I say that to distinguish they came from CVE, not another pool). Over a year after requesting them, most are still reserved. Since I am no longer with the company, I don't know if they will ever be released. If they aren't in 5 years, I may mail Steve out of the blue and say "these CVE requests will never get published I don't think", just to throw him a curve ball and make him think. Some of the vulnerabilities I found, have since been published. The company I was with finally opted not to publish advisories, after spending countless hours writing our policy, template, going back/forth with lawyers, etc. The ones I released were done quietly, with 100% responsible disclosure (waiting a long time for the vendor if needed), and have since been added quietly to CVE, OSVDB and Nessus in at least one case. The vulnerabilities I did not discover, but were handling disclosure for at the time, are the ones that will likely never see the light of day unless a third party finds it. That is very possible, because none of the software was really obscure. I hate being bound by NDA and sitting on vulnerabilities that were reported, but may be unpatched because no one harassed the vendor. On Wed, 23 Jan 2008, Steven M. Christey wrote: : Also, I don't ping the people who reserved CVEs in order to check on : their status. Some might have turned out to be false and the requester : never notified us; in other cases, maybe a decision was made not to : publish; some might still be in the middle of the resolution process. This would be a neat one time event. Ping the people who requested, ask the status. I suggest it because I have done this with a reserved OSVDB that sat there for a year. After I pinged the researcher, he basically said "oops, totally spaced it, thanks for reminding me" and he ended up publishing details and the OSVDB was made public. : Also, we are inconsistent about handling vague vulnerability reports : from auction / non-disclosure firms like WabiSabiLabi and Immunity, but : generally don't include them. This includes the hash publications we're : starting to see more of. Since this mail, more have been posted. If I had more time, i'd love to document all of them in one place, and ping the researchers every X months asking if it has since been disclosed. What bothers me most about this practice is that pre-posting hashes is essentially saying "i'm first, here's proof if i need it" and it isn't necessarily linked to the actual disclosure days/months/years later. : 2001 min=18 ; max=20 : 2002 min=33 ; max=40 : 2003 min=36 ; max=56 : 2004 min=48 ; max=74 : 2005 min=110 ; max=146 : 2006 min=134 ; max=170 : 2007 min=178 ; max=231 : 2008 min=68 ; max=100 This is a fascinating number too: 873. How many people have considered that there may be 873 known vulnerabilities (likely more when you consider CVE grouping/abstraction) out there, sitting in the hands of presumably 'good' security companies, but undisclosed. That begins to give an interesting basis for considering how many vulnerabilities are out there, undisclosed, without CVE candidates. Safe to assume 5x more? 10x more? 100x more? From str0ke at milw0rm.com Mon Dec 29 05:15:50 2008 From: str0ke at milw0rm.com (str0ke) Date: Sun, 28 Dec 2008 23:15:50 -0600 Subject: [VIM] CVE-2008-0135 Message-ID: <49585D06.9080801@milw0rm.com> Anyone who installs the app pretty much has to read the Readme.htm file. >From the Readme.htm *Change the database name:* When using an Access database, all the data is stored in a single file, unlike the other databases. So caution should be taken in where you store your Access database as it can be downloaded by anyone if they know the path. If you store your Access database in a folder outside of your www folder (or wherever you keep the files for the rest of your site), then you should be safe because no one can download your database if it is outside of your www folder. If you store your database in a cgi-bin folder, or in your www folder, then it is strongly recommended that you change the default database name from *snitz_forums_2000.mdb* to a cryptic or not easy to guess name. The name should be a combination of letters and numbers. That makes it hard for anyone to guess the name of your database. Example: *n92yr2fnis.mdb * /str0ke From coley at linus.mitre.org Tue Dec 30 18:45:00 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 30 Dec 2008 13:45:00 -0500 (EST) Subject: [VIM] duplicative CVE numbers on MS SQL vuln? In-Reply-To: <49506C82.6090303@securityglobal.net> References: <49506C82.6090303@securityglobal.net> Message-ID: On Mon, 22 Dec 2008, Stuart Moore wrote: > Hi. Anyone know if today's CVE-2008-4270 (Microsoft SQL Server) is the > same as the previously reported CVE-2008-5416 (Microsoft SQL Server, as > disclosed by SEC Consult)? Microsoft just confirmed that these are the same. We'll be using CVE-2008-5416 instead of the Microsoft-assigned CVE-2008-4270. - Steve ====================================================== Name: CVE-2008-4270 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4270 ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2008-5416. Reason: This candidate is a duplicate of CVE-2008-5416. Notes: All CVE users should reference CVE-2008-5416 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. ====================================================== Name: CVE-2008-5416 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5416 Reference: BUGTRAQ:20081209 SEC Consult SA-20081109-0 :: Microsoft SQL Server 2000 sp_replwritetovarbin limited memory overwrite vulnerability Reference: URL:http://www.securityfocus.com/archive/1/archive/1/499042/100/0/threaded Reference: MISC:http://www.sec-consult.com/files/20081209_mssql-2000-sp_replwritetovarbin_memwrite.txt Reference: CONFIRM:http://www.microsoft.com/technet/security/advisory/961040.mspx Reference: BID:32710 Reference: URL:http://www.securityfocus.com/bid/32710 Reference: FRSIRT:ADV-2008-3380 Reference: URL:http://www.frsirt.com/english/advisories/2008/3380 Reference: SECTRACK:1021363 Reference: URL:http://securitytracker.com/id?1021363 Reference: SECTRACK:1021490 Reference: URL:http://securitytracker.com/id?1021490 Reference: SECUNIA:33034 Reference: URL:http://secunia.com/advisories/33034 Heap-based buffer overflow in Microsoft SQL Server 2000 8.00.2050, 8.00.2039, and earlier allows remote authenticated users to cause a denial of service (access violation exception) or execute arbitrary code by calling the sp_replwritetovarbin extended stored procedure with a set of crafted parameters that trigger memory overwrite. NOTE: it was later reported that SQL Server 2005 9.00.1399.06 is also vulnerable.