eval.blog

Coping with Burnout as a Security Researcher

Coping with Burnout as a Security Researcher

The Burnout

Hacking has always been fun for me and I never really considered it as a career. I knew about bug bounties as well as the exploit market. I knew some people in the Whitehat community and could pursue a career in the security field quite easily. But somehow I ended up being a backend developer. Nonetheless, I succeeded as a developer and learned a lot about PHP and the server side. But the 2020 pandemic forced me to leave the job and do bug bounties. Sure I was in luck that my experience helped me find valid bugs and report them on HackerOne.

After several successful reports, it occurred. Somehow, I was no longer finding any bugs. I was (and still am) in this phase of feeling drudgery and boredom while doing bug bounties. Hacking was never boring to me, but bug bounties are making me feel like I am not giving my best. After reading a lot of articles, watching some talks on YouTube and talking to the community about burnout, I realized why not many people succeed in the bug bounties.

This article has been updated and posted in a new title while the Disclosure of CVE-2021-27902 and CVE-2021-27903 have been moved to a new article.

The Real Problem

You see, hacking is hard. It gets easy when you know what you are doing. Most people do not even know what they want. Money is complimentary. The real prize that you want is to have that adventure of hacking. The problem occurs when you try to look for money but money comes from the vulnerabilities you report. But you are not looking for the vulnerabilities, you are after money. Money is important. But you can't find money in HTTP responses.

Another thing that people miss is that they keep digging without any hint. It's like a treasure hunt. You need to find hints to find the treasure. But what if there is no hint? Would you be digging holes in someone's backyard or park blindly just to find a treasure chest that you don't even have any clue whether it exists or not?

Sometimes, people fail to completely understand bug bounty hunting. Lemme explain in brief.

From a company's perspective, bug bounty hunting can be seen as a testing strategy, a marketing stunt, or a way to shut mouths. But as a researcher, we are more interested in the testing strategy. Bug hunting is just a buzzword that means testing. The bug hunters do monkey testing or gorilla testing or both to find security vulnerabilities and report them. There is a catch though. Monkey and gorilla testing in bug bounty hunting is done on the user level ie. on the final product. The tester is not given a full understanding of what the software does. The tester ie. the bounty hunter tries to find patterns in the illusion of outputs to understand what the software is doing under the hood.

Sometimes, source code is provided. This is where whitebox testing comes into play. Whitebox testing is kinda clean. Tester is provided the source code, he dissects the source code and tries to find vulnerable code. This is quite advantageous. But then, You need to know how code works. To be a hacker, programming is necessary. Hackers do testing but testing is not hacking. Those who tell you that they hack but don't know programming are simply lying to you. Either they know programming or they are not hacking. A hacker may not know any computer language, but they see the logic behind and the underlying patterns and that is programming. A hacker is someone who sees how an action is being done and takes advantage of that to perform another action ie. reprogram software not rewrite it. Tools and utilities are complementary, not necessary. But understanding the logic is the basis of programming as well as hacking and is a must.

The Buzz Word

Another reason why people don't succeed in bug bounties is the frustration of duplicates and N/A. The reason why you mostly find duplicates or N/A is not because you are reporting low-hanging bugs but because you are reporting bugs and not vulnerabilities. Lemme explain.

With the bug bounty boom, people are more relatable with the buzzword "Bug Hunting" rather than the testing or auditing and the exploits are "surprisingly" known as bugs. The problem with this "Bug" word is that a bug can be anything. From a for loop missing the last iteration to an overflow that led to an RCE. An unrestricted file upload is a bug, but uploading a shell to execute code is a vulnerability. The exploits utilize bugs, but bugs are not exploits. Bugs are faults in the software. Exploits, on the other hand, are security vulnerabilities. Depending on how many people know it, the exploits are labeled as zero days, 1-day or n-day ie. known exploits are not zero days and zero days are not known and bugs are not exploits but exploits are built on top of those bugs.

Coming back to burnout, what companies are doing with bug bounties is that they are giving you a target and asking you to report the bugs in that target. Now when you report any kind of bugs without enough impact, they can say these bugs are not impactful. So they will not fix them. Since they are not fixing the bugs but expecting a bug, they are creating a dilemma for the newcomers. What to consider a bug and what to not. A simple way to come out of it is to see every bug as a bug. And not call them bugs when they are security vulnerabilities. There is a difference and that difference defines what is impactful and what is not. A bug can be a security vulnerability. But a security vulnerability is a bug. It is all about treating the bugs as bugs and vulnerabilities as vulnerabilities. XSS is a vulnerability, not a bug. Unfiltered Input is a bug.

Let's combine this new perspective with our treasure hunt analogy. The hints you need to find treasure are bugs. But the treasure is not a bug nor a bounty but a successful exploitation of a vulnerability. Using the bugs, you have to perform exploitation.

Another thing, they won't even pay for a theoretical vulnerability. You need to prove it by exploiting it to a reasonable limit. Found an XXE, can you pop a shell? Found an XSS, can you steal the cookies? Found a leak, is it PII? Found an access token in a public repo, can you log in with them? Found an open redirect, can you take over the account? Found a potential subdomain takeover, well go ahead and take over that subdomain.

So instead of reporting bugs, you should try to successfully exploit the bugs that can result in something impactful without going beyond the policy of course. That is known as chaining. Chaining those bugs, you can find other bugs that can give something impactful. But be cautious of the thin line and not damage anything while going up the chain and stay within the policy.

The wrong start

I believe, there is no wrong, no right but a matter of perspective. And from my perspective, people often start wrong as they jump right onto the black box testing aka bug bounty hunting on end products and don't care to understand what is happening behind the curtain. As I said before, you must learn to program to become a hacker. There is no way around this. Many celebrities will tell you how they became a hacker without writing a single line of Python. Hey, you were not writing a line of Python but were you a hacker at that time? And now that you are a hacker, did you still not learn at least one language? In the end, did any real hacker called you a hacker?