SECURITY MECHANISMS AND ANALYSIS FOR INSECURE DATA STORAGE AND UNINTENDED DATA LEAKAGE FOR MOBILE APPLICATIONS

Using one mobile programming language like Objective-C, Swift or Java is challenging enough because of the many things that need to be considered from a security point of view, like the programming language secure guidelines and vulnerabilities. With the introduction of Swift in 2014 it’s now possible to build Swift/Objective-C mobile applications. Building a mobile application using two languages also adds a greater attack surface for hackers because of the need for developers to stay up to date on vulnerabilities on more than one language and operating system. To our best knowledge, since as of today, there is no academic-research based effort comparing Swift, Objective-C and Android from a programming language and platform security point of view. Our comparative analysis covers a subset of OWASP top ten mobile vulnerabilities and seeing how Swift, Objective-C and Android programming languages safeguard against these risks and how the built-in platform security mechanisms for Android and Apple for the chosen subset of OWASP vulnerabilities compare when placed side-by-side.


INTRODUCTION
Apple's introduction of Swift in 2014 into the mobile application programming language arena brought many programming opportunities for developers as well as for malicious attackers. The introduction of a language that claimed to be safe leaves the question as to how safe did Apple really make Swift in comparison to Objective-C and Java for Android. We focus on OWASP's 2014 Top Ten Mobile Vulnerability [3] Second, Insecure Data Storage, and Fourth, Unintended Data Leakage, and look at what Apple and Android provide on their developer websites as guidelines/aids they claim defend against attacks that fall within the two vulnerabilities. Moreover, we also look at what built-in security mechanisms the programming language or platform provides against attacks within these two vulnerabilities, and test both the built-in mechanisms as well as code in Swift, Objective-C and Java (for Android) that uses said guidelines to provide a comparative analysis of these three languages with respect to the two mentioned vulnerabilities.

MOBILE ANALYSIS TESTING TOOLS
To successfully test the secure guidelines posted by Apple and Google Android on their developer websites and built-in security mechanisms built into the programming language, we use open-source static analysis tools and dynamic analysis to confirm the static analysis results. Static analysis is used in this study to ensure that no device is compromised because the code and behavior can be examined without executing the program being analyzed. For Swift, we use Xcode's built-in and Tailor static analyzers [5] [6]. The static analyzer built into Xcode parses project source code and identifies Logic flaws (accessing uninitialized variables and dereferencing null pointers), Memory management flaws (leaking allocated memory), Dead store flaws (unused variable), and API-usage flaws (not following the policies required by the frameworks and libraries the project is using) [5]. The open-source static analyzer Tailor focuses on enforcing style guidelines outlined in the Swift Programming Language, GitHub, Ray Wenderlich, and Coursera [6]. For Objective-C, we use static analyzer Clang [7]. Clang checks for logical errors for function calls, uninitialized arguments, null function pointers, division by zero, null pointers passed as arguments to a function whose arguments are marked with the nonnull attribute, dereferences of null pointers, sending retain, release, or autorelease directly to a class, incompatible type signature when overriding an Objective-C method, methods that lack a necessary call to super, suboptimal uses of NSAutoreleasePool in Objective-C GC mode, usage of NSError** parameters, prohibited nil arguments in specific Objective-C method calls (caseInsensitiveCompare, compare, compare:options, compare:options:range, compare:options:range:locale, I S S N 2 2 7 7 -3061 V o l u m e 1 5 N u m b e r 8 I n t e r n a t i o n a l J o u r n a l o f C o m p u t e r a n d T e c h n o l o g y 7009 | P a g e c o u n c i l f o r I n n o v a t i v e R e s e a r c h M a y , 2 0 1 6 w w w . c i r w o r l d . c o m componentsSeparatedByCharactersInSet, initWithFormat), leaks and violations of the Cocoa Memory Management rules, self is properly initialized inside an initializer method, private ivars that are never used, passing non-Objective-C types to variadic collection initialization methods that expect only Objective-C types, and mismatched deallocators. For Android-Java, we use the Lint static analyzer [8]. Lint helps look at Java Android project source file code for potential bugs and optimization improvements for correctness, security, performance, usability, accessibility, and internationalization [8].
Needless to say, based on the issues these tools are able to identify is what will limit the extent to which this study will confirm or deny whether the secure guidelines and built-in security mechanisms defend against Insecure Data Storage and Unintended Data Leakage attacks.

