The Bug Bounty Dilemma: When to give up on an API target
API security is a hot topic right now. Bug bounty programs are becoming increasingly popular, as businesses of all sizes try to protect their data. And chances are, if you’re reading this, you’ve jumped on the bandwagon. If not, you might want to check out my article on how to make money hacking APIs and search for the section on API Bug Bounties.
Anyways… if you are web hacking, you might find yourself struggling from time to time as you try to find API vulnerabilities. You might even wonder when to give up on a bug bounty target. And that’s what I wanna talk about today.
In this article, I’ll discuss four key things you should be considering as a bug bounty hunter that will maximize your efforts when trying to create an income hacking APIs.
Understanding depth vs breadth in bug bounties
So there are two main areas of thinking when it comes to bug bounties. The first is that you can invest a lot of time in your recon to “search wide“, finding new or obscure assets of a company that other hackers will miss. It’s common to see advice from leading bug bounty hunters that they want to participate in programs that have a huge scope that allow them to find new targets fast and find the low-hanging fruit before anyone else does.
The other methodology is to “dig deep“; you invest your time researching how the application works in much greater detail, and look for more complex bugs that demonstrate more impactful critical vulnerabilities.
When you are just starting out in bug bounty, searching wide quickly seems like the logical place to go. I argue, as API hackers, that this is flawed thinking for bug bounty hunting. At least for web applications that include APIs.
Vicki Li wrote an excellent article on Why You Fail at Bug Bounties. She brings up the point that you will fail at bug bounties searching for low-hanging fruits. The whole point of bounty hunters stressing out over dupes comes from the fact you are finding the same stuff as everyone else.
API hacking is different. You are purposefully looking for vulnerabilities in how web applications interact with APIs. If you consider the OWASP API Security Top Ten, every one of those classes of vulnerability gets a whole lot more interesting the deeper you look into the logic of how the mobile or web application consumes the API.
The best hackers are looking for creative security vulnerabilities. If you look at the write-ups for some of the more popular bug bounty programs, you will see that the bug hunters with the most success report attack vectors that you won’t find with automation tools.
So if you are going to “go deep”, you better take a methodical approach to it so you don’t waste time randomly going down the wrong rabbit holes and chasing bad ideas.
#1 – Define your methodology and stick to it
Having a defined process in how you as a bug hunter approach a target is HUGELY important when hacking APIs. Especially when penetration testing, where you may be time-boxed.
In the past, I’ve talked about how to leverage OWASP guidance for the OWASP Top Ten along with the OWASP Application Security Verification Standard (ASVS) to build your own API security testing blueprint. And that’s a great start for defining your methodology.
But your methodology is more than that.
A good bug bounty methodology includes:
- Rules that are easy to follow consistently, each and every time.
- Allows you to understand the time required at each stage before you even start hunting.
- Includes flexibility to automate parts of the process, where it makes sense.
- Gives you focus, clarity, and trackability when you do certain things manually.
- Includes a strong data collection and documentation process so you can stay on top of things as you find security issues and build your report.
Let me point you to one example of a good methodology. Jason Haddix presented an excellent approach to application analysis at Nahamcon 2022. You can watch his presentation here and grab his slides here. Lots of great bug bounty tips for application analysis.
If you look at his approach, he boils it down to key basic knowledge questions he always wants to think about on a target:
- How does the app pass data?
- How/where does the app talk about users?
- Does the app have multi-tenancy or user levels?
- Does the app have a unique threat model?
- Has there been past security research & vulnerabilities?
- How does the app handle XSS, CSRF, and code injection?
You can watch his presentation for more details on this; what I want you to take away from this is that his methodology focuses on looking at the app holistically and methodically.
Now apply that to the APIs. Cross-reference that with the common vulnerabilities described in the OWASP API Security Top 10 and the specific API testing guidelines in the ASVS (which I covered here) and you can build your own methodology that covers the largest attack surface with the least amount of time.
Speaking of minimizing time while maximizing results, how you manage your time on target is important. Let’s talk about that.
#2 – Manage your Time on Target
There is a quote I always think about when talking about managing time and effort:
“Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”
Abraham Lincoln
When it comes to how you should hack on new assets of a web application, that is spot on.
The successful bug bounty hunter doesn’t just jump in looking for known vulnerabilities. You would think that’s the case with all the “bug bounty brags” on Twitter. But that just won’t work in the long run for decent bug bounty programs.
No, a good hunter knows before seeking out security issues you need to invest time in the setup and preparation. They also define what success means for the engagement.
Let’s talk about that.
Understand your time investment in the initial setup and analysis
Whenever you take on a new engagement, there is a setup cost. It doesn’t matter if it’s in public programs that concentrate on a specific web application, or internal resources as part of a penetration testing engagement, you will need to invest time in understanding the software.
Think about it for a second. If it takes you a whole week to set up your environment and learn how the web application works, it is a waste to give up on the hunt for a vulnerability after just a couple of hours of focus.
The larger the application scope, the longer it will take you to truly learn how the software functions. You need to factor that into your planning. Nothing says you have to test EVERYTHING the developers have written. But you want to make sure you are focusing on testing all the critical endpoints that expose the application to the most amount of impactful risk.
Here is my rule of thumb. Many organizations have trials for their software hosted online. Before fretting about setting up your own test resources give their software a try as a normal user (if you can). This will let you understand how the software functions.
Make sure you record all the traffic. Use your browser’s devtools to save it out as a HAR capture. Then use that to generate your own rogue API documentation so you get an idea of the scope of endpoints you will need to consider testing.
Then take the number of hours spent learning the app and multiply it by 1.5. So if it takes you 4 hours to learn how a set of features in an app works you should be prepared to spend an additional 6 hours on bug bounty hunting of those features.
If you aren’t prepared to do that, then walk away. It means the features, app, and/or program aren’t interesting enough to you to invest time on.
But what if you spend all that time on a target and don’t find a bug? When is enough… well… enough?
That all depends on your goals for the target.
Define SMART goal(s) for the target
Some people say bug bounty hunting is more an art than a science. I think it’s a bit of both.
You definitely need a good intuition on where bugs hide; you can gain that skill with experience over time. I believe though that if you have reasonable goals and expectations, it can be a worthy pursuit.
This comes down to SMART goals.
What are SMART goals?
SMART goals are specific, measurable, achievable, relevant, and time-bound. That means you need to be clear about what you want to happen and how you will know when you have succeeded.
For example, say you want to focus on a login endpoint of a web application.
A specific goal could be to find an account enumeration issue. A measurable goal could be to enumerate 100 valid user accounts in less than 24 hours. An achievable goal might be to use a brute force attack against the endpoint since it’s a common issue.
A relevant goal is one that meets the program’s scope and requirements. Time-bound means you put restraints on yourself so you don’t spend months going down a rabbit hole.
With all these factors considered, a SMART goal for a login endpoint might look like this: “In the next 48 hours, I will brute force the login endpoint and attempt to enumerate 100 valid user accounts using common passwords found in haveibeenpwned’s Pwned Passwords API.”
The idea is to clearly define what “done” means. And then sticking with it.
Use MVP thinking for your PoC exploits
The best bug reports include proof-of-concept (PoC) exploits that can demonstrate impact, without causing damage or a data breach. Write-ups should include clear repro instructions that allow the company security triage team to test your findings.
Your exploits have to work. But you don’t have to make it overly complex. Use minimum-viable-product (MVP) thinking.
MVP thinking means that you build an exploit that can demonstrate the vulnerability, and nothing more. Why require a huge amount of setup and configuration if you can give them a single cURL command to demonstrate a bug in an API call? Or a bash script to run a couple of commands to do the heavy lifting. Check out my Exploiting APIs with cURL article if this sounds foreign to you.
My point is… build the bare minimum exploit to demonstrate the bug you found. It will save the triage team and developers time if it’s self-documented and clearly shows the vuln. Don’t waste your time building a GUI tool or complex ncurses coloring CLI so the tool can look cool. They won’t be impressed. You’re just wasting time that can be spent in search of the next bounty.
Tip: Reuse code. Personally, I have a whole library of bash and python scripts I use as a base for a lot of my PoCs. Just don’t go overboard. You want to demonstrate a vuln in the least amount of lines of code as possible.
Use templates to minimize the time spent on your writeups
I don’t think I know anyone who likes writing reports. There are tools out there that can help.
Personally, I use Obsidian and create a new workspace for each engagement. As it is primarily markdown, it’s easy for me to feed data in as I go about my work.
I then run a shell script that will take my markdown files and run them through pandoc using a latex template to generate a professional-looking PDF. John Hammond did a great job showing something similar in a video he recorded a few years back.
Going one step further, I have an automation action in Git that automatically runs this script any time I check in changes. So as I go about an engagement and update my findings, it automatically prepares all my reports for me. YMMV of course… but it works well for me.
You could just as easily use a Google Docs or Microsoft Word template. That just takes more work. Or you could consider taking a look at Codingo’s Bug Bounty Report Templates repository.
Whatever method you choose, just eliminate the wasted time on the basic format and setup. Use templates in your reports whenever you can.
#3 – Balance mental health with getting sh*t done
Bug bounty hunting can be stressful. You could spend hours, days, or even weeks and not come across a single vulnerability. Sometimes you won’t find anything at all, no matter how much time you put into it.
Don’t get disheartened. It happens to us all at some point.
The mental rollercoaster is compounded when you are following bug bounty on Twitter, LinkedIn and the main Discord servers. You keep hearing about these great vuln finds, and the wicked payouts. What you aren’t hearing is the real struggles that happened before the find.
I find bug bounty brags kinda annoying. I don’t think people are always being intellectually honest. Sure, they scored a $10K bounty. But if it came only after 6 months on target, was it really worth the effort? It all depends. Investing time on a target to really understand it has merit. But if you are trying to put food on the table and kids through college… a career in API bug bounty hunting needs to have decent returns for the time invested.
This is where having a documented methodology to follow and a clear understanding of your time on target is important. But even if you get that all right, your mental state has to be regularly checked.
During the pandemic Stok did a great presentation about Mental Hacking 4 Better Bounties. I really liked how his talk related to the mental aspect of learning new skills, personal optimization for better results, and how to deal with dupes. It’s worth watching if you are struggling with this side of the equation.
Anyways, when I talk about mental health and hacking, over the last 30 years I have enough scars to tell you what NOT to do. To make this article more useful, let me put a positive spin on what I have learned in that time as I have self-actualized a career in security (de)engineering:
Take breaks
Get up. Move around. Sitting for hours upon hours without doing this is not only bad for your physical health, but it also stifles your mind and reduces your ability to think more creatively.
Get sleep
If API bug bounty is a side hustle, remember you have another life of school, work, or what have you. And if you are doing it full time, you need to get away from it. You NEED to take time to sleep. You make too many mistakes when you are tired and can miss stuff.
Imposter syndrome is a real thing.
There will always be people better than you. And that’s OK. Feeling this way means you are stepping out of your comfort zone and evolving into your next-level self. Don’t fret about others. Only worry about yourself. Are you improving? Then you’re winning.
Don’t fear it when others say it can’t be done
It can be a real mindf*ck when someone you respect tells you something can’t be done. Everything is impossible until someone actually does it. Trust your gut. If you are wrong, learn from it. If you’re right, embrace it.
Adjust your expectations
I think people get overly stressed because they compare themselves to other hunters, or worse think they are just as good as the million-dollar hackers HackerOne and BugCrowd like to brag about. Dial it back. Be honest with yourself. Set reasonable goals. Don’t fret about making 6 figures hacking APIs until you are consistently finding stuff. Remember MOST hackers are only making about $20,000/year doing it part-time. Those of us making more than that didn’t get there overnight.
#4 – Understand the business economics of Bug Bounties
Since we are talking about money, one last thing to consider is that about the business economics of bug bounties.
There is a great article Codingo wrote on BugCrowd called The Shocking Truth You May Not Know About Being A Full-Time Bug Hunter. I highly recommend you check it out.
To summarize, there are several variables that can affect your outcome as a bug bounty hunter. You need to be clear about the Expected Value, and know what your Burn Rate is.
Expected Value
Expected Value (EV) is focused on the ability to forecast what you can expect to make based on measures of how you are actually doing. If you are averaging a bounty of $1,000 per bug, and each bug takes you somewhere in the neighborhood of 16 hours to find, you can expect an EV somewhere in the neighborhood of $62.50/hr.
Burn Rate
Burn Rate is focused on how much you spend each month, and how quickly you will consume savings without making any money. These are your living expenses. Internet costs. Subscription fees for tools like Burp Suite. It’s all the costs to live, breathe and hunt.
And don’t forget taxes. The government wants its share.
It all adds up.
Knowing your Burn Rate and your Expected Value allows you to forecast a cash runway report. This is an easy-to-follow key performance indicator (KPI) that will tell you when you will run out of money. You really should have at minimum 3 to 6 months of cash runway in the bank at all times. This gives you the flexibility to deal with bounty droughts and allows you the freedom to take breaks when you need them.
More importantly, having a clear understanding of your bounty economics and having enough money in the bank lets you feel confident that you’re starting to find a sustainable approach to making a good living.
Conclusion
So, when should you give up on a bug bounty target API? The answer is: it depends.
You need to take into account your own skillset, the economics of bug bounties, and how much time you’re willing to invest in finding bugs. If you find that you’re constantly encountering roadblocks and not making significant progress, it might be time to move on.
But don’t forget — bug hunting is also about learning, so don’t be afraid to try new things and experiment with different techniques as you hunt for your API bug bounty. The most successful hunters are always evolving and expanding their knowledge base to find new bugs.
Want more resources for API hacking? Make sure you check out my Beginner’s Guide to API Hacking and download my free PDF of the Ultimate Guide to API Hacking Resources for more guidance, articles, and books.
Hack hard!
The post The Bug Bounty Dilemma: When to give up on an API target appeared first on Dana Epp's Blog.
*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/the-bug-bounty-dilemma-when-to-give-up-on-an-api-target
