Is Your Bug Bounty Program Uber Risky?

In October 2016, Uber discovered that the personal contact information of some 57 million Uber customers and drivers, as well as the driver’s license numbers of over 600,000 United States Uber drivers had been hacked.  Uber, like many companies, leveraged a vulnerability disclosure or “bug bounty” program that invited hackers to test Uber’s systems for certain vulnerabilities, and offered financial rewards for qualifying vulnerabilities.  In fact, Uber has paid out over $1,000,000 pursuant to its program, which is administered through HackerOne, a third-party vendor.  Uber initially identified the breach as an authorized vulnerability disclosure, paid the hackers $100,000, and the hackers deleted the records.  Yet, Uber has faced lawsuits, governmental inquiry and much public criticism in connection with this payment.

What did Uber do wrong and how can organizations ensure that their programs are not subject to the same risks?  To answer this question, one must first understand why and how companies create bug bounty programs.

Why Institute a Bug Bounty Program?

Many companies feel it is far better to pay money upfront to identify vulnerabilities before those vulnerabilities turn into public relations and regulatory nightmares that not only drain manpower and financial resources, but also may result in litigation and increased governmental oversight.  In addition, advance knowledge of a vulnerability allows a company to develop the right solution for the problem, rather than reacting hastily in the pressure-filled post-breach environment.  A properly structured bug bounty program also can be a great way to test the viability of a new concept, product or platform.  It should be noted that the payments made pursuant to bug bounty programs are rewards and NOT ransoms.  The difference is the collaboration and structure of permission-based interactions.

Hackers may be motivated for a number of reasons, including financial gain, intellectual challenge and the personal prestige to be gained from discoveries.  Most of all, by participating in a sanctioned bug bounty program, hackers are able to do what they love without fear of legal repercussion.  The Computer Fraud and Abuse Act prohibits the unauthorized entry into a “protected computer” for purposes of obtaining information from it.  Put simply, any individual who hacks a system could be criminally prosecuted.  However, when a company sanctions and even invites the activity, as is the case with a bug bounty program, a hacker can be reasonably certain that it will not be prosecuted, provided that it complies with the program’s requirements.

Having made the decision to launch a bug bounty program, a company must then decide whether to create an ad hoc program, or to engage a third-party service provider to run the program.  Going it alone requires a dedicated team of employees that not only understand the bug bounty program and the technology or functionality being tested, but also are qualified to evaluate any discovered vulnerabilities and issue resulting compensation. Alternatively, outsourcing can provide some comfort, not to mention the expertise of a vendor who can scale the program as needed.  Essentially, the vendor acts as an intermediary to help the client formulate goals for its use of the program, communicate with hackers, evaluate the identified vulnerabilities and administer payment of the bounties.  Bug bounty vendors offer a measure of safety to all parties, not just in terms of bug bounty program reliability, but also in ensuring increased accuracy and quality of the hackers.

Components of a Bug Bounty Program

In June 2017, the Department of Justice’s Criminal Division Cybersecurity Unit (the “CU”) provided written guidance for companies seeking to implement a vulnerability disclosure program.  Presented as more of a list of considerations, as opposed to a list of requirements, the CU specifically recognizes that each company’s program must be driven by its unique business purposes and needs.  Nevertheless, the CU suggests that a good program will be:

• Appropriately designed with a clear scope – The CU suggested that when developing the program, a company must designate both the components and/or data and the types of vulnerabilities or methods of attack it wants hackers to test.  The CU does include factors to consider when the company’s program targets protections of sensitive information, which include detailing restrictions on and handling requirements for sensitive data (such as prohibitions on saving, storing or transferring such sensitive data) and detailing what methods hackers can use to find vulnerabilities.  Lastly, the company should consider whether any of the vulnerabilities it is testing impact interests of third party business vendors or partners; if so, the company should obtain authorization from such third parties to proceed with the program.
• Properly administered – Once a company has clearly outlined the scope of the program, it must include guidance as to how the program works.  Companies should include clearly stated points of contact, preferably nonpersonal email accounts that are regularly monitored.  A company will want to be able to reproduce or corroborate any identified vulnerability, and the CU suggests that while a company is free to set the rules as to documentation format, it should be mindful that if hackers are prevented from saving certain data, it may have to be willing to accept written descriptions.  Timing should also be addressed – some companies require a prompt disclosure, while some have a long-term deadline and others create short-term challenges which offer higher payouts for the more bugs identified in a defined time period.  Lastly, the company should determine its overall budget for the program and advertise the levels of bounties offered and the attendant requirements to attain each level of reward.
• Accompanied by a stated vulnerability disclosure policy – The policy should clearly state the scope and administrative requirements of the bug bounty program.  The critical component here is having the policy publicized and accessible to potential participants.  In addition, the company should state the consequences for hackers that operate outside the parameters of the program.  While laws are a bit vague on this point, companies often promise not to prosecute if hackers fully comply with all elements of the program.  Lastly, the policy should provide a company contact to whom hackers can direct questions and receive guidance on program rules.

Conclusion

Once a bug bounty program is created and publicized, a company must hold itself to as strict a compliance standard as it applies to its hacker participants.  What challenged Uber was that it paid a drastically larger amount (ten times the highest advertised reward amount pursuant to the program) for just one breach, thereby circumventing its own publicized and authorized program.  Not only did the amount exceed the limits of its stated program, but Uber negotiated with the hacker, which appeared as extortion-like behavior.  In addition, officials at Uber were aware that this situation unfolded differently than the typical bug bounty interaction.  Rather than notify Uber of the potential vulnerability, the hacker downloaded the sensitive information, then contacted Uber to request payment.  At that point, Uber should have notified law enforcement.  Not only did Uber fail to contact authorities, it waited more than a year to notify the public or authorities about the breach.

Whether a company runs its own program or enlists the aid of a service such as HackerOne, it would be well-advised to ensure compliance with the terms of the program.    Furthermore, it must make certain that all relevant business and legal leaders at the organization are aware of the identified vulnerability, particularly if it is a significant one or involves sensitive information.  Only by involving all stakeholders in the discussion can the organization ensure that its program does not run afoul of relevant legal and other guidelines and requirements.