The replacement security analyst's Top 10

I'm a huge football fan so the depth of my joy at the return of the "real" NFL referees cannot be measured. Given the replacement ref debacle I felt compelled to share a replacement security analyst's Top 10.
Note: at one time or another in my career I have truly heard all of these.
In no particular order...

1. Disable AV altogether, its inconvenient when moving malware samples around.
2. Passwords longer than eight characters make it hard to do your job.
3. Don't worry about chain of custody or evidence integrity, cases rarely go to court anyway.
4. When a concerned user calls about a potentially compromised system, tell them to just run McAfee Stinger.
5. Why would you want to keep DNS logs?
6. Go ahead and give developers the ability to deploy code to straight to production from their desktops. It helps them be agile and creates efficiency.
7. Proxying egress web traffic is an invasion of privacy and makes users mad, so don't do it.
8. Your vulnerability scanner is causing my service to crash! Turn it off!
9. We don't need to fix XSS. You can't hack a server with it.
10. But it is encrypted. We used MD5 hashing to store the credit cards in the database.

In a similar vein, you'll really enjoy Infosec Reactions if you haven't already seen it.
Welcome back, NFL refs. :-)
Cheers.

Phorum Phixes Phast

I was paying a visit to the FreeBSD Diary reading Dan Langille's post grep, sed, and awk for fun and profit (a great read, worthy of your time) when my Spidey sense kicked in.
Specific to log messaging he'd created for captcha failures, Dan mentioned that "these messages are created by some custom code I have added to Phorum."
Oh...Phorum, CMS/BBS/forum/gallery software I'd not seen before.
I installed Phorum 5.2.16 in my test environment, ran it through my normal web application security testing regimen, and found a run-of-the-mill cross-site scripting (XSS) bug. There's no real story there, just another vuln in a realm where they are commonplace.
What is not commonplace in this tale though is the incredibly responsive, timely, and transparent nature with which the Phorum project's Thomas Seifert addressed this vulnerability. I truly appreciate devs and teams like this. He even kindly tolerated my completely misreading the Github commit's additions and deletions.

August 22nd - XSS vuln advisory submitted to security@phorum.org. Yay! They have a security alias, and they read what's submitted to it. :-)

August 25th - Thomas replies and says "Thanks for your report.
We fixed the issue in the git repository, https://github.com/Phorum/Core/commit/c1423ebfff91218a4c1b31047d6baf855603cc91, and will push out a new release in the next 2 days." Sweet, not only is the project responsive and transparent, they're open with their source and change management.

August 26th - Thomas replies again, Phorum 5.2.17 is live. "Release is out:
http://www.phorum.org/phorum5/read.php?64,149490,149490#msg-149490." Outstanding! And a day early than the suggested release window. Advisory published.

One need only read the changelog to see the level of dedication and commitment Thomas and team afford their project.

Nothing else to say but bloody well done. Thank you, Thomas and the Phorum team. More smiles and less middle finger make for happier security grunts.

Cheers.

toolsmith: OpenVAS-4

Between writing this post and writing April's toolsmith a couple of weeks ago, I used OpenVAS-4, April's toolsmith topic, for a penetration testing engagement rather than the other freely available vulnerability scanner.
The project leads just released OpenVAS-4 in March and it offers some noteworty enhancements.
Between the highly functional web UI, the Greebone Security Assistant, and the impressive scan configuration methodology, I may be a convert.



OpenVAS-4 offers seriously strong report-fu; an essential part of successful engagement tooling.
I also find the ability to slave multiple OpenVAS Managers to one Manager to load balance and distrbute resource intensive scan tasks.






As part of recent testing I discovered a host running the Mongoose web server.



It's here we'll have some fun, a contest if you will, more of a guessing game than anything.
On what specific host type was Mongoose running?
Hint: Keep in mind that Mongoose is an "easy to use web server. It also can be used as embedded web server library to provide a web interface to applications."
First correct guess received via holisticinfosec at gmail dot com will receive an information security book of my choosing.


Check out OpenVAS; I think you'll be impressed.
Cheers.

CSRF: Six Degrees of Kevin Beaver (or at least his printer)

Perhaps you followed the CSRF debate between RSnake and Kevin Beaver last month.
While I fall well on Robert's side of the tracks, Kevin made some interesting points.
I may take issue with some of them (ok, almost all of them) but Robert took him to task, and I'm pretty sure Kevin has done his penance ;-), so no need to beat that dead horse.
Except that scanner comment. Scanners <> CSRF detection; it's a largely manual check, and it actually does exist significantly more often than you might think (pretty much everywhere). Watch your Tamper Data or Burp sessions for requests made without tokens/formkeys/canaries, etc. and you'll soon know what I mean. There is no "high-quality vulnerability scanner" that will solve the CSRF challenge for you.

