File Buz

Today the security for online banking (OLB) is insufficient. High severity vulnerabilities in the source code and multiple flaws in authentication and authorization mechanisms of systems allow remote attackers to execute unauthorized transactions or take complete control of an affected system. This has the potential to cause both financial and reputation damage.

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.

Cases 

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.

General Findings 

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%).



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. Lets 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 attackers 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 vendors 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.



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.



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.



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.



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 banks 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.



Our Recommendations 

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. 

Online banking (OLB) systems are publicly available web and mobile applications, so they suffer from vulnerabilities typical of both applications and banking systems. Bank-specific threats include theft of funds, unauthorized access to payment card data,  personal data and bank secrets, denial of service and many other attacks that can trigger significant financial and reputation losses.

This report synthesizes statistics that were gathered during OLB security audits performed by Positive Technologies in 2015. Comparison with the results obtained in 2013 and 2014 vividly illustrates the dynamics of information security development in modern OLB systems.

Cases

The research covered 20 OLB systems, including several financial services written in 1C that usually have vulnerabilities similar to those in online banking. The 20 OLB systems tested have all undergone a complete analysis including an operation logic audit. Most systems are designed for personal online banking (75%) and they include mobile banking systems consisting of server and client components (35%).

65% of the systems were developed by banks using Java (the majority of apps) and 1C (8%). The rest were implemented on platforms of well-known vendors. In order to comply with our responsible disclosure policy regarding vulnerabilities, no companies are named in this report.

Most OLB systems (75%) are operational and accessible to clients. The rest are testbeds, but ready for commissioning. 57% of OLB systems developed by well-known vendors are operational.

Vulnerabilities and Threats

The percentage of high-severity vulnerabilities has dropped from 44% (2013-2014) to 30% (2015), though the general level of OLB security remains low: high-severity vulnerabilities exist in almost every online banking service (90% of systems in 2015 vs 78% in 2013-2014).

More than half of the systems tested (55%) contain vulnerabilities that may lead to unauthorized access to user data. These security bugs are primarily caused by authorization flaws. The second most common flaw (50%) is insufficient session security (improper user session termination, incorrect cookie settings, multiple sessions under the same account, and lack of association between user sessions and client IP addresses).

In 2013-2014, the CVE-2015-1635 vulnerability was absent, but in 2015, it was detected in two OLB systems. This vulnerability is generated by HTTP.sys errors on Windows (see Microsoft MS15-034). Exploiting this security flaw, hackers can execute arbitrary code or conduct a DoS attack via specially crafted HTTP requests.

The research also revealed threats that could be used against OLB systems if exploited together with other vulnerabilities detected. Thus, one of the systems allows a hacker to steal money via a combination of insufficient session security and two-factor authentication flaws.



25% of the investigated OLB systems are under threat of serious attack. These attacks include theft of money by an authorized user as a result of rounding attacks, unauthorized access to arbitrary user operations, and SQL Injection. As a result, banks could suffer financial losses and lose their reputation as a reliable partner. About half of the systems (55%) allow an unauthorized user to access a DBMS with personal and financial data.



Commercial OLB Systems Became More Vulnerable

All commercial OLB systems appear to be exposed to high-severity vulnerabilities. This is similar to personal OLBs (87%). The number of medium-severity vulnerabilities per commercial system has visibly increased since 2014. The security level of commercial OLB systems has dropped, the security level of personal systems remains as low as in 2014.



OLB Vendors Do Not Guarantee Security

OLB systems supplied by vendors contain 50% more source code bugs than OLBs developed by on-site programmers (40% vs 28%), though in-house OLBs have more vulnerabilities in program configuration (35% vs 27%). In 2013 and 2014, off-the-shelf OLBs had twice as few security flaws (14%).

The number of high-severity vulnerabilities in online bank systems developed by vendors has dropped as compared to 2013-2014, but nonetheless all of these products have critical bugs.

OLB systems supplied by dedicated developers contain 1.5-2 times more vulnerabilities than in-house systems, as the latter are developed for a particular architecture and have set functionality, which makes them simpler and, thus, less vulnerable. However, switching from off-the-shelf to in-house systems does not mean that the newly developed OLB will be secure.


Vulnerabilities by severity for off-the-shelf and in-house systems

Production Systems are Vulnerable

Production systems contain fewer vulnerabilities than testbed systems in 2015, indicating that banks undertake some effort to secure their running applications. However, the security level of production OLB systems is not high: almost all of them contain high-severity threats. 40% of all vulnerabilities detected in production systems are highly dangerous.



Flaws of Protection Mechanisms

A predictable ID format is typical of all OLB systems, and only 60% of them provide users with an opportunity to change it.

Two-factor authentication used for logon and transactions mitigates risks of users’ money being stolen, but 24% of systems do not use this mechanism at all and 29% of systems implement it incorrectly. Almost half of the in-house systems (45%) are vulnerable, and off-the-shelf systems also have this flaw (33%).

Over one third of OLB (35%) do not protect a session from hijacking and further exploitation.



iOS Banking Apps are Better

iOS applications are still more secure than Android apps with 75% of systems exposed to high-severity vulnerabilities, but one third of security bugs in iOS apps are highly dangerous. These bugs are triggered by storing and transferring data in clear-text.



Each Android application contains 3.8 vulnerabilities (compare to 3.7 in 2013-2014), while each iOS application contains 1.6 vulnerabilities (2.3 in 2013-2014).



Though the most common mobile OLB vulnerabilities are classified as medium severity, in some cases a combination of bugs can have a critical impact on the system. For example, if logon is performed via a short PIN code and session IDs are stored in the file system, a hacker with physical access to the device can spoof a web server’s response, and every time an incorrect PIN code is entered, the server will return the true value. A hacker can thus obtain full control over a user’s personal account including changing settings or executing transactions. One of the systems tested allows a hacker to access a user’s mobile bank, exploiting insecure data transfer. In this case, the system facilitates the use of self-signed certificates while transferring data via HTTPS.

Conclusion

The security level of OLB systems remain low, though the total number of high-severity vulnerabilities has dropped as compared to 2013-2014.

The security bugs found in systems already put into production indicate the importance of secure software development lifecycle processes. Security audits of an OLB system should be performed not only prior to commissioning, but also during the course of its operational use. These audits should be regular (e.g. twice a year) and should involve control over elimination of detected flaws.

Off-the-shelf systems are of primary concern: in fact, they are more vulnerable than systems developed by on-site programmers. Banks should also use preventive protection means like web application firewalls. When using commercially available systems, a WAF is required until the third-party vendor releases an update, which prevents attackers from exploiting already known vulnerabilities.

To access a user account, a hacker needs to use well-known flaws like insufficient session security. OLBs must ensure that the correct implementation of security mechanisms is used. It is important to implement secure development procedures and provide comprehensive testing at the acceptance stage.

Considering the findings of this report, that the severity of source code vulnerabilities remains relatively high, it is necessary to regularly check OLB security via white-box testing (including automated tools) or other techniques.

Full research is available at www.ptsecurity.com/library/whitepapers/