Week 11 Studio: Uber Breach

Today’s case study resulted in Joe Sullivan, the former Chief Information Security Officer (CISO) of Uber, being convicted of two felonies – the first time a CISO has ever been held criminally liable for a corporate security breach.

First, some background: In May of 2014, a hackers broke into Uber’s database and stole information on 50,000 drivers. Uber did not discover and fix this breach until September 2014. As a result of this breach, the US FTC launched an investigation into the data security practices at Uber, and determined that they were not protecting sensitive data up to modern standards. Uber and the FTC entered into a “consent decree”, which is an agreement between a company and the US government that is filed with the courts and can be later enforced by the courts. This consent decree required Uber to hire a Chief Information Security Officer (CISO), undertake a number of modern data security protections, and notify the FTC of any future breaches.

Now, for today’s case. In 2016 — two years later — a hacker broke into Uber’s server and stole information about 57 million drivers and riders, including phone numbers, email addresses, and names, on Uber’s services. The hacker accessed this information as it was stored on a third party (cloud) server that was operated by Uber.

The hacker then contacted Uber’s CISO Joe Sullivan, and asked for a $100,000 ransom payment to delete the copy of the data. Sullivan (the CISO) told Travis Kalanak (the CEO) about this. Sullivan asked the hacker to report this breach to the company’s bug bounty program, and then used that program to send the attacker $100,000 and ask the attacker to sign a non-disclosure agreement.
That same week, Sullivan testified before the FTC that Uber had not had any further breaches after the May 2014 breach.

For unrelated reasons, the board fired Travis Kalanak (the founder and CEO) and replaced him with Dara Khosrowshahi. When this new CEO learned of the breach and bug bounty payment, he fired Mr. Sullivan (the CISO) and reported the breach to the FTC. Not long after this, the US Department of Justice opened an investigation into Mr. Sullivan for lying to the FTC.

In October of 2022, Mr. Sullivan was found guilty of hiding information from the FTC in a federal court. He was sentenced to three years of probabtion and a $50,000 fine

Part 1: Understand the Case

Let’s use the skills we’ve been developing to understand this case. Start by reading the two news articles linked above. You’ve read through a number of case studies, and are starting to get a better gut feeling for what information is important and what information isn’t. Trust your gut; you can always go back and look again later. You can also google for more information; this case was in the news a lot, Uber was very cooperative with the DoJ investigation, and almost all details have been made public, so there are a lot of news stories about it.

Let’s go through the same process we have been doing for the last couple of weeks to map out and understand what is happening.

Figure out who the relevant actors are. We’ve got the attackers, the victim, additional defenders, etc. Fill out an actors and motivations worksheet for each of them to try to think through who was doing what, and why they did what they did.

Figure out the attack, and what vulnerability enabled the attack. How did the attacker get into Uber? How did Mr. Sullivan find out?

Don’t spend too long on this. Details help, but all of this work is really to help you gain a basic understanding of what happened. You should hopefully be getting faster and better at these tasks as you practice them every week.

Part 2: Pricing Vulnerabilities

Let’s try to figure out what that bug bounty program might have looked like, by putting ourselves in his shoes.

Imagine you work for a large company that makes an gig work app like Uber, DoorDash or UberEats. This app has 2 types of users: 1) end users log into the app and use it to place orders and make requests; and 2) gig workers log into the app, see the orders and requests from the users, and then try to fulfill those requests. Your app helps connect these two groups, and you have an algorithm that tries to help the right gig workers connect to the right requests and orders.

Of course, this app has all kinds of sensitive information: gig workers have their names, contact information (phone, email), and social security numbers so they can get paid. The app tracks locations of both gig workers and end users so they can be matched up better, and lots of locations can be sensitive (e.g. an order to a planned parenthood clinic for a teenager). Sometimes, even orders can be sensitive.

Technologically, the app is organized into three pieces: 1) there is an app for end users, available from both Apple App Store and Google Play Store, that people can download and use to place orders. 2) That app uses a web-based API to access a server (or server farm) that you run that stores all of the information centrally. You have a team of developers that write the code for this server and run the operations of this server. Currently, the server is run in the cloud using Amazon Web Services, but your team operates and manages it. 3) There is a second app, also available in the Apple App Store and Google Play Store, that is designed for gig workers. It also uses the same API to access the same servers, which is how all communication happens.

You have started running a “bug bounty” program for your company. People outside the company can report bugs in your software through this program. If you determine that these bugs are serious enough, then you will pay them a “bounty” — a monetary reward — for reporting this. You do this because you’d rather have them report the bugs to you so you can fix them, than sell the bugs to hackers who do things that will make your company look bad. But you don’t want to overpay for the bugs; you have a limited budget.

Below are some of the bugs that have been reported. Your goal is to price them — figure out how much you should pay to a hacker who has reported them.

You should use the Common Vulnerability Scoring System (CVSS) to generate a score for each bug (just use the “base score”), and then use that score to determine which category the bug falls into, and the payment for each category.

