We read the correspondence of Ubank customers with support
I already wrote about the vulnerability in Alfa-Bank’s mobile application , which allowed receiving statements for any client of the bank.
This time I decided to check out the Ubank payment service mobile application .
To analyze the requests sent to the server, I again used the Fiddler program . How to configure it, I will not describe it again, anyone who is interested can read about it in the above article . The only thing I did differently was to reproduce requests not through the Postman plugin in Google Chrome, but using the Composer tool built into Fiddler.
Examining the requests sent by the application to the server, I found that when loading the correspondence history with support, the message identifier is not checked for the user's session, and accordingly, sorting through the message id, we can get other users' correspondence with support.
So, using Fiddler, I wrote down a request for receiving the message content from correspondence with support:
Then I opened it in Composer:
In the request, I increased the value of the question_id parameter by one and sent it to the server.
In the response, I received the contents of someone else's message:
During further analysis, I managed to find out that in addition to the message id, the files sent in the message were not checked for binding to the user's session.
As with the Alfa-Bank mobile application, the Ubank application also did not use SSL Pinning , which in turn made it possible to conduct a MitM attack if an attacker manages to install his certificate on the victim’s device, which is quite feasible in the following ways:
1) the user does everything himself for ignorance. For example, to gain access to a wi-fi access point in a public place
2) the purchased used phone may already contain an installed malicious certificate
3) the certificate is installed on the iOS phone in a few seconds if it happens to be in the hands of an attacker (for example, he asked to call)
4) infection of network equipment through vulnerability
Conducting a MitM attack on this application is fraught with the loss of the victim’s money, since the application’s functionality allows you to replenish your wallet with a card, make p2p transfers and other financial transactions. Also, when a victim makes a payment, an attacker can replace his details, thus redirecting funds to his account.
Unfortunately, my communication with company representatives did not lead to anything other than a debate about the usefulness of SSL Pinning.
At the moment, after more than 2 months after I contacted the company, the vulnerability remains open.