Conference notes: How to Differentiate Yourself as a Bug Bounty Hunter (OWASP Stockholm)

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.

differentiate-yourself-as-a-bug-hunter.png

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: bug-bounty-effectiveness-1.png

  • 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

visualisation.png

  • 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

bug-bounty-effectiveness-2.png

  • 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

bug-bounty-effectiveness-3.png

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!


Comments