Unintended Data Leakage -OWASP Mobile Top Two
Unintended Data Leakage is a vulnerability exploitable by anyone who has acquired a lost or stolen mobile device, malware, or any repackaged application executing on the device on an attacker's behalf. If an attacker has gained physical access to a device, using open source tools, an attacker may be able to access third party application directories that may contain stored sensitive data, or an attacker may construct malware or modify a legitimate application to steal sensitive data. Development teams or organizations that assume users or malware will not have access to the mobile device's file system and data storage on the device are at the highest risks and may also forget that devices lose any encryption protections once rooted or jail broken.
Threat-modeling an application is the best way to understand how it processes data and how underlying API's handle said data. Places where OWASP has often seen insecure data stored includes SQLite databases, Log Files, Plist Files, XML Data Stores or Manifest Files, Binary data stores, Cookie stores and SD Cards [21]. Unintended data leakage may result from vulnerabilities in the underlying OS, frameworks, compiler environment, or new hardware. Undocumented or under-documented processes OWASP has most often seen this vulnerability includes in the way OS, platforms, and frameworks handle URL caching request and response, keyboard press caching, copy/paste buffer caching, application backgrounding, logging, HTML5 data storage, browser cookie objects, and analytics data sent to 3rd parties [22].

SECURITY STUDY -iOS
iOS executables targeted towards versions 4.3 and later have the necessary flags for Address Space Layout Randomization and Position Independent Executable Flags enabled by default, and earlier versions of iOS can add this security measure by adding the Position Independent Flag. Address Space Layout Randomization (ASLR) along with the compiler's Position Independent Executable adds a layer of protection towards buffer overflow attacks. Address Space Layout Randomization randomizes where data and code is mapped in a processes address space to defend against attacks that target specific addresses in a process's layout. In applications compiled with Position Independent Execution (PIE), the application's memory regions are randomized and the binary is loaded at a random address for each execution [18].
iOS adds another layer of protection towards buffer overflow attacks by employing Non-Executable Stack and Heaps by making use of the processors NX bit feature, and marking the stack and heap as non-executables. Memory pages cannot be marked as both executables and writeable at any time and, once a memory page is marked from an executable to writeable, it later cannot be marked back as executable. Any attack that places executable code on the stack or heap and tries to run will fail as a result. Return Orientated Programming (ROP) based payloads can bypass the non-executable memory security feature, which is why non-executable memory is used in combination with ASLR to increase exploit complexity [18].

Heap Overflow (String Handling)
Because many string handling functions have no built-in checks for string length, strings are prone to buffer overflow attacks [9]. Apple warns about using strcpy in Objective-C, since it overwrites anything afterwards:  The string-handling function Apple recommends is safe is strlcpy, because it truncates the string to one byte smaller than the buffer size while also adding the terminating null character:

Fig. 5 Objective-C Correct String Handling
The built-in Xcode analyzer does not detect any buffer overflow issues when the app uses this string-handling function and builds successfully.
In Swift, to copy a string, an assignment would suffice: var src = "Hello World" var dst = src Because the same string function (strcpy) in Swift would not even allow Memory to be accessed it does not allow the application to build as in figure 6 below:

NSUserDefaults
NSUserDefaults saves user preferences and properties in an application, and the data persists even after the application closes and starts again. Common things saved onto NSUserDefaults are the logged in state of a user (YES or NO), or a user's access token. Saving any of these things into NSUserDefaults makes it possible to not have to ask the user to sign The data saved by NSUserDefaults is not secure because it can easily be viewed from the application bundle in a plist file that has the name of the bundle id of the application. Using the open-source application from InfoSec Institute localDataStorageDemo, in figure 12 is an example [14] of how to access content stored in NSUserDefaults:

