"No More Free Bugs" Initiatives

Two years after the launch of the "No More Free Bugs" philosophy, several companies and Open Source projects are now offering programs designed to encourage security research in their products. In addition, many private firms are publicly offering vulnerability acquisition programs.

This post is an attempt to catalog all public and active incentives. This includes traditional "Bug Bounty Programs" as well as "Vulnerability/Exploit Acquisition Programs".
Update (19 Oct 2013): A new website http://www.bugsheet.com/bug-bounties has started collecting bug bounties and disclosure programs. I do recognize that an actual website is better than a single blog post, thus I've discontinued this list.

Bug Bounty Programs



AT&T Security vulnerabilities found within the AT&T API Platform $100-$5,000, plus merchandize (e.g. LTE data cards, phones with free service)
Avast Security vulnerabilities in the latest consumer Windows versions of Avast $200-$5,000
Barracuda Vulnerabilities in Barracuda appliances, including Spam/Virus Firewall, Web Filter, WAF, NG Firewall $500-$3,133.7
BugCrowd Crowdsourced security testing. BugCrowd manages bug bounty programs for third-party companies Starting from $250
BugWolf Marketplace for bug bounty hunters. BugWolf manages bug bounty programs for third-party companies Starting from $500
Coinbase Previously unknown security vulnerabilities in Coinbase's web platform Starting from 5 BTC
Cryptocat XSS bugs, crypto implementation bugs, arbitrary code execution in Cryptocat's code $n/a
Djbdns Verifiable security holes in the latest version of Djbdns $1000
Etsy Web application vulnerabilities affecting the main www.etsy.com site, the etsy.com API, or the official Etsy mobile application Starting from $500
Facebook Facebook web platform security bugs. No third-party applications Starting from $500
Future of Enforcement Web vulnerabilities in Future of Enforcement's website €100
Gallery Security issues in the latest stable release of the popular web based photo album organizer $100-$1000
Google Chromium browser project, Chrome OS and selected Google web properties bugs $500-$20,000
IntegraXor HMI/SCADA Security vulnerabilities in IGX SCADA systems with verifiable proof-of-concepts Up to 8K I/O points (~$3999)
Hex-Rays Security bugs in the latest public release of Hex-Rays IDA Up to $3000
Kaneva High impact web application vulnerabilities $100
Mega Web application vulnerabilities and crypto bugs affecting MEGA's online systems Up to €10000
Meraki All web content under *.meraki.com, Meraki-operated web properties, systems manager client applications and Meraki hardware devices $100-$2500
Mozilla Firefox, Thunderbird and selected Mozilla Internet-facing websites bugs $500-$3000, plus Mozilla T-shirt
Nokia Vulnerabilities in all Nokia run services, applications and products excluding corporate infrastructure $n/a
PayPal Web application vulnerabilities in www.paypal.com $n/a
Piwik Flaws in Piwik web analytics software $200-$500
Qmail Verifiable security holes in the latest version of Qmail $5000
Ripple Security issues in Ripple, an OpenSource person to person payment network Up to $10000
Samsung Security bugs in Samsung TV/BD Starting from $500
Tarsnap Tarsnap bugs, affecting either pre-release or released versions $1-$2000
Yandex Security vulnerabilities in Yandex's services or mobile applications, as specified on the terms and conditions page $100-$1000

Vulnerability/Exploit Acquisition Programs



BeyondSecurity SecuriTeam High and medium impact bugs in widely spread software $n/a
Coseinc Unpublished security vulnerabilities for Windows, Linux and Solaris $n/a
Exodus Intelligence Program Vulnerability research acquisition program for unknown vulnerabilities affecting widely deployed software packages $n/a plus yearly bonuses
ExploitHub Legitimate market-place for non-zero-day exploits $50-$1000. Both one-time purchase payments as well as recurring monthly payments from site-license customers
iSight Partners Bugs in typical corporate environment applications $n/a
Netragard 0-day exploits against well-known software $n/a
Packet Storm Exploits for 0-day and 1-day vulnerabilities in enterprise-grade software (Microsoft, Flash, Java, etc.) $1000-$7000
TippingPoint ZDI Undisclosed vulnerability research, affecting widely deployed software $n/a plus awards and benefits, depending on the contributor's status
VeriSign iDefence Security vulnerabilities in widely deployed applications $n/a
White Fir Design Bugs in WordPress code and plugins (with over 1 million downloads and compatible with the most recent WordPress) $50-$500

Contributions are welcome! If you are aware of an initiative not listed here or you want to report an inaccuracy in your initiative, please leave a comment and we will update this page over time. In fact, the more people, the better.

