iOS Application Security | Part 7 | Analyzing the Local Data of an application

Forensics
1

Introduction

This article explains the procedure to analyze and identify potential security vulnerabilities in an iOS application raised upon the assessment of Local Data storage. In order to get an understanding of the things explained in this article, going through the previous articles is recommended in order to understand the structure of iOS application. Let’s get started.

Getting the Local Data Storage on local machine

We have learned the extraction of Local Data storage of an application in the article ‘Extracting the IPA File and Local Data Storage of an iOS application’. We will now go further and dump the same on our local machine.

Considering that we have compressed the local data storage of Facebook application to fb_local.zip in /var/root/LocalData directory, we would now proceed further as shown in the screenshot.



The obtained file can now be unzipped on the local machine and can be viewed using command line or a file manager.



Analyzing the Local Data Storage of the Application

We will now analyze the data directory of a ‘logged in’ facebook account. During this task, we would be looking to search some file types in which the common iOS applications tend to store data insecurely. This would lead us to make local data related checks or controls for an iOS application.

Searching for plist files

Plist files can be searched using their file type or by using the extension ‘.plist’.

Zg1iCRE3mezBN47ntzlHBvf66G6F0TdobyoORktUn9cjJYVgUtZL6yxPTIgMdNHlOd469LDsyqT-l1IulmBkADp9xSdf7XmNNKS_AYe0FrQmhdEu3GfdPku_F7ZzElPzZx6bWcoG.png729×329 43 KB


Searching for database files

Database files can be searched using their file type or by using the extension ‘.db’, ‘.sqlite’ or ‘.sqlite3’.



ONQDwXizyhEe04wNBtaBO1H_PmfMFC-LAnFayiFUfQ_cXT53d1a_m7HZOZFvuEtbUvC7W7x0SkX_9w10lzPVjeiRtY1ccwwoJEQN3dkyd69bMKnIvGsKwQun9rUcMe6ZW9zHl-Pr.png734×306 49.6 KB


Searching for custom files

Custom files are those files that developers may create for storing and retrieving data according to their own convenience. There might be any number of custom files with any extension in the local data storage of the application. Since an application may have any type of custom file for storing local data, searching for specific extensions may not work. But to name a few, we can check them as shown.



At this stage, we have enumerated and categorized the files in the Local Data Storage of the application. Our next task would be to traverse all these files manually and identify any ‘useful information’ for us one by one. By ‘useful information’, we mean anything which can increase the attack surface, help in recon, or help in understanding the workings of the internals of the application, obtaining session identifiers, tokens, etc. Such information could be any of the following:
  • User’s PII (Personally Identifiable Information) such as Aadhar Number, PAN Number, Social Security Number etc.
  • User’s other sensitive information such as name, phone number, email address, password, MPIN, session identifier, token etc.
  • User’s activity information such as groups, messages, contacts, transaction history etc.
  • Information about the application’s internals that can help in recon
So, if we can get any of these information from our logged in instance of the application, we can be quite sure that we would get the same from the victim’s device as well. This particular vulnerability impacts the confidentiality and the severity depends upon the type of information stored. If personal or sensitive information is needed to be stored in the local data storage, it should be stored in encrypted form so that an attacker cannot crack it by any chance. If some information is needed by the application at runtime, it is required to be stored it in a form non-guessable for modification (preferably encrypted) so that an attacker cannot fetch any resource for which privileges are not given to him/her.

Completing the Static Analysis of iOS Application

One might think that we are done with the static analysis of the application, but it is not so. We still need to look further into some more controls for static analysis.

Insecure Data Storage in NSUserDefaults

Unencrypted sensitive data in NSUserDefaults is not secure as it can be read and modified by specially crafted attacks. Objects of NSUserDefaults class can be checked by opening the file <Bundle_Identifier>.plist in Library/Preferences directory if NSUserDefaults are stored as preferences.



It can be observed that the Facebook application does not store NSUserDefaults in the Preferences directory.

By using cycript, standard user defaults object can be dumped as shown in the screenshot.



Insecure Data Storage in NSHTTPCookie

It is dangerous for an application to store sensitive data in NSHTTPCookie. This is because objects of this class are immutable, which means that even if they are deleted or overwritten, they will continue to persist in memory. They are stored in the Local Data Storage in binary form. They can be dumped using Objective C or Swift functions. Cookies are sent in the request headers in the application traffic. To check the same using cycript, follow the steps shown in the screenshot.



Response Caching

By default, many iOS application frameworks enable response caching. This can lead to sensitive information disclosure as the server’s responses might contain victim’s sensitive information in clear text. Responses may be found cached in database file or in a binary file in the Library/Caches directory. We can read database files using any db browser as shown in the screenshot.





