The Value of Having A Bug Bounty Program

Posted 2017-06-20  in Community
bug illustration with the words The Value of Having a Public Bug Bounty Program

In Spring of 2017, DigitalOcean transitioned from a private bug bounty program to a public bounty program on Bugcrowd. There were many drivers behind this decision, including getting more researcher engagement with our products, leveraging the pre-existing researchers that exist in the Bugcrowd ecosystem, and creating a scalable solution for the DO security team to manage. Although researchers were actively engaged in our original private bug bounty program, we immediately began to see quality vulnerabilities reported once we made the switch. Our old bug bounty program consisted of manual verification and a reward of Droplet credit and/or DO swag. While this worked when we were a much smaller company, the need to level up our bug bounty program has grown as we’ve scaled.

While we already conform to secure coding practices and undergo regular code audits and reviews, bug bounty researchers are able to find valuable bugs for our engineers to fix. Currently, any Bugcrowd researcher is able to test against the platform (although we’ve limited the scope to our API and Cloud endpoints for the time being).

Once we launched, we immediately saw results as hundreds of new researchers began testing the platform in the first few days alone:

In the rest of this post, we’ll explore some examples of bugs we received within 24 hours of launching our new bug bounty program.

Submissions over time

One of the first submissions we received was a stored XSS in the notifications field via team name. This bug coincided with the launch of our new Teams product, and although our engineers had built client-side sanitization, server-side sanitization was not properly implemented. For this reason, an attacker could modify the team name, and any users invited to that team would have a stored XSS in their notifications area. After triaging and verifying this vulnerability, we worked closely with our engineers to get proper sanitization of all inputs, both on the client side and server side.

A second—and slightly more severe—reported vulnerability was a misconfiguration of Google OAuth in one of our applications. Even though all access to this application was supposed to be restricted to only valid DigitalOcean email addresses, the misconfiguration resulted in any valid Google Apps domain being able to authenticate successfully. Once we received this vulnerability, we worked quickly to check our logs for any potential unauthorized access. We didn’t find any, and as we reviewed the logs, we updated the OAuth provider to restrict appropriately.

The most exciting and severe vulnerability we received was a blind SQL injection into a specific search field in our API. We alerted the engineering team as soon as we received the report, and then audited the logs in search of any malicious activity exploiting this vulnerability. Thankfully, none were found, and our engineers were able to implement a fix within 24 hours of being notified of the issue.

As a company that takes security very seriously, we’ve gotten tremendous value from our new bug bounty program by finding issues and vulnerabilities that have passed code review and third-party penetration tests. It has afforded us the opportunity to work with and yield amazing results from skilled researchers we didn’t have access to before.

If you are interested in learning more—or participating in—our bug bounty program, visit our Bugcrowd program page.

Rusty Bower is an Information Security Engineer who manages the DigitalOcean Bug Bounty Program. When he is not triaging vulnerabilities, Rusty enjoys speaking about security topics and tinkering with random InfoSec projects in his basement.