Blackbox testing is great but if you are looking forward to learning how code works, this is where greybox testing comes in. Since you get access to the source code, you can see how code works and find vulnerabilities without bombarding your bests on a wall for nothing. White box testing combined with black box testing can yield impactful exploits which you couldn't find with only black box testing. If you are good enough, you can find some great zero days and sell them to zero-day acquisition companies like Zerodium and Zeroday Initiative for much much higher prices. Also, these zero days can be reported to the bug bounty programs and after the disclosure, the same zero-day becomes an n-day and many targets still have not fixed these common exploits that only you know of.

Starting gradually with Greybox Testing

Everyone has their way of learning. If you are stuck in black box testing, wanna learn code review or just want to see how I do it, here's my way of doing grey box testing. Note that this is not a set methodology of doing things. It is just how I do it.

1. Choose a target software.

2. Install it or get an installed instance (the one you have permission to hack kek)

3. Find potentially vulnerable code like functions with system calls, file handles, vulnerable inputs and their outputs.

4. Find inputs that can allow you to inject payloads to that potential code.

5. Exploit the vulnerabilities and write a PoC.

6. Report the vulnerability.

Choosing a Target

Choosing a target for grey box testing is completely dependent on your language of choice and the environment for installing the software. For example, If you know Swift, very likely you will be auditing software that heavily uses Swift. But if you do not have a Mac to run that code, you probably won't be able to test it.

Finding targets

Bug Bounty Platforms: Targets can be found in many bug bounty platforms. But there are not many companies that have their code as open source to allow a third-party tester to test. You can find them with the "Source Code" tag in bug bounty platforms.

Self-Hosted Bug Bounty Programs: Many companies run their bug bounty program which is not so popular. You can find them on the company's website or using some public databases like disclose.io.

Open Source Software: The best possible target for white box testing is Open Source Software. Yes if it is open source or free, you have a right to test it given you are not distributing the found vulnerabilities (which is also fine with some licenses, if my understanding of them is correct). You do not need a policy to break into your copy of code.

Installing it

Read the manual or documentation provided by the vendor.

Finding the vulnerable code

Depending on your target, there are many ways a vulnerability can exist in the code. From a system call function visible in plain sight to overflows hidden behind those off-by-one errors in for loops, there are plenty. You just need to be proficient in your language of choice and find vulnerabilities.

Finding inputs

These inputs can be found by following the code flow. You see, code has a flow and it runs from instruction to instruction. Even if it's multithreaded, object-oriented or event-driven, it still runs from one instruction to another line by line. This flow can be followed to the top where the human interface fills in the input and understand how it is processed down to the vulnerable code. If the payload reaches the vulnerable code, you might be able to exploit the vulnerability.

Exploiting and writing a PoC

While normal vulnerabilities are fine too, If you are hunting for zero days, you must try to reach the maximum impact like RCE or SQLi. So if you have found a smaller bug that can be chained, don't rush to report it. Try to escalate it to something bigger. Reading the code can give you a bigger view of what is possible. Also, writing a good proof of concept is as important as the report itself. A few days ago, I used a payload and reported the vulnerability. But then I forgot to give a clean payload in my report and the fixer couldn't reproduce the issue. Even a one-line report can go a long way if your PoC is precise.

Report the vulnerability

Before jumping into reporting the zero days, you should know whom to report. Usually, you wanna sell the vulnerability to the right buyer. First, understand how big a player your target is ie. see how many people use that code. Is the target being used by millions of people like WordPress? Or maybe it is only used by the company itself.

Zero-day Acquisition Companies: It is worth looking at the scope of Zero-day acquisition companies as well as getting in contact with them if you think your target is big enough. Even if it's not in their scope, they might accept it.

Bug Bounty Program: If your target runs a bug bounty program, you are in luck. There are chances that the maintainer of an open source program might be running a vulnerability disclosure program and not a bug bounty program ie. they don't pay. If that is the case, you can either earn goodwill or submit your report via a third party like Huntr.dev. As of 2021, Huntr.dev is a bug bounty platform that pays a significantly smaller amount of 40$ per report and 40$ for the fix but they pay for literally every valid report and every valid fix you submit. This is a good way to earn while you are learning. I see the potential in Huntr.dev to grow into something as big as HackerOne in the nearby future and maybe get some private companies to host their bug bounty program on Huntr.dev.