No matter your view or perspective, CSRF is pervasive, annoying to fix, and still lurking everywhere; it can be used to pwnzor your printer, your APC UPS, your website's shopping cart or CMS, or any other damned thing you expose to the Intarwebs that fails to check "exposure to unintended requests."
What value these targets? Depends on your motive.
Stealing printer resources? Probably not. ;-)
But a CSRF attack against a website operator who's using the likes of osCommerce, Zen Cart, or eclime (15 million+ at last check) and is foolish enough to be using one of them to manage credit card data? Game over.

Heck, CSRF vulns are so widespread that we could rate number 5 on the OWASP Top 10 like a video game...Rated E for Everyone, just like your Mom. Ohhh!

When I popped my new HP Photosmart C4700 on my home network and changed the admin password via CSRF with twenty second's worth of HTML, it all came to a head.
How do you patch that?
Vendors like HP and APC, who are extremely responsive to disclosures, no matter how low hanging the fruit, still can't easily update their software and expect all customers to apply the fix.
Then there all the vendors who do nothing (you know who you are).
Good code and responsible vendors are paramount, but so too is consumer awareness and understanding of risk.
What if a properly targeted "one click" attack turns off the power outlets on a UPS device with a hospital's ICU servers connected to it?
Is life in the balance?
Our "mysterious" web bug changes the nature of that very question.
Overly dramatic, sure, but you get the point.
Who'd be to blame under those circumstances?

So what's the solution (write secure code)?
I recognize that I'm asking more questions than providing answers (write secure code), but I'm at a loss as to how to solve poor coding practices easily (write secure code). Perhaps you, dear reader, have some ideas (write secure code).

Maybe RSnake should just CSRF Kevin Beaver's printer, force it to print a bunch of copies of OWASP's Development Guide, and we'll call it good. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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)

#6 of the Top Vulnerability Discoverers of 2009

As I was last year, I am again pleased to report that the vulnerabilities I've been happily and responsibly disclosing and posting have resulted in 6th place on the list of Top Vulnerability Discoverers of 2009. Thanks to Scott Moore of the IBM ISS Frequency X Blog who compiled the list for 2009.
I remain both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.

1) First, a reminder that my work has focused entirely on vulnerable web apps and pales in comparison to the likes of others named on both the all-time list and the list for 2009. Congratulations and well done to you all.

2) My efforts resulted in what the Frequency X post indicates is 48 unique web application vulnerabilities in 2009. This again serves as a stark reminder of what a challenged state of affairs the development process is for so many web application vendors. May the SDL and its ilk prevail.

3) I will continue my discovery and reporting efforts with the intention of somehow making a dent in the statistics (unrealistic, I know). I focused heavily on cross-site request forgery (CSRF) issues in 2009 and was not surprised to find that the average number of days for CSRF vulnerabilities to be resolved increased by 37 days to 93 days.



The above figure can be found on page 7 of the 8th Edition of WhiteHat's Website Security Statistics Report.
I believe, as the report states, that much of the reason CSRF issues linger unabated is that "no one at the organization knows about, understands, or respects the issue."
I can tell you from personal experience, I heard this many times in 2009.
It should therefore surprise no one that CSRF is number four on the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors.
Hopefully, each application discovered and reported as vulnerable to this issue leads to a downward statistical trend in the likes of the WhiteHat report.

I look forward to continued discussions of these issues with you, dear readers, and hope we can make a difference.

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)

Why PCI DSS is in a continued state of fail

Data breaches abound, half a million sites fall to SQL injection in 2008…the headlines are horrific and leave me to wonder.
Where does the PCI DSS fit in all this, if at all?
According to the WHID report about the rampant SQL injections, 11% of the sites were finance oriented and another 11% were retailers. According to my mad math skillz, that indicates that it is possible that 22% of 500,000 sites that fell to SQL injection attacks last year were beholden to PCI DSS. That’s 110,000 PCI sites that apparently failed to meet a very basic standard.
With my ear to the tracks for ongoing indiscretions, a delightful tidbit hit my radar, courtesy of a cheeky fellow in the UK named Michael Kemp of clappymonkey, who, whilst recently bored, was exploring the PCI Security Standards Council (PCI SSC) website, when lo, what did he find?
Yep…a lovely XSS vulnerability, in all places, the PCI QSA search script.



