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.
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:
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.
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.
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.
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.