Is it possible to steal money from mobile banking? Part 1
For the second year in a row, we have been conducting an independent analysis of the security of applications for mobile banking (MB) of Russian banks. During this time, a lot of observations, thoughts, ideas have accumulated, which I would like to share. We will pay special attention to MB, but general comments are also relevant for other applications that work with critical user information.
In 2013, we released the study “Security Analysis of Mobile Banking Applications 2012” . A little later, a similar work was published by a researcher from IOActive. You can read about his results in his blog post here . In 2014, we released the study “Mobile Banking Security: The Possibility of Implementing a MitM Attack” .
And who needs it?
Among some experts on banking security in Russia, it is widely believed that mobile banking has not yet earned such attention as, for example, the banking system (remote banking service). Their main argument is the fact that very few financial resources pass through mobile banking systems now. And therefore, they say, MB is not interesting for attackers.
For us, this segment seems very attractive for consideration, and there are several reasons for this. So, I would like to immediately draw the attention of readers to the fact that the Central Bank of the Russian Federation does not distinguish between RB and MB. Currently, the Bank of Russia is actively developing recommendations for a safe development cycle of automated banking systems. Unfortunately, it is not yet available in the public domain, but it is worth getting acquainted with it at the first opportunity.
In addition, it does not matter to attackers exactly how many and which transactions are made daily in mobile banking applications. Even if users just put money into their account to pay for the services of a telecom operator. It is important that the attacker, through vulnerabilities in the application, can gain access to the account where the client’s money is stored. Let's not forget that just hacking a key client of a bank is enough to have a significant impact on the activities of a financial organization.
Those who believe that it is necessary to pay special attention to RBS and not spend time on MB should know that these systems are interconnected. More than once we have seen this in practice during penetration testing and auditing. We were able to detect vulnerabilities and supporting information in MB systems, which in the future can be used to attack remote banking systems.
And finally, it’s simply foolish to deny world practice and say that mobile banking may not become popular in Russia. The number of mobile devices among users is only increasing, and mobile banking today is simply convenient.
Specific Mobile Banking Issues
1) Organizational problems.
Recently, quite a lot of communication has been possible both with customers (banks) of a mobile bank and with their executors (developers). It is always useful to look at the situation from different angles.
As for customers, it was possible to see several TK on MB and find it difficult to find a description of the item about security. There most often there are very general wishes in which mobile specifics are not taken into account at all. This is understandable: banks do not have separate mobile security specialists with knowledge of iOS, Android or WindowsPhone platforms. And as you know, security mechanisms must be laid right into the architecture, thinking about protection is necessary at all stages of development in order to save money in the future.
In conversations with developers, you will learn a lot of interesting things, starting to understand where such stupid errors come from in such a critical application as MB. Often when creating a product, the client part is written by one company, and the server part by another, or even it was written by someone quite a long time ago. To establish a good process of interaction between them is not an easy task, and a number of errors appear here. Further, banks often cannot provide a good test environment for developing the client part, which leads to the invention of various “crutches” by the developer. And then it only depends on him - whether he will forget to remove them before the release of the release ... And again, the problem of the availability of information security specialists for developers does not lose relevance.
2) Application redundancy problem
It would seem: there is an application for MB, which should help to conveniently and safely work with personal accounts, money. Where does it suddenly come from with the code responsible for working with various social services? networks, file services, note services, etc.?! For example, as a person paranoid about security, it’s very strange to see ... Manufacturers simply explain: in this way they expect to sell such an application endowed with unique features.
Naturally, no one really thinks that as the functionality increases, the complexity of the application grows, and the likelihood of making a mistake becomes higher. And corny because of all these third-party services attack surface is growing.
3) Data storage problem
Mobile devices are always with us and small in volume. They are easy to lose or just overlook for a while. At the same time, now mobile devices can say much more about us than their desktop “brothers”. Therefore, the problem of data storage remains one of the most important.
When analyzing the security of an application for MB, we often see critical information in the clear, which is either simply stored in the application or unknowingly falls into the cache of network requests, logs, crash dumps, screenshots. An attacker, while gaining physical access to a device, can download these critical files.
4) The problem of working in an untrusted environment
Often users themselves endanger their devices by gaining root access on their Android device or by installing jailbreak on their iOS device. Moreover, they most often do not understand that upon receipt of various freebies and gimmicks, the built-in OS security mechanisms are partially or completely disabled. Thus, the likelihood of infection of the device with malicious code increases and the likelihood of a successful attack increases. Advanced malware for mobile devices can now do this on its own - the main thing is to get to your mobile device anyway.
Having looked at almost all the MBs on the Russian market, it can be said that only some of them (2-3, to be exact) check the state of the mobile device - is there jailbreak or root access there. Next, they display a message and inform the user about it. Last year, one of these applications refused to work on a "discredited" device, but already this year the software simply makes a certain limit on the operations performed. And in most cases, applications for MB work as if nothing had happened.
5) Multi-factor authentication problem
In the classical RB system, the second factor often comes in the form of SMS to the phone, and the user confirms the transaction. In the case of mobile banking, with this approach, both factors come / enter on one device. If there is a virus on the device (which is especially true for the Android OS), then this malware will certainly intercept sensitive information.
The following approaches of multi-factor authentication are widespread in the mobile banking environment: SMS messages with OTP, one-time code tables, special mobile applications for OTP generation directly on the device, biometric authentication. Unfortunately, they all have one big common drawback: they come / enter to the same device and are transmitted via the same data channel, which can be controlled by an attacker during a MiTM attack or some malware on the device. So for mobile applications, it’s more important, rather than the presence of a second factor, but the existence of a second data channel.
6) The problem of application distribution
This problem applies only to mobile OS with many application stores. First of all, we are talking about the Android OS. There are a huge number of stores for Android (Google Play, Samsung Apps, Yandex market, Amazon mobile app distribution, SlideMe, etc.). Some of them are immediately “flooded” into the device by default, and the user has no choice, especially the usual one. As a result, in one store a legitimate application may lie, and in another its modified version with malicious functionality.
Recently, requests to see what the application for MB in the store does, which should not, in theory, have a relationship, have become more frequent. Also, there are simply unofficial applications for banks, which are “wrappers” over the Internet site. After reviewing a number of such applications, we have not yet discovered malicious functionality, but this does not mean that with the next update it will not appear and your data will fly to a third-party server. You need to use only official applications, and banks should monitor application stores for fakes.
7) Code protection issue
It seems that applications such as MB should make every effort to complicate the life of fans dig deeper into their insides, but this is not entirely true. Code obfuscation is found in Android applications, albeit infrequently. In iOS, it is completely absent. So to analyze this problem it is useful to compare these systems. The situation is similar with anti-debugging techniques. It is also worthwhile to clearly understand that code obfuscation and anti-debugging methods are not security mechanisms, but methods of complicating the analysis. Without all of this, vulnerability searches in code are simplified.
8) The problem of protecting the data channel
Mobile devices are wonderful in that they are always with us and give us the opportunity to access information from anywhere. Arriving at a cafe, restaurant, shopping center or movie theater, we are looking for affordable free Wi-Fi access points and without hesitation we join them ... or sit on the hook?
In the second part of the article, we will consider this situation and show when and how exactly an attacker can steal money from a mobile banking application.