Antitamper Mobile - Minded Security's Magik Quadrant for Mobile Code Protection

Minded Security's Magik Quadrant for Mobile Code Protection shows you our evaluation of the top vendors in this market, based on our research and experience.

Magik Quadrant

Why care about Code Protection?

There are a lot of reasons to care about Code Protection when dealing with Mobile Applications.
Every year a lot of money is lost due to piracy, intellectual property theft, cracked copyright mechanisms, tampered software, malware, and so on.

Mobile Apps are obviously installed client-side, therefore they are under the user's control.

For example, malicious users or competitors could decompile the application and analyse the result.
This could reveal valuable data as proprietary algorithms or intellectual property or allow the attackers to use that information to modify the code, repackage and redistribute it to create a "trojanized" clone of the App in a rapid fashion.

Moreover, if the App needs to run on untrusted devices, any malware could interact with the App at runtime level to steal data (credentials, credit card number etc.) or bypass security logic (local authentication, geo-restrictions, custom cryptography etc.).
As you can see a mobile App could be attacked at various layers and with very different goals in mind, creating a very complex problem for those who want to protect their products.
The following diagram shows some of the main attack types.

Why Apps reverse-engineering and tampering are easy?

Many developers do not know how easy mobile application reverse-engineering and tampering are. 

Since mobile Apps reside on user's devices and include valuable data inside  -  metadata, resources and even the code itself -, attackers could gather important information just by using publicly available tools.

In fact, according to the OWASP Top 10 Mobile Risks 2014,

“...it is extremely common for apps to be deployed without binary protection. The prevalence has been studied by a large number of security vendors, analysts and researchers.”

Without protections, it is quite easy to decompile an App to analyse its code (particularly on the Android platform) or to interact with it at runtime level on rooted/jailbroken devices.

How to make it harder?

To make the life harder to the attackers and help protecting valuable data, developers should:

• Harden DRM systems and licensing modules
• Reduce piracy
• Protect intellectual property and personal data
• Secure proprietary algorithms against analysis and reverse engineering
• Harden firmware and OS
• Protect cryptographic keys
• Protect the client side of encrypted communication
• Prevent malware intrusion

Therefore they have to deploy mobile applications with some kind of protection. To do this they could implement the following techniques:

• Code and Flow Obfuscation
• String and Class Encryption
• Debug code stripping
• Method Call Hiding (Reflection)
• Resource Encryption
• Debug Detection
• Root/Jailbreak Detection
• Runtime Injection Detection (Swizzle/Hook Detection)
• Tamper Detection
• Certificate Pinning
• Watermarking

There are many technical resources on Internet that describe at some level of detail how to implement one or more of the preceding techniques.
Moreover, there is some commercial tool which provides binary protection without requiring developers to implement their own custom controls.

Before going into detail about these tools it is worth noting that all these security controls do not give a guarantee that mobile applications are going to be 100% secure, but they can provide additional protection and make very hard to carry on reverse engineering, tampering and runtime attacks.

Interpreting the Magik Quadrant

The Magik Quadrant study performed on Code Protection solutions takes into account multiple criteria based on:

• Ability to Execute
• Completeness of Vision

Ability to Execute

Vendors must deliver strong functionality in the following areas of capability:

• Techniques implemented 
• After Sale Support

Completeness of Vision

Completeness of vision in the Code Protection market considers a vendor’s vision and plans for addressing buyer needs in the future.

• Cross-platform support
• Innovation
• Sale Strategy

Before proceeding it is worth noting that focusing on the leaders' quadrant isn't always the best choice. There are good reasons to consider market challengers. Moreover a niche player may support a specific needs better than a market leader.

Leaders

Leaders offer products and services that best cover current scenarios and are well positioned for tomorrow. They provide solutions that are cross-platform, and therefore with one vendor it is possible to protect many platforms.

Their complex solutions provide protection (through obfuscation, encryption, call hiding etc.), detection and reaction (in case an attack is detected).

Visionaries

In general, in any Magic Quadrant the Visionaries are the innovators. They understand well where the market is going and therefore they can provide innovative techniques to protect Apps in a cross-platform environment.

Niche Players

Niche Players, in our research, are vendors that do not offer, at the moment, a cross-platform solution but they are focused on a small segment.

Since they are offering platform-specific solutions, in some case they are able to provide innovative and specific solutions for that particular target.

Free and Open Source Solutions

The preceding analysis was done on commercial tools available on market.
In addition to this, we have also analyzed a free and open source solutions available for iOS: iMAS.
This solution has the main disadvantage that, since it is free and open source, it does not guarantee support. Nevertheless, we want to spend some words about it since it has some interesting features.

Vendor Strengths and Cautions

Arxan

This analysis pertains to Arxan's GuardIT.
Arxan is one of the most trusted names in application security. They provide protection against a widest range of static and dynamic attacks. The protection, provided by GuardIT, is implemented on different layers giving  the chance to select the desired level of security.

Strengths

