The waves of the digital storm cover more and more sectors of the economy, forming a new reality. The financial industry was no exception: countries, one after another, are developing and implementing a revolutionary approach to the work of credit institutions - the concept of open banking or Open Banking.
Open Banking is a unified software interface to bank information systems. It can be used by financial application developers - fintech companies to provide customers with new generation financial services.
Interaction with banks through an open interface is not only opportunities, but also risks. In this post, we will consider the risks and threats that arise with the implementation of Open Banking, and discuss possible options for protection against them.
About fintech companies
Despite the desire of banks to create innovative financial products, it is difficult for them to compete in this regard with fintech companies that are not connected by the requirements of the regulator and internal regulations. And the competition between banks and the desire to attract customers to the service to itself imposes natural restrictions on the creation of services that integrate the services of several credit institutions.
Fintech companies compare favorably with conservative banks. They can afford to attract customers from different banks, quickly introduce new non-standard products, using all the advantages of independence from the regulator.
The dynamic nature of financial and technological companies is to some extent a consequence of their organizational features. An analysis of financial technology providers by Trend Micro in preparation for the study “ Ready or Not for PSD2: The Risks of Open Banking ” showed that most of these companies:
- have a small number of employees;
- limited in financial resources;
- actively use cloud infrastructure for work;
- apply virtualization and containerization of services;
- Use third-party SDKs to shorten the development cycle and focus on innovation;
- shorten the testing cycle to save both time and money. There is nothing surprising. This approach is practiced in an effort to reduce costs even by such giants as Microsoft, which has abandoned full-time testers in favor of participants in the Windows Insider program.
The flip side of these features is significantly greater vulnerability compared to banks. With the growing number of countries introducing Open Banking, the threat landscape is becoming more diverse, as cybercriminals get at their disposal new targets for attacks. Let's talk about them in more detail.
Goals for Open Banking Attacks
Bank Public APIs
The Open API, implemented in European banks in accordance with PSD2 - the “Revised Payment Services Directive” - is just part of a big process. The implementation of such programming interfaces is taking place in many countries. Somewhere, these works are an initiative to unite private companies and banks. For example, the development of the Durable Data API in the USA is supported by the nonprofit association FDX , a subsidiary of the Financial Services Information Analysis Center (FS-ISAC) . Other governments prefer to have full control of the process, like Mexico, which passed the Fintech Law , or Australia, in which fintech access to bank software interfaces is only part of a large pool of events called Consumer Data Right .
The avalanche growth of financial APIs being introduced in the world. Source: Trend Micro
An increase in the number of public banking APIs will inevitably lead to an increase in attempts to use it for profit. Why crack the bank’s protection if there is an interface through which you can civilize to connect to an automated system and transfer a couple of millions to yourself?
A study by Trend Micro revealed a significant number of banks that disclose confidential information - one-time passwords, access tokens, e-mails, IMEIs and transaction data in the URLs of APIs and sites.
Although the use of SSL protects against traffic interception, the transmission of such information in the URL is dangerous because these parameters:
- May appear in web server logs;
- Will be displayed in the browser URL;
- Appear in browser browsing history;
- They will be visible to any device that performs SSL interception, for example, network monitoring equipment with a trusted certificate.
Confidential data in banking API URLs. Source: Trend Micro
In some browsers, browsing history is common to various devices, such as a laptop, smartphone and tablet. Displaying sensitive information in a URL will potentially weaken the effectiveness of multi-factor authentication, allowing hackers to attack the least secure devices to steal this information.
Real-life example: A European fintech company with millions of customers has published API documentation stating that the email addresses, passwords, passwords, and customer identifiers are sent in the API URLs.
Source: Trend Micro
Another method of malicious use of public APIs is DoS / DDoS attacks. Any interested hacker can try trial and error to find a combination of parameters that will cause a service failure.
Mobile applications
In addition to traditional attacks on mobile applications using overlays and other familiar options, the use of third-party SDKs also entails additional danger.
There are cases when malicious functions were introduced into them that subscribed a user of a program using this library to premium SMS or paid services, like E xpensiveWall, which was embedded in the gtk library , or DrainerBot, which was introduced in the Tapcore SDK and showed invisible videos for cheating on them .
In some cases, the initially safe and useful applications suddenly became malicious, such as the CamScanner - Phone PDF creator, which suddenly got a library with Trojan features .
Obviously, hidden functionality in programs for working with financial data can lead to the most unpleasant consequences.
And even if Open Banking applications are limited in the right to payments on behalf of customers, attackers will still be able to use them for profit. Data on completed transactions is also a valuable commodity. Information about when and where purchases are made allows you to get an idea of the daily movements of users, their habits, interests and financial situation.
Another target for attacking mobile apps is bug reports. If the application crashes, information about the device status and the circumstances that caused the error is sent to the developer's server. Moreover, the transmitted information may also contain confidential information:
Error reporting. Source: Trend Micro
If an attacker compromises the software developer for crash reports, he will gain access to this information.
Fintech Infrastructure
The use of cloud infrastructure for the implementation of fintech projects is a reasonable way to save the company from the cost of acquiring "iron" servers and ensuring their smooth operation. However, in this case, another participant is added to the company, the bank, the client and the fintech organization - the cloud service provider.
Hackers can organize an attack on the supply chain, having infiltrated the network of the cloud provider. Such an attack will affect several fintech companies with resources in this cloud. Its danger is that neither clients, nor banks, nor fintech companies themselves will learn about compromise, since the attack will occur outside their reach.
Users
Attacks on users are in first place in terms of efficiency and relevance. They are much simpler and cheaper to implement than "technical" cyber attacks.
During their work with users, banks managed to ensure that mass phishing emails like “Your credentials for SuperCredit Bank are out of date. Click here to reset the password "have lost their effectiveness. Users have become more wary of them.
When working with a fintech application, this experience is already inapplicable. Therefore, the letter “We are a fintech company MegaTech, a provider of services to SuperCredit Bank. Please click here to update your account details. ”It seems completely safe. Users do not realize that the password for the fintech provider account is as important as the password for the Internet bank. And the saddest thing is that banks will not find out about the user's compromise.
A more difficult way to attack users is fake fintech applications, which are displayed in the top Play Market or App Store, and then steal credentials, financial information and money.
How to protect Open Banking
Effective counteraction to fraudsters provides a set of measures, and open banking is no exception. We list the ways to protect fintech clients from threats.
Multi-factor authentication
This is a mandatory requirement of the PSD2 directive and similar regulations related to Open Banking. According to Microsoft, the use of multi-factor authentication blocks 99.9% of attempts to crack accounts.
Three whales of MFA - knowledge, possession, biometrics. Source: WSO2
In addition to the MFA, PSD2 adds the concept of dynamic linking - the use of authentication code that depends on the amount and recipient. Any change to these parameters will invalidate this code.
Secure API
As such, Open Banking proposes to use the Financial-grade API (FAPI) , a software interface based on OAuth 2.0. FAPI, which is being developed by the OpenID Foundation and the British organization for the implementation of open banking.
FAPI is a more secure version of the OAuth 2.0 protocol, which allows third parties to access a service provider without providing user credentials. Instead of a password, a third party receives a token to access the user data after obtaining his explicit consent. The user controls the access rights of third parties with the help of a token, for example, temporary access and read-only access. He can withdraw the token at any time, and in case of its theft, a password change is not required, since the password was not provided to anyone.
Interaction using FAPI. Source: Trend Micro
FAPI developers have added security modules to OAuth 2.0. Among these modules, it is worth noting:
- mTLS (mutual TLS) is a mutual authentication protocol similar to HTTPS, but here not only the server confirms its authenticity to the client, but also the client to the server. In other words, in order to complete a transaction, a fintech application must not only verify the authenticity of the server, but also confirm its authenticity to the server.
- OAuth 2.0 Token Binding (OAUTB) - binding access tokens and / or authorization codes to a TLS connection. If an attacker steals the authorization code, he will not be able to use it in another TLS connection. Unfortunately, Token Binding is currently only supported on Microsoft Edge.
- Client Approval JSON Web Signature (JWS Client Assertions) - establishes that only a specific client can use the access token on the bank authorization server.
- Code Exchange Verification Key (PKCE) - helps prevent attackers from using a client access token. To do this, the application sends an additional verification code to the authentication server to confirm that the client wants to use this access token.
Currently, FAPI has identified security issues that need to be addressed.
Infrastructure and Endpoint Security
Protecting the infrastructure of fintech companies is an important factor closing loopholes for hackers. Endpoints , cloud systems and development mechanisms must be protected , as well as end-to-end monitoring of the entire infrastructure .
We talked about the safety of endpoints in the publication When Walls Are Not Enough. How to protect endpoints . "
Conclusion
Any new technology requires not only consideration of prospects, but also a careful analysis of the risks that it poses. It is especially important to consider the dangers in the event that a new approach is being introduced in the field to which the closest attention of cybercriminals is traditionally directed.
Open Banking is already changing the landscape of financial relationships. In the next few years, these changes can turn our lives around, revolutionizing the way we manage our money. In order for these changes to be positive, it is extremely important that fintech companies, banks and other participants in the process not only take into account the identified threats, but also promptly refine APIs and standards to eliminate security problems.