Vulnerabilities / Threats

12/29/2016
08:00 AM
Jason Haddix
Jason Haddix
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

The Bug Bounty Model: 21 Years & Counting

A look back on the beginnings of crowdsourced vulnerability assessment and how its robust history is paving the way for the future.

When Netscape launched the first bug bounty program 21 years ago, it redefined the way companies approach system vulnerabilities. Today, there is widespread adoption of crowdsourced security programs across mainstream companies with more than 600 publicly disclosed programs and counting.

I’ve worked on a number of these bug bounty programs over the years, and served as director of penetration testing for HP Fortify. The changes have happened so fast, it’s easy to lose sight of how far we’ve come since the very first program was introduced in 1995. As we approach the new year, let’s take a look at the robust history that set the foundation for the modern bug bounty program.

The First Bug Bounty
Netscape Technical Support Engineer Jarrett Ridlonghafer designed and launched the first bug bounty program to discover vulnerabilities in Netscape’s beta version Navigator 2.0 Internet Browser. The company offered cash rewards to hackers who found bugs in the software.

Although this was a major advancement for the security industry, the model wouldn’t catch on for another seven years. By 2002, IDefense launched its own bug bounty program and in 2004, Mozilla created a program that is still running today. These early programs paved the way for the modern bug bounty and for the emergence of managed programs and bug bounties as a service.

Breaking the Mold
In 2010 and 2011, Google and Facebook took notice of crowdsourced security, adding them to their business models, which increased their popularity and incentivized more researchers to join the bug bounty community. In March 2011, Facebook paid a 22-year-old security researcher $15,000 for a bug discovered. By 2015, Facebook had paid more than $4.3 million to researchers globally.

Bug bounty programs were beginning to increase in popularity, yet many organizations still perceived them to be too risky. This perception was tied to the belief that a bug bounty gives hackers free reign of critical code. But the reality is much more controlled than that, because, whether you invite hackers in or not, as long as applications are connected to the Web, they’re vulnerable. Tapping into the intelligence of thousands of security researchers helps identify these vulnerabilities before the bad guys do and lowers the risk of being vulnerable.

Bug Bounties as a Service
In recent years, the growing need for bug bounty programs and the challenges and costs associated with managing them internally drove the creation of third-party platforms or bug bounties as a service. This opened new pathways for a growing hacker community and furthered adoption by other market sectors such as healthcare, financial services, automotive, and the Internet of Things.

For companies, third-party platforms offer the opportunity to create personalized programs by connecting organizations with trusted partners and a community of diverse security researchers. For researchers, the third-party platform verifies their results, handles arbitration issues with the company, and makes it easier for individuals to get paid and move onto testing for more bugs. Third-party platforms also drive the creation of a thriving community where researchers connect, educate, and inspire one another in an environment that allows people with a variety of backgrounds to share their knowledge and expertise.  

The Future
Crowdsourced vulnerability assessment has evolved to include more than just public programs. As I mentioned earlier, a common misconception about the bug bounty model is that all programs are public. In reality, the majority of all programs launched are invite-only. Private, ongoing, and on-demand programs are incredibly common and give companies a way to facilitate testing on harder-to-access applications, or focus testing on a small subset of an attack surface to meet organizational testing needs.

Private programs allow organizations of all sizes (like Western UnionOkta, and Aruba Networks) to validate the security work they’re doing internally, and leverage a curated crowd of talent to scale up their team and improve response time before going public.                  

Crowdsourced security programs have taken on many different forms and will continue to play a major role in securing applications, especially as companies face increased pressure to release updates and keep their customers’ data secure. From the increase of vulnerabilities in healthcare devices, IoT and the automotive industry, these programs can bring advancements to industries across the board. With the willingness and constant interest from intelligent engineers, bug bounty programs will continue to thrive.

Related content:

Jason is the head of trust and security at Bugcrowd. Jason works with clients and security researchers to create high value, sustainable, and impactful bug bounty programs. He also works with Bugcrowd to improve the security industry's relations with researchers. Jason's ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
100%
0%
Joe Stanganelli,
User Rank: Ninja
12/31/2016 | 12:54:14 PM
bounty misconceptions
In addition to public vs. private-only, another potential "misconception" (if that is the right word in this case) that abounds among many researchers/hackers is that you get a payday just for discovering (1) *any* security bug and (2) anything that *looks* like a security bug.  Additionally, they operate under the misconception that (3) they will necessarily be believed.

I still remember the 2013 case of Khalil Shreateh, who -- after several repeated reporting attempts to Facebook on a serious bug -- wound up having to hack Mark Zuckerberg's Facebook account and post to his wall to prove the bug he had found.  Facebook then continued to deny Shreateh the bounty because he had technically violated Facebook's TOS in hacking Zuckerberg's account -- despite admitting that the company was too "hasty and dismissive" in not rewarding him earlier.

(In the end, Shreateh got an $11k payout from an IndieGogo fundraising campaign in lieu of a Facebook-awarded bounty.)
6 Ways Greed Has a Negative Effect on Cybersecurity
Joshua Goldfarb, Co-founder & Chief Product Officer, IDRRA ,  6/11/2018
Weaponizing IPv6 to Bypass IPv4 Security
John Anderson, Principal Security Consultant, Trustwave Spiderlabs,  6/12/2018
'Shift Left' & the Connected Car
Rohit Sethi, COO of Security Compass,  6/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12026
PUBLISHED: 2018-06-17
During the spawning of a malicious Passenger-managed application, SpawningKit in Phusion Passenger 5.3.x before 5.3.2 allows such applications to replace key files or directories in the spawning communication directory with symlinks. This then could result in arbitrary reads and writes, which in tur...
CVE-2018-12027
PUBLISHED: 2018-06-17
An Insecure Permissions vulnerability in SpawningKit in Phusion Passenger 5.3.x before 5.3.2 causes information disclosure in the following situation: given a Passenger-spawned application process that reports that it listens on a certain Unix domain socket, if any of the parent directories of said ...
CVE-2018-12028
PUBLISHED: 2018-06-17
An Incorrect Access Control vulnerability in SpawningKit in Phusion Passenger 5.3.x before 5.3.2 allows a Passenger-managed malicious application, upon spawning a child process, to report an arbitrary different PID back to Passenger's process manager. If the malicious application then generates an e...
CVE-2018-12029
PUBLISHED: 2018-06-17
A race condition in the nginx module in Phusion Passenger 3.x through 5.x before 5.3.2 allows local escalation of privileges when a non-standard passenger_instance_registry_dir with insufficiently strict permissions is configured. Replacing a file with a symlink after the file was created, but befor...
CVE-2018-12071
PUBLISHED: 2018-06-17
A Session Fixation issue exists in CodeIgniter before 3.1.9 because session.use_strict_mode in the Session Library was mishandled.