Mobile App Security: Uncovering the Risks of Secret Theft at Runtime

This is our second blog highlighting the results of the Approov Threat Lab Report.

In our previous blog we looked at why secrets such as API Keys should never be allowed to get in the hands of hackers, and we saw that the Approov Threat Lab found that the top finance apps immediately gave up an embarrassing amount of secrets without putting up much of a struggle.

The team also researched the runtime security of apps and I want to dig into that a little more in this blog. 

As a reminder, at the beginning of 2023, the Approov Mobile Threat Lab released research describing the automated inspection of the top 200 financial apps in four countries in terms of downloads: US, UK, France and Germany - a total of 650 unique apps which together serve millions of users and manage billions of dollars, euros, pounds and various cryptocurrencies. 

Secrets can be stolen in many ways. They can be taken from repositories, they can be exposed in app code or they can be intercepted when an app is running. In general, hackers apply a two stage process: first steal useful secrets and then use them to create scripts and bots to access APIs, in order to steal data and derail services. The full report is available for download here.

Source: Approov.io

Let's look at what the research found about how well protected apps were at runtime. 

The Runtime Problem with Mobile Apps

Even if keys and secrets cannot be easily reverse engineered from the mobile app code, hackers can get another opportunity to grab secrets at runtime by manipulating the app, the environment and/or the communication channel(s).  

The Threat Lab looked in particular at two runtime attack surfaces: “Man-in-the-Middle (MitM)”, where the communications channel between app and API is hacked and “Man-in-the-Device” where the client environment that the app is running in is manipulated.  

The team did not actually carry out runtime attacks (that would be hacking), but managed to get a surprising amount of information from static scans of the mobile app packages. This is a problem since hackers can do the same and easily and quickly see whether your app is vulnerable and which runtime extraction approach will work best.  

Man-in-the-Middle

The communication channel between apps and APIs presents a rich target for hackers via Man-in-the-Middle attacks, which can be used to bypass advanced security measures such as MFA. In the mobile use-case, deploying Transport Level Security (TLS) alone is not sufficient since tools installed in the device can easily intercept encrypted communications and interfere with the truststore.  

MitM attacks occur when an attacker intercepts or manipulates mobile device communications to gain access to sensitive information. They give attackers the ability to see any communications, modify messages, steal login details or certificates, even when traffic is encrypted. 

The Threat Lab researchers used tools to inspect the network_security_config.xml file. This file lets developers customize an app's network security settings in a declarative way separate from the app code. By inspecting this file it was possible to see: 

• Is certificate pinning in use? Certificate pinning is a way of limiting the set of acceptable certificates and is declared in the network security config file. Use of pinning shows that efforts are being taken to protect the channel.
• How limited are the types of Certificate Authorities trusted by the app? Information captured from the network security config file can tell which Certificate Authorities (CA) are trusted for an app's secure connections. It is a good sign if the configuration shows that apps restrict the CAs allowed and do not allow self-signed certificates. 
• Does the app permit cleartext traffic? If cleartext (i.e. unencrypted HTTP) is enabled, that is a signal that this channel is open to attack at runtime. 
• Which versions of Android are allowed? Permitting older versions can be used to an attacker's advantage. And the config file shows if older versions are permitted.

There is much more detail about this in the full report but in summary, the team classified apps as Protected against MitM if pinning is detected in the network config file and no other red flags are raised and Vulnerable to MitM if the config file showed no pinning was in place and CAs, cleartext traffic and Android versions were not being properly restricted.

Source: Approov.io

Man-in-the-Device 

Although rooting, jailbreaking or other manipulation of the mobile device environment do not always mean that malicious activities are taking place, these are common techniques used by attackers and pentesters to bypass security mechanisms and limitations imposed by the original version of the OS. 

Rooted and jailbroken devices pose a threat to device integrity because these actions enable the in-built security mechanisms to be compromised. The threat extends to mobile app integrity because the mobile app is now running in an environment that cannot be trusted. Another form of code tampering is to inject code at runtime by using an instrumentation framework. 

Such frameworks are used to hook into the key functions that, when manipulated, will produce different app behavior than expected or will change input parameters or output results. Fraudsters can intercept and modify genuine user instructions. 

Again the scanners used were able to make some basic evaluation of the types of protection in place to prevent runtime manipulation of the environment, for example determining the presence of: 

• Debuggers: Although these are important tools for development and test phases. They should never be in place in a production environment and their presence is a bad sign. 
• Packers and Protectors: Both of these are intended to prevent tampering and reverse engineering of mobile app code at runtime. If present, this can be viewed as a positive step toward protecting against runtime tampering. 

Some Runtime Research Findings 

The research found that: 

• Only 4% of the top finance apps implemented TLS certificate pinning and therefore were well protected against MitM attacks
• 20% of the apps were vulnerable to Man-in-the-Device attacks
• Only four apps or less than 1% were protected at runtime against both MitM by using pinning and against Man-in-the-Device manipulation by using a packer or protector. This means that more than 99% of the apps were signaling that they were exposed to attacks at runtime. 
• For MitM protection, twice as many US-only based apps are open to MitM than European deployed apps.

Is Your App Protected at Runtime? 

If you are reading this then you may be concerned about the security of your own app. You should be! Our investigation found that 99% of the app packages inspected indicated they were not implementing protections to prevent secrets such as API keys from being extracted from the running app. 

You can check your own app using the information in the report or feel free to contact Approov- we will be pleased to check your app for you. 

No doubt the development teams behind these apps try to shift-left” and remove vulnerabilities during development. They also apply obfuscation techniques. This research however shows that these approaches are grossly inadequate, eliminating neither the risk of “zero day” vulnerabilities nor preventing loss and abuse of API keys at runtime. 

Runtime security is needed, in order to protect the app, the client environment and the communications channel from the app to the cloud. Such a solution should: 

• Systematically check that any request to the API is genuine and not coming from a bot, a script or a repackaged app.
• Be able to detect any unsafe operating environments on the client device, such as rooted/jailbroken devices, apps running under debuggers or emulators, or whether malicious frameworks are present.
• Protect the path from the app to the API from Man-in-the-Middle attacks by systematically implementing certificate pinning.
• Use a secrets management solution that manages API keys and certificates securely in the cloud, delivers them “just-in-time” and allows them to be easily rotated via over-the-air updates as required.  

Such solutions are available, so there really is no excuse! Let's hope when the Approov Threat Lab does this exercise next time there is a marked improvement in the security of these critical financial apps!

Download the full report to see detailed data, country by country, category by category, as well as detailed recommendations on how to better manage and protect secrets in mobile apps.