It’s been a hot week in Las Vegas, and the walking between Caesars and the Riviera hasn’t been particularly pleasant, so perhaps that’s an influence on what I’m thinking about at the moment.  But, before I get started, I’ll reiterate the disclaimer and point out that what I’m about to say doesn’t necessarily reflect the views, opinions or corporate stance of IBM Internet Security Systems (see, you’ve been warned!).

You’ve probably already read several postings from me over the years about responsible disclosure and my views of the ethics behind vulnerability-based services.  So, today I’m planning on going a little further – dispel a myth, and propose something to the major software vendors out there.

Since VeriSign and 3Com launched their commercial vulnerability purchasing programs (i.e. VeriSign’s iDefense Vulnerability Contributor Program and 3Com’s TippingPoint Zero Day Initiative), we have observed an increase in the number of competing programs – including the most recent Swiss-based WabiSabiLabi auction site – none of which appear to have benefited the security community.  In fact, we’ve even seen scary proposals in which third-parties would patent the patching techniques needed to fix a vulnerable software, and require the vendors to license it.

Sure, they all make claims about how they make valuable contributions to the community – but let’s face it, the net result is more vulnerability disclosures with more money going in to the coffers of anonymous bug-hunters – and without any real accountability.

TippingPoint Reversed

Now I’m sure that most of you reading this blog are already way-too familiar with how marketing teams influence the way products and technologies are presented and positioned.  In some realms it may be referred to as “spin-doctoring”, but in the software world it most often called “marketecture” (marketing architecture).  Anyhow, one such marketecture claim I’ve always found ludicrous has been TippingPoints insistence that the inclusion of pre-disclosure signatures for vulnerabilities released through their ZDI program provide greater protection (for the world no less – “peace on earth”?).

Basically, what 3Com have been saying – to justify their ZDI vulnerability purchase program – is that by purchasing some anonymous bugs and security vulnerabilities, they are acting as a responsible conduit for public disclosure.  But, prior to being ‘really’ responsible, they’re going to add signature protection to their TippingPoint IDS products (after all, it costs money to run programs like this – so you’ve gotta recoup those dollars somehow right?).

In theory that sounds all fine and dandy, except for the simple fact that some people have been extracting the technical details of these pre-disclosure vulnerabilities from their products for quite some time.  I guess you could say that the “Zero Day Initiative” has been a great source of zero-day exploits and bypasses for many people.  Since its inception, professional pentest teams have been extracting the info and putting it to good use in penetrating their clients (and I wouldn’t be surprised if less ethical hackers haven’t been doing the same).

Some people may find that a little shocking, but the simple fact is that a lot of the professional pentest teams I know invest quite a bit of time learning how to bypass protection systems.  I myself have had to sift through the reams of SNORT signatures (while sitting cross-legged on the cold floor of a clients datacenter) to uncover the changes I needed to make to my exploit code in order to bypass the signature IDS and IPS solutions that happened to be installed.

Personally, I’d have thought that Robert Graham's presentation – “The Lazy Hacker’s Handbook" – at BlackHat this week would have gotten a little more press attention.  In it, he disclosed one of the techniques to extract the zero-day information from a TippingPoint appliance.  OK, so some pentesters and researchers I know may be a little peeved that that vector is now public and supposedly fixed – but, lets face it, no matter how you slice it, for a signature engine to work you have to be able to load all those signatures in to memory on the device.  It doesn’t matter how sophisticated your encryption system is for protecting the static files containing the ZDI signatures and updates – once they are loaded in to memory they’re unencrypted and fair game.  The cat and mouse game continues, and people will persist in extracting their zero-day information.

Yes-but, no-but, yes-but, no

Like I said, this type of flaw has been known about for quite some time. But, while I’m on the topic of TippingPoint and the purchasing of vulnerability information, I’d like to also point out one more thing.  As part of their justification of the commercial purchase of vulnerabilities in other vendors products, they make the following couple of statements on their site:

1. “By giving advance notice to other security vendors, their customers may receive quicker and more effective protection responses from those vendors”
2. “The reason we're making such an investment in vulnerabilities is to maintain exclusivity and also to protect all end users, including non-3Com customers, until a patch is available from the vendor.”

I’m sorry if this sounds like a rant directed at TippingPoint by a competitor, but hey – I’ve been in the security business for a while now and I take personal integrity pretty seriously – and, as far as I’m concerned, these "justifications" of theirs are a load of bollocks. 

Unless I’ve been missing something, I'm pretty sure that ISS has never been given advanced notice by TippingPoint (perhaps they’re just forgotten about us or got our email address wrong?) - in fact I can't recall meeting anyone working at any of the other security vendors being given advanced notice either. I’m also struggling to see what they’ve been doing to protect all those non-3Com end users prior to patches being released by the vulnerable vendor – I’d be more inclined to say that they have gone out of their way to expose end users given the way they’ve failed to protect their ZDI signatures.

A Proposal

While I would love to see all these vulnerability purchase programs shutdown and disappear for evermore, I unfortunately think that the proverbial cat is out of the bag.  So, in order to curtail the popularity of these schemes and the creation of more of them, I’d like to propose something to all those major software vendors and security organizations out there.  Stop recognizing these irresponsible disclosers in your public vulnerability disclosures!

As the TippingPoint ZDI program points out, “It gives participating security researchers the positive recognition they desire”.  That is, these ‘researchers’ (anonymous or otherwise) want to have their cake and eat it too.  They want financial recompense for their discovery and to also get public recognition.

Some vendors have already adopted a partial response.  For example, Microsoft refuses to acknowledge vulnerability researchers that irresponsibly disclose their discovery – e.g. releasing proof-of-concept code prior to a patch being released.

My proposal would be thus:

1. Don’t acknowledge a “vendor” that serves as a broker or purchaser of third-party vulnerability information within your alerts or advisories.
2. Don’t acknowledge a “researcher” as being the discoverer of a vulnerability if it was sold or irresponsibly disclosed to any vendor.
3. Don’t acknowledge an alias or pseudonym for any researcher that discloses a vulnerability - even if they came to you directly.  Use real names only.

The purpose of these proposal measures would be to remove the recognition and marketing vectors that these guns-for-hire and irresponsible brokering vendors seek to capitalize upon.  Are they really out to improve the security for your customers, or are they in it solely for the money?

I’d also propose that the various international CERT’s and major security vendors also participate in not acknowledging those companies that promote the purchase of vulnerabilities.  There is no need to link to their advisories.  The advisory that comes from the vulnerable software vendor is probably enough – or, failing that, there are always other independent sources.

So, with all that said and proposed, and given the historical fervor that goes with discussions on disclosure, I guess I’d better don my asbestos suit in preparation for any upcoming flame war.