FEBRUARY, 2019

DON’T PLAY RUSSIAN ROULETTE WITH YOUR APPS

© In

side

Sec

ure

- 20

19 -

All

right

s re

serv

ed

2

TABLE OF CONTENTS

The Power

The Risk

Architecture of a Secure Mobile Application

Code Integrity and Protection

Whitebox Cryptography

Data Storage

Programming Language

Android

IOS

ARE YOU PLAYING RUSSIAN ROULETTE?

BEST PRACTICES TO DEVELOP A SECURE MOBILE APPLICATION

OPERATING SYSTEM CHALLENGES

CONCLUSION

45688

1011131315151718

3

Smartphones are becoming a prime target for hackers, the valuable data they contain and their vulnerability encourage hackers to focus their attacks on these devices.

These hackers are intelligent and highly resourced so they can exploit weaknesses in the mobile platforms, operating systems and applications.

Research suggests that half of mobile users will not take any steps to protect their devices, even when aware of the risks; and so-called operating system defences are easily broken down. Mobile application developers need to be aware of this; and have to assume that the devices their applications are running on have been - or will be - compromised. This means that developers need to take responsibility of making their applications protect themselves.

If developers do not take responsibility, the $124 billion spent globally on IT security could be rendered futile by weak mobile apps.

Taking responsibility protects the applications from threats including:

• Malware; • Insecure devices; • Repackaging attacks; • Reversing Engineering.

To protect their services and their users, mobile application developers need to ensure that the following techniques have been applied to their applications:

• Code Integrity Checks: Prevents any unauthorized changes to the mobile app. • Code Obfuscation: Hides the critical and sensitive portions of a mobile app. • Whitebox Cryptography: Enables secure encryption and data storage on any platform. • Processor Native Code: Provides the solid foundations to build the protection layers.

Inside Secure’s Code Protection and Whitebox Tools combine these techniques into a comprehensive package that has been deployed in more than 400 million mobile applications to secure financial, entertainment and gaming services. These applications have successfully gone through extensive penetration and attack testing by external security labs.

BEST PRACTICES TO DEVELOP A SECURE MOBILE APPLICATION

EXECUTIVE SUMMARY

4

ARE YOU PLAYING RUSSIAN ROULETTE?

It has become a cliché to say that our lives channelled through a mobile phone screen, but in many cases it is true:

we talk to our friends through social media apps, we manage our money through banking apps, we view the latest television through streaming apps, and we entertain ourselves with the latest video games. To put it into context, the average US adult spends over four times more in front of a mobile screen than seven years ago1 .

1 https://www.emarketer.com/Chart/Average-Time-Spent-per-Day-with-TV-Mobile-Devices-by-US-Adults-2013-2020-minutes/219574 and https://www.odwyerpr.com/story/public/5534/2015-10-08/report-growth-rate-mobile-use-finally-slowing-down.html

Figure 1 - U.S. daily Mobile usage time (minutes)

5

The growth in usage means that there is an increase in sensitive data being installed, stored and generated on mobile devices. That data is the users’ personal data – governed by privacy legalisation like GDPR; it is the Intellectual Property in the apps; and it is secrets like cryptographic keys that are used to secure both the data on the device and access to backend services.

Of course, criminals are fully aware of the value of the data stored on mobile devices - across a wide range of industries and sectors. These criminals are intelligent and highly resourced so can exploit weaknesses in mobile operating system and application security.

It is not just the raw data held within mobile applications that is valuable to criminals, mobile applications provide a path straight through perimeter defences of IT systems. This means that a weak mobile application will be the weak point in wider IT security

systems. If an attacker can control a mobile application, they can use it (or the data within it) to make apparently legitimate requests of the supporting IT systems – comprising not just the mobile application but also the whole IT system. The $124 billion spent globally on IT security2 could be rendered futile by weak mobile apps.

