Vulnerability in one of Alfa-Bank's services allowed viewing statements on any client

    A month ago, looking at a mobile application for Internet banking from Alfa Bank, I decided to check how secure it is.



    Since I am a client of this bank, I was wondering if they pay due attention to the safe storage of customer data. I’ll clarify that I am a client of the Ukrainian branch and accordingly had the opportunity to check only that part of the mobile application that is intended for Ukrainian customers.



    Training


    To track the traffic transmitted by the mobile application to the server, install Fiddler .

    The program is extremely easy to use, it is installed and configured according to the instructions quite easily. Additionally, in the program settings, you need to enable decryption of https traffic.
    In the phone, in the wi-fi settings, you need to specify the proxy address lifted by this application and in order for the program to decrypt mobile HTTPS traffic, we need to additionally install a certificate ( IOS , Android ).

    After all these steps, launch Fiddler and the Alfa Bank mobile application. Now all requests sent by the mobile phone will be displayed in Fiddler. In our case, it turned out to be SOAP protocol with requests in XML format.



    Now a little about the vulnerability search process


    I was looking for typical mistakes made by developers. The most common of these is the lack of access control when requesting using an identifier. We search for errors as follows. We take a request for a mobile application, secured by Fiddler and play it in the Google Chrome browser using the “Postman” plugin:



    In this request, we replace the integer identifier with a larger or smaller value and check the server response. If the server returns an error or an empty request, then everything is fine, if the client data, then there is a vulnerability. I did not have to search long. When requesting an extract, there was no verification of access rights. An identifier such as cardContractId was used to access the data. By increasing or decreasing its value, it was possible to receive statements from other users.

    On the same day, I sent a message about the vulnerability found through the Alfa-Bank website, but within a few days, not receiving an answer, I called the customer service and asked that the security service contact me. I must pay tribute, the SB officer called me back on the same day and after a little more than a week the vulnerability was eliminated.

    However, I would like to turn to the management of the bank’s unit responsible for the development of software products. Bank services are actively developing and gaining functionality in which, whether you want it or not, vulnerabilities appear. Existing communication channels practically do not respond when sending requests in electronic form. For example, two of my reports on XSS vulnerabilities on other Alfa-Bank resources, submitted several months ago, remained unanswered.

    Organize a separate communication channel for applying for vulnerabilities found and create an incentive program. Such programs exist with Google, Amazon, Yandex and even Privatbank and they very effectively help in quickly closing security holes. Do not wait until the attackers begin to exploit the vulnerabilities found and customers will inform you about the problems already in fact.

    Also popular now: