Conference notes: Eliminating False Assumptions in Bug Bounties (OWASP Stockholm 2018)

Hi, these are the notes I took while watching the “Eliminating False Assumptions in Bug Bounties” by Frans Rosén (@fransrosen) on OWASP Stockholm 2018.

eliminating-false-assumptions-in-bug-bounties.png

Overview

This is a talk where @fransrosen responds to arguments he heard on why you shouldn’t do bug bounties. It’s full of thoughts and ideas on how to approach bug bounty mentally and what you can do to overcome common hurdles.

What it is

  • Work whenever you want
  • Wherever you want
  • No requirements of time spent
    • There are exceptions like Google’s researcher grant (spend time hunting every month and get between $500 and $3,000) and Cobalt which looks like pentests (work for a week & get paid)
  • Great training of skills, like a CTF but you stop at step 1 (no pivoting)
  • Boost your career

What it is not

  • ROI on day 1. There be dragons
  • Any guarantee at all getting money
    • Dupe = Nothing
    • Depends on each program
    • And on type of vulnerability (e.g. Dropbox accept Open redirects but not Google)
      • Read company policies (sometimes they explains what bugs are out of scope and why)
      • Read vuln charts (like BugCrowd’s VRT & HackerOne charts) to get an idea of what a bug is worth. E.g.: If a bug is rated critical & the program pays between $100 and $10,000, you’ll know that you get the max bounty.
      • Some companies accepts critical bugs like SQLi on any asset or subdomain because they don’t want you to know which asset is sensitive to them & which isn’t

Hurdles

Competition with others

  • Dupefest. Time spent, nothing in return

Solution:

  • Know the kinds of bugs the company cares for. E.g. Dropbox cares a lot about Open redirects but not Google.
  • Find old programs with large attack surface like Google, Facebook, Yahoo.
  • A lot of experience bug hunters prefer them because they know newbies go for the new programs that nobody has tested yet.
  • But old companies put up new code all the time

Uncertainty

  • New program, unknown response, payout, skill level

Solution:

  • When @fransrosen tests a new program, he only spends a few hours on it instead of days and sends 3 or 4 bugs like XSS, just to see how they respond. If they’re responsive, he keeps digging & looks for authorization issues & their infrastructure.

Tiny differences in policy

  • Does not want XSS, domain takeovers or “Known bugs: RCE”

Solution:

  • Either stay away or make sure you know what they want
  • Often, to keep his ROI, he reports bugs he’s good at like XSS & similar to pay for the time spent on understanding the app.

First point of entry

  • Really hard. Every time
  • If he takes time off, it takes a few days to get back into bug bounties
  • His activity goes down almost every 3 months (because of boredom)

Solution:

  • Find a methodology that works for you to not get bored.

Methodology

  • @brutelogic’s way: spend time on one thing & do it all the time
  • @LiveOverflow’s way: No, move all over the place, change, challenge yourself all the time

@fransrosen’s way:

  • No way is the “proper way”. Both are right
  • Context-switching. All the time. If bored, stop immediately & try something else, maybe even somewhere else.
  • E.g.:
    • Look at new frameworks getting traction
    • Hacker News helped him look into new things
    • Read code; for e.g source code of open source programs that have a BBP like GitLab & Discourse
    • Look at crypto programs (not all are built in C on COBOL, PHP & Nodes programs also have crypto)
    • Work on any skill you want to improve (eg. regex)
  • His methodology changes all the time
    • E.g: CTFS make more sense to him now than 6 years ago
      • They’re a good intro to thinking out of the box
      • Some bugs are even like a CTF!
      • E.g. bug found while live hacking an enterprise product: FTP exposed a binary so you could SCP to the instance. They changed the SCP binary to something else & were able to get a shell from that. Then it was a load balancer. All kernels were updated except one, so they used DirtyCow & got root.
  • Make notes. They’re time optimizers
    • Documenting your work allows you to go quicker next time. It helps get into bug hunting quicker (lower point of entry)

Backside

  • Mental health!

What we can do

  • Self care is key. Easy to get sucked in this gig economy (similar to Uber drive)
  • Move forward. Don’t pile bugs. Eliminate them
    • Some hackers do their favorite bug & don’t want it to get fixed so that they continue to submit it
    • Advice for bug bounty programs: Don’t just fix your bug, communicate with vendors to eliminate it once & for all
  • Share knowledge

The story of Stök

  • Movie producer & Network architect
  • @fransrosen invided him to Nullcon in India to make a movie about it
  • They introduced him to Web app security, gave him a Burp license
  • The he focused one day every week (thursday) on bug bounties
  • In his first year, he got invited to a Hackerone event in Las Vegas. Bought his own ticket. Found bugs worth $20,250 including an XXE on Salesforces which is extremely hard. After the event, found two RCEs worth $15,000 each, then got $16,000 for the best bug found in a Buenos Aires Hackerone event.

Questions

  • Q: How many people are the opposite of Stök, i.e. fail at bug hunting?
  • A: It’s hard. There’s a geographical difference between people too. People in the Nordics tend to have a really good education, that’s why they don’t do bug bounty. They’re like we’re working with security day after day anyway, so why spend time on security when I come home? So it’s Stök’s mentality that maybe makes it easier for him. The majority of people doing bug bounties come from India & they have different incentives or reasons to do it. They also have totally different stories. We need both. There are bugs they’ll find that we don’t & vice-versa. It’s not a game of trying to be the only one but trying to enhance everything by different skills.

See you next time!


Comments