Research suggests that half of mobile users will not take any steps to protect their devices3 ; and so-called operating system defences are easily broken down. This means that mobile application developers need to assume that the devices their applications are running on have been - or will be - compromised. It therefore falls on the developers to take responsibility of making their applications protect themselves.

This paper will help developers, product managers and risk professionals to understand the steps required to secure mobile applications.

The Power

Organisations that embrace mobile can see substantial benefits.

They increase engagement with their customers and so increase revenue. It can also reduce cost by providing customers with convenient self-service solutions.

That word “convenient” is the key to unlocking the power of mobile.

Many organisation have developed mobile apps and expected them to be successful just because it is on mobile and "mobile is cool". These apps and services tend to fail and fail quickly.

Services that are successful on mobile are those that provide value to their users through convenience. It is a theme that runs through the history of mobile, with countless examples. When analysing the post popular apps and services, they all have convenience at their core.

2 https://www.forbes.com/sites/rogeraitken/2018/08/19/global-information-security-spending-to-exceed-124b-in-2019-privacy-concerns-driving-demand/#5a1ffe307112

3 Kaspersky, 2015

6

The Risk

Unfortunately, unlocking the power of mobile does not come without risk.

The challenge is to mitigate the risk without impacting on the convenience of the service.

Mobile devices are open and connected computing platforms. This makes the applications running on them vulnerable to attackers. These attacks can take many different forms.

Malware

Malware is malicious software running on the mobile device. It will typically have one of two purposes: it will steal processing power from the mobile device – building a botnet; or it will breakdown the operating defences to attack or spy on other applications running on the phone.

Typically, the owner of the device is not aware of the malware’s presence.

There are different routes malware takes to deploy itself onto the devices. It may be hidden in an apparently legitimate

application or it may use vulnerabilities in other software to force the execution of malicious code that downloads and installs the malware5 .

Rooting / Jailbreaking

Rooting or jailbreaking a device is the act of breaking down the operating system defences designed to isolate (aka sandbox) each application. Rooting is the Android terminology; the iOS ecosystem uses jailbreaking.

Rooting may be performed deliberately by users as they prefer the extra freedom of having a rooted phone. It can also be performed by malware as the first stage of its attack on another application.

It is common practice by applications to try to detect rooted or jail broken devices. Unfortunately, it is impossible to do this reliably – attackers can easily cloak the characteristics of rooting; so while root detection can be a useful risk indicator, it should not be the solely relied upon for app security.

4 https://bgr.com/2018/11/25/google-play-store-apps-removed-malware-found/

5 https://www.csoonline.com/article/3339776/security/android-phones-remotely-hackable-just-by-viewing-nasty-png-image.html

7

Reverse Engineering

Given the open nature of the mobile platforms, it is easy for an attacker to extract the application onto a desktop computer to analyse its contents. This reverse engineering is carried out to extract secrets from the app.

Secrets in the app include:

• User personal data;

• Cryptographic keys and algorithms used to secure data on the device and being transferred to/from backend services;

• Details of back-end service APIs and their authentication methods6;

• Intellectually Property such as sensitive algorithms;

• Weaknesses that an attacker can exploit.

Repackaging

One of the most common attacks is to repackage a legitimate application embedding malicious code. Estimates suggest that there are over 30,000 repackaged apps on Google Play7. The highest profile attack of this nature used Whatsapp as its starting point8 .

The aim of a repackaging attack is to trick a user into installing the malicious code. Starting with a legitimate application means the repackaged one can look, feel and act just like the original. It becomes impossible for the user to tell the difference between the original and the malicious one.

This can be a way for the attacker to deploy malware – research shows that 86% of malware is delivered through repackaging attacks9. More worryingly, repackaging also provides attackers with a way to put a “wiretap” into the application – allowing them to monitor the user and the application.

6 https://www.wired.co.uk/article/stevie-graham-teller-open-banking-barclays-hsbc

7 https://www.helpnetsecurity.com/2013/11/19/12-of-apps-on-google-play-are-repackaged-to-deliver-ads-collect-info/