• Cross-platform (Android, iOS, Windos Phone)
• Strong code protection
• Strong detection
• Capability to repair after damage

Cautions

• Price could be higher than expected

Company website: www.arxan.com

Metaforic

This analysis pertains to Metaforic Core, Authenticator, Concealer and WhiteBox.
Metaforic is one of the leaders in the application security market. They provide a cross-platform solution based on different "modules" (Core, Authenticator, Concealer and WhiteBox).

Strengths

• Cross-platform (Android, iOS)
• Strong Code and Flow obfuscation
• Strong cryptographic key protection

Cautions

• Price could be higher than expected

Company website: www.metaforic.com

WhiteCryption

This analysis pertains to whiteCryption's Cryptanium.
WhiteCryption provides code protection solutions since 2009, so they are relatively new on this market compared to Arxan or Metaforic. However they offer an innovative product that is designed to protect applications at all levels.

Strengths

• Cross-platform (Android, iOS)
• Strong Code and Flow Obfuscation
• Strong anti-tampering protection
• Anti-debug and anti-piracy features

Cautions

• White-box cryptography techniques are still adopted very little

Company website: www.whitecryption.com

PreEmptive

This analysis pertains to DashO and .NET Obfuscator.
The first version of DashO was released in 1998 and .NET Obfuscator was initially released few years later. Therefore PreEmptive has a long experience in Code protection.

Strengths

• Cross-platform (Android and Windows Phone)
• Strong code and flow obfuscation
• Watermarking
• Tamper prevention and reaction

Cautions

• No iOS support

Company website: www.preemptive.com

GuardSquare - Saikoa

This analysis pertains to DexGuard.
GuardSquare is very famous since they develop and support ProGuard, that is the successful open source obfuscator for the Java language. DexGuard is derived from it.
They have a great experience in Java and Android platform.

Strengths

• Large adoption among our customers
• Strong code optimization and obfuscation 
• Anti-tamper detection

Cautions

• Available only for Android

Company website: www.saikoa.com

Licel

This analysis pertains to Licel's DexProtector.
Licel is a new competitor in code protection. Its product, DexProtector, is designed for comprehensive protection of Android-applications against reverse engineering and tampering.

Strengths

• Affordable for our clients
• Strong code obfuscation
• Anti-tamper detection

Cautions

• Available only for Android

Company website: www.licelus.com

Bangcle - SecNeo

This analysis pertains to AppShield service. Bangcle provides a service that permits to developers to upload its APK on Bangcle's server and they provide fully automated App shield services. The whole process takes about one hour or less to complete.

Strengths

• Very simple use
• Anti-debug and Anti-tamper features
• App Data Encryption

Cautions

• Available only for Android

Company website: www.secneo.com

Smardec

This analysis pertains to Smardec's Allatori.
Smardec's main goal is to offer you high quality services and products at a reasonable price. Allatori first version was released in 2006 and it has reached these goals.

Strengths

• Strong code and flow obfuscation
• Watermarking
• StackTrace restoring

Cautions

• Available only for Android
• Only code protection/obfuscation   

Company website: www.smardec.com

Zelix

This analysis pertains to Zelix KlassMaster.
Zelix has a long story and experience in code obfuscation. Since its release in 1997, the Zelix KlassMaster Java code obfuscator has been continually developed to keep it at the forefront of obfuscation technology.
This solution provides a Java code obfuscator but it does not implement other protections such as those against tampering tries.

Strengths

• Strong code and flow obfuscation
• Strong Call Hiding
• Affordable for our clients

Cautions

• Available only for Java (Android)
• Only code protection/obfuscation

Company website: www.zelix.com

iMAS

This analysis pertains to iMAS.
This solution is free and open source, available on GitHub, and it provides modularity as the main feature. In particular the iMAS project is composed of many components that developers could include inside their project and every module provides a different feature. So it is up to the developers selecting the desired components and include them in the project.

Strengths

• Free
• Anti-tampering protections
• Code encryption

Cautions

• Available only for iOS
• No after sale support

Company website: project-imas.github.io

SSL MiTM attack in AFNetworking 2.5.1 - Do NOT use it in production!

During a recent mobile application security analysis for one of our clients, we identified a quite unobvious behaviour in apps that use the AFNetworking library.

It turned out that because of a logic flaw in the latest version of the library, SSL MiTM attacks are feasible in apps using AFNetworking 2.5.1.

The issue occurs even when the mobile application requests the library to apply checks for server validation in SSL certificates.

Given that AFNetworking library is one of the most popular networking library for iOS and OS X and it is used by Pinterest, Heroku and Simple among others, the problem could affect a very high number of mobile users.

Here's the usage of AFNetworking library on Github:

Github statistics for the AFNetworking library

Although the vendor has been aware of this issue since February 13th, 2015, there's still no official patch for it.

---

Update 27.03.15: AFNetworking patched the issue in version 2.5.2 a few hours after this post, we appreciated that.