Fig. 12 NSUserDefaults Application Example
If we enter the phrase Confidential Data -Test into the textbox for NSUserDefaults and press the button to Save in NSUserDefaults, if we are running this application through Xcode's iPhone simulator, that data can be found if you search for the plist file for the app like this: /Users/USERNAME/Library/Developer/CoreSimulator/Devices/3BBDC61C-8D67-454A-B50C-18F677F4223F/data/Containers/Data/Application/2E7059A2-2F53-4E9A-8756-E38961EBF73E/Library/Preferences/ com.highaltitudehacks.LocalDataStorageDemo.plist

Plist Files
Plist Files is another method of storing information onto the device unencrypted. That data is easily accessible, so it should not be used to store sensitive data like Access tokens, Usernames or passwords.

CoreData and Sqlite Files
Core data uses Sqlite internally to save data, so, it's used to create models of different objects with relationships. That data is saved locally as .db files as in figure 18 below and is fetched from the local cache with queries.

Fig. 18 CoreData database file Location
The values in the tables in these files can easily be dumped into a file. By default, data stored in CoreData is unencrypted and can be easily found within a device.

iOS ENCRYPTION TECHNOLOGIES
Common iOS encryption technologies include support functions like the Keychain services API (stores passwords, keys, etc.), the cryptographic message syntax (encrypts or signs messages commonly used with email), and the certificate key and trust services (provides trust validation and cryptography support functions), and Common Crypto (low-level C support for encryption and decryption). Basic encryption and decryption, signing and verifying of blocks of data is also available through the SecKey functions (SecKeyEncrypt, SecKeyDecrypt, SecKeyRawSign, SecKeyRawVerify) [20].

Secure Data Storage Encryption Example [16] (AES)
Symmetric encryption algorithm (ex. Advanced Encryption Standard or AES), or secret key, uses the same key for both encryption and decryption. Asymmetric encryption algorithms (ex. Rivest, Shamir, Adleman or RSA), or public key, use different keys for encryption and decryption.
In order to store data securely using the above storage options in swift, below is an example of how encrypt a string type using the encryption component (CkoCrypt2) from Chilkat software company, which allows users to set the algorithm (symmetric AES in this case), cipher, key length, padding scheme, encoding mode, initialization vector (if applicable), and secret key. The Android developer website suggests to minimize using API's that access sensitive or personal user data. If transmitting or storing is absolutely necessary, Android suggests that apps use hash or a non-reversible form of the data in its logic to reduce the chance of unintentional data leakage and insecure data storage. The Android developer website warns against over-permissive Interprocess communications, world writeable files, network sockets, and when writing to on-device logs. Since logs are a shared resource in Android, they are available to applications through the READ_LOGS permission [11]. In Java, Strings are immutable, meaning they cannot be modified after they have been constructed. Copying one string to another simply gives the new string variable the reference of the first string variable: String a = "hello"; String b = a; a = "world"; As in the example above, as long as there is at least one reference to the string, the garbage collector will not get rid of the string, so even though a new string was created and variable a was reassigned to reference "world" instead, variable b still references "hello".

Insecure Data Storage
Android has different storage options depending on whether an application needs data to be accessed by one or many applications, or depending on how much space the data requires. Android has Shared Preferences, Internal Storage and SQLite Databases. Shared Preferences is a class that provides a framework with persistent save and retrieval key-value pairs capabilities of primitive types.
Internal Storage allows files to be stored on the device internal storage to be only accessed by the application that stored them and not accessible to other applications or the user. SQLite databases on Android are lightweight file-based and only accessible to classes within the application. Similar to iOS's storage, these storage options store values in plain text, and so unless the values stored are encrypted, then these storage options if used with no encryption are not secure.

Secure Data Storage
Android has a cryptography API which has the main packages javax.crypto (package provides the classes and interfaces for cryptographic applications implementing algorithms for encryption, decryption, or key agreement), javax.crypto.interfaces (package provides the interfaces needed to implement the key agreement algorithm), javax.crypto.spec (package provides the classes and interfaces needed to specify keys and parameter for encryption) [15].
Android's Crypto API symmetric encryption algorithm example below is used to encrypt and decrypt a String using AES algorithm SHA1PRNG SecureRandom algorithm and a128-bit secret key [15]:

