Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
Surely you've heard the expression "bug hunting" many times. I dare to assume, you won't mind earning one or two hundred (or even thousand) dollars by finding a potential vulnerability in someone's program. In this article, I'll tell you about a trick that will help analyzing open source projects in order to find such vulnerabilities.
Bug Bounty is a common name for various programs, where website and software developers offer cash rewards for finding bugs and vulnerabilities. In addition to well-known Bug Bounty programs from such large corporations, as Apple or Microsoft, there are also programs for searching vulnerabilities in open source projects.
Many of them can be found on HackerOne, but perhaps the largest is FOSSA - Free and Open Source Software Audit. It's a program on searching vulnerabilities in various open source projects, sponsored by the European Union. The total prize fund is an impressive sum - as much as 850,000 euros!
First, you need to register on HackerOne. We'll need only open source projects. There is a whole list on HackerOne.
If you'd like to take part in Bug Bounty from the European Union, the list of projects, participating in this program, can be found here. For most projects, it will be enough to be registered on HackerOne, but many of listed programs are also on the intigriti.com website.
To participate, you have to choose an appropriate project for yourself and then carefully read the terms of participation. If you agree with them, go to a practical part.
To find a vulnerability and get your money, you'll just need to download a project (or clone it from GitHub) and thoughtfully analyze each code line, examining each expression for potential errors. If you find something, that can affect program security - make a report and send to developers. If they rate your finding as worthy to be rewarded - you have your money in your pocket :).
The simple part is that you don't have to analyze the code only manually. There are tools that let you search for errors in code automatically. For example - static code analyzers. I prefer using our tool - PVS-Studio. PVS-Studio analyzer is able to find errors in code, written in C++, C# and Java, as well as has a user-friendly interface. In addition, there are several options of its free usage. Anyway, there are other various code analyzers.
Of course, static analyzers can reveal not all errors. Never mind! After all, we have a purpose to find errors quickly and easily, and not to find them all.
Once the project is downloaded and built, it will take only a couple of clicks to start the analysis. The result will be a report with some (usually considerable) number of warnings generated by the analyzer. In PVS-Studio, they are classified into three levels of certainty. You should start with the first level of warnings, so the orange and yellow levels can be weeded out from the analysis result.
An example of filtering the results of the analysis. You can click on the picture to enlarge.
Thus, you'll only need to look though the rest warnings and choose the places that may pose the greatest danger. It is worth checking whether it is possible to reproduce any of them directly when running the program. If you manage to do it - it will not only increase the chances that developers will accept the report, but also certainly increase the amount of payment. In this case, visibility is your best friend.
It's also worth considering whether the bug you found affects the security of the program. After all, in this case, the amount paid to you will be several times more :)
The screenshot shows the Visual Studio interface. However, don't let it mislead you. The analyzer can be used not only as a plugin for Visual Studio, but also on its own, including the Linux and macOS environments.
First, using a static analyzer is one of the easiest ways to find bugs. You don't have to have any special knowledge to use code analyzers: you just need to understand the language in which the code is written.
Secondly, analyzers are attentive. They don't get tired and don't lose their vigilance, unlike a human being. Therefore, they can be used to analyze as large code bases as you like with almost minimal cost.
Third, analyzers often have more knowledge than humans. What does it mean? Let me explain my thoughts with the example from the Android kernel code:
static void FwdLockGlue_InitializeRoundKeys() {
unsigned char keyEncryptionKey[KEY_SIZE];
....
memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data.
}It would seem, where's an error here?
It turns out, that a compiler, seeing that an array isn't used anywhere else, can optimize the code and remove the call of the memset function from it. And it'll do it only when building the release configuration. Everything would be fine, but only the encription key will remain in the RAM uncleared for some time, this way it can be obtained by an intruder. That's a real breach is safety!
In addition, it can be hardly found by yourself: in the debugging mode the call of memset works fine. Tests also won't be of help... The only thing that remains is to be aware and remember about this feature yourself.
What if the project developers don't know about this feature? What if you don't know about this feature when you search for bugs? As for the analyzer, it has the V597 diagnostic, so you'll definitely find out about this feature when viewing the report.
Finally, the fourth point. One of the most useful advantages of using static analysis when chasing for Bug Bounty is speed. It's true that you can check two, three, four project in one evening - but that's not all.
The main thing is that you can be the first. While the award is offered for finding bugs in any project, the project continues to be refined and developed. Developers ship new releases and new features along with new code and new space for errors. When using the approach I've described, you'll be able to targetedly consider new errors and potential vulnerabilities in the very first day they're released.
An attentive reader may be puzzled:
Wait, wait! On the one hand, you're saying about searching for errors in code in programs, on the other hand - you're mentioning potential vulnerabilities. Vulnerabilities are more interesting in terms of Bug Bounty. Please, clarify what you mean!
The fact of the matter is that errors and potential vulnerabilities are basically the same thing. Sure, only a few errors/potential vulnerabilities prove to be real vulnerabilities in further research. However, a harmless blunder and crucial vulnerability might look exactly the same in code. The article "How Can PVS-Studio Help in the Detection of Vulnerabilities?" gives several seemingly common bugs that are now known to be vulnerabilities.
By the way, according to the report by National Institute of Standards and Technology (NIST), about 64% of vulnerabilities in applications relate to software errors, not issues directly related to security.
So grasp the nettle, get PVS-Studio and start searching for errors and safety flaws! Classification according to the CWE will be of great help here.
Hopefully, I helped a reader in his searching for that very bugs that will bring him honoring and monetary reward. I'm sure that static analysis will help in this! Remember that developers usually don't have time to analyze bugs in detail, so you'll have to prove that your finding can actually affect the program. The best way is to visually reproduce it. And remember: the more the bug destructs security - the more you'll get paid for it.
Well, that's it. Good luck in searching for a reward!
0
0
0
0