Easy way to make money on Bug Bounty

Surely you have already heard the expression “baghunting” more than once, and I’m sure that you wouldn’t refuse to earn a couple of hundreds (or even thousands) of dollars if you found a potential vulnerability in someone else’s program. In this article, I will talk about a trick that will help research open source projects for such vulnerabilities.

Bug Bounties on Free and Open Source Software - what is it?

Bug Bounty is the common name for various programs in which website and software developers offer cash rewards for finding bugs and vulnerabilities. In addition to the well-known Bug Bounty programs from large corporations such as Apple or Microsoft, there are also programs for finding 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. This is a program to search for vulnerabilities in various open source projects sponsored by the European Union. The total prize pool is an impressive amount - as much as 850,000 euros!

How to take part?

First you need to register at HackerOne . We will need exactly those projects that are open source. HackerOne has a whole list .



If you want to participate in the Bug Bounty from the European Union - a 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 the programs listed in that list are on intigriti.com.



To take part, you need to choose a project suitable for yourself, and then carefully read the conditions of participation. If they satisfy you, then it is time to practice.



To find the vulnerability and get your money, you just need to download the project (or clone it from GitHub) and carefully analyze each line of code, examining each expression for potential errors. If you find anything that could affect the security of the program - write it in a report and send it to the developers. If they evaluate your find as worthwhile, your money is in your pocket :).

Wait, where's the lightness?

And the ease is that analyzing the code exclusively by hand is not necessary at all. There are tools to search for errors in the code in automatic mode. For example, static code analyzers. I prefer to use our development - PVS-Studio . The PVS-Studio analyzer is capable of detecting errors in code written in C ++, C # and Java, and also has a convenient interface. In addition, there are several options for its free use. There are also many other code analyzers .



Of course, static analyzers can detect far from all errors. Yes, and God bless them! After all, our goal is to find mistakes quickly and easily, and not to find them all.



After the project is downloaded and assembled, it will be enough to make only a couple of clicks to start the analysis. Its result will be a report with some (usually a considerable) amount of warnings generated by the analyzer. In PVS-Studio they are classified into three levels of confidence. You should start with the first level warnings, so the orange and yellow levels can be filtered from the analysis result.

An example of filtering analysis results.



Thus, it remains only to review the remaining warnings and select from them those places that may constitute the greatest danger. It is necessary to check whether it is possible to reproduce any of them directly during the operation of the program. If you succeed in doing this, it will not only increase the chances that the developers will accept the report, but it will also increase the amount of payment. In this matter, visibility is your best friend.



It is also worth considering whether the error found affects the security of the program. Indeed, in this case, the amount paid to you will be several times larger :)



The screenshot shows the Visual Studio interface. However, do not be fooled by this. The analyzer can be used not only as a plug-in for Visual Studio, but also independently, including in Linux and macOS .

Pros of this approach

Firstly, using a static analyzer is one of the easiest ways to find errors. To use code analyzers, it is not at all necessary to have any special knowledge: you just need to understand the language in which the tested code is written.



Secondly, the analyzers are careful. They do not get tired and do not lose vigilance, unlike a person. Therefore, using them you can analyze arbitrarily large code bases with almost minimal cost.



Thirdly, analyzers often have more knowledge than a person. What does it mean? Let me explain my idea on the example of code from the Android kernel:

static void FwdLockGlue_InitializeRoundKeys() { unsigned char keyEncryptionKey[KEY_SIZE]; .... memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

It would seem where there might be a mistake?



It turns out that the compiler, seeing that the keyEncryptionKey array is not used anywhere else, can optimize the code and remove the memset function call from it. And he will do this only during assembly in the release configuration. Everything would be fine, but only the encryption key for some time will remain unlocked in the RAM, so that it can be obtained by an attacker. A real security hole!



And after all, finding this error yourself is almost impossible: in debug mode, the memset call works fine. And you won’t write any tests for this ... It remains only to know about this feature and remember it yourself.



But what if the developers of the project do not know about this feature? What if you don’t know about this feature when searching for bugs? This is not important for the analyzer, because it has the V597 diagnostics, therefore, when viewing a report, you will definitely know about it.



Finally, fourthly. One of the most useful benefits of using static analysis when chasing a Bug Bounty is speed. Yes, with it you can check two, three, four projects in the evening - but that’s not all.



Most importantly, you can be the first. While a reward is offered for finding bugs in any project, the project continues to be finalized and developed. Developers roll out new releases and new features, and with them come new code and new open spaces for errors. Using the approach described by me, it will be possible to accurately examine new errors and potential vulnerabilities on the very first day of their publication.

Potential vulnerabilities

The attentive reader may be puzzled:



Stop, stop! On the one hand, it refers to a search in the code for errors in programs; on the other hand, potential vulnerabilities are mentioned. Moreover, vulnerabilities are more interesting from the point of view of Bug Bounty. Please clarify!



The fact is that errors and potential vulnerabilities are essentially the same thing. Of course, only a few errors / potential vulnerabilities in further research can turn out to be real vulnerabilities. However, a harmless blooper and a serious vulnerability can look exactly the same in the code. The article “ How can PVS-Studio help in searching for vulnerabilities? ” Presents several such (at first glance ordinary) errors that are now known to be vulnerabilities.



By the way, according to the report of the National Institute of Standards and Technology (NIST), about 64% of vulnerabilities in applications are associated with software errors, and not with security deficiencies (not a lack of security features).



So confidently pick up PVS-Studio and start looking for bugs and security defects! By the way, the classification of warnings according to CWE will help you with this.

Conclusion

I hope I helped the reader in finding the very bug that would bring him a little recognition and monetary reward. I am sure that static analysis will help them with this! Remember that developers, as a rule, do not have time for a detailed analysis of the errors found, so you still have to prove that your find can really affect the program. The best way would be to visualize it. And remember: the stronger the bug in the code can violate security, the more they will pay for it.



That’s probably all. Good luck finding your reward!

If you want to share this article with an English-speaking audience, then please use the link to the translation: George Gribkov. An Easy Way to Make Money on Bug Bounty .