Skip to main content Link Search Menu Expand Document (external link)
LIS 640

Week 10 Exercises: Pricing Vulnerabilities

Imagine you work for a large company that makes an gig work app like 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 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 “Temporal Score” and “Environment Score”.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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: 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.

More information about the US Government Vulnerabilities Equities Process