Why are there still white hackers in Ukraine
This article will be a response to a recent publication by 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 programs to promote vulnerability search, which is carried out by Privatbank.
The next reason is to tell your success story of working with one of the largest bank in Ukraine within the framework of this program.
I also want to show the effectiveness of such a program using a real example and encourage companies that doubt or don’t see real advantages in organizing such programs.
Well, the last reason is to show future and present reviewers that participation in the bug-bounty programs is interesting, ethical and financially beneficial.
I do not consider myself a professional hacker, I do not have a specialized education in the field of security, I do not have certificates, I have not read the Talmud specification of the TCP / IP protocol and I have not participated in hackathons and other competitions of professional hackers. At the same time, I have experience in programming and writing various web services in PHP, Python, Java. And I roughly understand where programmers usually make mistakes and what aspects of security are ignored when developing web applications. This is enough for me to successfully find vulnerabilities of the most critical level.
At the moment, my experience as a reviewer is 3 years. That is how much time I take part in the PrivatBank vulnerability search program.
From the very beginning, I kept track of all the vulnerabilities found. I saved in a separate file a detailed description of the vulnerability, the playback method, confirmation screenshots. The latter ones help if, for some reason, the bank’s developers are unable to reproduce the vulnerability, or it turns out to be closed by the next update before the test begins. After some time, I began to file the time of application submission, fix time, and the amount of the fee. Thanks to 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 statuses, 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 because of their complexity or because at the time the vulnerability was taken to work, this service was radically rewritten. There were duplicates, but usually 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 the status of “accepted” were eventually closed and fees were paid for them.
Type of vulnerability / attack according to OWASP classification:
The vulnerability classification shows that the most common type is Broken Access Control. These are the vulnerabilities that allow unauthorized access by a simple enumeration of the inertial values that specify the user id or operation. The reason is that such vulnerabilities are easiest to detect and they are the result of errors in the application architecture. Since the 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 rights of the end user of the service. This leads to the appearance of vulnerabilities such as access to statements on the cards of other users, access to private data and, ultimately, access to users ’financial means.
Also, my personal preferences and the set of knowledge that I possess and which I use when searching for vulnerabilities set aside the mark on this rating.
Type of information or access obtained in case of exploitation of the vulnerability:
According to statistics, most often it was possible to gain access to private data (name, passport data, card, phone, address), financial data (account balance, statement, etc.), accounts in different services (usually due to XSS or Open Redirect) and, not least, in 1 out of 5 cases, access to the funds of other users.
Fix time. This is a conditional quantity. Since I did not have information about the exact time the vulnerability was closed, I took the time that passed from the moment of application submission to the notification of the planned payment of remuneration.
As you can see, most often the notification came within 2 months, but sometimes for some vulnerabilities there was no answer for 3-4 months.
Well, of course, the most interesting point for researchers is the average amount of remuneration for closed applications. I’ll warn you right away that the amount of interest 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 against the hryvnia.
As you can see, most often the amount of remuneration falls into the range of $ 50-500.
Now a few details. Below I have compiled a long list with a brief description of each vulnerability, so that an approximate idea of the criticality of each of them can be made:
Thus, by 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 the white hacker is ethics. The search for vulnerabilities should be carried out exclusively on the accounts and accounts of the “crackers” themselves or their relatives / friends / acquaintances with their personal permission. Also, if a vulnerability search was carried out as part of a bug-bounty program, it is worth disclosing information only after it is closed 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.
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 programs to promote vulnerability search, which is carried out by Privatbank.
The next reason is to tell your success story of working with one of the largest bank in Ukraine within the framework of this program.
I also want to show the effectiveness of such a program using a real example and encourage companies that doubt or don’t see real advantages in organizing such programs.
Well, the last reason is to show future and present reviewers that participation in the bug-bounty programs is interesting, ethical and financially beneficial.
I do not consider myself a professional hacker, I do not have a specialized education in the field of security, I do not have certificates, I have not read the Talmud specification of the TCP / IP protocol and I have not participated in hackathons and other competitions of professional hackers. At the same time, I have experience in programming and writing various web services in PHP, Python, Java. And I roughly understand where programmers usually make mistakes and what aspects of security are ignored when developing web applications. This is enough for me to successfully find vulnerabilities of the most critical level.
At the moment, my experience as a reviewer is 3 years. That is how much time I take part in the PrivatBank vulnerability search program.
From the very beginning, I kept track of all the vulnerabilities found. I saved in a separate file a detailed description of the vulnerability, the playback method, confirmation screenshots. The latter ones help if, for some reason, the bank’s developers are unable to reproduce the vulnerability, or it turns out to be closed by the next update before the test begins. After some time, I began to file the time of application submission, fix time, and the amount of the fee. Thanks to 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 statuses, 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 because of their complexity or because at the time the vulnerability was taken to work, this service was radically rewritten. There were duplicates, but usually 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 the status of “accepted” were eventually closed and fees were paid for them.
Type of vulnerability / attack according to OWASP classification:
The vulnerability classification shows that the most common type is Broken Access Control. These are the vulnerabilities that allow unauthorized access by a simple enumeration of the inertial values that specify the user id or operation. The reason is that such vulnerabilities are easiest to detect and they are the result of errors in the application architecture. Since the 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 rights of the end user of the service. This leads to the appearance of vulnerabilities such as access to statements on the cards of other users, access to private data and, ultimately, access to users ’financial means.
Also, my personal preferences and the set of knowledge that I possess and which I use when searching for vulnerabilities set aside the mark on this rating.
Type of information or access obtained in case of exploitation of the vulnerability:
According to statistics, most often it was possible to gain access to private data (name, passport data, card, phone, address), financial data (account balance, statement, etc.), accounts in different services (usually due to XSS or Open Redirect) and, not least, in 1 out of 5 cases, access to the funds of other users.
Fix time. This is a conditional quantity. Since I did not have information about the exact time the vulnerability was closed, I took the time that passed from the moment of application submission to the notification of the planned payment of remuneration.
As you can see, most often the notification came within 2 months, but sometimes for some vulnerabilities there was no answer for 3-4 months.
Well, of course, the most interesting point for researchers is the average amount of remuneration for closed applications. I’ll warn you right away that the amount of interest 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 against the hryvnia.
As you can see, most often the amount of remuneration falls into the range of $ 50-500.
Now a few details. Below I have compiled a long list with a brief description of each vulnerability, so that an approximate idea of the criticality of each of them can be made:
Vulnerability Table
No. | Domain | Vulnerability / Attack Type (OWASP) | Type of access | Short description |
---|---|---|---|---|
1 | privat24.privatbank.ua | Broken access control | Private data | Getting critical data from any card |
2 | privat24.privatbank.ua | Broken access control | Private data | Access to user payment archive |
3 | privat24.privatbank.ua | Broken access control | Private data | Access to users' private data (name, passport data, balance and debt) |
4 | privat24.privatbank.ua | Broken access control | Private data | Access to private user data (full name, passport data, mother's maiden name) |
5 | privat24.privatbank.ua | Broken access control | Financial data | View statements by card number |
6 | privat24.privatbank.ua | Broken access control | Financial operations | Payment sms mailing from someone else's card |
7 | liqpay.com | Broken access control | Financial data | Customer Payments Data |
8 | napi.privatbank.ua | Broken access control | Private data | Getting critical data from someone else’s internet card |
9 | napi.privatbank.ua | Broken access control | Financial data | Buying auto / train tickets by someone else's card |
10 | privat24.privatbank.ua | Broken access control | Financial operations | Creating a regular payment by someone else's card |
eleven | pcalendar.privatbank.ua | Broken access control | Financial operations | Change the status of any recurring payment, re-create, even if it was deleted, view data on it |
12 | siteheart.com | Session Variable Overloading | Account Access | Full access to any siteheart.com account |
thirteen | privat24.privatbank.ua | CSRF | Private data | Connecting your phone to SMS informing about operations with a foreign card |
14 | privat24.privatbank.ua | Broken access control | Financial operations | Creating a regular payment by someone else's card |
fifteen | cards.privatbank.ua | Xss | Account Access | Theft of cookies by an authorized user |
16 | privat24.privatbank.ua | Broken access control | Financial operations | Mass recharge of mobile phones from someone else's card |
17 | ecommerce.liqpay.com | Broken access control | Financial operations | Payment from someone else's card when paying for services on the site of a merchant connected to PrivatBank |
18 | privat24.privatbank.ua | Broken access control | Private data | Receiving phone numbers connected to the SMS-notification service for any PrivatBank card |
19 | privat24.privatbank.ua | Broken access control | Private data | View information on utility payments of privat24 customers (name, address of residence, mobile phone, debt) |
20 | pcalendar.privatbank.ua | Broken access control | Financial data | Balance on any PrivatBank card |
21 | pcalendar.privatbank.ua | Broken access control | Financial operations | Creating a regular payment by someone else's card |
22 | pcalendar.privatbank.ua | Broken access control | Financial operations | Creating a regular payment by someone else's card |
23 | privat24.privatbank.ua | Insecure configuration | Server data | Directory structure open |
24 | privat24.privatbank.ua | Broken access control | Modification operation | Getting and changing the Internet limit for any PrivatBank card |
25 | privat24.privatbank.ua | Broken access control | Financial data | View statements by card number, there are addresses and gps coordinates of ATMs and self-service terminals used by the client |
26 | privat24.privatbank.ua | Insecure configuration | Financial data | Google Checks Available |
27 | transfers.privatbank.ua | Broken access control | Financial data | Information on transfers to privat24 (PrivatMoney, Golden Crown, Unistream, Western Union, Contact, Coinstar and Swift) |
28 | privat24.privatbank.ua | Broken access control | Financial operations | Creating a regular payment by someone else's card |
29th | privat24.privatbank.ua | Broken access control | Private data | View information on utility payments of privat24 customers (name, address of residence, mobile phone, debt) |
thirty | privat24.privatbank.ua | Broken access control | Financial data | Information on applications for a credit rating in UBKI (full name, TIN, date of birth, credit rating, etc.) |
31 | client-bank.privatbank.ua | Broken access control | Financial data | Obtaining an acquiring statement for any PrivatBank merchant |
32 | client-bank.privatbank.ua | Broken access control | Passwords | Obtaining the password of any merchant registered in privat24 in acquiring. In addition to the password, a card number is available for receiving payments, client name, client website address, ip address, etc. |
33 | limit.pb.ua | Broken Authentication and Session Management | Private data | Detailed information on the client (name, card, phone number, date of birth, residential address, etc.) |
34 | privat24.privatbank.ua | Broken access control | Private data | Obtaining by card number, name, owner's name, phone number, card validity |
35 | socauth.privatbank.ua | Insecure configuration | Private data | Detailed information on the client (name, card, phone number, date of birth, residential address, etc.) |
36 | privat24.privatbank.ua | Broken Authentication and Session Management | Account Access | Repeatedly logging in to private24 using the generated link without entering a static and password reset even after the end of the user session |
37 | chat.sender.mobi | Xss | Account Access | Theft of cookies by an authorized user |
38 | msb.privatbank.ua | Xss | Account Access | Theft of cookies by an authorized user |
39 | mypayments.privatbank.ua | Broken Authentication and Session Management | Private data | Detailed information on the client (name, card, phone number, date of birth, residential address, etc.) |
40 | privat24.privatbank.ua | Broken Authentication and Session Management | Financial data | Statements on user cards. |
41 | liqpay.com | Broken Authentication and Session Management | Account Access | Weak user session protection during authorization via a call to a mobile phone |
42 | client-bank.privatbank.ua | Broken access control | Financial data | Statements for any terminal connected to acquiring. |
43 | client-bank.privatbank.ua | Broken access control | Financial data | View legal documents persons created using the document designer |
44 | chat.sender.mobi | Xss | Account Access | Theft of cookies by an authorized user |
45 | bank24.privatbank.ua | Xss | Account Access | Theft of cookies by an authorized user |
46 | blago.privatbank.ua | Broken access control | Financial operations | The vulnerability allows any registered user to replace the card of any other user with his own for receiving donations |
47 | client-bank.privatbank.ua | Broken access control | Financial data | Information on foreign contracts with foreign partners |
48 | client-bank.privatbank.ua | Broken access control | Private data | Information about users who have access to the specified account, namely login (sometimes this is a phone number), name, email. |
49 | privat24.privatbank.ua | Broken access control | Modification operation | Mass change (at least decrease) of credit limits on cards of PrivatBank customers |
fifty | nkk.privatbank.ua | Broken access control | Private data | Access to information that the client fills out when applying for a loan |
51 | privat24.privatbank.ua | Redirects and forwards | Account Access | Access to user account through token obtained through Open Redirect |
52 | client-bank.privatbank.ua | Broken Authentication and Session Management | Account Access | Access to the user account through the token obtained through the referer on the statistics site |
53 | client-bank.privatbank.ua | Redirects and forwards | Account Access | Access to user account through phishing using Open Redirect |
54 | client-bank.privatbank.ua | Broken Authentication and Session Management | Account Access | Access to the user account through the token obtained through the referer on the statistics site |
55 | client-bank.privatbank.ua | Broken access control | Financial data | Access to contracts with foreign partners of clients |
Thus, by 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 the white hacker is ethics. The search for vulnerabilities should be carried out exclusively on the accounts and accounts of the “crackers” themselves or their relatives / friends / acquaintances with their personal permission. Also, if a vulnerability search was carried out as part of a bug-bounty program, it is worth disclosing information only after it is closed 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.