Hacking Financial APIs - New Report, Familiar Results

Alissa Knight’s latest security research report “Scorched Earth” was recently released. In this blog we’ll look at 3 key themes from the report and the immediate mitigations that banks, crypto companies and fintechs should implement.

Working with Alissa in 2021, we published 2 reports into the state of security of mobile healthcare apps as well as FHIR healthcare APIs. What was striking about the new report on financial services apps and APIs was how similar the issues documented were. In fact, it’s fair to suggest that the 3 areas we will explore in this article are endemic across all mobile centric businesses. As we’ll see, the problems reported can be readily addressed and so there really is no excuse for businesses to be exposed to the risks of fraud and data breaches implied by Alissa’s report results.

Before looking at the key themes of the security research, a reminder that Approov protects data in mobile apps and the APIs that service those apps. It does this by authenticating that the genuine mobile app is present, unmodified and running on a safe mobile device; in this way Approov can protect against assets held in the app being extracted and used at scale to abuse the API and access backend resources and services. Good overviews of the solution can be found here for developers and here for DevOps engineers.

Theme 1: API Keys

Across the three research reports, the percentage of mobile apps containing API keys and tokens ranged from 53% to 98%, so it’s fair to say that this is a pretty common practice. Alissa is fond of saying: “Developers! You need to stop storing API keys in your apps.” and while this would certainly help the situation, we have some sympathy for those developers who are in situations where their platform backend expects incoming API requests to identify their source by presenting a valid API key. In such scenarios, developers are entitled to reply: “Yes, I get that it’s not ideal to store API keys in the mobile app, but where should I keep them then?”

There are a couple of straightforward options here:

• Using a dynamic API key. The Approov token which results from a successful mobile app authentication is a short lifetime JWT which travels with each API request and proves that the request has come from a genuine mobile app instance running on a safe device. Since the app authentication is repeated and the Approov token changed every 5 minutes then it can be used as a dynamic API key, replacing the need for a traditional static API to be stored in the app.
• Using a second factor alongside your API key. In many platforms, the API key verification is an integral part of the authentication process and removing it has implications on multiple parts of the infrastructure. In such cases, the static API key can still be used and can still be stored in the mobile app, but it needs to be protected against abuse at scale. In other words, you need to assume that the API key will be extracted from the mobile app but you must ensure that it can only be used in the context of a genuine mobile app instance. This is Approov’s primary use case, protecting your business against abuse from scripts which impersonate your mobile app and communicate with your API directly; these scripts will present the valid API key and it will normally be very difficult for you to distinguish such scripted traffic from genuine traffic. The Approov token can be considered a second factor which must be presented alongside the static API key, enabling your backend to grant access to genuine API requests and block scripted traffic which will be unable to present a valid Approov token.

So, API keys in mobile apps are not all bad if handled correctly. There is another blog on this topic which you might like to review.

Theme 2: Certificate Pinning

Amazingly, looking across all three security research reports, man/woman/person-in-the-middle (MitM) attacks were feasible in pretty much all cases. If attackers are able to weaponize your mobile channel by intercepting and manipulating your API traffic, the potential consequences are very serious for your business.

The above findings mean that certificate pinning was most likely missing entirely, or perhaps was present but implemented but in a way that was easy to bypass. For us, this isn’t as much of a surprise as it might be for others since we have had countless conversations with customers on this topic, primarily advising them on best practices to implement, monitor and manage pinning.

Pinning your APIs is essential and should be implemented. The main reason we find that customers are reluctant to do so is a feeling that it is complex and there is a risk that certificate rotations and compromises could create situations where their mobile apps become ‘bricked’ and need to be updated in the field. This is indeed a nightmare scenario.

However, efficient and effective certificate pinning solutions do exist, including the dynamic pinning capability which has been a standard part of Approov for some time now. Essentially, Approov dynamic pinning makes implementation of pinning automatic and, even more important than that, it makes certificate management simple since Approov enables certificates to be updated directly in deployed mobile apps without requiring an app update.

We have written extensively about this and would recommend you to watch a recording of one of our recent webinars, Making MitM Attacks a Thing of the Past, or if you prefer you can read our whitepaper on the same topic.

Theme 3: API Shielding

All 3 reports documented examples of OWASP Top10 API vulnerabilities, mainly related to authentication and authorization. It should not be a surprise that these APIs have vulnerabilities, almost all APIs have them. We often say that the vulnerabilities in your APIs are simply divided into those you know about and those you don’t.

So, testing for vulnerabilities and correcting them is a necessary task, and both time and resources should be allocated to this in your engineering plans. Further, it is important to acknowledge that this is an ongoing project because every API code change you make may introduce a new vulnerability.

Of course, better than finding vulnerabilities during testing would be to remove them during development, and this is the process known as shifting left. Many vendors and tools are emerging to help with this.

However, given the size of the effort and the ongoing nature of finding and fixing vulnerabilities, it is necessary in parallel to protect your business from vulnerability exploitation. Remembering that almost all API vulnerabilities are exploited via scripts, it should be clear that Approov can be deployed in this role since it ensures that API requests are only valid if they come from genuine mobile app instances running on safe devices.

Shift left and Shield right is an industry term which describes a suitable approach to improve the overall security posture of mobile centric businesses, although arguably the Shield right activity is more urgent since it provides an immediate benefit in protecting the platform from the exploitation of vulnerabilities, known and unknown.

To learn more about this topic and understand all of the attack surfaces in your mobile channel, please review our webinar on API Shielding and read our whitepaper on Mobile App/API Threats. 

Summary

Although the security reports cited at the start of this article are a litany of bad news and have spawned a large amount of negative press, there is a silver lining which is available to those who look. 

Securing mobile apps and the APIs that service them in a holistic, effective and efficient way is still a relatively new challenge and the good news can be located when looking at companies, like Approov, who have been developing, deploying and evolving appropriate solutions for some time. To talk to us about your use cases and have a security expert explain where and how Approov can help, you can schedule a call with us here.

So, for fintechs new and old, now is the time to consider specific solutions for specific problems, safe in the knowledge that the majority of security holes which undoubtedly exist within your apps and APIs right now can be covered today. Shift left over time by all means, but please shield right first.