Home From Burnout to RCE: Getting out of the rat race
Post
Cancel

From Burnout to RCE: Getting out of the rat race

Burnout is just the stress you are facing. This stress is normal when you work a lot but reach nowhere. It is like running in the rat race and trying to compete with other hunters for the money. The first one takes the prize and burnout is natural.

This article has been divided and the Disclosure of CVE-2021-27902 and CVE-2021-27903 has been moved to a new article.

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 whitehat community and could pursue a career in the security field quite easily. But somehow I ended up being a backend developer. None the less, I succeeded as a developer and learned a lot about PHP and 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 is 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 on burnout, I realized why not many people succeed in the bug bounties.

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 complementary. 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. Its 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 a brief.

From a company’s perspective, the 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 buzz word 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 actually does. The tester ie. the bounty hunter tries to find patterns in the illusion of outputs to understand what the software is actually 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. In fact, 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. Hacker is someone who sees how an action is being done and take advantage of that to perform another action ie. reprogram a software not rewrite. 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 buzz word “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 labelled as zero day, 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 the 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 bug. And not call them bug when they are security vulnerability. 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 an 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 access token in public repo, can you login 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 ofcourse. 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 to 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 blackbox 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 hacker (not the larps) called you a hacker?

This post is licensed under CC BY 4.0 by the author.