In order to design a secure application, you must trust the foundation on which the application is built. Whether it’s an app and its operating system, firmware and its hardware, or a webpage in a browser – what happens when the foundation itself is not secure?   

R – Resiliency is an important topic in the MASVS, and some see “R” as a recommendation. At Digital.ai we believe Resiliency is the actual secure foundation in an otherwise insecure environment.  The “R” level is fundamental to protecting the L1 “Standard Security” level. Why? Because the standard security measures described in L-1 are too easily broken when apps are run in insecure environments. Insecure environments include jailbroken or rooted mobile devices, emulators, and even malware-infected devices.  All these environments are common. In fact, in a meta-analysis of the millions of app instances that Digital.ai protects, we have found that in any given week more than half of the apps we protect are put into unsafe environments. 

In the following blog post, we’ll discuss the Resiliency requirements and how to meet them using code obfuscation, monitoring, and RASP tools. We’ll also share insights and opinions about the L1 – Standard Security recommendations, their corresponding attack vectors, and the ways you could mitigate them.  Finally, we’ll discuss some challenges that occur when application engineers only follow the L-1 recommendations. We’ll start with the top-level or “Resiliency” requirements discussed in the MASVS.  

What is MASVS?

The Mobile Application Security Verification Standard, or “MASVS”, is a compiled list of different recommendations spread across multiple areas such as networking, storage, integrity, and more. These recommendations are classified into 3 main models: 

• MASVS-L1 – Standard Security: Consists of the best security practices, such as code quality, handling sensitive data, and interaction with the mobile environment. 
• MASVS-L2 – Defense in Depth: This model has everything included in MASVS-L1 plus additional recommendations based on the threat model for industries such as banking and healthcare that handle particularly sensitive data. 
• MASVS-R – Resiliency Against Reverse Engineering and Tampering: Protection from specific client-side attacks, such as tampering, modding, or reverse engineering.

How to Meet Resiliency Requirements  

MSTG-RESILIENCE-1  

The app detects and responds to the presence of a rooted or jailbroken device either by alerting the user or terminating the app. 

Digital.ai App Security detects many sophisticated rooting and jailbreak detection methods. We are even able to detect tampering in the operating system’s own code. 

MSTG-RESILIENCE-2  

The app prevents debugging and/or detects and responds to, a debugger being attached. All available debugging protocols must be covered.  

Digital.ai App Security provides full protection from debuggers. 

MSTG-RESILIENCE-3  

The app detects, and responds to, tampering with executable files and critical data within its own sandbox. 

Open Source cryptography libraries such as OpenSSL and Mbed-TLS are easy for attackers to detect.  Because our protections provide an arsenal of white-boxed cryptography algorithms using proprietary implementation, Digital.ai customers can efficiently implement integrity checks without leaving traces that are identifiable by attackers. 

MSTG-RESILIENCE-4  

The app detects, and responds to, the presence of widely used reverse engineering tools and frameworks on the device. 

Digital.ai Application Security detects the presence of dynamic instrumentation toolkits, frameworks, and reverse engineering tools such as FRIDA, FRIDA-gadget, and cycript.

MSTG-RESILIENCE-5 

The app detects and responds to being run in an emulator. 

Digital.ai Application Security can detect emulators such as QEMU by testing the CPU on which the protected app is being run. 

MSTG-RESILIENCE-6  

The app detects and responds to tampering with the code and data in its own memory space. 

Digital.ai Application Security detects and allows customers to create custom responses to tamper events. In addition, we can detect attempts to deflect tamper detection. We also detect memory editors such as GameGuardian and iGameGod – and we can detect memory scans when tampering acts are suspended. 

MSTG-RESILIENCE-7  

The app implements multiple mechanisms in each defense category (8.1 to 8.6). Note that resiliency scales with the amount, diversity of the originality of the mechanisms used. 