8 https://bgr.com/2017/11/05/whatsapp-android-google-play-store-fake-app/

9 A Large Scale Investigation of Obfuscation Use in Google Play by Warnke et al

8

BEST PRACTICES TO DEVELOP A SECURE MOBILE APPLICATION

Architecture of a Secure Mobile Application

Given that the platforms cannot protect the application, mobile application developers should build self-defending programs so that deployed instances can protect themselves from hackers, pirates, targeted malware, insider betrayal and even hardware errors.

The best way to achieve this is to consider security at the start of any development rather than try to add it at the end.

A recent study by Ponemon Institute10 on mobile applications revealed that 77% of organizations cite “rush to release” pressures as a primary reason why their mobile applications contain vulnerable code. The trouble with this approach is that they are trying to add security at the end of the development. The earlier and more embedded security thinking is in the development process, the more effective it will be.

Security does not need to be applied uniformly.

In fact, it would be impossible to apply maximum security to every line of code and byte of data.

By identifying security sensitive assets (data, crypto keys, IP, etc.) within the mobile applications allows security to be focused and the software architected correctly. This allows developers to balance security against other competing requirements. After all, engineering is the art of compromise.

10 http://ibm.co/1F595xW

9

Applications are built out of multiple components (often called libraries). When architecting an application, it is important to identify which of those components are security sensitive. Ensuring sensitive data never leaves the components identified as security sensitive in an unencrypted form, means the other components do not become a risk and allows developers more scope to balance requirements in the other components.

The security sensitive components can, of course, contain code and data that is not necessarily sensitive - it just happens to have been secured. In fact, many would argue it is good security practise to build the majority of the business logic into the secure components.

Stepping back from the component level, it is also important to use code protection technologies, such as anti-tamper and obfuscation, to bind the different components into single solid application.

This is good practise, as recommend by the likes of Gartner11 , as it protects the application as a whole, as well as protecting assets across the application and provides additional protection to the secure libraries.

11 Toolkit: Security Checklist for Mobile App Developers, August 2018

Figure 2 - Architecture of a Secure Mobile Application

10

Code Integrity and Protection

The security of any application has to be built on a strong foundation.

That foundation is anti-tamping (aka code integrity checking). Anti-tampering ensures the code executing is exactly the same as was published by the application developer. It is not possible to trust other security measures if an attacker can change them, anti-tampering protects against this.

Powerful anti-tamper that is validating the executing code as is running provides many security benefits. As mentioned above, it anchors other security measures – this is why it is required as the foundation of app security. It also stops repackaging attacks and greatly restricts the damage malware can do – if it is not possible to insert malicious code into the application, the executing code cannot be changed or tampered.

One of the biggest but least recognised benefits of anti-tamper is stopping the learning phase any attacker will undertake before performing an attack. Given the open nature of mobile devices, it is not difficult for an attacker to achieve unlimited access to an application – for example they can simply lift the application from a compromised device. Once a hacker has unlimited access to the application, they can perform a wide range of attacks on the application to understand its operation and weaknesses. On their own, these attacks may be of limited risk to the application provider but if they reveal how to perform a mass attack across the installed user base, then the risk could be substantial.

To provide maximum protection but limited performance impact, an anti-tampering solution should intelligently analyse your code, then automatically inject an optimised network of software “checks”. This network of checks forms a nervous system that reacts when the software is tampered with. Developers should never have to interact with the nervous system; it should all be handled automatically as part of the protection process.

Intelligent analysis and optimization enables the system to distribute hundreds and thousands of checks throughout the code, checking the program and each other, while typically having a negligible impact on performance. These checks are resistant to detection and automated removal techniques. If any change is made to the executable, multiple checks detect the change and respond.

Anti-Tampering

Anti-tamper technology:

• anchors other protections (e.g. root detection) within the app;

• restricts reverse engineering attempts;