RELATED WORKS
Buffer Overflow Detection using Static Analysis (Critical Embedded Programs in C Language) In Allamigeon's paper Static Analysis of String Manipulations in Critical Embedded C Programs [13], we saw that buffer overflows were being looked at for a subset of the C language found in critical embedded software using Static Analysis based on the theory of abstract interpretation. In comparison to this approach, our study takes a different approach by using relatively recently released open source Static Analysis tools on code Apple and Google have posted in their secure guidelines websites to test Insecure Data Storage and Unintended Data Leakage attacks.
Unintended Data Leakage (Android -ASLR By-Pass Exploit) Android's ASLR security feature was thought to be a difficult feature to exploit until a 2016 research paper by Hanan Be'er of software research company NorthBit was released [12]. This exploit of Android's ASLR feature affects Android devices with versions 2.2 -4.0 and 5.0 -5.1 (since Android 2.2 -4.0 don't implement ASLR).
The research focuses on Metaphor, which is the name given to the paper's implementation of stagefright; An Android multimedia library that gained attention in July 2015 when several of its heap overflow vulnerabilities were discovered. The paper refers to the library as "libstagefright" and to the bug as "stagefright." Metaphor bypasses Android's ASLR by using Android's heap allocator, jemalloc, and the way it allocates objects of similar sizes in the same run. The web browser is used as the attack vector and techniques like heap grooming (allocates many objects vs spraying the heap) are employed to control the order of allocations and deallocations, and thus, design the order of heap objects in a predictable manner.
Successful exploitation of this library requires JavaScript execution to be enabled, among other architecture specific specifications to also match (like the ASLR algorithm to run on a 32 bit ARM to be able to translate gadget offsets to absolute addresses). But in summary, to allow for Data Leakage, this exploit can be used to overwrite the contents of the mStorage array (mStorage is an array of keys and MetaData::typed_data elements. Mediaserver parses and sends metadata from within the media file back to the web browser. The metadata is stored inside MetaData objects, that store all data in their mItems fields, which are a dictionary of FourCC (4 characters code) keys to MetaData::typed_data values) to point to arbitrary locations in memory and thus leaking information back to the web browser.

RESULTS
The introduction of Swift did not bring much underlying change into iOS mobile application security. The language does introduce an advance Error Handling Model and Syntax improvements, among other things [4]. But, the fact that it can be used along with Objective-C indicates that any vulnerabilities found in the underlying libraries and frameworks in iOS with the use of Objective-C can still be exploited through Swift.
iOS has added safer memory management and memory allocation with Swift which make certain buffer and stack overflows no longer possible in Swift because the application throws a compiler error. Apple's secure coding guidelines provide heap and stack overflows prevention examples and precautions but no encryption examples to use for when storing data in any of their local stage options. Both the iOS and Android local storage options store data in plain text. Encryption is the best solution for securely storing data into any of these storage options. Since there is an OWASP Mobile Vulnerability M6 [3] (Broken Cryptography) dedicated to the misuse of cryptography, the topic of testing the cryptographic algorithms available goes beyond the scope of this study.
In comparison to Objective-C, Android did prove to not be as easily to exploit in terms of heap and stack overflows. Also, the application sandboxing in Android also adds a layer of security into the storage options in comparison to the storage options in iOS.

FUTURE WORK
The OWASP Mobile Top Ten Risks had Broken Cryptography as their sixth vulnerability, which we did not include in this study. After researching the available security mechanism built in the storage options for both iOS and Android it was clear the importance encryption has in securing the information stored in these local storage options.
As a future addition to this study, the fact that, not the lack of encryption used, but rather that the encryption added to applications is broken and as a result is vulnerable leads to question as to how safe really is an application if even after using encryption, there is a chance that it might still be vulnerable due to the cryptography being "broken." In June 2015, a year after its introduction, the programming language Swift also became open source. It would be interesting to add to this study how this affects the safety of the applications developed in Swift as opposed to using a non open source application.