Digital.ai Application Security customers choose when and how to implement and invoke a variety of detection methods. For example, whenever a tamper event has been detected, either by a hidden background process or a plain integrity violation, the customer can choose their desired (RASP) response. The customer could shut down the application, force the end-user to re-authenticate using two-factor authentication, or flip the gravity setting in a game to zero, thus ruining the gameplay for the cheater while leaving no traces of the originating tamper-detection code. 

MSTG-RESILIENCE-8  

The detection mechanisms trigger responses of different types, including delayed and stealthy responses.  

Digital.ai Application Security lets the customer handle when and where protections are invoked with custom handlers and stealthy schedulers. We even supply a ‘crash’ function that abruptly quits the application without disclosing the origin of the code that caused the crash to take place.

MSTG-RESILIENCE-9  

Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.  

Code obfuscation is the original basis of our technology. We hold 6 patents related to code obfuscation, including the first patent ever awarded for code obfuscation. Digital.ai Application Security provides a code flattening solution that heavily obfuscates code. In addition, our white-boxed cryptography variables and constants are obfuscated and “live” in memory for short spans of time so that process dumping, or automatic crypto scanners, are unable to yield any benefits. We also provide runtime string obfuscation protection as well as full obfuscation to textual runtimes, such as Java and Objective-C.   

MSTG-RESILIENCE-11  

All executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis does not reveal important code or data.  

We provide different encryption solutions for both code and data. For example, on Android, Digital.ai Application Security support DEX encryption and native-shared-library encryption, paired with our white-box cryptography and our anti-debugging and instrumentation features would cover the product both statically and dynamically, leaving the attacker clueless. 

 MSTG-RESILIENCE-12  

If the goal of obfuscation is to protect sensitive computations, an obfuscation scheme is used that is both appropriate for the task and robust against manual and automated de-obfuscation methods, considering currently published research. The effectiveness of the obfuscation scheme must be verified through manual testing. Note that hardware-based isolation features are preferred over obfuscation whenever possible. 

Every obfuscation can be eventually defeated, but good obfuscators cannot be de-obfuscated automatically. Our obfuscation techniques include many active protections against de-obfuscators and emulators and are tested against all publicly available solutions, including JEB decompilers.

MSTG-RESLIENCE-13

As a defense in depth, next to having solid hardening of the communicating parties, application-level payload encryption can be applied to further impede eavesdropping.  

To eavesdrop on comms an attacker has 3 main methods:  

1. Perform a Man in the Middle (MITM) attack (Ex. removing certificate pinning) 
2. Tampering with the cryptography functions
3. Tampering with the network function 

Our Application Security solution detects any type of tampering, including tampering with the OS’s own code. Our Key and Data Protection product cannot be automatically detected using publicly available tools. Together these two solutions prevent the three methods outlined above.  

L1 Requirements

MSTG-ARCH-1 

All app components are identified and known to be needed.  

As software engineers we want our code to be as lean and efficient as possible. However, from a security point of view, removing unnecessary code could increase your attack surface. With mobile applications, lean code might be a bad thing. Smaller identifiable components are a jackpot for attackers. Code obfuscation is the first line of defense against static reverse engineering and coding in a lean and logical manner unfortunately makes life easier for attackers.

MSTG-ARCH-10  

Security is addressed within all parts of the software development lifecycle. It’s very easy to mark a check and move on to the next one.  

Security is really about awareness, and it always gets you to places that you least expected. Digital.ai Application Security protects your app both as a black boxed-not-to-tamper-with while providing strategic capabilities for you to rely on broken environments.

MSTG-STORAGE-1  

System credential storage facilities need to be used to store sensitive data, such as PII, user credentials, or cryptographic keys.  

Ideally, system credential facilities are the only reliable way to store sensitive data. But when the operating system has been tampered with, your storage facilities might not be reliable. You shouldn’t blindly rely on such secure stores to store secrets. Given many different techniques to identify rooting and JB, emulation, and more – and given custom actions per threat – an attacker could find himself struggling with the target while the next version is rolled out, having totally different protection mechanisms, thus frustrating the attacker. 