Just to clarify, we aim at indexing programs that are:
  • Legal. Although black/gray market places exist, we don't certainly want to list them here
  • Active. We want to keep track of ongoing initiatives. Even time-limited programs are eligible, as long as they are still accepting submissions
  • Public. All entries must have publicly available details. This may range from accurate guidelines and rules to just a simple sentence stating the nature of the incentive. It hence follows that we are going to report public information only. In case of cash rewards, the actual amount is reported whenever the min-max price paid is clearly stated
  • Reward-based. In most cases, entries are "cash-for-bugs" programs. However, any kind of tangible reward is eligible. "No More Free Bugs" versus "No More Cheap Bugs" disputes are not considered here
Disclaimer: we do not endorse, represent or warrant the accuracy or reliability of any of these programs.

    On exploits and assessing security

    Everything started on a summer Friday, August 19 2011, 23:23 BST (so it might be reported to Sat 20 Aug, depending on your timezone).
    Kingcope, a Greek hacker known for a long stream of 0days and trash Greek music soundtracks, posts a very short email on the Full-Disclosure mailing list. The email has a promising title, Apache Killer, and an attachment: killapache.pl.

    The script is extremely simple: 84 lines of perl, comments included, capable of killing any Apache web server.

    The core of the attack is extremely simple: the script sends a (perfectly legit) request to the Apache server, including a Range header similar to this:

    Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19, 5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29, -[..and many many more..].

    What happens behind the scene is that Apache has to make separate copies of the response for each of those ranges and, guess what, it explodes.

    The Range header (defined here in RFC 2616) has legitimate uses: for instance, PDF readers use it while you scroll down the page. Let us reiterate that the attack is a perfectly well formed request: "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity."
    On a side note, IIS only allows up to 5 ranges for each HTTP request, and it is not vulnerable - with the notable exception of IIS 5, but you don't have those around anymore, do you?

    But back to our story. Apache reacted "quickly", issuing a security advisory [CVE-2011-3192] a mere 4 days after the release, on August 24 16:16 GMT [http://article.gmane.org/gmane.comp.apache.announce/58]. They acknowledged the bug, promising that "A full fix is expected in the next 48 hours.". Apache also provided a number of different mitigations, by using mod_rewrite, limiting the size of the request field or even a dedicated module.

    +1 for having included so many mitigations inside the advisory, -1 for taking so long to give an official answer.

    A number of different answers were surfacing by that time, including Spiderlab's suggestion of using ModSecurity (but truth be told the answer was already floating on some forums). The 24th was, in short, the moment where the general public started noticing the issue - also thanks to a The Register's article which, even though it drops a totally out of place comment on open source security, at least cites Zalewski.

    And this is the interesting bit of the story: the bug was well known!
    lcamtuf reported this exact issue in 2007 - just 4 years ago.

    The reactions were, to say the least, wrong. William A. Rowe [of the Apache Software Foundation] answered: "With the host of real issues out there in terms of massively parallel DDoS infrastructures that abound, this is, as you say, quite a silly report.". Yeah, sure. The issue was also thought to be connected to the sliding window (Rowe: On the matter of your 1GB window (which is, again, the real issue), you have any examples of a kernel that permits that large a sliding window buffer by default).
    Probably even lcamtuf did not understand the full impact of this issue - we are speaking about a full DOS against the default installation after all, even if it is very easily avoided - as he says: "William, again, this is not a critical issue; I did mention that, and if it were, I wouldn't report it that way". The issue was thus not really understood by both parties, or at least its full implications were not. If we go into the details of the bug report we must grant the fact that it focused more on the "network" attack vector - not exactly the one exploited by Kingcope's attack, which results in memory exhaustion. Siim P├Áder also tried to implement the attack, but failed. The thread then just died.

    Bottom line: general failure of the community to identify and evaluate a risk in the absence of an exploit. So long for all the "risk assessment without full disclosure" talks: without an exploit, an entire community looking at the description of a bug in the most widespread web server of the world failed to evaluate risk.

    At the same time, in the Apache dev@ mailing list there was not a single mention of the bug. Compare that to the mail thread [mod_deflate & range requests) from last August: http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/browser, or here. This exploit, in the end, resulted in a ticket on the ietf with a request for changing the standards [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311]: that's what we call impact.

    And all because an exploit was not developed in the first place...

    MS Access SQL Injection Cheat Sheet Reloaded

    SQL Injections are still very popular, for both ethical and unethical attackers.
    Although numerous research covering this topic have been published, SQL Injection vulnerabilities in Microsoft Access powered websites didn't receive much attention.

    Back in 2007, @_daath published the first MS Access SQL Injection Cheat Sheet. A few years later, NibbleSec decided to update the document in a brand new format. New stuff has been added as well as external resources have been merged.

    Enjoy the reloaded MS Access SQL Injection Cheat Sheet