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. Whitebox testing combined with a blackbox testing can yield impactful exploits which you couldn't find with only blackbox 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 own way of starting. But if you are stuck in blackbox testing or maybe you wanna learn code review. Either way, I will explain how to do greybox testing my way. Note that this is not a set methodology of doing things. It is just how I do it.
- Choose a target software.
- Install it or get an installed instance (the one you have permissions to hack kek)
- Find potential vulnerable code like functions with system calls, file handles, vulnerable inputs and their outputs.
- Find inputs that can allow you to inject payloads to that potential code.
- Exploit the vulnerabilities and write a PoC.
- Report the vulnerability.
Choosing a Target
Choosing a target for greybox testing is completely dependent over your language of choice and having the environment for installing the software. For example, If you know JavaScript, very likely you will be auditing a software that heavily uses JavaScript. But if you know swift but do not have any Mac to run that code, you cannot test it.
Finding targets
Bug Bounty Platforms : Targets can be found in many bug bounty platforms. But there are not many companies which have their code as open source to allow a third party tester like you to test it. You can find them with the "Source Code" tag in bug bounty platforms.
Self Hosted Bug Bounty Programs : Many companies run their own bug bounty program which are not so popular. You can find them on the company's website or using some public databases like (disclose.io)[https://disclose.io/].
Open Source Software : The best possible target for whitebox 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 own 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 its 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 the 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 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 to look 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 its 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 bug bounty program ie. they don't pay. If that is the case, you can either earn a good will or submit your report via a third party like Huntr.dev. 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 personally 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 own bug bounty program on Huntr.dev.