iOS, Objective C, and what it means for Me (a Business Case for Afaria and SAP App Protection by Mocana)

Executive Summary

Recent events involving misbehaving apps on Apple iOS highlight some of the challenges Apple has in ensuring that third party apps behave so that they do not impact other Apps or access sensitive data controlled by Apple APIs. SAP mobility customers with higher security requirements can no longer assume that malicious behavior of other apps is technically restricted, and should consider implementing solutions like SAP Afaria or SAP App Protection by Mocana to ensure the confidentiality and integrity of the data in use by their mobile apps and web applications.

Introduction

I am still struggling to come to wrap my head around the implications of the recent cases of application misbehavior in the Apple mobile app universe – XCodeGhost, YiSpecter, and now, the YouMi-related apps pulled from the App Store.

A fundamental assumption in many SAP mobile deployments is that Apple, Google, and other mobile OS manufacturers have spent considerable time locking down their OS to control third-party application developers and keep them in line. In the case of Apple’s iOS, other apps installed on iOS devices are supposed to play by the rules; if they don’t they won’t be approved by Apple in the app store, or in the case of XCodeGhost and YouMi-related apps, will be pulled retroactively. We assume that our apps and app data are safe in their sandbox, safe from the prying eyes of other apps.

Unfortunately, the YouMi incident has caused me to come to the conclusion that this is no longer a safe assumption. People deploying SAP apps or SAP web applications to mobile devices should not assume that this data is protected from other apps running on the device, especially in a BYOD scenario.

Background Information – XCodeGhost

The two most problematic incidents leading to this conclusion are the XCodeGhost and YouMi apps that were pulled. In the case of XCodeGhost, the Apple iOS SDK wasn’t available for local download in China – it had to be downloaded all the way from the mothership in Cupertino, and for app developers in China, this was extremely slow. To get around this, Baidu and other providers helpfully cached this locally on Baidu servers local to China, making the download much quicker. The problem was, someone had tampered with the SDK and added “hooks” that sent sensitive, device specific info to a mysterious group of servers. At the time, the hooks in the modified SDK allowed these attackers to access private APIs that gave the SDK distributors access to sensitive info, including the device ID and paste buffer – sensitive info that apps playing by the rules should not access. Apps developed using this compromised SDK have been pulled from the app store by Apple.

And then there’s YouMi

SourceDNA has a great writeup on the problems with the YouMi apps recently pulled by Apple – there are 250+ affected apps in total. YouMi is an advertising platform that makes an SDK available to mobile developers. Mobile developers wanting advertising revenue from the YouMi network could easily incorporate YouMi into their apps, simplifying the process of monetizing their user’s eyeballs.

The problem, SourceDNA found, was that, again, the apps incorporating YouMi didn’t behave by the rules. The YouMi code accessed private APIs that, according to SourceDNA, sent the following sensitive data (from Apple’s perspective) to YouMi servers:

A list of installed apps
The platform serial number
Device enumeration
Generated a numeric value associated with the Apple ID

Although YouMi has publicly disputed some of the specifics, as a result, hundreds of apps incorporating the YouMi SDK have been pulled from the App Store.

What’s concerning is that SourceDNA’s solution for app developers to avoid this in the future points to a more serious problem in iOS.

SourceDNA’s Solution

The solution SourceDNA is proposing, and offers to app developers via their SearchLight offering, is a deeper level of validation than Apple currently does. In order to understand the validation process and why it’s important, it helps to understand some of the fundamental architectural issues that Apple is facing. The challenge is, Objective-C based iOS apps are supported in the iOS app model. For Objective-C based apps, Objective-C calls to methods are passed as strings through objc_Send, and by design there is no technical restriction on what can be called. Evidently, Apple addresses this by 1) de-documenting and obfuscating their private APIs, and 2) by statically analyzing App Store candidates, looking for strings calling private APIs and methods. (Caveat: I am an InfoSec practitioner. I am not an iOS developer, nor do I play one on TV). What SourceDNA found was that, in the case of YouMi, the method calls were obfuscated and assembled pseudo-randomly from the code in such a way that the protected APIs did not appear as strings in the source code, and so were able to pass Apple’s static analysis checks.

SourceDNA’s solution is their SearchLight offering and is the next logical step: analyzing these apps at for private or protected method use runtime. Basically, they execute and exercise the code, looking to see if protected APIs are called. If they are, the app developer knows that some framework or SDK they are incorporating into their app is misbehaving, and proactively drop use of that SDK or framework prior to seeking App Store approval.

The Fundamental Problem

Is anyone else getting a sense of deja-vu here? Does all of this sound familiar? Change the name of “Searchlight” to “Antivirus Scanner” and change the term “protected method use” to “malicious code”. We have been here before, and we can pretty much predict where this trajectory will end.

Oh, there are differences between virus writers and malicious iOS app developers. Virus distributors had almost zero negative consequences if their code was detected; App store developers stand to lose out on legitimate revenue if their apps are pulled. The risk of getting caught is higher, and the cycles to evolve counter-detection measures in your code take longer because each cycle includes registering at the app store, getting your app approved, and getting it installed on devices. But this game will continue to evolve; malicious app writers will get better at covering sensitive API/framework/method use in iOS. And as Steve Gibson of grc.com and “Security Now” pointed recently, the protected methods don’t even need to be in the source code in any form – private, privileged methods can be retrieved from an external server at runtime and then used by the app to form the call to that method. This is a logical next step and it will make detection of misbehaving iOS apps extremely difficult to detect once implemented by the black and gray hats.

An aside – reverse engineering private APIs used to be a dark art, but guides on how to reverse engineer these are in the public domain. I’ve included a couple in the references section.

What this Means for Me and my Mobile SAP Deployments

At the end of the day, developers of SAP Mobile applications should assume that other untrusted apps can view and even use mobile SAP application data. The types of behaviors observed today in PC-based malware are within the reach of a malicious iOS app. Developers deploying mobile solutions should assume the same level of confidentiality for application data that they assume for semi-trusted or untrusted PCs.

If they:

Store sensitive data
Process sensitive data

Transmit sensitive data (and yes, this includes usernames and passwords)

…then controls ensuring the confidentiality and integrity of that data are important part of the security controls of the solution. To that end, a couple of options are available to SAP customers to help address this risk:

For Corporate owned devices, SAP Afaria can be deployed to whitelist apps that can be installed on corporate owned devices. This greatly limits the likelihood of a malicious app being installed on their population of mobile devices. Note that other MDM solutions can be used to whitelist approved applications as well.
In a BYOD scenario, this is not always feasible. This is where SAP App Protection by Mocana comes in. SAP App Protection by Mocana assumes that the device is semi-trusted or untrusted, and so the Mocana wrapper encrypts stored and transmitted data, using Mocana-specific encryption keys and app-initiated VPNs. For SAP customers deploying apps with sensitive data on semi-trusted devices, SAP App Protection by Mocana is a control that balances the needs of the user community while helping ensure the confidentiality and integrity of mobile app data.

Remember – from a security perspective, the infrastructure for mobile solutions extends to the mobile devices themselves. And mobile solutions need to incorporate technical controls that not only address the threats and vulnerabilities we know about today, but should include the vulnerabilities we won’t know about until later on in the lifecycle of the solution – in 2018, 2020, and even beyond. Either one of these controls will greatly expand the options an organization has to adapt changes in the threat environment.

Good luck out there!