Hi, these are the notes I took while watching the “Trickle Down PwnOnomics” talk given by Darrell Damstedt (aka Hateshape) on LevelUp 0x02 / 2018.

Link #

• Video: https://www.youtube.com/watch?v=Vp03EtR5-TY&list=PLIK9nm3mu-S6gCKmlC5CDFhWvbEX9fNW6&index=3

About #

• This talk is about how Hateshape “went from having zero bug bounty experience to regularly experiencing ($$$) success”.
• Trickle Down Pwnonomics: A theory promoting the discovery and reduction of vulnerabilities on a bug bounty program as a means to stimulate my bank account.

Helpful things #

• Recommended tool for pentesters: CrackMapExec with the flag --darrell
• State of Infosec today:

Helpful Thing #1: Learning from the mistakes of others #

• Mistake #1 - Theories are not proof!

  • How much evidence do we need?
  • Do not submit reports that have theoretical possibilities as the whole meat of the report
  • No proof no glory

• Mistake #2 - Don’t go too fast

  • At what point is a report warranted?
  • Do not submit bugs without explaining their impact
  • Showing the associated risk of a bug matters even after prooving the issue exists

• Mistake #3 - Scope can kill

  • Be sure an issue is in scope & owned by the program

• Mistake? #4 - Many may be one

  • If multiple instances of a vulnerability are found, should multiple reports be submitted or dhould the findings be aggregared into one report?
  • Risk: Ending up with 1 triage report and many not applicable
  • Common sense is if a bug requires the program to change their code to fix the issue, it’s a finding that stands alone
  • Submit an aggregate report and trust that programs will truthfully tell us if a one change fixes everything

Helpful Thing #2: Doing things nobody else wants to do #

• Rely on manual analysis on top of using automated tools
  • Manually browse the full site
  • Read the HTML, JavaScript, etc
  • Read any and ALL product documentation (help documentation, administration documentation)
  • Cyber stalk developers, if possible
  • Github, Twitter, Reddit, Google, StackOverflow, Blogs, Forums
  • Read ALL the everything. Manually.
• Tools are great and should be used on every target
• Some tools
  • https://github.com/nahamsec/JSParser
  • https://github.com/GerbenJavado/LinkFinder
• Hateshape’s seven 10K bounties were found manually

Helpful Thing #3: Continuous monitoring #

• Religiously monitor everything new in the bug bounty & penetration testing world
• Read everything you find
• Follow the awesome hunters on Twitter, blogs, RSS feeds, full disclosures, Hackerone hacktivity…
• What to do with all this information?
  • Read a blog post about how a researcher found an issue
  • Would you have found that bug?
  • If yes, compare how you could have found the issue and how the author of the blog post just found it
  • If not, try to figure out what you’re not doing that would make you miss it
  • Try to figure out how to fill the gaps between the two
• Scrape Bugcrowd Top 200 public rankings via cron job daily all while being alerted to someone new rising in the ranks so you can follow them

Success stories #

• How I Found CVE-2018-8819: Out-of-Band (OOB) XXE in WebCTRL
  • Target scope: *
  • Recon done=
  • WebCTRL page found
  • Reference to help manual found in the source code
  • Read it ALL => nothing
  • WebCTRL version used => CVE of unauthenticated XXE but no details disclosed
  • Tried to reproduce it & found a new CVE
  • Great finding but N/A bug bounty report!
    • “The ISP providing the IP range did not update their ARIN records so it still shows up as an asset”
  • Consolation CVE + recon win
• Sploit summary
  • Found a target
  • Viewed all resources available (manually)
  • Found a potential issue (CVE)
  • No exploit was published, but knew the type of vulnerability
  • Did a ton of research & found nothing
  • James Kettle FTW
  • Working payload found through trial & error
  • No bounty, but CVE

Reporting #

• Details may be obvious… to us
• Don’t be stingy, explain everything
• Write things once and well!
  • Jason Haddix uses report templates
• If the proof of concept is complicated, record it

Duplicates #

• Only possible solution: Go all crazy on your setup to placate yourself from the duplicate issues

Summary #

• Tools are great, but they don’t make up for thing that we don’t know yet. Then can actually hold us back
• Embrace manual testing/discovery FTW
• Be honest with yourself
  • Know what you know & what you don’t
• Fill in the gaps
• Read everything
  • both in targets you’re testing & everything new publicly released by researchers
• Read everything again
• Take the advice that so many in this community freely give

See you next time!