Fintech platform flaw could have allowed bank transfers, exposed data

Fintech provider flaw could have hit dozens of U.S. banks, says Salt Security

Salt Security spotted a vulnerability in a large fintech company's digital platform that would have granted attackers admin access to banking systems in addition to allowing them to transfer funds to their own accounts.

If exploited, the flaw would have also exposed both users' personal data and financial transactions.

"This vulnerability is a critical flaw, one that completely compromises every bank user," Yaniv Balmas, vice president of research at Salt, an API security firm, told The Register.

"Had bad actors discovered this vulnerability, they could have caused serious damage to both the fintech company and its users. At a minimum, an attacker could have leaked personal account and banking transaction data."

Salt Labs researchers declined to name the fintech company, saying only that it is based in the United States and that its online banking services platform is used by dozens of banks and other financial institutions that collectively serve hundreds of thousands of US customers.

Such platforms are considered prime targets by attackers that focus on abusing API vulnerabilities, the researchers wrote in a blog post.

"Their API landscape and overall functionality is very rich and complex, which leaves a lot of room for mistakes or overlooking details in development," they wrote, adding that "if a bad actor can successfully abuse this type of platform, the potential profits are huge, since it could allow control of millions of users' bank accounts and funds."

The threat of such attacks increases as more banks partner with fintech providers and shift their traditional services online, a trend that only accelerated during the COVID-19 pandemic, according to Balmas.

"Institutions that will not provide online services in the coming years will quickly become irrelevant," he said. "I also believe that because trends toward open banking lack current standardized regulations for securing APIs, broader awareness around API protections will be the next frontier to focus on in this arena."

When migrating to online services, a financial institution can either create the framework in-house or on rely third-party vendors. Either way, the services rely heavily on APIs.

"In today's world with very rapid development efforts and quickly emerging API technologies, tracking APIs and protecting them proves to be a major challenge for organizations of all sizes," Balmas said.

"We have been seeing some improvement in awareness of these kinds of potential vulnerabilities and threats, yet API security is still far from optimal."

Third party integrations

In this case, the Salt Labs researchers focused on external interactions of one bank's websites that rely on the fintech platform. In particular, they looked at webhooks and third-party integrations, which are important because they enable functions such as advanced notification options and fund transfers.

The researchers were able to manipulate the APIs in the platform and the JWT tokens – cryptographically signed keys that lets the bank's server know who the requesting user is and what permissions they have – to establish a connection between that server and one run by Salt Labs.

Using user-supplied URLs, they found that the bank's server would contact any arbitrary domain provided by them.

"We forge a malformed request containing our own domain, cross our fingers, and wait," they wrote. "A few seconds later … Bingo! We got a connection coming into our server. Seeing this traffic validates our suspicion and means the server blindly trusts domains provided to it in this parameter and issues a request to that URL."

It creates a critical security issue called a server-side request forgery (SSRF), which occurs when a web application fetches a remote resource without validating the user-supplied URL. An attacker exploiting this flaw can craft a request for information to a bank's application. It's a way for a threat actor to reach servers that are behind firewalls and not accessible via an external network.

According to cybersecurity firm Acunetix, the 2019 breach of Capital One and others into Microsoft Exchange servers involved the use of SSRF as one of the break-in techniques.

Watch out for user-controlled input

The company said that while an SSRF vulnerability is present on average in 1 percent of web applications, it's a dangerous flaw that can cause series security breaches.

In this instance, the researchers were able to get the bank's application to return a list of every user on the banking system and associated details. They also were able to get another list of every transaction made by every user.

They contacted the fintech company, which has since fixed all the issues raised by the Salt Labs team. However, the research raised warnings about user-controlled input, which was the key culprit in this case, Balmas said.

"Such parameters should never be blindly trusted," he said. "Software and API developers should always make sure to apply as many protections as possible to any user input, especially if the input values are susceptible to attacks, such as URL values that may lead to SSRF or other vulnerability classes."

The most effective protection is a combination of both static protections – such as basic sanitation or whitelisting – and runtime protections that would identify API traffic anomalies, he said. Doing so would close gaps or bypasses made to the static methods. ®