The main vulnerabilities of online banks: authorization, authentication and Android

High-level vulnerabilities in the source code, as well as the serious shortcomings of authentication and authorization mechanisms in many systems of remote banking services, allow unauthorized transactions or even gain complete control over the system by an external attacker, which can lead to significant financial and reputational losses. Such conclusions are contained in the study of the vulnerabilities of RBS, detected by Positive Technologies experts in 2013 and 2014 during security analysis work for a number of the largest Russian banks. In this article, we present some of the results of this study.

As part of the study, 28 systems of remote banking services for individuals (77%) and legal entities (23%) were considered. Among them were mobile remote banking systems, represented by the server and client part (54%). Two thirds of the systems (67%) were owned by banks (Java, C # and PHP were used), the rest were deployed on the basis of platforms of famous vendors. Most of the RBS systems (74%) were in commercial operation and were accessible to customers, and a quarter of the resources were test benches that were ready for commissioning.

Overall results

Almost half of the detected vulnerabilities of the RBS systems (44%) have a high level of risk. Approximately the same number of vulnerabilities have medium and low risk (26% and 30%). Overall, high-risk vulnerabilities were detected in 78% of the systems studied.
')
Most of the vulnerabilities (42%) are related to errors in the implementation of the mechanisms for protecting RB systems put in place by developers. In particular, this category of vulnerabilities includes deficiencies in the identification, authentication and authorization mechanisms. In second place are vulnerabilities associated with errors in application code (36%). The remaining vulnerabilities are mainly related to configuration flaws (22%).

The most common vulnerabilities in RBS systems were related to the ability to identify the software being used and to the predictable formats of user identifiers (57% of the systems). More than half of the systems (54%) encountered errors in the “Cross-site scripting” type code. If, in the presence of this vulnerability in the system, the client of the bank follows a specially crafted malicious link, the attacker can gain access to the RB System with the privileges of this client.

Vulnerabilities that allow to implement attacks on user sessions (54% of systems) are also common. These include vulnerabilities associated with incorrect session termination, incorrect setting of cookie parameters, the possibility of simultaneous work of several sessions for one user, the lack of session binding to the client’s IP address, etc. If a successful attack occurs, an attacker can gain access to the user's personal account with its privileges .

The most common vulnerability is the high-risk “Implementing external XML entities” vulnerability, which is found in 46% of systems. As a result of its operation, an attacker can get the contents of files stored on a vulnerable server, data about the open network ports of a node, cause a denial of service for the entire RB System, and, in some cases, access an arbitrary node on behalf of the vulnerable server and develop an attack.

Denial of service for the RB System can be triggered using various vulnerabilities in half of the resources studied (52%).



The most common vulnerabilities of RBS systems (share of systems)

Most common vulnerabilities have a medium or low level of risk. However, in combination with the specific features of the operation of specific RBS systems, this can lead to the realization of serious security threats, including theft of confidential data (89% of systems) and theft of funds (46%).

The RBS systems studied also contain a number of significant flaws at the logic level. For example, in a number of systems, the possibility of attacks based on the incorrect use of number rounding algorithms was discovered. For example, an attacker transfers 0.29 rubles to US dollars. When the cost of one dollar is 60 rubles, the amount of 0.29 rubles corresponds to 0.00483333333333333333333333333333 dollars. This amount will be rounded to two decimal places, that is, to $ 0.01 (one cent). Then the attacker converts $ 0.01 back into rubles and gets 0.60 rubles. Thus, the attacker "wins" 0.31 rubles. As a result of the automation of this procedure, given the lack of restrictions on the number of transactions per day and the minimum transaction size, as well as the possibility of exploiting the Race Condition type of vulnerability, in some cases an attacker can receive unlimited amounts of cash.

Developer Vulnerabilities

High risk vulnerabilities are greater in the RBS systems provided by vendors (49%) than in the systems of a particular bank developed (40%). In addition, systems supplied by professional developers, on average, contain 2.5 times more vulnerabilities at the application code level than systems of their own design. This fact can be explained by the fact that when using software from a vendor, the bank relies mainly on the supplier in terms of code quality. At the same time, complex architecture, cross-platform and a large number of functions of RBS systems do not always allow the vendor to provide an adequate level of security at the level of the application code.



Average number of vulnerabilities in systems (depending on the developer)

Security vulnerabilities

The most common drawback of the RBS system identification mechanisms is the predictability of the account identifier format (64% of the systems). Knowing several identifiers existing in the system, an attacker can calculate the mechanism of their formation and find the right one. 32% of the systems studied revealed information about existing accounts in the system, returning different answers depending on the existence of the entered identifier; in 20% of cases, RBS systems contained both of the above identification vulnerabilities.

58% of the systems reviewed had weaknesses in the implementation of the authentication mechanism — weak password policies, insufficient protection against the selection of credentials, the ability to bypass the CAPTCHA mechanism, or the lack of mandatory two-factor authentication when logging into your account.



Vulnerabilities of authentication mechanisms (system share)

79% of the systems contained various shortcomings in authorization and transaction security. At the same time, in 42% of cases, an attacker could get unauthorized access to user data (personal data, information about bills, payments, etc.), and in 13% of systems the offender could directly perform banking operations on behalf of other users.



Lack of authorization mechanisms (proportion of vulnerable systems)

Mobile client vulnerabilities

Client software for Android OS is more vulnerable than iOS apps. In particular, critically dangerous vulnerabilities are contained in 70% of Android apps and 50% of iOS apps.



Shares of client mobile programs vulnerable to vulnerabilities

On average, each Android-based application contains 3.7 vulnerabilities, while for an iOS application, this figure is 2.3.

The most common in mobile remote banking systems were vulnerabilities associated with unsafe data transfer (73%), followed by insufficient protection of sessions (55%) and unsafe data storage in a mobile application (41%).



The most common mobile software client vulnerabilities

Although the most common vulnerabilities of mobile RB systems have a medium or low degree of risk, in some cases the combination of identified deficiencies made it possible to implement serious security threats. For example, one of the investigated applications sent a broadcast message containing an SMS received from a bank (with a one-time password for conducting a transaction), which could be intercepted by a third-party application. In addition, this mobile application logged important data, such as a user account, as a result of which, if the user's device was successfully infected by malicious code, the attacker could gain full access to the authentication data and conduct transactions on behalf of the user of the mobile application.

More detailed results of this research will be presented at the Positive Hack Days V International Security Forum, which will be held on May 26 and 27 in Moscow. You can also participate in contests for hacking ATMs and online banking services . Details on the website www.phdays.ru .