Why in Ukraine there are still white hackers

This article will be a response to the recent publication of Vladimir Taratushka.
I had several reasons for writing this article.
The first is to show that there are white hackers in Ukraine. They exist thanks to one of the vulnerability search promotion programs that Privatbank has been conducting .
The next reason is to tell your success story of work with one of the largest banks in Ukraine under this program.
I also want to show the effectiveness of such a program with a real example and encourage those companies that for some reason doubt or don’t see any real advantages in organizing such programs.
And the last reason is to show future and present managers that participation in bug-bounty programs is interesting, ethical and financially beneficial.

I do not consider myself a professional hacker, I do not have a security education profile, I do not have certificates, I have not read the Talmud TCP / IP protocol specifications, and I have not participated in hackathons and other professional hacker competitions. At the same time, I have experience in programming and writing various web services in PHP, Python, and Java. And I roughly understand where programmers usually make mistakes and which aspects of security are ignored when developing web applications. For me, this is enough to successfully find the vulnerabilities of the most critical level.

At the moment, my experience as a receiver is 3 years. That is how much time I take part in the vulnerability search program of PrivatBank.

From the very beginning I kept records of all the vulnerabilities found. I saved in a separate file a detailed description of the vulnerability, mode of reproduction, screenshots of confirmation. The latter help, if for some reason the developers of the bank fail to reproduce the vulnerability, or it turns out to be closed by another update before the start of the check. Some time later, I began to fill in the file the time of application, fix time, the amount of remuneration. Because of this, I have some statistics with which I would like to introduce you today.
')
So, at the moment I have collected statistics on 55 vulnerabilities I have declared, all of which are currently closed.

According to statistics on application status, the picture is as follows:



As you can see, most applications are accepted for work. Some vulnerabilities were not reproduced by the developers of the bank due to their complexity or because at the time of how the vulnerability was taken into operation, this service was radically rewritten. There were also duplicates, but as a rule they were simple, easily detectable vulnerabilities. N / A - this means that for some reason I did not save the results for this application. All applications with “accepted” status were eventually closed and rewards were paid for them.

Type of vulnerability / attack classification OWASP:

According to the classification of vulnerabilities it can be seen that the most common type is Broken Access Control. These are the vulnerabilities that allow unauthorized access to be obtained by simply iterating through the values ​​that specify the user id or operation. The reason is that such vulnerabilities are the easiest to detect and they are the result of errors in the application architecture. Since a bank is a complex system of numerous internal subsystems interacting with each other, such as back-office, processing, antifraud, this imposes certain difficulties on the implementation of the interaction of the web application with these systems within the framework of the end-user rights of the service. This leads to the emergence of such vulnerabilities as access to statements on the cards of other users, access to private data and, ultimately, access to funds of users.

It is also certain that the imprint on this rating is put off by my personal preferences and the set of knowledge that I possess and which I use when searching for vulnerabilities.

Type of information received or access in case of exploitation of a vulnerability:



As can be seen from the statistics, most often it was possible to gain access to private data (full name, passport data, card numbers, phone numbers, addresses), financial data (account balance, statement, etc.), accounts in different services (usually due to XSS or Open Redirect) and, which is not unimportant, in 1 of 5 cases access to the financial means of other users.

Fix time This is a conditional value. Since I did not have information about the exact time of closing the vulnerability, I took the time that passed from the moment of filing the application to the notification of the planned payment of remuneration.



As you can see, most often the alert came within 2 months, but sometimes there was no response for 3-4 months for some vulnerabilities.

And of course, the most interesting moment for researchers is the average amount of remuneration on closed applications. I'll warn you right away that the amount of the remuneration was not tied to the dollar exchange rate until mid-2015, so for some time it decreased in dollar terms due to the rapid growth of the dollar exchange rate to the hryvnia.



As you can see, most often the amount of remuneration falls in the range of $ 50-500.

Now for some details. Below, I have compiled a long list with a brief description of each vulnerability, so that we can get a rough idea of ​​the criticality of each of them:


Thus, analyzing the criticality of the above vulnerabilities, you can evaluate the effectiveness of this program for the bank.

And finally, I would like to dispel the persistent, but erroneous opinion of many that it is better not to work with PrivatBank, since they can be accused of hacking, as was described in the story with Alexei Mokhov .

The main principle of a white hacker is ethical. The search for vulnerabilities should be conducted exclusively on the accounts and accounts of the “burglars” themselves or their relatives / friends / acquaintances with their personal permission. Also, if the vulnerability was searched for within the framework of the bug-bounty of the program, it should be disclosed only after its closure and only with the permission of the owner of the resource on which it was found. Then all your actions will not be carried out to the detriment of the company and will not violate the law, and therefore there will be no complaints against you, as a researcher.