MSTG-STORAGE-10  

The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.  

Our white box cryptography offers automatic management of sessions key, and its evacuation. Besides cryptography, Digital.ai Application Security could also monitor for unallowed memory accesses from all over the operating system, allowing the customer to react with a custom-tailored logic. 

MSTG-CRYPTO-2  

The app uses proven implementations of cryptographic primitives. 

Cryptography implementations have many potential pitfalls, and one must be a field expert in order to implement such algorithms with the right caution in mind. Luckily, Digital.ai Application Security offers many different cryptographic algorithms which you can trust and use out of the box. There are some problems with known and proven cryptography libraries out there. Some libraries such as OpenSSL, Mbed-TLS, and those supplied by the Android and iOS operating systems have identifiable binary signatures, enabling attackers to pinpoint sensitive areas in the code, and even automate some processes, like certificate unpinning. Our anti-tampering solution protects against tampering scenarios where the targeted code uses such public libraries, while also offering a fully embedded, protected, and hidden cryptography solution inside the code which prevents attackers from viewing traces of our cryptographic solution. 

MSTG-PLATFORM-1  

The app only requests the minimum set of permissions necessary. 

Our technology grants many security features without requiring any special permission.

MSTG-CODE-1  

The app is signed and provisioned with a valid certificate, of which the private key is properly protected. 

Besides the operating system’s own integrity mechanisms, Digital.ai Application Security provides techniques for detecting and protecting from repackaging and in-memory patching.

Conclusions and Further Food for Thought

The MASVS is a veritable document that is written by volunteers and is indispensable to mobile software security vendors, their prospects, and their customers. We hope the text above provides our readers with a guide to the recommendations in both the L1 and R sections of the document. What follows are a few comments on some of the positions the MASVS takes in the “Forward”, particularly in the sections that distinguish between “security protections” and “security controls” that we believe merit further discussion. 

As alluded to in the introduction, the L1 requirements specified by MASVS form a foundation for application security and in particular security as it relates to privacy. We believe the foundation that the MASVS identifies can essentially be shaken by threat actors availing themselves of a few commonly available and frequently used emulators, debuggers, and dynamic instrumentation toolkits. For example, when the MASVS “Forward” states: “Software protections are not useless, but they can ultimately be bypassed, so they must never be used as a replacement for security controls” we counter that even if coders rely on the operating system for security and follow all the L-1 requirements to a tee, the L-1 requirements won’t deliver basic security functionality if the underlying operating system is broken (I.e., jailbroken or rooted). In this case, the opposite is true – using software protections such as tamper detection as outlined in the “Resiliency” section is the only reliable path to security.  Why do we believe this to be the case? Take, for example, your Keystore.  If your Keystore is fully exposed, then so is your application’s sandbox. In this case, the app and its files could be tampered with, repackaged, and instrumented – which could automate some processes, such as certificate unpinning and resource extraction. Additionally, there are cases where L-1 does not adequately protect privacy.  Mobile device malware, for example, might break the mobile operating system and make it easy for attackers to eavesdrop on instant messaging or VOIP apps by hooking strategic APIs or public frameworks through the identification of their binary signatures.

Also in the Forward, the MASVS claims that “Mobile security is all about data protection”.  This is often true, but not always. When you deal with sensitive information, like short-lived tokens, you must make sure this information is inaccessible. Security is more than privacy – it is often coupled with business continuity and revenue. Games, for example, where many in-game transactions take place, might affect the client side only. In addition, many game events force the server to trust user input for latency reasons. For example, shots in an FPS game involve many optimizations due to the inherent frequency of that specific event – usually one event per bullet. 

Client-side security is an ongoing cat-and-mouse game, when app developers/coders provide enough protections, the attacker will move on to a different target out of frustration. In addition to that, releasing frequent client updates with polymorphic obfuscation makes ongoing research of current applications worthless, thus frustrating attackers even more.

For more information on Digital.ai Application Security, click here.