In this article we present some results of the research on OLB vulnerabilities discovered by Positive Technologies experts in 2013 and 2014 in the course of security assessments for a number of the largest Russian banks.
28 systems for personal (77%) and commercial (23%) online banking were investigated in the course of this research. They included mobile banking systems consisting of server and client components (54%). Two thirds of the systems (67%) were developed by banks themselves using Java, C#, and PHP. The rest were implemented on platforms of well-known vendors. Most OLB systems (74%) were operational and accessible to clients. 25% of the systems were testbeds, but ready for commissioning in the foreseeable future. The severity of the vulnerabilities was graded based on CVSS version 2.
Almost half of the OLB vulnerabilities discovered (44%) were classified as High severity. Vulnerabilities classified as Medium (26%) and Low (30%) severity were approximately equal. In general, high severity vulnerabilities were discovered in 78% of the investigated systems.
Most vulnerabilities (42%) were caused by developers' bugs in OLB security implementation. This includes flaws in identification, authentication, and authorization mechanisms. The second most common vulnerability (36%) are bugs in the application source code. The rest (22%) relate mainly to misconfiguration.
The most common OLB vulnerabilities found are related to software information disclosure and predictable user ID formats (57%). More than half of the systems (54%) were vulnerable to Cross-Site Scripting (XSS) attacks. Successful exploitation of this vulnerability could allow an attacker to obtain OLB access in the context of the targeted user if the victim navigated to a specially crafted website.
Vulnerabilities that facilitated attacks on user sessions were also very common (54%). These included improper session termination, incorrect cookie settings, multiple sessions under one account, and a lack of association between user sessions and client IP addresses. Successful exploitation of these vulnerabilities could allow an attacker to obtain access to the targeted account with full user rights.
XML External Entity (XXE) vulnerabilities were among the most common high severity vulnerabilities discovered in 46% of the systems. Successful exploitation of these vulnerabilities could allow an attacker to read files on a vulnerable server, reveal open network ports on the host, cause a denial of OLB services or, under certain conditions, impersonate a vulnerable server to perform further attacks on arbitrary hosts.
Half of the investigated OLB systems (52%) were vulnerable to Denial of Service (DoS) attacks.
The most commonly found vulnerabilities are classified as Medium or Low severity. Nevertheless, these vulnerabilities in conjunction with some OLB features could cause critical security flaws like stealing personal data (89%) or money (46%).
Top OLB Vulnerabilities (across systems)
The investigated OLB systems also contained a number of severe logic vulnerabilities. For example, a number of systems were vulnerable to attacks involving floating point rounding errors. Let's assume that an attacker wants to convert 0.29 RUB (Russian Ruble) to USD (United States Dollar). If the price of 1 USD is 60 RUB, then 0.29 RUB equals to 0.004833333333333333333333 33333333 USD. This sum is rounded up to the hundredths place, i.e. to 0.01 USD (one cent). Then the attacker converts 0.01 USD back to rubles and gets 0.60 RUB. The attacker's bonus is 0.31 RUB. Thus, a malicious user can automate this procedure and obtain an unlimited amount of money, as there are no limitations on the number of transactions per day and on the minimum sum to exchange. Race Condition vulnerability may also facilitate exploitation of this bug.
Vulnerabilities by Developers
High severity vulnerabilities are more common for third-party OLBs (49%) than for proprietary systems OLBs (40%). OLB supplied by dedicated developers contain 2.5 times more source code bugs than OLB developed by onsite programmers. This is due to banks using third-party software and relying on the vendor's source code QA. However, as OLBs are cross platform and have complicated architectures and multiple features they do not allow vendors to provide sufficient security at the source code level.
Average Number of Vulnerabilities (by Developer)
Most common security vulnerabilities
The most common security flaw, found in 64% of OLB identification mechanisms is a predictable ID format. An attacker who knows several valid IDs may predict the algorithm used to generate them. 32% of the investigated systems exposed information on valid accounts by generating different responses depending on whether the user account existed. 20% of OLB systems contained both identification vulnerabilities mentioned above.
58% of the investigated systems contained security flaws in the authentication mechanisms, for example weak password policy, insufficient protection against brute force attacks, CAPTCHA bypass vulnerabilities, and the lack of two-factor authentication.
Authentication Vulnerabilities (per System)
79% of the investigated systems had insufficient authorization and transaction security and 42% allowed attackers to obtain unauthorized access to user data (personal data, bank accounts, payments, etc.). 13% of the systems allowed direct banking operations on behalf of the targeted user.
Authorization Vulnerabilities (per System)
Mobile Banking Vulnerabilities
Applications for Android OS are more vulnerable as compared to iOS applications. High severity vulnerabilities were discovered in 70% of Android applications and in 50% of iOS applications.
On average, each Android application contains 3.7 vulnerabilities, while each iOS application contains 2.3 vulnerabilities.
Application Vulnerabilities by Mobile OS
The most common vulnerabilities in mobile banking applications are related to insecure data transmission (73%), insufficient session security (55%), and unsafe data storage (41%).
The most commonly found mobile OLB vulnerabilities were classified as Medium and Low severity, but in some cases, a combination of these vulnerabilities could have a critical impact on the system. For example, one of the investigated applications was broadcasting bank's SMS message with a one-time password for the transaction, which could be intercepted by an external application. Moreover, this mobile application logged sensitive data that could allow an attacker to obtain user credentials and perform transactions on behalf of the mobile application user by executing malicious code on the targeted mobile device.
TOP Mobile Banking Vulnerabilities
To reduce any risks related to OLB vulnerabilities banks should implement secure development procedures, provide comprehensive testing at the acceptance stage, and use preventive protection means like the Web Application Firewall. Additionally banks should use the Application Firewall for third-party productive systems in order to prevent vulnerability exploitation until it is patched by the vendor.
More details from this research will be presented at Positive Hack Days infosec conference (May 26-27, Moscow) were the participants can take part in hacking contests “Leave ATM alone” (detecting ATM vulnerabilities) and "Snatch" (exploiting an online banking system). See the contests’ rules and results at www.phdays.com.