Update 22.04.15: As correctly pointed out in this post (English version) by mala, AFNetworking 2.5.2 cannot still be considered secure, since it  does not enforce hostname validation by default.
We did not stress such circumstance in our blogpost as we were optimistically assuming that developers read the validatesDomainName property documentation, stating:

"- Whether or not to validate the domain name in the certificate's CN field. Defaults to `YES` for `AFSSLPinningModePublicKey` or `AFSSLPinningModeCertificate`, otherwise `NO`."

This default behaviour is present and documented since the first introduction of the property, that is from version 2.1.0.
Since the library does not verify by default that the hostname of the request matches to the hostname in the certificate, an attacker could use an arbitrary certificate signed by a trusted CA and successfully perform a MiTM attack.

In other words, if you're using a version of AFNetworking which is >= 2.1.0 and <= 2.5.2, then you should be vulnerable by default, unless you set validatesDomainName to YES.

The "new" issue was addressed in AFNetworking 2.5.3, where the default value of validatesDomainName has been properly set to YES under all security policies.

---

 

The Issue

On the 6th of March, when looking at the tested application source code, we identified the following part:

#if TARGET_IPHONE_SIMULATOR && defined(DEBUG) 

   [AFSecurityPolicy setAllowInvalidCertificates:YES] 

#endif 

SSL certificate validation was disabled if and only if the build target was the iPhone simulator and the DEBUG flag was set. Let's remind that the default value of the allowsInvalidSSLCertificate property is NO.

We tested the app on a real device and, unexpectedly, we found that all the SSL traffic could be regularly intercepted through a proxy like Burp without any intervention!

Further investigation led us to a particular part in AFNetworking code where trust evaluation was somehow disabled.

After few minutes, we figured out that there was a logical bug while evaluating trust for SSL certificate, whose consequence was to completely disable SSL certificate validation.

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain 

method within the AFSecurityPolicy.m file: 

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
      forDomain:(NSString *)domain
{
  NSMutableArray *policies = [NSMutableArray array];
  if (self.validatesDomainName) {
     [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL(true, (__bridge CFStringRef)domain)];
  } else {
     [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
  }

  SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);

  if (self.SSLPinningMode != AFSSLPinningModeNone &&
 !AFServerTrustIsValid(serverTrust) && 
!self.allowInvalidCertificates) {
   return NO;
 }

 NSArray *serverCertificates = AFCertificateTrustChainForServerTrust(serverTrust);
    switch (self.SSLPinningMode) {
        case AFSSLPinningModeNone:
            return YES;

Which means that if pinning is not used,

 SSLPinningMode == AFSSLPinningModeNone

then the yellow-highlighted  `if` statement evaluates to `false`, even though the property `allowInvalidCertificates` is set to `NO`.

The code flow will hence reach the red-highlighted branch, with the result of cancelling out the whole SSL certificate validation.

It is also important to note that the default value of SSLPinningMode is, indeed, `AFSSLPinningModeNone`.

After a few "feeling cool" moments, we discovered that the implementation flaw was already known and reported here. One month later a new issue was submitted with a more clear description.

Further investigation allowed us to understand that the bug was introduced in late January during the development of AFNetworking 2.5.1.

Warning: 2.5.1 is the latest version at the time of this writing and is installed by default using CocoaPods if not stated otherwise. Refer to the update note above.

 

The impact: SSL MiTM attacks

Eventually, the overall risk can be evaluated as high since a MiTM attack is feasible in all iOS applications using AFNetworking 2.5.1, even though the developers were mindful enough to disable debug settings in the production build.
Moreover, take into consideration that mobile apps are typically used while being connected via public hotspots.

Remediation

Minded Security suggests to consider applying the patch proposed by duttski on his GitHub AFNetworking code, as a workaround until an official patch will be released (click to enlarge):

Unofficial Patch of AFNetworking issue

Finally, it's worth mentioning that setting allowInvalidCertificates to YES would make you deliberately vulnerable no matter what the library does (yes, we know you know, but.. you know..;).

Brought to you by Simone Bovi and Mauro Gentile

iOS Masque Attack Demystified

The Masque Attack, recently discovered by FireEye security researchers, sets a new level of warning for iOS users.
This is a dangerous attack that also threatens non jailbroken Apple iOS devices both on iOS 7.x and 8.x platforms. While some issues were being fixed in iOS 8.1.3, it has been found that the very same version is affected by a variation of the attack.

This attack leverage the easiness to obtain valid enterprise certificates and provisioning profiles from the open Internet in order to deploy a malicious app that substitutes a regularly installed one on the target device.

This malicious app can read all the data belonging to the previous app (the Keychain being an exception) and could also be used to perform a phishing attack by mimicking the UI of the original app in order to steal user credentials.

It is important to note that this attack poses to iOS users a greater risk than the Android counterpart. Because on Android there is an option that forbid users to install applications from sources that are not the official Play Store, while on iOS this choice is not available.

Minded Security has written a white paper to give the reader a deep insight of the attack by illustrating the key concepts behind it and proposing some remediations.