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:

    Vulnerability Table
    No.DomainVulnerability / Attack Type (OWASP)Type of accessShort description
    1privat24.privatbank.uaBroken access controlPrivate dataGetting critical data from any card
    2privat24.privatbank.uaBroken access controlPrivate dataAccess to user payment archive
    3privat24.privatbank.uaBroken access controlPrivate dataAccess to users' private data (name, passport data, balance and debt)
    4privat24.privatbank.uaBroken access controlPrivate dataAccess to private user data (full name, passport data, mother's maiden name)
    5privat24.privatbank.uaBroken access controlFinancial dataView statements by card number
    6privat24.privatbank.uaBroken access controlFinancial operationsPayment sms mailing from someone else's card
    7liqpay.comBroken access controlFinancial dataCustomer Payments Data
    8napi.privatbank.uaBroken access controlPrivate dataGetting critical data from someone else’s internet card
    9napi.privatbank.uaBroken access controlFinancial dataBuying auto / train tickets by someone else's card
    10privat24.privatbank.uaBroken access controlFinancial operationsCreating a regular payment by someone else's card
    elevenpcalendar.privatbank.uaBroken access controlFinancial operationsChange the status of any recurring payment, re-create, even if it was deleted, view data on it
    12siteheart.comSession Variable OverloadingAccount AccessFull access to any siteheart.com account
    thirteenprivat24.privatbank.uaCSRFPrivate dataConnecting your phone to SMS informing about operations with a foreign card
    14privat24.privatbank.uaBroken access controlFinancial operationsCreating a regular payment by someone else's card
    fifteencards.privatbank.uaXssAccount AccessTheft of cookies by an authorized user
    16privat24.privatbank.uaBroken access controlFinancial operationsMass recharge of mobile phones from someone else's card
    17ecommerce.liqpay.comBroken access controlFinancial operationsPayment from someone else's card when paying for services on the site of a merchant connected to PrivatBank
    18privat24.privatbank.uaBroken access controlPrivate dataReceiving phone numbers connected to the SMS-notification service for any PrivatBank card
    19privat24.privatbank.uaBroken access controlPrivate dataView information on utility payments of privat24 customers (name, address of residence, mobile phone, debt)
    20pcalendar.privatbank.uaBroken access controlFinancial dataBalance on any PrivatBank card
    21pcalendar.privatbank.uaBroken access controlFinancial operationsCreating a regular payment by someone else's card
    22pcalendar.privatbank.uaBroken access controlFinancial operationsCreating a regular payment by someone else's card
    23privat24.privatbank.uaInsecure configurationServer dataDirectory structure open
    24privat24.privatbank.uaBroken access controlModification operationGetting and changing the Internet limit for any PrivatBank card
    25privat24.privatbank.uaBroken access controlFinancial dataView statements by card number, there are addresses and gps coordinates of ATMs and self-service terminals used by the client
    26privat24.privatbank.uaInsecure configurationFinancial dataGoogle Checks Available
    27transfers.privatbank.uaBroken access controlFinancial dataInformation on transfers to privat24 (PrivatMoney, Golden Crown, Unistream, Western Union, Contact, Coinstar and Swift)
    28privat24.privatbank.uaBroken access controlFinancial operationsCreating a regular payment by someone else's card
    29thprivat24.privatbank.uaBroken access controlPrivate dataView information on utility payments of privat24 customers (name, address of residence, mobile phone, debt)
    thirtyprivat24.privatbank.uaBroken access controlFinancial dataInformation on applications for a credit rating in UBKI (full name, TIN, date of birth, credit rating, etc.)
    31client-bank.privatbank.uaBroken access controlFinancial dataObtaining an acquiring statement for any PrivatBank merchant
    32client-bank.privatbank.uaBroken access controlPasswordsObtaining 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.
    33limit.pb.uaBroken Authentication and Session ManagementPrivate dataDetailed information on the client (name, card, phone number, date of birth, residential address, etc.)
    34privat24.privatbank.uaBroken access controlPrivate dataObtaining by card number, name, owner's name, phone number, card validity
    35socauth.privatbank.uaInsecure configurationPrivate dataDetailed information on the client (name, card, phone number, date of birth, residential address, etc.)
    36privat24.privatbank.uaBroken Authentication and Session ManagementAccount AccessRepeatedly logging in to private24 using the generated link without entering a static and password reset even after the end of the user session
    37chat.sender.mobiXssAccount AccessTheft of cookies by an authorized user
    38msb.privatbank.uaXssAccount AccessTheft of cookies by an authorized user
    39mypayments.privatbank.uaBroken Authentication and Session ManagementPrivate dataDetailed information on the client (name, card, phone number, date of birth, residential address, etc.)
    40privat24.privatbank.uaBroken Authentication and Session ManagementFinancial dataStatements on user cards.
    41liqpay.comBroken Authentication and Session ManagementAccount AccessWeak user session protection during authorization via a call to a mobile phone
    42client-bank.privatbank.uaBroken access controlFinancial dataStatements for any terminal connected to acquiring.
    43client-bank.privatbank.uaBroken access controlFinancial dataView legal documents persons created using the document designer
    44chat.sender.mobiXssAccount AccessTheft of cookies by an authorized user
    45bank24.privatbank.uaXssAccount AccessTheft of cookies by an authorized user
    46blago.privatbank.uaBroken access controlFinancial operationsThe vulnerability allows any registered user to replace the card of any other user with his own for receiving donations
    47client-bank.privatbank.uaBroken access controlFinancial dataInformation on foreign contracts with foreign partners
    48client-bank.privatbank.uaBroken access controlPrivate dataInformation about users who have access to the specified account, namely login (sometimes this is a phone number), name, email.
    49privat24.privatbank.uaBroken access controlModification operationMass change (at least decrease) of credit limits on cards of PrivatBank customers
    fiftynkk.privatbank.uaBroken access controlPrivate dataAccess to information that the client fills out when applying for a loan
    51privat24.privatbank.uaRedirects and forwardsAccount AccessAccess to user account through token obtained through Open Redirect
    52client-bank.privatbank.uaBroken Authentication and Session ManagementAccount AccessAccess to the user account through the token obtained through the referer on the statistics site
    53client-bank.privatbank.uaRedirects and forwardsAccount AccessAccess to user account through phishing using Open Redirect
    54client-bank.privatbank.uaBroken Authentication and Session ManagementAccount AccessAccess to the user account through the token obtained through the referer on the statistics site
    55client-bank.privatbank.uaBroken access controlFinancial dataAccess 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.

    Also popular now: