In 2002, iDefense started their Vulnerability Contributor Program. The VCP was created to solicit vulnerability information from the security community and pay researchers for the information. Paying up to US$15,000 for a vulnerability or exploit, iDefense proved there was a significant market for such information after years of debate. The VCP also served as a stark reminder that researchers do not have an obligation to report vulnerabilities to vendors, that doing so is a courtesy.
The VCP pays for “actionable research”, meaning exploits in prominent software (e.g., Microsoft, Oracle) and infrastructure devices (e.g., Cisco). With the information in hand, iDefense in turn leverages researcher’s time by notifying their customers as an early warning system while handling the responsible disclosure of the information to the vendor. This activity can save a world of time for researchers who are long since tired of the headache that often comes with disclosure.
The list of vulnerabilities disclosed by iDefense is impressive. They attribute the large number of advisories to “250 security researchers worldwide”.
In the past few months, an OSF employee (Nepen) has begun to add creditee information for many vulnerabilities in prominent software. This has resulted in creditee information being added for all of the iDefense vulnerabilities. Using OSVDB, we can now look at their advisories in a new light.
iDefense employees have released 131 advisories, credited to 11 unique researchers and “iDefense Labs”. The VCP program has released 479 advisories, credited to 78 unique researchers and “anonymous”. If we assume the 250 researcher number is an estimate and includes both iDefense and VCP, then 89 researchers are distinct and public. That means the “anonymous” submissions make up approximately 161 unique people and cover 326 advisories out of the 479 released.
Using OSVDB’s new creditee system, we can see a neat timeline of the advisories as related to both iDefense and their VCP:
iDefense VCP (79 researchers, 479 advisories): http://osvdb.org/affiliations/1139-idefense-labs-vcp
iDefense Labs (12 researchers, 131 advisories): http://osvdb.org/affiliations/1091-idefense-labs
This is one of many neat ways to use the enhanced creditee system. Over time, as more information is added to the database, we can begin to look at other researchers and organizations.
On January 17, 2007, SnoSoft / Netragard LLC announced a new Exploit Acquisition Program designed to compete with iDefense, TippingPoint and others. Nothing special or different other than the suggestion that they would pay more for high end vulnerabilities. A little over a year later, and they announced they were shutting down the Exploit Acquisition Program. From their post:
We regret to say that its true, we’ve shut down the Exploit Acquisition Program. The reason for the shutdown was that it was taking our buyers too long to complete a single transaction and it wasn’t fair to the researchers. While we’d expect a single transaction to take no more than a month, the average transaction time for our buyer was 4 months. The last transaction that we attempted took 7 months at which point the issues were silently patched and the transaction was dead. As it stands right now, we can’t justify asking anyone to wait that long to move a single item. So until the end players learn how to move faster, the high price bug brokering market just isn’t viable.
No offense to SnoSoft / Netragard, but their competitors have proven that the market is viable. I guess the trick is how you ‘sell’ the information. For iDefense it is early warning for their customers in case the same vulnerability is being exploited by others. For TippingPoint it is early warning and IPS signatures. For WabiSabiLabi it is more like the SnoSoft program, where one buyer gets exclusive rights to the information, and it appears to be working to some degree.
Another interesting article regarding the value of 0-day vulnerabilities. Rob Lemos relates the stories of a few researchers who sold their 0-day vulnerability/exploit information for big dollars. The twist here, which is news to some, is who purchased it (the .gov) and for how much (as high as 80k). This is significantly more than vulnerability purchase shops iDefense and ZDI (3COM/Tipping Point) currently offer. The only catch? The big spenders aren’t advertising so you have to have contacts to make such a sale. The scary part? We all know how cheap the U.S. government can be.. so how much are other governments paying?
Since the debate about pay-for-disclosure started, some folks have wondered what vulnerabilities are worth. We’ve seen companies like Verisign/iDefense and Tipping Point/ZDI offer serious money for vulnerabilities in the past. Adding to the mix, matousec.com has published a purchase page with prices of some of their vulnerability research information:
* Full analysis of reviewed personal firewalls
Visit Windows Personal Firewall analysis methodology page to get information about what the full analysis is. The full analysis is preferentially offered to the product vendor. If the vendor buys the analysis it is given 30 days protection for all private information included in this analysis.
o ZoneAlarm Pro 6.1.744.001 analysis – 1,500 ($ 1,950)
o Kerio Personal Firewall 4.3.246 analysis – 500 ($ 650)
o Norton Personal Firewall 2006 version 126.96.36.199 analysis – 1,500 ($ 1,950)
o BlackICE PC Protection 3.6.cpj analysis – 1,500 ($ 1,950)
* Single bugs of reviewed personal firewalls
Visit Windows Personal Firewall analysis methodology page to get information about what the single bug is.
o ZoneAlarm Pro 6.1.744.001 bugs – visit ZoneAlarm Pro 6.1.744.001 – Review
o Kerio Personal Firewall 4.3.246 bugs – visit Kerio Personal Firewall 4.3.246 – Review
o Norton Personal Firewall 2006 version 188.8.131.52 bugs – visit Norton Personal Firewall 2006 version 184.108.40.206 – Review
o BlackICE PC Protection 3.6.cpj bugs – visit BlackICE PC Protection 3.6.cpj – Review
Ever wondered what some of the bigger vendors do in response to vulnerability Disclosure? Federico Biancuzzi has written an article on his Disclosure survey which may answer the question for you. Apple, Computer Associates, Google, IBM, Microsoft, Novell, Oracle, Red Hat, SAP, Sun Microsystems and Yahoo all answered to one degree or another. As always, some of the vendors are a bit weak in the description. Take Oracle for example, who says they want researchers to wait for their patch before disclosing. Next he asks the two big vulnerability purchasing shops iDefense and TippingPoint’s ZeroDayInitiative (ZDI) their thoughts. Finally, he asks three prominent researchers; David Litchfield, H D Moore and Michal Zalewski.
Brian Krebs has a fantastic post on his blog covering the time it takes for Microsoft to release a patch, and if they are getting any better at it. Here are a few relevant paragraphs from it, but I encourage you to read the entire article. It appears to be a well developed article that is heavily researched and quite balanced. Makes me wonder if his editors shot it down for some reason. If they did, shame on them.
A few months back while researching a Microsoft patch from way back in 2003, I began to wonder whether anyone had ever conducted a longitudinal study of Redmond’s patch process to see whether the company was indeed getting more nimble at fixing security problems.
Finding no such comprehensive research, Security Fix set about digging through the publicly available data for each patch that Microsoft issued over the past three years that earned a “critical” rating. Microsoft considers a patch “critical” if it fixes a security hole that attackers could use to break into and take control over vulnerable Windows computers.
Here’s what we found: Over the past three years, Microsoft has actually taken longer to issue critical fixes when researchers waited to disclose their research until after the company issued a patch. In 2003, Microsoft took an average of three months to issue patches for problems reported to them. In 2004, that time frame shot up to 134.5 days, a number that remained virtually unchanged in 2005.
First off, these are the kind of statistics and research that I mean when I talk about the lack of evolution of vulnerability databases. This type of information is interesting, useful, and needed in our industry. This begins to give customers a solid idea on just how responsive our vendors are, and just how long we stay at risk with unpatched vulnerabilities. This is also the type of data that any solid vulnerability database should be able to produce with a few clicks of the mouse.
This type of article can be written due to the right data being available. Specifically, a well documented and detailed time line of the life of a vulnerability. Discovery, disclosure to the vendor, vendor acknowledgement, public disclosure, and patch date are required to generate this type of information. People like Steven Christey (CVE) and Chris Wysopal (VulnWatch) have been pushing for this information to be made public, often behind the scenes in extensive mail to vendors. In the future if we finally get these types of statistics for all vendors over a longer period of time, you will need to thank them for seeing it early on and helping to make it happen.
This type of data is of particular interest to OSVDB and has been worked into our database (to a degree) from the beginning. We currently track the disclosure date, discovery date and exploit publish date for each vulnerability, as best we can. Sometimes this data is not available but we include it when it is. One of our outstanding development/bugzilla entries involving adding a couple more date fields, specifically vendor acknowledge date and vendor solution date. With these five fields, we can begin to trend this type of vendor response time with accuracy, and with a better historical perspective.
While Krebs used Microsoft as an example, are you aware that other vendors are worse than Microsoft? Some of the large Unix vendors have been slow to patch for the last twenty years! Take the recent disclosure of a bug in uustat on Sun Microsystems Solaris Operating System. iDefense recently reported the problem and included a time line of the disclosure process.
08/11/2004 Initial vendor contact
08/11/2004 Initial vendor response
01/10/2006 Coordinated public disclosure
Yes, one year and five months for Sun Microsystems to fix a standard buffer overflow in a SUID binary. The same thing that has plagued them as far back as January 1997 (maybe as far back as December 6, 1994, but details aren’t clear). It would be nice to see this type of data available for all vendors on demand, and it will be in due time. Move beyond the basic stats and consider if we apply this based on the severity of the vulnerability. Does it change the vendor’s response time (consistently)? Compare the time lines along with who discovered the vulnerability, and how it was disclosed (responsibly or no). Do those factors change the vendor’s response time?
The answers to those questions have been on our minds for a long time and are just a few of the many goals of OSVDB.