[Full-disclosure] Re: Publishing exploit code - what is it good for
Aviram Jenik wrote: What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. Speaking with my sysadmin, netadmin & (sometimes) IT manager hats on, the reason *I* value full-disclosure security reports is simply because of the business politics involved in dealing with security issues at a company level. It's much, *much* easier to convince a CEO/CIO to allocate urgent resources (in both labour & funding) to deal with a *proven*, security vulnerability, than to a 'theoretical' security issue. And another business slant on this is that it's better to be one of millions of organisations being threatened by a well-documented, publically-known exploit that'll probably be patched by the software vendor or neutralised by the anti-virus companiess in a few days, than to be one of a few dozen organisations targetted by professional extortionists with *unreported* vulnerabilities in their toolkit, for which you have zero knowledge, & against which you are helpless. ___ 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] RE: Publishing exploit code - what is it good for
Aviram, Working at a major organization, I find the one thing that is most frustrating is trying to validate whether a public exploit is actually a threat or not, we rely on tools like nessus and such the like that may or may not provide false positives. I believe public exploits (full disclosure) is a necessity and whether or not top security firms believe it, doesn't matter to me, it's not something that will never be stopped. I'd give you my company name, but unfortunately I am not allowed to. Suffice to say it is a major privately held organization that does business in the billions per year. They are very adamant about putting security in place, and not just from an attack and penetration perspective, but true engineering of applications with security in mind. If this analyst believes that all that public exploits do are put users at risk, they are missing the bottom line of this whole thing, which is...education. OK so we'll all simply rely on the vendors to patch our systems, without fully investigating the ramifications of those patches on 3rd party applications that are either relying on the O/S or sharing an O/S or that are integrated with the very system we are patching. The bottom line is public exploits help to educate us security engineers and sys admins on security, and provide us with an in-depth look at what other people are doing to exploit systems, it's an education process, it helps us it does not detour us. What detours us is when some kid or frustrated person decides to wrap up the exploit in some mass-distribution application. Conversely the argument could be made that if public exploits where not available the number of these worms/viruses would be far minimized, to which my response would be, take away information from people and they will find other means to obtain it. Sure we can try and argue against public exploits because they give mischievous people opportunity to wreak havoc on systems that we have to support, but if you have a good patch management and AV solution in place, guess what...you have nothing to worry about. This is my personal opinion having worked in security for quite a few years as well as managing a team of senior systems engineers responsible for enterprise systems. -Wesley North [EMAIL PROTECTED] -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 5:14 AM To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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/
[Full-disclosure] RE: Publishing exploit code - what is it good for
I agree that in some cases, release of exploit code is unnecessary - but in other cases, it is completely essential. In an open source product - as was recently the case with the osCommerce HTTP splitting vulnerability - it is necessary for programmers to fix vulnerabilities, in cases where the organisation that produces the software does not release a patch or updated version in time. Also, open source products - especially web applications - are often modified by their users. I am responsible for maintaining several osCommerce carts that have been heavily modified to suit the needs of the companies that use them. Even if a patch or new version were released for a security problem, it would be of little help for me: to install it would require remodifying each cart. This would be a horrendous waste of time; it is far quicker simply to fix the vulnerability in each installed instance, and in cases like that, proof of concept code is essential: without it, one cannot reliably test fixes applied to the product. Finally, proof of concept code has value - in all cases - as a means of proving the existence of a vulnerability. It is the most efficient way to provide other researchers with the proof that a vulnerability is real, with the means to reproduce the problem, and with the ability to check the original researcher's approach for flaws or related vulnerabilities that may not have been discovered the first time round. Release of proof of concept code is obviously dangerous, but not *very* dangerous: it's a trade-off between the verifying the quality of research and the ability to fix problems, and the safety of the wider community. I assert that, as is often the case with this type of problem, the benefits outweigh the risks: blackhat communities will likely distribute their own exploit code anyway, and determined attackers will not be put off by the lack of proof of concept code. In other words, the lack of proof of concept *can* harm the community, and is unlikely to make much difference to evildoers. Harry Metcalfe -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: 30 June 2005 13:14 To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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/
[Full-disclosure] RE: Publishing exploit code - what is it good for
Hi Aviram, I use this type of code to ensure that when patches are applied, it does not "break" any part of the OS and or application which has already been patched. Also I don't take anyone's word that a system has been patched or a security hole has been fixed without testing and re-certifying the application or the OS. Without the exploit code I would not be able to verify any of this and could very well leave my systems wide open. In a private sector company this code should be used in the same manner, to ensure compliance with SOX. To leave systems untested would be hanging your company out to dry. David Morales [EMAIL PROTECTED] 703-696-4022 -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 8:14 AM To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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/
[Full-disclosure] RE: Publishing exploit code - what is it good for
I for one am glad to see PoC code. Too often vendors are very vague with their patchsets (Oracle basically says to install a huge tarball to fix 'critical' vulnerabilities without listing exactly what it fixes and the recent Backup Exec vulnerability had a later patch version available for a different unrelated problem than the published advisory for the agent password overflow - you had to read three different advisories to find out if the later patchset had the fix - it did, even then it was a crap shoot). Given the lack of disclosure from the vendors, I like to have PoC code available to test if the patch really was applied correctly (and was the correct one). Don't forget the instances when either a patch silently fails, or if you are a security admin, don't trust that the admins really patched all of their machines. I would forgo most PoC codes if vendors would *exactly* explain what was in their patchsets (and provided a way to test for the existence of easily) and what they addressed without these matrix's of different versions of their product cross-referenced to a simple 'critical' reference. Even as vague as MS announcements are, they are still one of the better disclosing vendors when it comes to their announcements. Then again, I like to learn from the PoC code to further my knowledge as how the inner workings of programs work and how much of a poor job someone did while coding 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/
[Full-disclosure] Re: Publishing exploit code - what is it good for
Interesting, becuase this just hit me the other day. Wearing my sysadmin hat, I woke up one morning to find that the NetBSD package converters/xlreader had a vulnerability. Nobody seemed to have a patch for it, but looking at it, even with my rather limited level of C coding skill, I reckoned I could fix it. (Standard buffer overflow: replace sprintf with snprintf kinda thing.) So I did. Or at least, I think I did. I can't get my hands on a working exploit, so I don't feel truly comfortable that I did indeed fix the problem. Maybe to someone more familiar with C it would be proved fixed by inspection, but I don't feel that comfortable with it myself. I didn't really used to think that exploits were so useful until this. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA ___ 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] Re: Publishing exploit code - what is it good for
On Thu, 30 Jun 2005, Aviram Jenik wrote: What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. I'll skip over the obvious stuff (exploits are distributed anyway, knowing when exploits exist is helpful for prioritizing patches, etc) and jump to your specific question: how this helps me and my organization as end-users. When a vendor issues an advisory, it tells us that their software should be upgraded, and often gives mitigating factors. But upgrading software all the time is risky: you never know when a patch will break something. So it's often helpful to wait a day before upgrading, if you know that there is no known exploit. FD lists therefore help us prioritize updates. Also, many times there are enough mitigating factors that it may be difficult to determine whether (in the case of an exploit being published before we've had a chance to patch) there was any period of vulnerability. For example, with stack randomization enabled, the exploit might fail. It would be reassuring to confirm that. Finally, many vendors (RedHat being a notable one) backport security patches, rather than upgrading to the latest version (which may introduce new bugs^Wfeatures). A side effect is that it's often difficult to determine whether your machines are vulnerable to any given exploit. Yes, we could probably glean the information from changelogs and security advisories from the vendor, but that's often a confusing process (the inclusion of CAN/CVE numbers helps). And, of course, if you're the security guy (I've worn this hat too), all you can see is that they're running (for the case of OpenSSH) OpenSSH_3.6.1p2, which might be vulnerable. You don't know that the fix was backported into openssh-3.6.1p2-33.30.4. So you need to test. In fact, I suspect this is why your friend doesn't want the exploits to be released. If organizations could test their own security (which *requires* having the exploits, as I just explained), it would cut into his company's market-share. Damian Menscher -- -=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=- -=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=- -=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=- -=#| <[EMAIL PROTECTED]> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=- -=#| The above opinions are not necessarily those of my employers. |#=- ___ 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] RE: Publishing exploit code - what is it good for
While performing penetration testing at the request of a Fortune 500 financial services company, I discovered a vulnerability that, if abused, could have been used to initiate fraudulent funds transfers, stock market transactions, etc. The client was skeptical when told the exploit could occur in a matter of two or three seconds, go unnoticed by the victim, and gain such comprehensive unauthorized access. At the client's request, I wrote a proof-of-concept exploit that demonstrated everything except the final fraudulent action, but made it clear that exposure was only one more tiny step away. The client overcame their skepticism. While this particular exploit was not published, it shows a real-world "end-user organization [with] legitimate needs for exploit code" resulting in greater security for all customers of this organization. Another penetration tester in similar circumstances might be able to use or adapt a published exploit instead of writing a new one from scratch. Marvin Simkin http://simkin.asu.edu/ ___ 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] Re: Publishing exploit code - what is it good for
> I recently had a discussion about the concept of full disclosure with one of > the top security analysts in a well-known analyst firm. Their claim was that > companies that release exploit code (like us, but this is also relevant for > bugtraq, full disclosure, and several security research firms) put users at > risks while those at risk gain nothing from the release of the exploit. > reluctant. Their claim was that based on their own work experience, a > security administrator does not have a need for the exploit code itself, and > the vendor information is enough. The analyst was willing to reconsider their I think its a question of what the role of the 'security administrator' is within the enterprise. If their job is primarily threat evaluation and appropriate patching/updating in response, then I agree that the publication of an exploit is not very helpful. If, however, the job is firewall/IDS management or incident investigation, then having access to actual exploit code is extremely valuable to have. -- Dr. Everett (Skip) Carter Phone: 831-641-0645 FAX: 831-641-0647 Taygeta Network Security Services email: [EMAIL PROTECTED] 1340 Munras Ave., Suite 314 WWW: http://www.taygeta.net/ Monterey, CA. 93940 ___ 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] Re: Publishing exploit code - what is it good for
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On (30/06/05 15:13), Aviram Jenik didst pronounce: > What I need is a security administrator, CSO, IT manager or sys admin > that can explain why they find public exploits are good for THEIR > organizations. Maybe we can start changing public opinion with regards > to full disclosure, and hopefully start with this opinion leader. > I sysadmin a small number of machines, mainly Debian based. When an exploit comes out, it's usually released as "version X is vulnerable". Debian's version numbers don't always directly match releases of the vulnerable software, so having exploit code available helps to verify whether or not the software is vulnerable, without having to wait for Debians advisory, which are usually released later than the vulnerability release. It's also very useful to decide whether you need to use a workaround (which may cause disruption or change to the service) or not. - -- Chat ya later, John. - -- BOFH excuse #1: clock speed -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxDkNQBw+ZtKOvTIRAt3oAJ9iaBMYQbS5P0j1K8Sv90L+j1cnggCbBSZ5 BHK6XUdm1pIwbJkblRVJ2sk= =kHrg -END PGP SIGNATURE- ___ 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] Re: Publishing exploit code - what is it good for
benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Heh...very close-minded to begin with. Good luck trying any argument with this "analyst". Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. You may wish to point out to your "analyst" that end-user benefits are indirect How many times have we seen organizations attempt to sweep problems under the cover. This is an old, well understood reason for full disclosure. Now, how many times have their been arguments about "this is not a code injection exploit, only a DoS, so the customer impact is not severe, so we're delaying fixing this until release X.Y in 3 months time", only to find someone actually coded an exploit to prove that a vulnerability is fully exploitable. The end result: Exploit code, responsibly handled, serves the exact same purpose that vulnerability information disclosure serves: an accountability mechanism to ensure that Vendors do not attempt to bury information that they perceive to negatively impact their products and services. Thus, exploit code serves the customer by ensuring that vendors handle vulnerabilities promptly because the vendor is aware that exploits will likely be developed, and that the negative publicity of exploits running wild against their products outweigh the negative publicity of admitting (and fixing) a vulnerability. But, somehow, giving the attitude your analyst is conveying, I'd say more effort has been expended than is worthwhile. Thomas ___ 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] RE: Publishing exploit code - what is it good for
I have used public exploits for: 1. Verifying that the manufacturer's recommendations have been followed and that they work. This was invaluable in the first few rounds of Microsoft RPC patches a couple of years ago - some patches appeared to have installed correctly but the machines were still vulnerable. They would not have been patched successfully without exploit testing. Yes, the public exploit code helped lead to widespread malware outbreaks, but those first few bugs were so blatant that black hats could exploit them easily anyway and the outbreaks still would have happened. Witness the continuing success of those vectors. The public exploits at least let us test to see if we were prepared. 2. Developing methods to detect the exploits. 3. Understanding the exploitation process better. This way I can make the hard sell on taking systems off line for patching with the appropriate urgency. 4. Blocking appropriate attack vectors (and thinking of other potential vectors), and making sure the attacks don't get through. ___ 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] Re: Publishing exploit code - what is it good for
We are a company that actively keeps up to date on publicly available exploits. Their availability not only prompts us to understand the risks when prioritizing, but also provide us with the necessary tools to dispel nay-sayers arguments of disbelief. Nothing like showing management the true risks... Beyond that, from a more theoretical standpoint, we believe that full-disclosure and publicly accessible exploits serve as a cattle-prod for vendors that would otherwise ignore vulnerabilities. Exploits are not easily available, so they must not exist. We all know that this is not the case. My personal opinion is that full-disclosure allows those whose minds are inclined to break things something constructive to do, short of joining the dark side. I'm much less likely to consider H.D. Moore a danger to my network since he is able to release his (their) toolset freely. Otherwise, the urge to "prove" how great they are might lead more hacker-types down the seductive path. HDM is great, and we all know it. He doesn't have to prove it by doing a "seriously righteous hack." But that's just my thinking. Dangerous to listen too closely. Matthew Carpenter IT Security Specialist Alticor Corporation Phone: 616-787-0287 Email: [EMAIL PROTECTED] Page Me (230 characters Max) Email ITSS On-Call Account -BEGIN PGP PUBLIC KEY FINGERPRINT- PGP Fingerprint: 52C3 328D C29C 178B 2DFD 9EA8 C710 0042 8CB4 3CDB -END PGP PUBLIC KEY FINGERPRINT- Aviram Jenik <[EMAIL PROTECTED]> 30/06/2005 08:13 To full-disclosure@lists.grok.org.uk, bugtraq@securityfocus.com cc Subject Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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/
[Full-disclosure] Re: Publishing exploit code - what is it good for
As the security officer for our organization, I find full disclosure to be an indispensable part of our software selection process. Software that has not been thoroughly examined and tested is considered strongly suspect by our organization and is not likely to find its way to our short list. Without the exploit code, we have only some unknown person's suggestion that the software is vulnerable. Without the code, it becomes difficult to discern the difference between a legitimate exploit and someone's personal bias against a particular company or software package. With the exploit code we can independently verify the vulnerability - thus increasing our internal confidence in the opinions of the researcher and the researcher's organization (if any). The code is indispensable. Period. >>>Aviram Jenik <[EMAIL PROTECTED]> 06/30 6:13 am >>> Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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/
[Full-disclosure] Re: Publishing exploit code - what is it good for
Here is my quick $0.02: In a lot of environments (including the one that I work on/in) we make our own modifications to software to get them to work in such a way that is more beneficial to our organization. Because we make modifications to the way software works we don't always know if the software we are using is actually vulnerable to exploits based upon version number. In some cases we have actually fixed a security problem without realizing it before any known vuln was released. It's also possible to open up older problems through patching and coding. Having exploit code available is a huge plus as it lets us test our software. Without it we wouldn't know (as quickly) if our in house version of XYZ is exploitable to the newest vuln release. In a nutshell, exploit code allows people to easily find out if they are vulnerable to a specific problem without spending lots of time looking into it. After all, I'd rather exploit my own code and fix it as opposed to having someone else do it while I try to scramble to figure it out. Steve Aviram Jenik wrote: Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. ___ 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] RE: Publishing exploit code - what is it good for
I remember using a published exploit to show proof positive something malicious could be done to an email gateway. This so frightened the higher ups they instituted a rigorous security policy and encouraged me to keep abreast of constant developments. I have free reign to use any code be it malicious or trustworthy to secure the systems I am responsible for now. ___ 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] Re: Publishing exploit code - what is it good for
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Aviram! On Thu, 30 Jun 2005, Aviram Jenik wrote: > What I need is a security administrator, CSO, IT manager or sys admin th > at can > explain why they find public exploits are good for THEIR organizations. Getting a serious bug fixed before full-disclosure was much harder. Any and all potential isssues were just denied by vendors. Denial no longer worked after everyone could just google for a working exploit. Then vendors got a bit of religion and started admitting and fixing a few things. Same thing for customer networks. "It ain't broke so we won't fix fix it" was the ruile of the day. Now when a pen test, using a public exploit, pokes a hole in a customer system there is a chance they may fix it. They can no longer claim that just because you found it does not mean the bad guys can. Going back to the old ways is just burying our collective heads in the sand again. Nothing got fixed because no-one could "prove" there was a problem. Now that some things get fixed, the net is safer for all on the net. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxCqt8KZibdeR3qURApa7AJwLoJYjZ4z91L7y7tgEUDhZtgUePQCeKc3u YQgKGjOc90ZV/42ktKwbdss= =Ts5l -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
