The trend of finance going mobile is unstoppable. According to the 2021 Mobile App Trends report from Adjust, there are 2.5 finance apps on average installed per user.
Global online payments have reached USD 1.39 billion in 2020 and are projected to reach USD 1.68 billion this year, registering an astounding revenue increase by 250% from 2020 to 2025.
As mobile banking and finance grows in popularity, cybercriminals have also directed their attention to mobile applications. In the 2022 Security Report published by Check Point, cyberattacks targeting the finance/banking sector have seen an annual growth of 53% in 2021. Given the escalating scale of cyberattacks, 77% of finance apps have at least one critical or high severity vulnerability according to Intertrust’s 2021 State of Mobile Finance App Security Report.
The stats below shows Intertrust’s investigation into the risk types and the preparedness of financial apps facing rising cyberattacks:
On the other hand, AppSec standards have been through some changes recently, impulsed by the PSD2. In these circumstances, there is a strong need for the maturity of the mobile app security landscape.
Is your organization ready and well-equipped to enter this game?
To help organizations efficiently develop and secure their mobile apps, the OWASP (Open Web Application Security Project®) has put together highly valuable resources:
In order to help organizations to prioritize their work in terms of mobile app protection and to understand the exploitability and the business impact of each threat, OWASP has put together a top 10 of the Mobile App Risks. Although this list is dated now (2016), it remains highly relevant:
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.
Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or another repackaged app acting on the adversary’s behalf that executes on the mobile device.
When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s travelling across the wire.
Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.
Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary’s behalf.
Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.
Threat Agents include entities that can pass untrusted inputs to method calls made within mobile code. These types of issues are not necessarily security issues in and of themselves but lead to security vulnerabilities. For example, buffer overflows within older versions of Safari (a poor code quality vulnerability) led to high-risk drive-by Jailbreak attacks. Poor code-quality issues are typically exploited via malware or phishing scams.
Typically, an attacker will exploit code modification via malicious forms of the apps hosted in third-party app stores. The attacker may also trick the user into installing the app via phishing attacks.
An attacker will typically download the targeted app from an app store and analyze it within their own local environment using a suite of different tools.
Typically, an attacker seeks to understand extraneous functionality within a mobile app in order to discover hidden functionality in backend systems. The attacker will typically exploit extraneous functionality directly from their own systems without any involvement by end-users.
The Mobile Application Security Verification Standard (MASVS) is a standard for mobile app security. Depending on the apps’ features and the required level of protection, these standards can be combined as follows:
At eShard, we have automated a wide range of security tests to be run on your mobile applications. You can run preset OWASP campaigns to verify how far you are from the OWASP compliance. Want to give it a try?
> MASVS-L1: Mobile Application Security Verification Standard - Standard Security
Any mobile application should at least follow this standard. It gathers the basic best practices when it comes to sensitive data management (e.g. payment or user data), code quality, and much more.
> MASVS-L2: Mobile Application Security Verification Standard - Defense-In-Depth
Suited for mobile applications handling PII (Personally Identifiable Information), payment information, or that allow users to move funds. This is also recommended if you’re looking for specific regulatory compliance such as:
> MASVS-R: Mobile Application Security Verification Standard - Resilience
This section is critical to be protected against vulnerabilities coming from the user’s mobile phone. As a mobile app editor, you need to make sure the app you provide to your users is under control: how is it supposed to behave on a rooted phone? Can it detect a code injection attempt? Does it prevent the use of debuggers or emulators which are tools attackers may use to reverse-engineer your app?
To help the app testers during the mobile app security testing phase, OWASP has put together a series of testing cases, broken down into 8 categories:
These test cases can be either run manually by your Engineers or Security teams or can be automated by a tool like esChecker. Actually, some of them can not be automated, but how would your teams feel if a decent part of them could be?
You can also use the OWASP Mobile App Security Checklist to identify precisely the use cases to be tested against each MSTG:
Now you know:
eShard is the only MAST solution on the market to cover OWASP-R criteria (Resilience layer of the MASVS), from the binary, and not from the source code. We want to use the same resource a potential hacker would use to harm your business.
It helps you make the change from DevOps to DevSecOps, which leads to an automation of the Security Testing for every new build of your mobile app before it does live on the stores.
With years of reverse engineering experience, our team has gathered a specific test suite to stress mobile applications.
And this is performed leveraging our dynamic testing technology: the application is tested when it is running by recording a sequence of operations and replaying it as many times as necessary, allowing to test 100% of the code at runtime.
Have you ever thought of the potential threats mobile applications could represent? There’s a reason why In-App Protections are now getting a real thing in all organizations, regardless of their size, for two main reasons:
Did you know that some people are skilled enough to inject code into their mobile phone to fake a particular behavior, such as pretending to pay for a premium option, increasing their gaming wallet, accessing protected spaces of your app pretending to be logged in as a genuine authorized user, etc?
If you provide a non-secure application to your users, you expose them to critical risks. Some apps (maybe yours?) store personal information or credentials within the mobile phone memory. If you don’t want your Data Protection Officer to be mad at you, make sure that the data you manipulate on behalf of your users is securely handled and stored.
Oh, and if you thought that Apple devices were less exposed than Android’s thanks to iOS, you are so wrong. Both Operating Systems are vulnerable. We highly recommend paying as much attention as possible to your entire mobile apps ecosystem. That’s why we’ve incorporated automated security testing for iOS and Android into esChecker, our MAST tool.
There are so many ways to harm your business if you don’t protect your mobile application:
> Use of rooted/jailbroken phones
Mobile phones are rooted by their owners because they want to gain full control over and access to their mobiles. Most of the time, they want to force the uninstallation of the default apps or the extra OS layer of the device manufacturers or get rid of Google services. This also leads to the uninstallation of the built-in protections of iOS or Android.
As a consequence, apps could potentially access every personal private and sensitive information used in your own app, if users have untrustful and malicious apps installed on their mobile phones.
> Hook attacks
Hooking an application is a way for an attacker to change the expected behavior of an application. By injecting some code, an attacker could change the data displayed on the app, or collect some sensitive information and save it or send it to an external space. An attacker can use this hooking technique to understand and the application works to exploit the breach in a more harmful manner. This allows misleading the users and compromises their trust in the mobile app.
> Emulators & Debuggers
The mobile application must prevent the usage of a debugger and an emulator in production. Attackers may use such tools to understand the way the app works and help them to reverse engineer it. You must make their job as hard as possible to preserve your protection.
> Coding best practices
when developing an application, there are some basics that you must follow:
With esChecker, you get immediate feedback covering a large range of requirements. Everything is summarized in a single report.
It is as easy as:
You can now dig into the OWASP Report, category by category, to understand the MSTG’s that require your attention to obtaining OWASP compliance.
Beyond your internal usage, the report can also be used as a demonstration of compliance.
We’ll be happy to show you how much time it saves and how relaxed you’ll become with this protection audit tool in your hands.