How to Find Better Bugs with JR0ch17

How to Find Better Bugs with JR0ch17

Introduction

One of the issues bug bounty hunters hate the most is duplicates. It’s not fun spending hours finding a vulnerability and creating a PoC for it only to be told on the report that someone else found it earlier. To avoid getting duplicates, you either have to be the first on the low-hanging fruit which typically requires a great automation system. Or, you need to look from a different perspective than other hunters. My approach to bug bounty is the latter and as a result, I don’t get many duplicates. I try to take my time understanding as much as possible, what’s actually going on in the application, and by doing a deep dive. 

Reconnaissance

Like every bug hunter, step one into hunting is usually recon. Automation isn’t really my thing so I typically don’t go wide and look for subdomains, I normally just go for the core applications. Because of that, my definition of recon is a bit different. Since I look at programs with smaller scopes, I tend to do recon on a single application. This involves the following main steps, in no particular order.

• Read documentation such as the following:
  • API Docs
  • LinkedIn
    • Read job descriptions on sites like LinkedIn and Indeed
    • Look at employee profiles on LinkedIn and see what they work on
  • Look at developer’s GitHub accounts
  • The target’s engineering blog
  • How-to’s (by doing certain actions in the web application, it may activate more features, which means more attack surface)
• Create a chart which documents user roles and permissions if one doesn’t exist in the target’s own documentation
• More of a technical recon
  • Use tools such Wappalyzer and BuiltWith to identify technologies used
  • Verify where the application is hosted (ie. AWS, GCP, Azure, on-premise, etc)
  • Verify whether a WAF is used
  • Do directory brute forcing specific to technologies, frameworks and languages used by the web application
  • Go through JavaScript files to identify endpoints using tools like xnLinkFinder or Burp Suite plugins such as JS Link Finder and JS Miner

Deep Diving

Once I feel like I really know my target application, I start browsing around while intercepting all traffic in Burp Suite or Caido and identify interesting functionalities that are known to have vulnerabilities. Since I like server-side vulnerabilities, I typically look for those first. However, depending on the application or company, I may look for vulnerability classes that would be more important for the company. For example, if privacy is really important for the target application or company, I may look for information disclosures, IDORs, etc. 

While browsing around, I also start looking at the requests in Burp and start highlighting interesting ones. Or, I may play with one right away if I feel like there’s big potential or if it’s a low-hanging fruit. This is also a good time to start identifying and documenting certain things that may help in the future for identifying a bug, chaining bugs together or exploiting one. Here are a few questions to ask yourself in order to identify and document those issues.

• What methods of authentication are supported?
• Is caching used?
• Are there any odd or unknown headers?
• How is CSRF protection implemented?
• Is there any cross-domain communication which could affect CORS and postMessage?
• What file types are supported in file uploads and where are the files getting stored?
• Which requests involve a database query?
• Which features may do a request to other internal or external applications
• Is there a reverse proxy that routes traffic to internal microservices?
• Are there any template engines used?
• Are there any data imports and exports that could result in an SSRF or other vulnerability?
• Is XML used anywhere that could result in an XXE?
• Are IaC tools like Terraform or Ansible potentially used? IaC, which stands for Infrastructure as Code, is a practice used by developers and DevOps teams to define their infrastructure in code such as VMs, storage buckets, VPCs, etc and to deploy it in an automated way.
• What HTTP version is used? Is there potential for desync attacks?
• How does the communication work within the web app? Is there a REST API? Is GraphQL or maybe gRPC used?
• Are there any integrations to external applications? Or, are there any webhooks or external communication done with email?
• How does the password reset flow work?
• Is 2FA supported?
• Are there any technologies used running on old and vulnerable versions which have known CVEs and exploits?

You might notice that these questions could also be recon related. As you work on an application, you’ll learn and discover new things so you’ll continuously be doing reconnaissance.

Tips

When asking yourself the above questions and documenting, you may find yourself getting lost in your own documentation or trying to remember a small detail in a specific web application from a specific program. Here are a few tips that help you put the pieces together when it’s time to chain vulnerabilities together before submitting a high-impact report.

• Rename your tabs in Repeater for every single request that is important or that you find odd. You may stumble on something later which requires details from a previous request. By renaming tabs, it’s easier to find what you’re looking for. Trust me, you don’t want to start looking for a specific request when you have over a thousand tabs open. 🙂
• Use the group feature in Repeater for vulnerabilities that require more than one HTTP request as well as flows that involve multiple requests.
• Document every little informational or low-impact bug such as missing HttpOnly flag on a cookie, sensitive information in the browser’s sessionStorage, an Open Redirect, etc.
• If you think it would help, create a diagram for the flow of the application and it’s infrastructure.
• If possible export all data from your Burp Suite project to ElasticSearch or similar tool. Logger++ is great for that. That way, if you ever find a vulnerability in a specific technology, it’ll be easy to find other targets that are running that technology so it might be an easy win and bounty.
• Collaborate. Personally I have a lot more fun hunting when I’m collaborating with friends. On top of that, having more minds working on the same problem often ends up with better results and you can learn from each other and improve your skills.

Results

Every bug hunter works differently so this might not help you at all, but for me it works great! However, I find that doing all of this does help me as I’ve been able to find some interesting vulnerabilities that I’m sure a lot of people have missed. A good example of this is about a bug I found a few months ago. After spending a lot of time on the application and documenting the data flow and architecture, I was able to somewhat guess that my input had made its way into an Ansible file in an internal system. The internal application then deployed the corresponding infrastructure in a separate web application which contained my transformed input with the outcome being that I was able to access environment variables which contained sensitive secrets in their internal application. 

As someone who does bug bounty as a hobby, I find it more fun to take my time to learn the ins and outs of my target to try and find hidden vulnerabilities in backend systems and infrastructure. So if you are like me, I hope that this blog post has given you a few ideas on how you could improve your own methodology.

About the Author

An infosec and hacking enthusiast with 10 years of experience in the field, he currently works at Nasdaq as Senior Director of Information Security. He worked for several years as a Penetration Tester and developed an expertise in application security and web hacking. For the past few years, he has also been doing bug bounty in his spare time and has participated in several Bugcrowd Bug Bashes around the world and winning trophies such as the Best Bug as well as the Most P1s. He currently ranks in the top 100th on the all-time Bugcrowd leaderboard. He has also been a speaker at several conferences including Bugcrowd’s LevelUpX03.