Data Info

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/