Hi, these are the notes I took while watching the talk “How to Differentiate Yourself as a Bug Bounty Hunter” given by Mathias Karlsson at OWASP Stockholm.

Links #

• Video

About #

This talk is about how to differentiate yourself from the crowd, to ensure that you are successful at doing bug bounties.

Bub Bounty Effectiveness #

• Bug Bounty Effectiveness (BBE) formula:

• 3 underrated ways of achieving BBE:

  • Effective recon
  • Golden goose bugs
  • Collaboration

Effective recon #

Proactive recon (enumeration) #

• What Mathias does before he starts working on a program
• It’s the enumeration of all assets & functionalities included in scope
• Assets can include subdomains, stuff from open source intelligence, virtual hosts, web services, specific paths, the developers’ Github accounts (=> information on how the backend works)
• Why?
  • More known assets = More code to test = Increase bugs found
  • Things enumerated that are harder to find = Decrease risk of duplicate
  • Things harder to use/understand = Decrease risk of duplicate
    • Most bug hunters discard them because they are intimidating
    • Examples:
      • Learn new technologies like Graphql
      • Get & test the pro version (paid)
  • Automation = Decrease time spent
    • Automate everything you can
    • It doesn’t have to be good, as long as you understand how it works
    • Can be a Bash script that calls a bunch of Perl or Python scripts
    • You don’t want to do anything in your recon process manually more than once

Reactive recon (monitoring) #

• Always do all the programs that you’re invited to
• Automation will allow you to detect changes in assets
• Why?
  • Big change in known asset = Decrease risk of duplicate
  • Asset changes = Decrease risk of duplicate
    • If you find an IP or subdomains with no port open, move on but continuously monitor them, in case a new service becomes available
    • You’ll know even before the program notifies hunters of the change, on bug bounty platforms
  • Visualisation
    • Take a screenshot of the web service & push it to Slack
    • Will allow you to find bugs just by scrolling through screenshots, even when you’re tired/not motivated

• Bonus: Accidental bug find

  • E.g.: Server with 404 error on the main page. Directory bruteforce => Just sending GET /shudown shuts down the server (Denial of service, $12,000)

• During your recon process:

  • Collect your data creatively
  • Monitor your data carefully
    • Don’t dismiss the data you’ve collected once because it might become valuable even if it’s not now
  • Don’t forget to store it
    • Most important point!

Recon blindness #

• Common issue among bug hunters
• It’s when you do recon for hours & end up so tired that you don’t have energy left to test for bugs
• Finding more info on a target is a never-ending process:
  • /admin
  • Web archive
  • Mail server
  • Shodan
  • Censys
  • Subdomain
  • Old software version
• Recon is a means to an end
• Data is useless unless you find bugs with it
• Recon is super fun but don’t over do it, finding bugs is the goal

Golden goose bugs #

• Common question: How do I beat people doing bug bounty 24/7 with “an hour here and there?”
• With golden goose bugs!
• Bugs/misconfigurations affecting multiple programs, but only a specific stack
• For e.g. an easy to make misconfiguration of Apache
• Not to be confused with 0days (where it’s the vendor’s fault)
• Examples:
  • Subdomain takeover
    • Hostile Subdomain Takeover using Heroku/Github/Desk + more
  • CDN cache poisoning
    • Practical Web Cache Poisoning
  • OAUTH redirect_uri bugs
    • How I Hacked Any Facebook Account…Again!
• Why?

• So you can start doing research on a subject in the few hours you have here and there until you find one of these bugs, then look for it on bug bounty programs

Collaboration #

• Seems like a bad idea since you’re splitting the bounty money with someone
• But it’s not the case because when you collaborate with someone:
  • Time spent is multiplied by 2
  • You can cover different grounds & do not duplicate each other
  • You generally find more bugs & bugs that you wouldn’t have found by yourself

Also:

• It’s more fun
• You make friends

But:

• It’s easy to become jealous & envious of others (My bugs!)
  • Work on it because if you can overcome that, you’ll benefit from the positive side of collaboration
• I found more bugs than you!
  • Be very clear on the terms of your collab before starting
  • He recommends splitting the bounty 50/50 because:
    • If you still feel it’s unfair, pair up with people with the same competence as you
    • Or pair up with someone with less competence than you & view it as an investment to get them to the same level as you
  • Change “I found more bugs than you” to “We found more than any of us could”
  • If you can’t you’re not ready for collaboration

Questions #

Note: I’m paraphrasing here, not reporting exact quotes…

• Q: Have you ever hit backlists when monitoring targets & got yourself blocked out because you were monitoring too hard or too often?

• A: My monitoring is very gentle. It happens but not often. I don’t run tools like Nessus. I only send a few HTTP requests per day. They’re spread out over time

• Q: [not clear, I understood something like: can you still hack a target even if they’re using a WAF?]

• A: WAFs are really good at blocking automated attacks but not manual ones. If I detect a WAF, I either give up because it’s a waste of time or figure out a way around it. Many times, it’s possible

• Q: Do you do recon against the employees of your target? For example, trying to figure out what their programming style is based on what they published on public personal accounts

• A: yes, that’s what a real attacker would do

• Q: Did you ever go out of scope & make someone upset?

• A: It’s happens but accidently. Programs are pretty understanding, I never got into real trouble

See you next time!