• stops malware inserting hooks into an app;

• blocks repackaging attacks.

11

Code Obfuscation Obfuscation is often used as a generic term for code protection; but more precisely, it is the act of taking well engineered code and making it difficult to read or understand.

With the move from the web towards native mobile applications, very significant quantities of sensitive logic and key Intellectual Property (IP) has shifted from backend servers behind corporate firewalls to millions of mobile devices. At the same time many new features deployed on such devices contain commercially sensitive algorithms, security-sensitive features that seek to fingerprint or authenticate devices and users, or those that decrypt streams of sensitive content are now included in applications

Within applications, these sorts of routines can be routinely examined using a wide array of freely available debugging and hacking tools, creating significant risk of hacking and IP theft.

Powerful obfuscation dramatically increases the complexity of reverse engineering an application’s sensitive functions, significantly hampering attempts to statically or dynamically analyse their operation, making

analysis impractical for all but the most skilled attacker and ensuring that even elite hackers will move on to softer, less frustrating targets.

The obfuscation technology used should allow flexibility to target specific functions and provide the ability for complexity to be tuned to maximize efficacy while meeting performance and code size requirements.

Strong obfuscation requires multiple different techniques to be interwoven. This includes control flow obfuscation to make it difficult to trace through an application, symbol name obfuscation to hide tell-tale identifiers, decoy code to confuse an attacker, string and literal encryption to remove clues about the nature of the code, and opaque predicates and expressions ensure that the code must be dynamically analysed if any attempt at understanding is to be made.

Applied correctly, obfuscation can be a powerful tool to limit an attackers understanding of an application.

Whitebox Cryptography solves the problem of securing cryptographic operations on exposed devices like mobile phones.

For critical secret processing, Whiteboxes dissolve secrets into the code and obscure

algorithms. This means that even when an attacker has full access to the application, they cannot determine cryptographic keys.

Whitebox solutions come in two models: those that provide a pre-generated Whitebox and those that provide the tools for developers to create their own Whiteboxes.

Whitebox Cryptography

Obfuscation technology Restricts reverse engineering attempts.

12

The former has advantages that the effort to create the Whitebox is pushed to the solution provider. The latter gives a great degree of flexibility and freedom; any algorithm (not just the crypto the solution provider supports) could be Whiteboxed and algorithms can be chained together to increase the security of an operation.

The other point to remember is that whoever creates the Whitebox controls the cryptographic keys that unlock the Whitebox. If the application developer

creates the Whitebox then they are the sole entity to have those keys. If the solution provider creates the Whitebox, then they have the keys.

As with obfuscation, Whitebox technology is only one layer in the defences and to reach the highest level of security, it needs to be used with a powerful anti-tamper solution. The highest protection comes when the anti-tamper solution can fully integrate the

Whitebox with the rest of the application. To fully anchor the Whitebox into a secure component, it is important to have the Whitebox’s source code so it can be compiled along with the rest of the secure component.

Whitebox technology

• Protects secrets and data within applications;

• Hides cryptographic keys.

Figure 3 - A classic dynamic whitebox

13

Sensitive information must be protected in use, at rest and in transit. “In use” is covered by the techniques discussed above.

“In transit” requires secure communication protocols, the mobile end-point of which should be within a secured component.

Not all programming languages are created equal.

It is important to recognise that the way code is compiled and executed can impact on the resulting security of the application.

The closer the complied code matches the executable code, the stronger the protection that can be applied. Successful application security relies upon a strong

foundation of anti-tampering – ensuring the published code executes as intended. This is possible if the executed and published code are the same. If there is “runtime compilation” or the code is interpreted, there is no way to distinguish this intended modification from malicious tampering.

This means that the most sensitive parts of the application should be developed using static languages that compile to processor native code.

