I am a narcissistic vulnerability pimp

The Verizon Business Security Blog has drawn the line in the sand of the kitty litter box they're apparently playing in, labeling those who irresponsibly disclose "information that makes things less secure" as narcissistic vulnerability pimps.
Wow.
Time to pull those iPhone wannabes from betwixt the Verizon lily whites and dial 1-866-GET-CLUE.
I love it when risk "experts" start sounding off about that of which they know nothing.
As members of the Verizon Risk Intelligence group, clearly an oxymoron, Wade Baker and Dave Kennedy must be the same guys who describe risk level in the cloud as .4.
What?
Here's a secret.
Vulnerability disclosure is, as Robert Graham says, rude at its core.
"Hey Mr. Vendor, your code sucks, fix it."
But what about when Mr. Vendor decides to blow off the security researcher who tried on numerous occasions, via numerous channels to disclose a vulnerability?
So when that security researcher goes public after vendor FAIL, he's now a narcissistic vulnerability pimp?
Is Charlie Miller a security researcher or a narcissistic vulnerability pimp?

Attrition.org (d2d) recently summed this conundrum up succinctly:
"So what is actually responsible or ethical? The lines are blurred quite a bit. The "responsible" method is also the "painful", "expensive", and often "ineffective" method that gets little resolved for exponentially more work, time and money. Is all that waste not irresponsible? What about all of the other organizations unknowingly affected by things I've found, organizations who never got a heads-up, no less a patch, because my attempts at "responsible" disclosure failed?"

No matter how you define it, disclosure drives vendors to repair code they would otherwise neglect and leave vulnerable for the real criminals to exploit.
Yes, risk may be elevated in the time period between disclosure and repair, as well as repair and patch deployment. But if researchers wait on the likes of Oracle to fix their kluges, nothing would ever get fixed.

Dan Goodin says in his writeup, "as the recent Pwn2Own contest made abundantly clear, software makers can't be counted on to secure their products, at least not on their own."
Dan clearly be styling some bling of his own.

I at Holisticinfosec.org do hereby resolve to faithfully ignore Verizon Risk Intelligence dreck forthwith.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

REI: vulnerability remediation done wrong

Part 2 of 2 of Vulnerability remediation done *

It makes me sad to use REI as another example of the wrong way to manage vulnerability disclosure; I am a member who is fond of their stores and products. I will not name names or blather on about negligence.
Rather, I will let the facts simply speak for themselves.

1) On April 11th, 2008 (more than a year and a half ago), I reported a cross-site scripting vulnerability specific to the REI website search functionality. Via email I received a reply indicating that "I’ll have our team evaluate this." I had every reason to believe it would be resolved.

2) The issue completely fell off my radar thereafter until one evening I was checking old findings and noticed that the vulnerability remained on October 1, 2009.

3) Surprised, if not shocked, I tried an alternative approach. I called REI HQ and asked to speak with an appropriate party to report the issue again. I was transferred to a person who provided me with an email alias to which I could forward the issue. On October 6th, 2009, only when I requested a reply as confirmation, I received "I forwarded your information on to our Security team."

4) The issue again fell my radar until November 29th, 2009 when, once again, I noticed that the vulnerability remained (nearly two months since October 1). I was quite ticked off at this point and fired off a feisty email stating that if the issue was not resolved, or a timeline for resolution provided, within seven days that I'd publish the finding regardless.

5) Today, I checked again and found the vulnerability remediated. Had I received one reply to any email sent after October 5th? No, not one indication that a solution had been implemented.

Following are screen shot and video.
Think about what this issue might have meant to consumers while noting that yesterday was CyberMonday.



VIDEO

So, to be clear, the issue is fixed, but the response, and the amount of time taken to resolve the issue is beyond disappointing.
I'll leave it at that.
Comments, as always, are welcome.
Should someone from REI wish to offer insight or explanation I will gladly accept the comment or add it to the post.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pligg pluggs holes: vulnerability remediation done right

Part 1 of 2 of Vulnerability remediation done *

Often, when I disclose web application vulnerabilities to Secunia, who in turn works with vendors to drive mitigation and remediation, we are met with vendors who don't reply, don't care, or don't fix.
Yet, once in a rare while a vendor chooses the righteous path.
Such is the case with Pligg.
Pligg posted a detailed, transparent, candid writeup regarding the disclosure and their response prior to the scheduled release date (12/2/09) for the advisory. In addition their new release (1.0.3) addressing the issues in now available.
As I am too often prone to complaining, I relish the opportunity to say "well done."
To Pligg, a hearty thank you; you are now amongst the standard bearing few who swiftly address vulnerabilities, do so with candor and transparency, and care about your user base.
When the advisories go live as scheduled tomorrow they will be found here and here.
Again to Pligg: well done.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Disclosure standards and why they're critical

If you've read this blog over the last couple of years you've likely made note of the varying degrees of success I've had disclosing vulnerabilities.
You've seen the best of breed in AppRiver and SmarterTools.
You've also seen lessons in how to not handle disclosures in the likes of American Express and Ameriprise. I believe Ameriprise is Pwnie-worthy for Lamest Vendor Response given that Benjamin Pratt, Ameriprise’s vice president of public communications, said "There's no one at risk here." and that there are no plans to review any of the mechanisms the company may have in place to receive notifications from the public about website vulnerabilities. Wow. The Consumerist clarified those statements aptly with "we assume he means, "No one important on our side of things. Our customers can suck it."

I take disclosure very seriously. I believe it is a deep seated, inherent responsibility that rests squarely on the shoulders of vendors and site operators. Equally, disclosure must be responsible, even when efforts to advise the vendor have come up empty. To that end: ReportSecurityFlaws.com, the result of a recent interview I gave to by Ira Victor of the Data Security Podcast on the topic of mishandled disclosures. We decided on a joint project, thus ReportSecurityFlaws.com.

Report Security Flaws exists to increase awareness and responsiveness in Internet vendors and web site operators when they receive security-related disclosures.
It is our hope that all vendors/operators maintain an email alias that exists for the sole purpose of receiving disclosure notices from parties reporting noted security flaws on the vendor/operator’s web site.

Further, said email alias should be monitored by individuals with an understanding of web application security issues and business logic flaws, while maintaining a close working relationship with the site developers and operations engineers. This relationship should allow for the quick escalation of reported issues for mitigation and remediation.
Examples of such email alias might include:
security@domain.com
websecurity@domain.com
webreports@domain.com

Too often vendors and web site operators fail to manage the proper intake and escalation of reported security flaws, leading to lapses in web application security for days, weeks, and even months.

Report Security Flaws will provide resources and guidance for vendors and site operators facing such challenges, with the hope of improving internet security posture for vendor/operators and consumers alike.

If you, dear reader, have tried to no avail to drive a site operator/web vendor/cloud provider to fix flaws, and received no reply, let us know. ReportSecurityFlaws intends to serve as a public motivator to close such gaps and promote improved vendor response, complete with standards.

NOTE: ReportSecurityFlaws is not intended to out vendors who fail to fix. Rather, it is to use all means necessary to ensure they do fix, and promote better standards and practices.

With standards in mind, I've been participating in discussions regarding ISO/IEC 29147, which will hopefully be embraced globally as the ISO standard Security
techniques – Responsible vulnerability disclosure.
We also believe there is an opportunity for the PCI Council to incorporate stringent disclosure practices in the PCI DSS.

Disclosure can and must be handled properly. This week's reading included a remarkable and detailed public incident report from Apache to the compromise they'd suffered the week prior. This kind of transparent, open response does, as they clearly state, make the internet a better place. Well done, Apache.

Stay tuned for more....
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)