Showing posts with label disclosure. Show all posts
Showing posts with label disclosure. Show all posts
Monday, February 4, 2013
Vulnerability Disclosures in 2012
A new blog post by me is up on the IOActive site - 2012 Vulnerability Disclosure Retrospective. It follows from a review of the new analyst briefing document from NSS Labs about the statistics of vulnerabilities throughout last year and their increase.
Sunday, November 15, 2009
"Responsible Disclosure" - Friend or Foe
It's been an interesting weekend on the "responsible disclosure" front. Reactions and tweet threads from several noted vulnerability researchers in response to K8em0's blog post (Behind the ISO Curtain) most notably those of Halvar Flake via his post (Why are most researchers not a fan of standards on "responsible disclosure" have been fast and (semi)furious.On one hand it seems like a typical, dare I say it "annual", flareup on the topic. But then again, the specter of some ill-informed ISO standard being developed as a guide for defining and handling responsible disclosure was sure to escalate things.
To my mind, Halvar makes a pretty good argument for the cause that any kind of "standard" isn't going to be worth the paper its printed on. I particularly liked the metaphor...
"if I can actually go and surf, why would I discuss with a bunch of people sitting in an office about the right way to come back to the beach ?"But the discussion isn't going away...
While I haven't seen anything on this ISO project (ISO/IEC NP 29147 Information technology - Security techniques - Responsible Vulnerability Disclosure) I suspect strongly that it has very little to do with the independent vulnerability researchers themselves - and seems more focused on how vendors should aim to disclose (and dare I say "coordinate" disclosures) publicly. In general most vendor-initiated vulnerability disclosures have been mostly responsible - but in cases where multiple vendors are involved, coordination often breaks down and slivers of 'ir' appear in front 'responsible'. The bigger and more important a multi-vendor security vulnerability is, the more likely it's disclosure will be screwed up.
Maybe this ISO work could help guide software vendors in dealing with security researchers and better handling disclosure coordination. It would be nice to think so.
Regardless, I think the work of ICASI is probably more useful - in particular the "Common Frameworks for Vulnerability Disclosure and Response (CVRF)" - and would probably bleed over in to some ISO work eventually. There are only a handful of vendors participating in the consortium (Cisco, Microsoft, IBM, Intel, Juniper and Nokia), but at least they're getting their acts together and working out a solution for themselves. I may be a little biased though since I was briefly involved with ICASI when I was with IBM. Coordination and responsible disclosure amongst these vendors is pretty important - eat your own dog-food and all that lark.
At the end of the day, trying to impose standards for vulnerability disclosure upon independent researchers hasn't and isn't going to work - even if these "standards" were ever to be enshrined in to law.
Tuesday, June 30, 2009
ATM Jackpot Talk Blocked from Blackhat
Barnaby Jack was meant to be delivering his new talk "Jackpotting Automated Teller Machines" in Las Vegas but has had to cancel it due to the affected vendor(s) not getting things fixed in time and subsequent pressure being applied to his employer to drop the talk.
The abstract for Barns talk was the following (now removed from the Blackhat site):
I've always liked the scene in Terminator 2 where John Connor walks up to an ATM, interfaces his Atari to the card reader and retrieves cash from the machine.This isn't the first time a scheduled high-profile talk has had its rug pulled out from under it at Blackhat. Unfortunately this kind of thing is becoming a more regular occurrence at large technical security conferences - which is a shame.
I think I've got that kid beat.
The most prevalent attacks on Automated Teller Machines typically involve the use of card skimmers, or the physical theft of the machines themselves. Rarely do we see any targeted attacks on the underlying software. This presentation will retrace the steps I took to interface with, analyze, and find a vulnerability in a line of popular new model ATM's.
The presentation will explore both local and remote attack vectors, and finish with a live demonstration of an attack on an unmodified, stock ATM.
Interestingly enough I had proposed a talk for Blackhat Las Vegas this year along with Stefan Frei which would have discussed how to stop this kind of thing from happening in the future. Pity it wasn't accepted this time round (would have been prime fodder for the ATM media circus) - but it gives us a bit more time to build and test things out. For those that are interested, the talk was going to be about "Guaranteed Disclosure" - abstract as follows...
Vulnerability disclosure – it’s close to all our hearts. For the last decade the disclosure debate has swung from Full Disclosure through to Responsible Disclosure, and every faction in-between. Let’s step up the pace and throw in a new disclosure paradigm – Guaranteed Disclosure.Barns -- looking forward to your talk whenever you get the corporate nod to finally give it.
What would the vulnerability disclosure landscape look like if you could disclose a vulnerability to a security vendor and etch in stone when it’ll become public? No sidestepping by the vendor – they’ve got 90 days to fix the vulnerability because that’s when the vulnerability will be public – and you can honestly say “it’s out of my hands, the timer has already begun!”
In this session we cover a new option for vulnerability researchers to independently and securely disclose their findings to vendors – and guarantee that they’ll be publicly disclosed on a date in advance, despite any future pressure from the Vendor or Government. Guaranteed Disclosure will ensure that hard limits are placed upon the time for vendors to fix a vulnerability and make it public – without the researcher being pressured to halt.
Subscribe to:
Posts (Atom)