Part 2.1: Scoring Bugs

To score a bug, you need to learn about the vulnerability, and then make a number of decisions about the vulnerability and how it might be able to be used by an attacker against you.

We are going to use the Common Vulnerabilty Scoring System (CVSS) to score our bugs. For this, we are just going to calculate the “Base Score”, and ignore the modifiers under “Supplemental Metrics” and “Environmental”.

For understanding the scoring, CVSS has a description of each option in the Base Score in their specification document. For each bug, you should read through each of these scoring options, and then make a decision which of the scoring options apply. CVSS also provides a number of examples that illustrate applying the score to real-world bugs.

You initial goal is to score the bugs. Below are a series of bugs that have been reported to your bug bounty program. Go through and figure out a score for each of these bugs. For each bug, write down on a sheet of paper or the vulnerability scoring worksheet WHY you think it deserves this value for each metric (much like the examples do – metric, decision, and reason). Then enter these metrics into the calculator and see what the final score is.

The Bugs

Your bug bounty program has received reports about the following bugs:

When logging into to the end user app, if you enter a specific username into the login screen, then it allows you to access that app without a password. If someone else had previously logged into that app on that device, then it gives you access to their account.
If you have a legitimate account as a gig worker, then you can send can specially formatted API query to the central server using your gig worker account information. This query will then return the payment information (name, SSN, amount paid) for all other gig workers in the system.
If you have a gig worker account, you can send a specially formatted API query to the central server. The server will take a LOT of computation to respond, which will freeze up the server for a minute for each query you send. There is no limit on the number or rate of queries for gig worker accounts, so you could send a lot of these queries and freeze up the server so no one else could access it.
The end user app, used to place orders and receive updates on status, uses TLS to encrypt the communications between the app and the servers. The app uses a custom library to do the TLS, and there is a bug in the library. The encryption prevents an attacker (or anyone else) from reading the messages that include the orders place, credit card information, and amounts to be charged. However, that bug allows an attacker to communications – to change letters or numbers in place. So it can change a 3 to a 5, but it can’t read what the current number is or add additional letters or numbers to the messages.
The app for gig workers has a bug in it – when it asks you to enter your name or your location, if either of those includes one specific non-english letter in the name (e.g. ß or ç), then the app crashes and you have to start over.
The programmers who created the server included a “test” username and password – anyone using this username and password would be given access to the server as a regular gig worker. This “test” username and password was accidentally left in the real server, and the user is named “test” and the password is “12345’ – something that is very easy to guess. Hackers are very likely to be able to successfully guess this username/password.

Part 2.2: Determining Payments

Next, you need to figure out how much to pay people for these vulnerabilities. Normally, the way these bug bounties are structured is that there is a specified payment or payment range for different categories of bug (low, medium, high, and critical). See https://medium.com/airwallex-engineering/a-pragmatic-guide-to-building-your-bug-bounty-program-2caaf332c9d3 for an example. Other, real-world bug bounty program minimums and maximums can be seen here: https://www.guru99.com/bug-bounty-programs.html

This month, you have just over $3000 allocated to your bug bounty program (annual budget: $40k). What are good payments for the bugs you found above? Come up with a payment schedule for the bugs your scored in part 1 of today’s lab. That payment schedule should include a range for each class of bug. Then decide: How much should you pay the person who reported each bug? Look at each bug, and talk it over with your partner, and decide whether this one deserves a payment on the higher end or lower end of each range.

Additional Reading

Before this, Mr. Sullivan was a highly respected expert in cybersecurity who worked for the Department of Justice, Uber, Cloudflare, and was appointed to multiple advisory committees. Mr. Sullivan claims that he was just “doing his job” to protect the company Uber from cyber risks and bad press, and that all of his actions are common, everyday occurances for most CISOs.

However, the U.S. Government decided to prosecute and convict Mr. Sullivan. Mr. Sullivan claims that this prosecution basically makes all CISOs liable to be thrown in jail when their companies get hacked, and means that no one will be willing to be a CISO as a result. He claims that creating criminal liability for normal CISO activities will make it significantly harder to actually protect companies from cyberattacks.

The U.S. Government disagrees, and claims that what Mr. Sullivan did was unusual, and outside of the realm of normal cybersecurity work protecting companies. They claim that he lied and covered up attacks, and that those lies and coverups harmed users of the company’s products.

This is a complex policy issue. Should the U.S. Government want CISOs to act like Mr. Sullivan did to protect their companies, or should the government draw a line and stop CISOs from acting like Mr. Sullivan did? And if the government wants to discourage this behavior, is criminal law (i.e. throwing people in jail) the best way to discourage this?

Lawfare blog has a good writeup about these policies questions that is worth reading. It will help you think through some of these questions.

Another similar case: the SEC filed criminal charges against the CISO of SolarWinds for making false and misleading statements that misled the company’s investors and failing to disclose cybersecurity risks. That case is still pending, though SolarWinds has requested it be dismissed and multiple business groups support that position. (Update: That case was recently dismissed in November 2025.)