Re: [Full-disclosure] Ektron CMS TakeOver Part (2) - PaylPal-Forward.com demonstration
: From: Mark Litchfield mark () securatary com : As previously stated, I would post an update for Ektron CMS bypassing : the security fix. : A full step by step with the usual screen shots can be found at - : http://www.securatary.com/vulnerabilities Uh... you expect people to login to your site with their Facebook or Twitter credentials, to access these advisories? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Ektron CMS TakeOver Part (2) - PaylPal-Forward.com demonstration
: : From: Mark Litchfield mark () securatary com : : : As previously stated, I would post an update for Ektron CMS bypassing : : the security fix. : : : A full step by step with the usual screen shots can be found at - : : http://www.securatary.com/vulnerabilities : : Uh... you expect people to login to your site with their Facebook or Twitter : credentials, to access these advisories? : : Errr no ?? Use the other option ?? And if you don't want to register, don't : bother !! Links from /vulnerabilities, directly from advisories off the Research page, and even Follow us on Twitter all drop back to a login page asking for authentication using either Facebook or Twitter. This is not the behavior of the site as of 48 hours ago. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Ektron CMS TakeOver Part (2) - PaylPal-Forward.com demonstration
: This is not the behavior of the site as of 48 hours ago. : Let me check. Normal registration should also be available ? Infact I : will remove the registration. : : The purpose of this whole registration in the first place was to allow : for future postings I am going to make later this week that would only : be available to registered users. Not necessarily vulnerabilities, but : useful stuff for pentesting. Also all registered users would be given : a 48 hours head start on any new vulnerabilities that I post in the : future. Which is great, but I strongly recommend you allow a site-specific registration for such purposes. Giving up one of the two dominant social media accounts for it is excessive. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Collabtive multiple vulnerabilities.
http://seclists.org/fulldisclosure/2013/Jul/195 : - Release date: July 22th, 2013 : - Discovered by: Enrico Cinquini : 1) UPLOAD PHP FILE INSIDE AVATAR: Disclosed 2012-06-04 by Mark Hoopes (OSVDB 82811). http://xync.org/2012/06/04/Arbitrary-File-Upload-in-Collabtive.html : 2) ACCOUNT DELETION Disclosed 2013-06-21 by the vendor, and referenced by 'drone' in his SQLi advisory for Collabtive (OSVDB 94558): https://github.com/philippK-de/Collabtive/commit/82943ad58e5572ccef54d709220c4c411e80049b http://forelsec.blogspot.com/2013/06/collabtive-10-sqli.html At least the XSS look new! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] OpenSSH User Enumeration Time-Based Attack
What you describe is CVE-2006-5229. While the CVE description does not explicitly say long passwords, it does cover the general idea. Read the mail list posts associated with it and it shows people testing based on minor differences in password length. Stands to reason that 39,000 characters would apply. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-5229 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] AVAST Internet Security Suite - Persistent Vulnerabilities
Seriously? Your avast! issues weren't tested properly it seems. The command shell you invoke is running with the same privileges as the user installing/running the software. There is no privilege escalation based on the 'exploit' you report. These are not vulnerabilities. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [ MDVSA-2013:101 ] lynx
: It is necessary. : Waiting a week for a batched email to find out my software has : vulnerabilities is not acceptable just because some people insist on : reading email on their telephone. You aren't reading these advisories I take it. Several of them are reporting that Mandriva has finally fixed publicly disclosed issues from 2010 and 2011. You are already waiting *years* to find out your software has vulnerabilities, and you find that perfectly acceptable. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [OSVDB Mods] Fwd: Internet Explorer Stack Exhaustion - Flag [MSIE9] (fwd)
-- Forwarded message -- From: security curmudgeon jeri...@attrition.org To: duk...@safe-mail.net Cc: moderat...@osvdb.org Date: Fri, 21 Dec 2012 04:32:31 -0600 (CST) Subject: Re: [OSVDB Mods] Fwd: Internet Explorer Stack Exhaustion - Flag [MSIE9] On Fri, 21 Dec 2012, duk...@safe-mail.net wrote: : regarding to this vulnerability: : : http://osvdb.org/show/osvdb/88539 : : Why has this been flagged as myth/fake? Because your claims of code execution are wrong. : Paste the payload in a file, save it as test.html and run it in Internet Explorer: : : table/for xmlns=1 : tddatetimecolgroup : idddcol : /tableobject : hrbase : : It will cause a crash. Yes, it will cause a crash. : Use a debugger, you will see this is a stack exhaustion. Yes, stack exhaustion leads to a crash. : Also, if you have any basic knowledge, take a look at the registers (ESP : 003FDDD4 = Stack Exhaustion). There is no myth and no fake. I would like : to receive a statement why this has been flagged. If there is no reason, : please remove the message that this is a myth/fake. Our official statement: You claimed code execution in your post. In case you forgot, let me remind and clarify: http://seclists.org/bugtraq/2012/Dec/109 Successful exploitation may lead to arbitrary code execution. This is inaccurate. Thus, we have flagged the entry Myth/Fake because stack exhaustion leads to a crash, not code execution. There is a difference between a stack overflow (exhaustion) that crashes, and a stack-based buffer overflow that *may* lead to code execution. You have only proven stack exhaustion and a random crash. This is a common mistake among new researchers. Your mail to us now about stack exhaustion is different than your initial post to Full-Disclosure. Your post to F-D was a) lacking relevant details to make sense of b) very different than your email to us. You need to figure out what details you think you found out, and stick to them. Posting apples and mailing us claiming aardvarks doesn't fly sir. You said in your F-D post, The application is prone to a remote stack overflow vulnerability. which makes anyone immediately reading it believe it's a stack-based buffer overflow - especially since you claim it may lead to arbitrary code execution. Your PoC does not demonstrate anything other than a straightforward crash (a stack overflow exception - 0xc0fd). Further, you titled this Microsoft Internet Explorer 9.x = Remote Stack Overflow Vulnerability. I am giving you the benefit of the doubt and assuming you are claiming this in version 9.x, and not implying less than or equal to 9.x. But just in case, did you even bother to test on multiple versions of 9.x? If so, why didn't you specify the exact version? Did you test before that and notice that MSIE 8 appears to crash, while MSIE 6 and 7 do not? I mean seriously, listing 9.x without any more details is amateur hour. I won't even get into the fact that you did not mention patches, or platform. If you feel that we are wrong, consider one of the replies to your post: http://seclists.org/bugtraq/2012/Dec/119 From: Fabio Baroni fabiothebest () gmail com Date: Thu, 20 Dec 2012 01:05:07 +0100 Jonathan Ness from the Microsoft Security Response Center says this IE9 POC is stack exhaustion, not a stack-based buffer overflow and Stack exhaustion is typically not exploitable for code execution. That is now two people that dispute your finding, yet you seem to think you know more than anyone while only posting the most pedestrian of advisories. While you can cry that you want to read Ness' statement, remember that you have published NOTHING other than a simple crash. You have not demonstrated anything else, and certainly not demonstrated code execution. You said to us, Also, if you have any basic knowledge..., I would like to say that I believe OSVDB staff have more than basic knowledge. However, based on your F-D post, you don't get access to our reversing ninja. Based on the crap you posted, you only get access to me and my guinea pigs. Waffle and Tater aren't that good at reversing, but they can usually smell suspicious bullshit, as demonstrated when I try to hand feed them a vegetable in a desperate ploy to grab one for mandatory pet time. Until you show that YOU have basic knowledge, you only get to deal with two guinea pigs and a washed up, bitter ex-penetration tester. For now, the entry remains Myth/Fake. The easiest way for you to get us to change our entry, is for you to a) demonstrate code execution or b) get the vendor to admit code execution is possible. If you can demonstrate code execution off this particular bug, I will Paypal you US$250 just for proving me wrong. Jericho p.s. Our database has 87510 entries, and only 401 are marked as Myth/Fake. Congrats, for making the very few! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure
Re: [Full-disclosure] New vulnerabilities in eSitesBuilder
: SecurityVulns ID: 11310. : XSS (WASC-08): : : http://site/console/forget.php?e_mail=%3Cscript%3Ealert(document.cookie)%3C/script%3Eseenform=y How many times are you going to disclose this? http://seclists.org/bugtraq/2010/Jun/189 http://seclists.org/fulldisclosure/2010/Aug/306 http://seclists.org/fulldisclosure/2010/Dec/465 The June disclosure has a timeline indicating you had announced it almost two years prior to that: 21.11.2007 - found some of these vulnerabilities. 11.08.2008 - announced at my site. 11.08.2008 - informed admins of web site. 11.08.2008 - found others of these vulnerabilities. 11.02.2009 - disclosed at my site about first vulnerabilities. 05.05.2009 - disclosed at my site about other vulnerabilities. 06.05.2009 - informed admins of web site about other vulnerabilities. 18.06.2010 - disclosed at my site about vulnerabilities in eSitesBuilder (after I found that they concerned with eSitesBuilder). 19.06.2010 - informed developers (in case if owners of vulnerable site didn't informed them in previous years). Seriously, how long can you milk a single XSS here? : 2010.10.08 - announced at my site. : 2010.10.08 - informed developers. : 2010.12.16 - disclosed at my site. : : I mentioned about these vulnerabilities at my site : (http://websecurity.com.ua/4588/). http://websecurity.com.ua/4300/ Several times, yes you did. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] QtWeb Browser version 3.3 build 043 Insecure DLL Hijacking Vulnerability (wintab32.dll)
: 1. OVERVIEW : : The QtWeb Browser application is vulnerable to Insecure DLL Hijacking : Vulnerability. Similar terms that describe this vulnerability have been : come up with Remote Binary Planting, and Insecure DLL : Loading/Injection/Hijacking/Preloading. : 3. VULNERABILITY DESCRIPTION : : The QtWeb Browser application passes an insufficiently qualified path in : loading an external library, wintab32.dll when a user opens its : associated file with extensions - htm, html, mhtml. : : 4. VERSIONS AFFECTED : : 3.3 build 043 and lower Virtually all Qt based applications will be vulnerable to this. We've seen the first wave of reports of X is vulnerable, looking for Y librari, but we haven't seen a lot of details or follow-up on where the inclusion of the library comes from. Popular libraries and cross-platform frameworks that are vulnerable, will in turn affect any product or software that uses them. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Why the censorship? (was re: Inquira: Multiple Vulnerabilities)
Hi Neohapsis, The mail to Full-disclosure on Mar 20, 2009 has been edited on the archives of Neohapsis: http://archives.neohapsis.com/archives/fulldisclosure/2009-03/0326.html Every occurrence of Inquira has been redacted. Since the original disclosure suggests the vendor was contacted, and chose not to reply, it is curious that their name would be removed from your archive. Could you explain why, or at the very least share what I suspect was a CD style letter demanding their name be removed? I ask because other archives do not redact their name for whatever reason: http://seclists.org/fulldisclosure/2009/Mar/0300.html http://marc.info/?l=full-disclosurem=123753854425289w=2 http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2009-03/msg00300.html http://www.opensubscriber.com/message/full-disclosure@lists.grok.org.uk/11725824.html [..] - security curmudgeon -- Forwarded message -- From: Kristian Erik Hermansen kristian.herman...@gmail.com To: full-disclosure@lists.grok.org.uk Date: Fri, 20 Mar 2009 01:34:28 -0700 Subject: [Full-disclosure] Inquira: Multiple Vulnerabilities Bonjour, During a recent penetration test, we discovered and worked with Inquira to close numerous web-based issues. The vendor has not replied back about a formal release of these issues, so I am posting this notice here to inform customers to check for an update for their products. You can contact Inquira via the link below. http://www.inquira.com/ Additionally, it is also advised that customers change the default passwords used by the affected software. For instance, the default Apache Tomcat administrator account details are listed below and should probably be added to publicly listed default password databases (phenoelit, etc). Vendor: Inquira Products: (multiple) Username: inquira Password: inquira123 Cheers, -- Kristian Erik Hermansen http://www.linkedin.com/in/kristianerikhermansen ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] Mr. Magorium's Wunderbar Emporium
On Fri, 14 Aug 2009, valdis.kletni...@vt.edu wrote: : Of course, getting a CVE for that issue would have forced disclosure of : the bug too, quite possibly before the vendors were ready to ship Huh? Apparently you don't know how CVE assignment works. If you request one from CVE, they can assign one without knowing any details of the vulnerability. CVE will embargo the details until the researcher and/or vendor are ready. I assume the Candidate Numbering Authorities would be able to do the same, but going to Red Hat, Debian or Ubuntu in this case may not be the best option. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] ZDI-09-007: Apple QuickTime Cinepak Codec MDAT Heap Corruption Vulnerability
: ZDI-09-007: Apple QuickTime Cinepak Codec MDAT Heap Corruption : Vulnerability : http://www.zerodayinitiative.com/advisories/ZDI-09-007 : January 21, 2009 : : -- CVE ID: : CVE-2009-2006 CVE-2009-0006 perhaps? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] List of security teams contact information
: I've created a list with contact information for various security teams: : : http://skypher.com/wiki/index.php?title=List_of_security_teams_contact_information : I hope this makes informing vendors about security issues easier. If you : have any additional information or spot an error, let me know. http://osvdb.org/vendors This project was created a while back to do the same. Please consider contributing to it. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Why do the URLs of the post keep changing in lists.grok.org.uk?
: I usually keep the links of some interesting vulnerabilities posted in : this mailing list. But when I try to access them after 6 months or so, I : find that some of the links are invalid and some of them are pointing to : different posts? Why does this happen? When the list administrators recieve a takedown notice or request to remove something, they delete the post. This causes the archive to re-index and renumber, causing the entire archive to change. This was noticed by several vulnerability databases that reference posts and the above was the explanation received. I suggested that instead of deleting the entire message, they should just remove the body of the post instead, and replace it with a brief note explaining the content was removed at the request of X. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploit Brokering
Hi Simon, : SNOsoft has been legitimately and legally brokering exploits since early : 2000, and we're still doing it very successfully. As a matter of policy : we will not ever purchase items from careless developers, and will not : sell to careless buyers or non US based buyers... With exploit brokering : comes great responsibility and liability. : : People posting emails in public forums in an attempt to sell exploits is : not only careless and irresponsible, but is also a testament to that : persons immaturity and lack of experience. Do they ever stop to think : about the potential liability? What happens if they sell to a hostile : foreign party, what could happen to them, etc...? Can you describe SNOsoft's process for validating buyers and assuring they are US based? Is there any process to ensure that even though they are US based they do not have any ill intention toward their country? Just because someone has a US ID doesn't mean they were born here or not working for a foreign party. jericho ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SecNiche : Microsoft Internet Explorer Pop up Blocker Bypassing and Dos Vulner
: I wonder why we can't find Aditya K Sood in any of the security list : even though he has made so many public disclosures. : : See:- : : http://www.google.com/search?hl=enq=site%3Asecunia.com+aditya+sood : : http://www.google.com/search?hl=enq=site%3Aosvdb.org+aditya+sood : : Is it because these lists dislike Aditya or is it because they find the : vulnerabilities to be false while verification? : : AFAIK OSVDB has a system of tagging vulnerabilities as Myth/Fake. I : wonder why the disclosures published by Aditya are missing in OSVDB. : OSVDB should add these vulnerabilities and properly classify them or tag : them as fake. Anyone from OSVDB here who can respond? OSVDB did not begin agressively tracking and cataloging myth/fake vulnerabilities until earlier this year. Before that they were added as time permitted, and over the years primarily if there was a lot of confusion or assumption that a published vulnerability was accurate, when it clearly was not. OSVDB will add legitimate vulnerabilities before myth/fake typically, so in some cases they are just at the bottom of the queue. The lack of results for your search above is also likely due to the lack of creditee information associated with many of our entries. This is due to the creditee field not being added until last year. In some cases, his vulnerabilities (legit or otherwise) may be in the database, just missing creditee fields. Brian OSVDB.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
On Wed, 6 Jun 2007, Kradorex Xeron wrote: : Illegal or not, this is still pretty damned shady. : : : I will seldom touch on the legal side but I have a possible scenario: : : -- If David is no longer at that address, it could be said that his mail : account was taken down and the mail sent ended up in a possible catch : all box, perhaps someone at SecureWorks was looking through the said : catchall mailbox for any interesting mail sent to the secureworks.com : domain (i.e. to old employees) - It's quite common for companies and : organizations to monitor former employee mailboxes in the event anyone : that doesn't have any new contact information to be able to still get : somewhere with the old address. And them being a security organization, : maybe they proceeded to investigate the link sent. This is no doubt exactly what happened. A more ethical company would have sent HDM a polite note saying that the person no longer works there before curiosity got the best of them. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
: A more ethical company would have sent HDM a polite note saying that : the person no longer works there before curiosity got the best of them. : : Does your company do this for all former employee e-mail accounts? No. But they also don't continue to accept mail to those accounts either. : Let's hope he unsubscribed from all his mailing lists before he left. If a company is going to continue monitoring a former employee's mailbox (intentionally or via a 'catch all'), that is fine. But when they specifically act on a personal private mail between someone outside of their company and the former employee, they are crossing the line of ethical behavior I think. As I said, the least they should have done is mail HDM and notified him the person no longer works there. If they didn't do that, and if you think they shouldn't be required to, then they shouldn't act on the information in the mail either. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] OpenBSD owned
: Was OpenBSD owned ... http://www.openbsd.org I'd guess hosting problems: http://www.openssh.org/ Forbidden You don't have permission to access / on this server. Apache/1.3.34 Server at www.openssh.org Port 80 http://www.openntpd.org/ Forbidden You don't have permission to access / on this server. BSWS-Apache/1.3.29 Server at www.openntpd.org Port 80 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Rixstep aren't as leet as they thought they were
: It may not come as a shocker, but so far the Month of Rixstep Bugs : has not netted a single bug. : -- http://rixstep.com/1/20070115,00.shtml : : Maybe because nobody was looking? http://osvdb.org/blog/?p=160 Month of .. who?! Posted in General Vulnerability Info on January 15th, 2007 by jericho http://rixstep.com/2/20070104,00.shtml :A Month of Rixstep Bugs :Its a win-win proposition. :Starting now and for the duration of January 2007 Rixstep will be : holding a Month of Rixstep Bugs campaign: find a bug in any Rixstep : software product and win a prize. Its not a win-win proposition, it is a lame gimmick. After the month of apple bugs, week of (cancelled) oracle bugs, and the month of linux kernel bugs, Rixstep wants in on the bandwagon. Few small problems: 1. They posted this announcement on the 4th, not even giving a full month. 2. They didnt post this to Bugtraq, Full-Disclosure or any other security list/resource I monitor. 3. Rixstep doesnt have the saturation that Linux, Apple or Oracle do. It is considerably easier to test those products and platforms versus Rixstep, who many of us have never heard of, let alone seen deployed. If you want to play with the big boys Rixstep, man up and put some of your products up on your site and post the challenge to Bugtraq and Full-Disclosure. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Are consumers being misled by phishing?
: There are a million books on phishing in borders book store, if the : phishing phrase hadn't been coined, a lot of people wouldn't be : millionaires right now. : : They brought in phishing in 2003. The actual act of phishing had been : going on for years before the phrase was coined. Since the beginning of The term was coined long before 2003. March 3, 1996: http://web.textfiles.com/ezines/LOLIE/1lolie.txt May 8, 1999: http://web.textfiles.com/ezines/UHA/uha1-7.txt And i'm sure there are other references going back to the early 90's if someone wants to do some digging. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] US Government Studies Open Source Quality
(I recommend you read the original, as many parts of the text are links to other resources) http://www.osvdb.org/blog/?p=104 US Government Studies Open Source Quality US Government Studies Open Source Quality reads the SlashDot thread, and it certainly sounds interesting. Reading deeper, it links to an article by the Reg titled Homeland Security report tracks down rogue open source code. The author of the article, Gavin Clarke, doesnt link to the company who performed the study (Coverity) or the report itself. A quick Google search finds the Coverity home page. On the right hand side, under Library, there is a link titled NEW Open Source Quality Report. Clicking that, you are faced with request information, checking the Open Source Quality Report box (one of seven boxes including Request Sales Call as the first option, and Linux Security Report is the default checked box), and then filling out 14 fields of personal information, 10 of which are required. So, let me get this straight. My tax dollars fund the Department of Homeland Security. The DHS opts to spend $1.24 million dollars on security research, by funding a university and two commercial companies. One of the commercial companies does research into open source software, and creates a report detailing their findings. To get a copy of this report, you must give the private/commercial company your first name, last name, company name, city, state, telephone, how you heard about them, email address, and a password for their site (you can optionally give them your title, and describe your project). Excuse me, but it should be a CRIME for them to require that kind of personal information for a study that I helped fund via my tax dollars. Given this is a study of open source software, requiring registration and giving up that kind of personal information is doubly insulting. Coverity, you should be ashamed at using extortion to share information/research that should be free. Even worse, your form does not accept RFC compliant e-mail addresses (RFC 822, RFC 2142 (section 4) and RFC 2821). Now I have to add your company to my no plus web page for not even understanding and following 24 year old RFC standards. HOW CAN WE TRUST ANYTHING YOU PUBLISH?! Oh, if you dont want to go through all of that hassle, you can grab a copy of the PDF report anyway. http://osvdb.org/ref/blog/open_source_quality_report.pdf ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] McAfee VirusScan vs Metasploit Framework v2.x
On Sun, 11 Dec 2005, Pavel Kankovsky wrote: : Just for the info, they have also added Nmap as potentially unwanted : application (http://vil.mcafeesecurity.com/vil/content/v_100955.htm) : [...] : : Are we making a list? : You can add Symantec reporting a copy of Netcat as a hacking tool. A wealth of irony regarding that too. Symantec bites the hand that feeds.. http://www.osvdb.org/blog/?p=70 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Call to participate: GNessUs security scanner
Hi Tim, Don't take this as anything but honest questions please! I am curious about everyone's thoughts and opinions on this, as I have mostly seen Renaud/Ron/Tenable pointing out some facts, and most replies being a bit lacking in reason and explanation. I ask these questions to *anyone* that has replied to the Nessus announcement. : GNessUs is a GPL fork of the Nessus security scanner. As a result of : recent announcements by Tenable, we believe a fork of Nessus is required : to allow future free development of this tool. : : Whilst we would like to believe that we will be able to continue to take : updates of the Nessus 2 source code from the Nessus web site we will be : endeavoring to add fresh functionality and plugins as part of the : GNessUs project. The fork will be based on the current nessus 2.2.5 : packages from GNU/Debian, the source of which can be found above in a : slightly modified form. We would welcome contact from any interested : developers. Nessus has been open source for a long time. Despite that, the majority of contributions have come from a very small amount of people. Even with plugins, some 95% (i think) were written by the Nessus team, not outside contributors. Recently on DailyDave, Ron Gula replied: Now that it is being closed, I wonder how long it takes before the community once supporting Renauld will fork the current code and carry on by themselves. We haven't had any support of this kind. I really feel there are very capable programers out there who can contribute to Nessus, but to date we haven't really gotten any. Even on the NASL vuln check side, a majority of the plugins are Tenable. Renaud has also pointed this out, although I can't find the exact quote/list post. As far as the Nessus engine and functionality, there have been basically no real contributions or enhancements from anyone other than the core team/Tenable. All that said, my questions: Why do you see a need to fork the Nessus tree at this time? Why haven't you or anyone else contributed in the past? Finally, do you think that if more people supported Nessus with contributions of code/time/enhancements, that they would have kept things the same? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Bigger burger roll needed
: Since its inception, supporting NT 3.0 beta and onward, I have been : dealing with BSOD's. In total, there have been comparatively very few : times were it was a direct fault of MS code. It has very commonly been : in relation to 3rd party drivers that needed reworking or updating by : the 3rd-party manufacturer. : : This is not PR spin (of which I don't think you could find any published : PR spin for either side of this argument either). This is real world : experience with the NT+ products across i386 and Alpha hardware : platforms using peripheral devices from many different major : manufactures. There are admins on both sides of the anti-MS fence that : I communicate with that would agree with this conclusion. Fine, it isn't PR spin. But, compare this to Unix. How many times do you run user-land, 3rd party applications, that cause a kernel panic? Why does Windows *let* third party applications BSOD the core operating system? Fine, Microsoft didn't code the application causing it, but they sure coded the operating system that doesn't know how to handle malformed input. And the first few years of Windows 95 saw many, *many* BSODs that were due to Microsoft code. That lead to the general impression and sentiment you see today. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Bigger burger roll needed
: I don't appreciate you changing caps in my name. I'm not 'spin'ing : anything - I addressed a specific question with an honest real-world : answer. I did not include propaganda nor did I denounce any alternate : products. There's no need to be a disrespectful ass. A decade of close exposure to Windows boxen has destroyed your sense of humor. =( Hope you aren't sterile too. : Absolutely, Win95 was a pain in the ass So was 98 and Me. But I : disagree with the sentiment that it was solely due to MS code. Without : getting into specifics that no longer matter, surely they could have did : their part better to handle malformed input - but who was malform'ing : the input in the first place? By this reasoning, we can blame all the hax0rs and security professionals for SQL injection, cross-site scripting, file inclusion, path disclosure, overflows and format string vulnerabilities too, right? Because hey, *they* provided the malformed input to the application in the first place! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Bigger burger roll needed
: You know, I wouldn't mind it IF the conversation was properly : [re]directed in context. In fact it often leads to many fascinating : discussions. But other times it feels like some people that : contributing are schizophrenic. Seems like the people that didn't catch that leap don't quite grok the security industry at all. : Why if someone doesn't like or agree with a particular answer or topic : its OK to respond with something completely different without any : qualification is really bizarre - especially from a technical community. Microsoft / Windows / BSODs no, wrong / 3rd Parties / BSODs This lead to a comment of blame the 3rd party for providing malformed input, not microsoft/windows! At this point, two of us reply blame hackers for malformed input, referring to the numerous input manipulation vulnerabilities (XSS, SQL Injection, Format String, Overflow, et al), as it is a fairly direct comparison to those who blame hackers for shoddy programming. By the logic of that quote, we should blame hackers for *vulnerabilities* in code, not just exploiting them. To lay blame on the person providing malformed input is silly, be it a hacker or 3rd party device driver author. It all boils down to coding that can't handle unexpected input, which is a utopian attitude in a world that is anything but. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Third issue of the Zone-H Comics
: Not if the U.S security services decide to have a war on cyber terror : sites. You aren't from the US are you? The idea that U.S security services can arbitrarily shut down a site outside the US, and that the FBI or anyone else *would* shut down a site, even in the US is a bit silly. Almost as silly as thinking defacing or defacement mirrors are cyber terrorism under any definition of the word. When the attrition mirror was being maintained, our #1 visitors were security companies and law enforcement. The FBI (and other agencies) used our mirror to track computer crime, and eventually figured out they could subpoena us for records that potentially helped their investigation. They knew that some defacers would not clean the logs of systems they attacked, and they knew that the defacers would view their work on our site, as well as contact us directly (often from hotmail, with x-originating-ip) giving them a nice trail back to the person who comitted the crime. So, one subpoena, conviction in a box practically. You think the FBI would close that kind of resource? As KF and str0ke said, there will always be a defacement mirror. There was one before Attrition, several during, and several since. Instead of deciding they should all be shut down for whatever reason, you should be calling for the mirrors to act as professionally and ethically as possible. If you question this comment or can't figure out what would distinguish defacement mirrors in this way, then do a little reading on the topic for background. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Third issue of the Zone-H Comics
: Nahh if it comes to world domination my money is on Jericho Forget the : defacement archive that's easy..Anyone who runs the site that has : managed to keep a fairly complete record of who has been sleeping with : who since 1996 includeing feds and a bunch of privacy freaks like : hackers Is a man to be pheared in my book. hah, the Hacker SexChart is maintained by Lish. She is 'the man' =) http://attrition.org/hosted/sexchart/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] OSS means slower patches
: http://australianit.news.com.au/articles/0,7204,16650762%5E15306%5E%5Enbv%5E,00.html The obvious criticism: The Mozilla family of browsers had the highest number of vulnerabilities during the first six months of 2005, with 25, the Symantec report says. Eighteen of these, or 72 per cent, were rated as high severity. Microsoft Internet Explorer had 13 vendor confirmed vulnerabilities, of which eight, or 62 per cent, were considered high severity. Microsoft IE had at least 19 vulnerabilities from 2005-01-01 to 2005-06-30. Why does Symantec make the distinction of X vulnerabilities in Mozilla vs MSIE had X *vendor confirmed vulnerabilities*? This all to conveniently allows the silently patched vulnerabilities to slip through the cracks of our statistics. Does Mozilla's honesty in acknowledging vulnerabilities come back to bite them in the ass? Mozilla browsers had more than 25, but are 72 per cent really high severity? Download information spoofing x2, File extension spoofing, URL restriction bypass, DoS x2, redirect spoofing, XSS, link status bar spoofing, Dialog overlapping, URL Wrap Obfuscation.. are all of these really high severity? Is that theoretical, practical, or hype? Now, the media/symantec driven propoganda (for lack of better word?): THE growing popularity of open-source browsers and software may be responsible for the increasing gap between the exposure of a vulnerability and the provision of patch to fix it, security software vendor Symantec has said. Mr Sykes said the increasing popularity of open source software, such as the Mozilla Foundation's Firefox browser, could be part of the reason for the increase in the gap between vulnerability and patch, with the open source development model itself part of the problem. It is relying on the goodwill and best efforts of many people, and that doesn't have the same commercial imperative, he said. I'm sure that is part of what is causing the blow-out in the patch window. The growth in Firefox vulnerability reports coincides with its increasing popularity with users. It is very clear that Firefox is gaining acceptance and I would therefore expect to see it targeted, Mr Sykes said. People don't attack browsers and systems per se, they attack the people that use them, he said. As soon as large banks started using Linux, Linux vulnerabilities started to get exploited. The premise of this article is open source software is to blame for longer vendor response times. In laymen's terms, blame vendors like Mozilla for having vulnerabilities patched slower? Err, compared to what? This shallow article doesn't even qualify that statement! Slower than previous vulnerabilities? Slower than non open source? Given the article directly compares Mozilla browsers to Microsoft IE, it is trivial to assume the claim is made in relation to closed source vendors such as Microsoft. So then what .. 30 days blown out to 54 days is some huge time gap compared to Microsoft IE patches? What clueless *moron* really believes this crap they are shovelling? Is it Symantec or Chris Jenkins or Australian IT? Given that Symantec won't even quote previous statistics: Symantec had not published previously statistics on the average time required to produce patches, but Mr Sykes said data showed the lag had previously been about 30 days. Given that Jenkins/AusIT/Symantec won't give us any statistics (even questionable ones) regarding MSIE patches, we're supposed to take this at face value? It is *well documented* that Microsoft takes well over 30 days to patch vulnerabilities. It is also becoming crystal clear that Microsoft is hiding behind their 30 day patch cycle to imply that is the longest they go before patching a vulnerability, when it simply is not the case. Taking a look at a *single vendor* [1] and their experience with reporting vulnerabilities to Microsoft, we see that they give MS a 60 day window to patch vulnerabilities, and are consistantly overdue. As of this mail, the worse is *ONLY* 114 days past due (we've seen it closer to 250 days before). So again, where are these implications coming from? Where does this statement/conclusion/observation that OSS causes slower patches come from exactly? [1] http://www.eeye.com/html/research/upcoming/index.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] IIS 5.1 Source Disclosure Under FAT/FAT32 Volumes Using WebDAV
Hi Jerome, : It is possible to remotely view the source code of web script files : though a specially crafted WebDAV HTTP request. Only IIS 5.1 seems to be : vulnerable. The web script file must be on a FAT or a FAT32 volume, web : scripts located on a NTFS are not vulnerable. : : The information has been provided by Inge Henriksen : mailto:inge.henriksen%20at%20booleansoft.com. The original article can : be found at: : http://ingehenriksen.blogspot.com/2005/09/iis-51-allows-for-remote-viewing-of.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=2000-0778 IIS 5.0 allows remote attackers to obtain source code for .ASP files and other scripts via an HTTP GET request with a Translate: f header, aka the Specialized Header vulnerability. -- This appears to be the same issue? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: MS not telling enough - ethics
: Well done, anyone else who knows of people committing fraud against isc2 : should report them. Unfortunately I don't think its feasible for isc2 to : check everybody. Oh, how coincidental.. : They do random credential checking and I should I know, since I was : audited after I passed the exam. Ethics Complaint Procedures [0] The board and its agents undertake to keep the identity of the complainant and respondent in any complaint confidential from the general public. [..] The board will consider only complaints that specify the canon of our code that has been violated. [..] Complaints will be accepted only from those who claim to be injured by the alleged behavior. While any member of the public may complain about a breach of Canon I, only principals may complain about violations of Canons II and III, and only other professionals may complain about violations of Canon IV. [..] All complaints must be in writing. The board is not an investigative body and does not have investigative resources. Only information submitted in writing will be considered. [..] Complaints and supporting evidence must be in the form of sworn affidavits. The board will not consider other allegations. [..] Where there is disagreement between the parties over the facts alleged, the ethics committee, at its sole discretion, may invite additional corroboration, exculpation, rebuttals and sur-rebuttals in an attempt to resolve such dispute. The committee is not under any obligation to make a finding where the facts remain in dispute between the parties. Where the committee is not able to reach a conclusion on the facts, the benefit of all doubt goes to the respondent. [..] Discipline of certificate holders is at the sole discretion of the board. Decisions of the board are final. -- Ok, let me translate this for you: Keep it private, for your own good, we swear! This way the complaint is kept out of public scrutiny. You have to clearly define what canon was violated, even though they are general and vague. You must personally be injured to complain, even though breaking any of the four canons may not directly harm one individual! You must submit said complaint in writing, and the board does not have time to investigate your complaint at all. Such complaints must be in the form of sworn affidavits [1], signed by a notary as witness to your signature etc. If there is any dispute of facts, which is entirely up the to the (ISC)2 board, it is entirely their discretion whether to act on or continue the process. The board may arbitrarily decide not to pursue or consider additional evidence, will make no effort to research the matter themselves, and drop the matter without further consideration. Even if the board finds someone guilty of breaking one of the canons, the board will decide what punishment, if any, is appropriate, including 'none'. How many hoops does one have to jump through to file a complaint that will actually be considered?! Should I slice my wrists and bleed all over the signed and notarized document in case they need a blood sample or DNA? Does the complaint need to be shouted out from town square right after slaughtering a chicken while juggling hedgehogs? I mean really, how many ways can they make this process counter-productive and full of backdoors so the 'board' can simply ignore your complaint? : Ivan Coric, CISSP You are so proud of our certificiation, you won't even list yourself in the (ISC)2 directory so that we can verify you even hold the certification! [2] : The CISSP cert is the best security cert around, without a doubt. Best for who?! Oh yes, for you since you hold it. And best for those issuing it, since they profit directly from the ceritification and the yearly 'renewal' fee. The fact is, (ISC)2 and the CISSP certification is a marketing ploy and money maker. It is *not* in their best interest to allow the credibility of their certification to be tarnished for any reason, even when criminals are 'earning' it. security curmudgeon [0] https://www.isc2.org/cgi-bin/content.cgi?page=176 [1] http://en.wikipedia.org/wiki/Affidavit [2] https://www.isc2.org/cgi-bin/directory.cgi?displaycategory=503 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] windows linux final study
: Here we go again, so called intelligent people talking utter rot! [..] : Come on people grow up, put your prejudices aside and look at the : information provided, draw conclusions based on that, and be prepared to : change that opinion when the information to hand dictates. Did you read the report yourself? You sound like a Microsoft cheerleader. From the report: Additionally, when examining the days of risk time between when a vulnerability is publicly disclosed to when a patch is released by the vendor for that vulnerability we found an average of 31.3 days of risk per vulnerability for the Windows solution, 69.6 days of risk per vulnerability for the minimal Linux solution and 71.4 days of risk for the default Linux solution. This is from page 2 of the study. Can we agree that if you find a serious flaw/error in the paper by page 2 (out of 37) that one might have reason to be skeptical? Does anyone in the security industry *really* think Windows ever has a 31.3 day of risk for vulnerabilities? If you are naive enough to believe this, dare to visit eEye's page on their advisories where they not only disclose wonderful vulnerabilities in the Windows platform, but also track how long it took Microsoft to patch them. From a soon to be published article: Claims of Microsoft only having a 31 day risk window seem very suspect, especially given their current 30 day patch cycle compared to some vulnerabilities that were disclosed as many as 208 days [1] before the patch. Before you dismiss this as a freak occurance, eEye Digital Security has recorded other time frames such as 71 days [2], 188 days [3], and 190 days [4]. These figures are right in line with several other security companies that have disclosed issues to Microsoft./p If you think eEye is not the norm for dealing with Microsoft, think back to Thor Larholm's excellent (but discontinued) page of unpatched Microsoft IE vulnerabilities. Looking at an archived copy of that [5], we see the following: 11 September 2003: There are currently 31 unpatched vulnerabilities. [..] IE https certificate attack Description: Undetected SSL man-in-the-middle attacks, decrypting SSL-encrypted traffic in realtime Published: June 6 2000 ( ACROS ) So there we have MSIE vulnerabilites left unpatched for *3 years* and may still be unpatched for all we know. If you read several sources of vulnerability information, you will consistantly see Microsoft is not that quick on patching vulnerabilities.. certainly not 31.3 days quick. If these examples aren't enough to make you question the report, ask others who have found major vulnerabilities in Windows. I'd love for Marc Maiffret or Chris Wysopal or the countless others who have discovered Windows vulnerabilities to reply to this with their first hand experience in getting a fast turnaround on patches. Look beyond that and think out loud about the second part of the original paragraph quoted: per vulnerability for the Windows solution, 69.6 days of risk per vulnerability for the minimal Linux solution and 71.4 days of risk for the default Linux solution. So now there is a difference in patch cycle between minimal linux and default linux? Can anyone cite a source for any linux vendor that makes this distinction between install types AND releases patches on a different cycle for them? How far do you have to take word mincing to make this statement true? jericho [1] http://www.eeye.com/html/research/advisories/AD20041012.html [2] http://www.eeye.com/html/research/advisories/AD20041012A.html [3] http://www.eeye.com/html/research/advisories/AD20040413C.html [4] http://www.eeye.com/html/research/advisories/AD20050208.html [5] http://attrition.org/security/rant/z/thor_larholm-unpatched_ie.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
