SSRF Flaw in Fintech Platform Allowed for Compromise of Bank Accounts

A server-side request forgery (SSRF) flaw in an API of a large financial technology (fintech) platform potentially could have compromised millions of bank customers, allowing attackers to defraud clients by controlling their bank accounts and funds, researchers have found.

A team at Salt Security’s Salt Labs identified the vulnerability in an API in a web page that supports the organization’s platform fund transfer functionality, which allows clients to transfer money from their accounts on its platform into their bank accounts, researchers disclosed in a report published Thursday.

The company in question—dubbed “Acme Fintech” to preserve its anonymity–offers a “digital transformation” service for banks of all sizes, allowing the institutions to switch traditional banking services to online services. The platform already has been actively integrated into many banks’ systems and thus has millions of active daily users, researchers said.

If the flaw had been exploited, attackers could have performed various nefarious activities by gaining administrative access to the banking system using the platform. From there they could have leaked users’ personal data, accessed banking details and financial transactions, and performed unauthorized fund transfers into their own bank accounts, researchers said.

Upon identifying the vulnerability, researchers reviewed their findings and provided recommended mitigation to the organization, they said.

High Reward for Threat Actors

API flaws are often overlooked, but researchers at Salt Labs said in the report that they “see vulnerabilities like this one and other API-related issues on a daily basis.”

Indeed, 5 percent of organizations experienced an API security incident in the past 12 months, according to the company’s State of API Security report for the first quarter of 2022. This period also showed significant growth of malicious API traffic, they said.

“Critical SSRF flaws are more common than many FinTech providers and banking institutions realize,” Yaniv Balmas, vice president of research for Salt Security said in a press statement. “API attacks are becoming more frequent and complex.”

Fintech companies are especially vulnerable to compromise because their customers and partners rely on a vast network of APIs to drive interactions between various websites, mobile applications and custom integrations, among other systems, researchers said.

This, in turn, makes them “prime targets by attackers looking to abuse API vulnerabilities” for a couple of reasons, researchers wrote.

“One, 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. “Two, 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 Vulnerability

Researchers discovered the flaw while scanning and recording all traffic sent and received across the organization’s website. On a page that connects clients to various banks so they can transfer funds to their bank accounts, researchers discovered an issue with the API the browser calls to handle the request.

“This specific API is using the endpoint located at ‘/workflows/tasks/{TASK_GUID}/values,’ the HTTP method used to call it is
PUT, and the specific request data is sent in the HTTP body section,” researchers explained.

The request body also carries a JWT Bearer token, which is a cryptographically signed key that lets the server know who is the requesting user and what permissions he has.

The flaw was in the request parameters that send the required data for a funds transfer—specifically a parameter called “InstitutionURL,” researchers explained. This is a user-provided value that includes a URL pointing to some GUID value placed on the receiving bank website.

In this case, the bank’s web server handled the user-supplied URL by trying to contact the URL itself, allowing for a SSRF in which the web server still tried to call an arbitrary URL if it was inserted into the code instead of the appropriate bank’s URL, researchers explained.

Exposing the SSRF Flaw

Researchers demonstrated this flaw by forging a malformed request containing their own domain. The connection coming into their server was made successfully, proving that “the server blindly trusts domains provided to it in this parameter and issues a request to that URL,” they wrote.

Further, the request that came into their server included a JWT token used for authentication, which turned out to be a different one than the token included in the original request.

Researchers embedded the new JWT token into a request they’d previously encountered to an endpoint named “/accounts/account,” which had allowed them to retrieve information from a bank account. This time they returned even more information, they said.

“The API endpoint recognized our new JWT administrative token and very gracefully returned a list of every user and its details across the platform,” researchers revealed.

Trying the request again to an endpoint named “/transactions/transactions” with the new token also allowed them to access a list of all transactions made by every user on the banking system, they said.

“This vulnerability is a critical flaw, one that completely compromises every bank user,” researchers said. “Had bad actors discovered this vulnerability, they could have caused serious damage for both [the organization] and its users.”

Salt Labs hopes that shining a light on API threats will inspire security practitioners to take a closer look at how their systems may be vulnerable in this way, Balmas said.