Alissa Knight’s latest security research report, Scorched Earth, was recently released. In this blog, we will address 3 key themes from the report and the immediate remedial actions that banks, crypto companies and fintechs should implement.
In collaboration with Alissa in 2021 we have published 2 reports on the security posture of mobile health apps and FHIR health APIs. What was striking about the new Financial Services Apps and APIs report was how similar the documented issues were. In fact, it’s fair to say that the 3 areas we’re going to explore in this article are endemic to all mobile-centric businesses. As we shall see, the issues reported can be easily addressed and as such there really is no excuse for companies to be exposed to the risks of fraud and data breaches implied by Alissa’s reporting findings.
Before we dive into key security research topics, it’s worth remembering that Approov protects data in mobile apps and the APIs that serve those apps. It does this by authenticating that the real mobile app exists, is unmodified, and running on a secure mobile device; This allows Approov to protect against assets stored 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.
Topic 1: API Keys
In the three research reports, the percentage of mobile apps that contained API keys and tokens ranged from 53% to 98%, so it can be said that this is a fairly common practice. Alissa likes to say, “Developers! You need to stop storing API keys in your apps.” and while that would certainly help the situation, we have some sympathy for those developers who find themselves in situations where their platform backend expects incoming API Requests identify their source by presenting a valid API key. In such scenarios, developers have the right to reply: “Yes, I understand that storing API keys in the mobile app is not ideal, but then where should I keep them?”
Here are a few simple options:
- Using a dynamic API key. The Approov token that results from a successful mobile app authentication is a short-lived JWT that travels with each API request, proving that the request came from a real mobile app instance running on a secure device . Because the app authentication is repeated and the Approov token is changed every 5 minutes, it can be used as a dynamic API key, replacing the need to store a traditional static API in the app.
- Using a second factor alongside your API key. On many platforms, API key verification is an integral part of the authentication process, and its removal impacts multiple pieces of infrastructure. In such cases, the static API key can still be used and stored in the mobile app, but it needs to be heavily protected from misuse. In other words, you must 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 real mobile app instance. This is Approov’s primary use case, protecting your business from abuse by scripts masquerading as your mobile app and communicating directly with your API; These scripts present the valid API key and it will usually be very difficult for you to distinguish such scripted traffic from real traffic. The Approov token can be considered as the second factor that needs to be presented alongside the static API key in order for your backend to grant access to real API requests and to block scripted traffic that cannot present a valid Approov token.
So, API keys in mobile apps aren’t all bad when handled properly. There is another blog on this topic that you might want to read.
Topic 2: Certificate Pinning
Amazingly, looking at all three security research reports, Man/Woman/Person-in-the-Middle (MitM) attacks were feasible in almost all cases. If attackers are able to weaponize your mobile channel by intercepting and manipulating your API traffic, the potential consequences for your business are very serious.
The above results mean that certificate pinning was most likely missing entirely, or perhaps present, but implemented in a way that was easily bypassed. This isn’t as much of a surprise to us as it is to others, as we’ve had countless conversations with customers on this topic, primarily advising them on best practices for implementing, monitoring, and managing pinning.
Pinning your APIs is essential and should be implemented. The main reason we think customers are reluctant to do this is the feeling of complexity and the risk that certificate rotations and compromises could create situations where their mobile apps are “bricked” and need to be updated locally . This is indeed a nightmare scenario.
However, efficient and effective certificate pinning solutions exist, including the dynamic pinning feature, which has been a standard part of Approov for some time. Essentially, Approov’s dynamic pinning makes the implementation of pinning automatic and, more importantly, it simplifies certificate management as Approov allows certificates to be updated directly in deployed mobile apps without the need for an app update.
We have written extensively about this and would encourage you to watch a recording of one of our recent MitM Attacks Become a Past webinar or, if you prefer, read our white paper on the same topic.
Topic 3: API Shielding
All 3 reports documented examples of OWASP Top10 API vulnerabilities, mainly related to authentication and authorization. It should come as no 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 and those you don’t.
Therefore, vulnerability testing and remediation is a necessary task, and both time and resources should be allocated to it in your engineering plans. Additionally, it’s important to acknowledge that this is an ongoing project, as any change you make to the API code may introduce a new vulnerability.
Of course, finding vulnerabilities during testing would be better than removing them during development, and that’s the process known as left shifting. Many vendors and tools are emerging to help with this.
However, given the scale of the effort and the ongoing nature of finding and remediating vulnerabilities, there is a need to protect your organization from vulnerability exploits in parallel. Considering that almost all API vulnerabilities are exploited via scripts, it should be clear that Approov can be deployed in this role as it ensures that API requests are only valid if they come from real mobile app instances, running on secure devices.
Shift left and shield right is an industry term that describes an appropriate approach to improve the overall security posture of mobile-centric businesses, although the shield right activity is arguably more urgent as it provides an immediate benefit in protecting the platform from vulnerability exploits offers. known and unknown.
To learn more about this topic and understand all the attack surfaces in your mobile channel, please watch our API Shielding webinar and read our Mobile App/API Threats white paper.
Although the safety reports cited at the beginning of this article are a litany of bad news and have spawned a great deal of negative press, there is a silver lining available for those who check.
Securing mobile apps and the APIs that serve them in a holistic, effective, and efficient manner is still a relatively new challenge, and the good news can be found by looking at companies like Approov, which are developing suitable solutions for some , deployed and further developed have time. To talk to us about your use cases and have a security expert explain where and how Approov can help, you can schedule an appointment with us here.
For fintechs new and old, now is the time to consider specific solutions to specific problems, safe in the knowledge that the majority of the vulnerabilities that are undoubtedly present in your apps and APIs today can be covered today. Definitely shift to the left over time, but please shield to the right first.
*** This is a Security Bloggers Network syndicated blog from Approov Blog written by David Stewart. Read the original post at: https://blog.approov.io/hacking-financial-apis-new-report-familiar-results