mul5yAMOsvl7580IXHfv6Ge5354Zmz72W1ANIg0PKIVQ8QB6MbGDtU58Yr0IIv9ZWa3P82L6wZEwfYkhedumCA4OS-z9v6aYey5UeUODXaILEP3uL2GRK9OT_mn7OKorZacAYoYK.png1074×554 62.8 KB


Sensitive Information Leakage Via Application Background Snapshot

Every iOS application captures a screenshot by default when it moves to the background. That screenshot might contain the victim’s sensitive information. In iOS, the screenshot gets saved in ‘Library/Caches/Snapshots/<Bundle_Identifier>’ directory.

nXTm4iNNJ2Cs4OfdTMR5LyQaogGQLDgnjKOB5DmNPeColIfxCPBOGdoLWEh_OQVUX8Ty4OsfHdr5UGMnc6QvAEQptZrKLJPBlVsuYVvHwf5OpF-7ixw051ewF1S4xI2h9iVJJ1XJ.png567×551 69.3 KB


It can be observed that the Facebook application captures a screenshot to the Library/Caches/Snapshots/com.facebook.Facebook directory when it moves to the background.

Pasteboard Leaking Sensitive Information

Pasteboard or clipboard in iOS is shared by all the applications and hence might be accessed by any application. A malicious application can monitor pasteboard of the device using the Objective C or Swift functions. Hence, pasteboard must be disabled on sensitive fields. For checking purposes, we can long press on sensitive fields and check if we get a copy option.

DE076V_AFkGKFir5quYSl0hZXMtnjHUxERsnf6n5xx9PTazUdOoqH5c5ewWtUpHsBsv9YPx0o-25r2_9e6sTIhisAn0NyYfa92HGEofF-3j_Q5l0rK6wSZDhB1egJZTIMBXULlDI.png640×1136 61.2 KB



To check the same using cycript, follow the steps shown in the screenshot.



Insecure Data Storage in Keychain

Keychain in iOS is a password and certificate management tool. It is used to store store items that the user needs but may not be aware of. It is a common storage for all wifi passwords as well as application data. All these items are stored in an encrypted database whose path is ‘/var/Keychains/keychain-2.db’. But now, there are many open source tools that can dump the iOS keychain in plain text. Keychain Dumper and Keychain editor are a few of them. Keychain Dumper can be downloaded from https://github.com/ptoomey3/Keychain-Dumper.

This tool is used to dump the keychain of the whole device and then application’s keychain data can be filtered out accordingly.



Sensitive Information Leakage through Application Logs

An iOS application may use logging feature in order to make its debugging easier. NSLog in Objective-C and Swift may print information to application logs at the time of crash or any other event. Production-ready applications should make sure that no sensitive information is being logged into the application’s logs. In order to analyse logs of an iOS application, we may use XCode console on macOS or libimobiledevice utils on mac or Linux. There’s also idbtool which serves this and several other purposes.

gvPUjKNd_PNU8Q5uGAqvU8X9M8XUI8K0ivBdIsLnSzotqSYrJP9akeUsgskW0vaVWUDBwZcsj8kL86vNltVeO74PRRMyTHbK5uXYNMrIkYYL-b2sUv6ZHS6TQpQYiEPNO4KMPqYT.png962×674 222 KB


pxIkZ9rbohRxVzpWhXq6DEgrir6bqrbTHHh82ffs6V5tfxk6uhnZq3Ekeyufcls5VyhUDfLYJNRDB1X-lfhAxV1iC-4b87CPLePninKClZM5oos_NbNxFkzt28m4sepfJ_csp32i.png1006×491 226 KB


Using ‘objection’ for Static Analysis

Objection is a run-time mobile exploration tool based on Frida. Objection can be used for static as well as runtime analysis of iOS as well as Android applications. Some benefits of this tool include:
  • Bundle and Data directories are easy to find
  • Dumping of keychain of only the required application
  • Monitoring pasteboard gives clear text output
For tutorials on installation and use of objection refer to https://github.com/sensepost/objection. Some of the static analysis techniques using objection are shown in the below screenshots.









Conclusion

In this article, we have completed learning the static analysis of iOS applications. We have used some standard tools and techniques for performing static analysis. Many more tools are available to perform these tasks. The same can be automated using open source libraries of some popular programming languages like Python and Ruby. Up next, we will be starting with the traffic analysis of iOS applications.

Article Link: https://blog.lucideus.com/2019/04/ios-application-security-part-7.html