Mike indicates a swift fix on the part of PCI SSC on his blog, but I must say, this finding lends itself to some serious questions. I simply couldn’t let something this rare pass by unfettered.
1) Why isn’t the PCI SSC applying its own standard to itself? Fortunately, given no apparent forms oriented to taking payment card information on https://www.pcisecuritystandards.org, they’re not beholden to their own standard. But it would seem that a WAF or a review of site code per PCI DSS 1.2 Section 6.6 to prevent cross-site scripting as indicated in PCI DSS 1.2 Section 6.5.1 would be in order, yes?
2) Are we to believe, if PCI SSC doesn’t adhere to its own standard, that anyone else will, except during the annual audit? As there is little to no enforcement of PCI violations, it seems unlikely that PCI DSS will continue to be any more than a self-congratulatory security check list method with which enterprise can meet minimalist requirements once a year.

Allow me further the point.

CSRF falls under PCI DSS 1.2 Section 6.5.5. As part of my ongoing effort to cure the world of ailing web apps I recently disclosed a CSRF vuln in osCommerce. In discussing that vuln with Mike Bailey, he immediately found and disclosed a similar issue with Zen Cart. A couple of quick Google searches yield extraordinary numbers.
“powered by oscommerce” and “powered by zen cart” returned a combined 11,630,000 results!
Now let’s say for argument’s sake that just half of those results point to a legitimate site running the software (probably a low estimate) for a total of 5,815,000. Let’s further assume, because that both these vulns were disclosed recently, that a large majority of these sites are still running vulnerable code. How about half again? We can therefore surmise that 2,907,500 sites might currently be running code vulnerable to CSRF attacks. For our final assumption, how many of those sites are likely required to meets PCI DSS 1.2 standards. By my calculations…ALL OF THEM. You run osCommerce and Zen Cart to take online orders, paid for by credit cards.

So what then are we to say of PCI DSS in its current state of lax enforcement, double standards, and ill begotten data losses? I say, “For shame." PCI DSS could provide so much more, and offer better protection for the many, from the devious few. A standard is only as good as the extent to which it's enforced. The fact that the PCI SSC site didn't even meet its own standard indicates a significant credibility gap. It is my hope that they'll be reviewing their site regularly in the hopes of avoiding embarrassing and preventable flaws like this.

del.icio.us | digg | Submit to Slashdot

#8 of the Top Vulnerability Discoverers of 2008

When, towards the end of 2008, I noticed the total count of vulnerabilities I'd disclosed and posted climbing past 50, I didn't imagine the effort would merit ending up as 8th on the list of Top Vulnerability Discoverers of 2008, as determined by Gunter Ollmann of the IBM ISS Frequency X Blog.
I am both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.
1) While I appreciate being on this list I must say that the caveat offered as part of Gunter's post is valid: "cross-site scripting vulnerabilities in a commercial shrink-wrapped application count for the same as a remote root vulnerability on a default Windows service."
My work has focused entirely on vulnerable web apps to date, and truly qualifies as low hanging fruit when compared to the findings of the likes of Luigi Auriemma. I am reminded of Wayne and Garth...I'm not worthy. My hat is off to Luigi, as it has been for quite awhile.
2) Gunter has, in the past, stated that he "wants companies to stop acknowledging an alias or pseudonym for any researcher that discloses a vulnerability - even if they came to you directly. “Use real names only,” he adds." Amen. The use of stupid, h@x0r nicknames lacks credibility and flies in the face of what I believe our core mission should be: find, advise, and promote repair of vulnerable software on behalf of users and consumers who may fall victim to its exploit. Disguising this mission in some self-perceived leetness-by-nomenclature denigrates the essence of this work. Courage, my friends...be true to yourselves and the cause.
3) Gunter has further indicated that he wants "software vendors to stop acknowledging companies and researchers who buy and sell security vulnerabilities." I must agree entirely here as well. I'd no sooner sell a vulnerability for profit than I would exploit it for personal gain.
4) Finally, the fact that, with relative easy, I discovered and reported what the Frequency X report indicates is 53 unique web application vulnerabilities in 2008 is really testament to what a sad state of affairs the development process is for so many of these vendors (not all, but many).
My plan for 2009, in addition to continuing this effort in earnest, is the promotion of the use of the Security Development Lifecycle (SDL). I believe that weaving the SDL mindset into software development is essential to preventing the flaws we vulnerability researches enjoy pointing out.
More to come, to be certain.
Cheers, and thank you, Gunter.

del.icio.us | digg | Submit to Slashdot