When it comes to “at rest”, it is important to design the storage of an application in such a way as to minimise the critical information (e.g. passwords) residing directly on a device. For the data stored on the device, it must be stored securely within encrypted storage that cannot simply be copied of the device. If the data can be copied and then read on another device, it leaves the app open to cloning attacks.

Whitebox Cryptography is powerful technology for creating secure storage implementations.

Secure storage:

• Protects data at rest; • Stops apps being cloned to other devices.

Data Storage

Programming Language

14

12 Inside Secure’s recently launched Code Protection Tool for Android brings significant advances to the level of protection that can be provided to Java and Kotlin applications (https://www.insidesecure.com/Company/Press-releases/Inside-Secure-delivers-Application-Protection-to-defend-against-malicious-attacks-on-Android-Java-devices).

13 Recent developments also allow Kotlin to be compiled to Native but this is not common practise.

In many cases it makes development sense to use bytecode or scripted languages. On some platforms (e.g. Android) there will be little option but to use Java or Kotlin for certain things - particularly User Interfaces (UIs) and some other operating system services. Bytecode and scripted languages, can also provide good cross platform support, reducing development cycles.

The way to balance these benefits is to consider the code in modules as described in section 2.2. That allows the correct development language to be selected for each task.

Language Type Examples Security Advice

Native C, C++, Objective-C, Swift By compiling to machine code, these languages provide the best choice for security critical operations.

Bytecode12 Java, Kotlin13 , C# The runtime compiled nature of these languages makes it difficult to build a strong security foundation.

Script Javascript, HTML5 The delivered code is pretty much cleartext. This makes these languages the hardest to secure.

15

14 http://www.technewsworld.com/story/79458.html

OPERATING SYSTEM CHALLENGES

Android

With the advent of smartphones, the mobile ecosystem quickly converged onto a duopoly of Google’s Android and Apple’s iOS.

Both platforms bring unique challenges when it comes to securing applications hosted by them.

A recent study14 found more than 97% of the paid-for Android applications were vulnerable with many security issues.

This is in part down to a lack of consideration given to security issues by developers and in part down to the Java environment that Android encourages developers to work in.

The generic architecture of a secure mobile application described above also applies to Android (figure 5). It is acceptable to develop the standard components in Java or Kotlin; but the secure ones need to be developed in C++ using the Android NDK to allow strong anti-tamper to be applied to them.

Figure 4 - Android vs iOS market share

1%

28%

71%

Android

IOS

Other

16

Figure 5 - Architecture of a Secure Android Application

Java Bytecode and the Anti-tamper Challenge

Given the dominance of Android, the majority of mobile applications are written in Java or Kotlin. The problems that these languages present to secure application development are significant.

Successful application security must rely upon layers, with anti-tampering of application code the most effective foundation to build the other layers.

A crucial part of anti-tampering is code integrity checking, which verifies that genuine application code is being executed and that a hacker has not modified it. This can be achieved with compiled languages like C and C++ because the code that executes is identical to the code that was originally compiled.

This is challenging with “runtime compiled” languages, like Java and Kotlin, because the code shipped is in bytecode form. This bytecode is not executed directly when

the application runs. When an application runs, the language runtime compiles the bytecode into machine code and executes that. Given that there is no way to distinguish this intended modification from malicious tampering, it is impossible to deliver strong runtime anti-tamper protection of Java bytecode.

A Formidable Hacking Toolkit

As well as evading anti-tampering, a hacker can modify the language runtime to transform all of the bytecode in a Java application, right down to the instruction level.

These transformations can be used for a wide range of purposes, including:

• Making large-scale behaviour changes to the application;

• Injecting runtime analysis mechanisms into every part of the code;

• And even adding features to the application

17

The danger is that a hacker can perform these transformations anywhere from the bytecode through to the compiled machine code. Modifying the bytecode is very simple and powerful enough for most tasks (and the hacker’s additions are helpfully optimised by the runtime), whereas modifying the machine code allows the hacker to do almost anything.

The real issue this causes from a security perspective is that it allows hackers to implement extremely efficient emulation-level analysis tools, which they can use against any security measures the application contains. This significantly raises the bar on the security measures that the developer needs to employ, if they are to remain effective - defences essentially have nowhere to hide from this type of attack.

Bitcode

Bitcode15 is an intermediate representation of application code – it can be considered halfway between source code and machine code.

Apple are moving to model where developers publish Bitcode to the AppStore rather than machine code. Apple will then do the final recompilation prior to downloading the application to devices.

This is already mandated for watchOS and tvOS. It is optional for iOS.

The advantage of Bitcode is that it allows Apple to optimise the application with the latest version of their toolchain and for the exact target device.

Given that anti-tamper is the foundation of securing an app, and anti-tamper relies on matching the executing code to a known master copy, anti-tampering Bitcode is challenging. In effect, the master copy is not known prior to the developer publishing the application.

Good security practise is to lock down as much of the app as possible before publishing. That means, where possible, Bitcode should not be uploaded to Apple.

Method Swizzling

The Objective-C method swizzling attack takes advantage of Objective-C’s dynamic typing to hook method calls, allowing a hacker to control the behaviour of an application at the method level.

This approach has obvious limitations but hackers have used it successfully for a number of purposes, the most well-known being to disable jailbreak detection code in iOS applications.

The leading protection for iOS applications can detect when a swizzling attack is in progress and react to the attack rendering it pointless.

IOS

15 Inside Secure’s new Bitcode protection technology provides a unique approach to protecting iOS applications distributed as Bitcode

18

CONCLUSIONMobile applications are already central in most people’s life i.e., the primary method for accessing banking, healthcare, entertainment and increasingly for payment services.

As a result, sensitive data and functionality are increasingly exposed to theft and subversion. We have seen from the Ponemon Institute study how organizations “rush to release”, putting their users and consumers sensitive data vulnerable for attacks. This attitude needs to change, as security of mobile applications should be weighed equally, if not more, than the data centre itself. To protect their employers and users, mobile application developers need to ensure that the following techniques have been applied to their applications to secure them from any potential leak of sensitive data:

• Code Integrity Checks: Prevents any unauthorized changes to the mobile app.

• Code Obfuscation: Hiding the critical and sensitive portions of a mobile app.

• WhiteBox Cryptography: Enables secure encryption and data storage on any platform.

• Processor Native Code: Provides a solid

foundation from which to build the security layers.

Inside Secure’s Code Protection and Whitebox Tools combine these techniques into a comprehensive package that has been deployed in more than 400 million mobile applications to secure financial, entertainment and gaming services. These applications have successfully gone through extensive penetration and attack testing by external security labs.

The tools allow mobile applications to securely process and store sensitive data in a hostile mobile environment. It simplifies the integration of security into mobile applications and allows them to defend against malicious attacks. Application providers in financial, banking, retail, healthcare and enterprise industries can benefit from the Inside Secure security solution.

For further details about Code Protection please visit https://www.insidesecure.com/Markets/Mobile-App-Security

To learn more about Inside Secure’s unique protection for Android Java and Kotlin applications, please visit https://www.insidesecure.com/Company/Press-releases/Inside-Secure-del ivers-Appl ication-Protection-to-defend-against-malicious-attacks-on-Android- Java-devices.

About Inside SecureInside Secure (Euronext Paris – INSD) is at the heart of security solutions for mobile and connected devices, providing software, silicon IP, tools, services, and know-how needed to protect customers’ transactions, ID, content, applications, and communications. With its deep security expertise and experience, the company delivers products having advanced and differentiated technical capabilities that span the entire range of security requirement levels to serve the demanding markets of network security, IoT and System-on-Chip security, video content and entertainment, mobile payment and banking, enterprise and telecom. Inside Secure’s technology protects solutions for a broad range of customers including service providers, operators, content distributors, security system integrators, device makers and semiconductor manufacturers.

For more information, visit www.insidesecure.com