In this blog, we are going to demonstrate how to examine and detect potential security risks in an iOS application based on a Local Data storage evaluation. So, Let’s get this party started.

The following are some ways of storing data on a device:

• Property List files
• CoreData and SQLite databases
• NSUserDefaults Stores Insecure Data
• Pasteboard Exposes Private Information
• Keychain

Analyzing the Application’s Local Data Storage

We’ll now go through the data directory of a logged-in DVIA account. During this exercise, we will check for certain file formats in which iOS applications frequently store data insecurely. This would need the creation of local data-related checks or restrictions on an iOS application.

Property List files

Plist files can be found by searching for their file type or extension “.plist”. For finding plist we are going to use objection with this command:

objection -g com.highaltitudehacks.DVIAswiftv2.MF56UVPW53 explore

By executing the command “env”, we can view all folders that this application uses.

Then, from > Local Data Storage, we’ll browse to our Plist challenge. After that, we’ll fill in the relevant information and select the “Save in the Plist file” option.

We’ll now visit the application’s “Document” directory to see whether any files have been produced by it.

We can observe that a “userInfo.plist” file exists. To read the contents of the file, we’ll need the commands listed below.

CoreData and SQLite databases

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

Custom files are ones that developers can build for the purpose of storing and retrieving data. In the application’s local data storage, there might be any number of backlog files with any extension. Because an application may use any form of custom file to store local data, searching for certain extensions may be ineffective. At this point, we have enumerated and classified the files in the application’s Local Data Storage. Our next step would be to manually go through all of these files and find any “valuable information”, albeit one by one. By “useful information”, we mean anything that can extend the attack surface, help in reconnaissance, or help in understanding the workings of an application, such as obtaining session IDs, tokens, and so on. Such data can include any of the following:

• PII (Personally Identifiable Information) of the user, such as Social Security Number, etc.
• Other sensitive information about the user, such as name, mobile number, email address, password, MPIN, session identifier, token, etc.
• User activity data such as groups, messages, contacts, transaction history, etc.
• Information regarding the internals of an application

So, if we can obtain any of this information from our logged-in instance of the application, we can be confident that we will obtain the same information from the victim’s device as well. This vulnerability affects confidentiality, and the severity is determined on the type of information stored. If personal or sensitive information needs to be saved in local data storage, it must be encrypted so that an attacker cannot decipher it. If certain information is required by the application at runtime, it must be kept in a manner that  it cannot be altered (ideally encrypted) so that an attacker cannot get any resource for which users are not granted privileges.

NSUserDefaults Stores Insecure Data

Unencrypted sensitive data in NSUserDefaults is not safe because attackers can access and modify it. By opening the file Bundle Identifier, you can inspect objects of the NSUserDefaults class. If NSUserDefaults are saved as preferences, place plist in the Library/Preferences directory.

Because connecting an objection to DVIA-v2 and retrieving environment variables for the application is covered in the last section, we won’t go over it again.

From Local Data Storage, we’ll navigate to our NSUSerDefault challenge.

We’ll fill up the relevant fields and then choose “Save in the NSUSerDefault” from the drop-down menu.

Returning to our hooked objection terminal, enter the following command to examine the stored data.

ios nsuserdefaults get

As can be seen, the DVIA-V2 application does keep NSUserDefaults in the Preferences directory.

The typical user settings object can be emptied using objection, as seen in the screenshot below.

Pasteboard Exposes Private Information

In iOS, the pasteboard or clipboard is shared by all applications and may thus be accessed by any application. Using Objective C or Swift methods, a malicious application can monitor the device’s pasteboard. As a result, pasteboard should be disabled in critical fields. To test, we can press on sensitive fields to see whether we receive a copy option.

Follow the instructions in the screenshot to test the same with cycript.

Keychain Data Storage Is Insecure

Keychain is a password and certificate management feature in iOS. It is used to store items that the user requires but may be unaware of. It serves as a central repository for all wireless passwords and application data. All of these elements are kept in an encrypted database called “/var/Keychains/keychain-2.db”. However, several open-source applications are now available that can dump the iOS keychain in plain text. Among them are Keychain Dumper and Keychain Editor. Keychain Dumper is available for free download at Keychain-Dumper.

This utility is used to dump the whole device’s keychain, after which the application’s keychain data may be filtered out.

From the > Local Data Storage menu, we’ll go to our Keychain challenge.

We’ll fill in the relevant information and then select the “Save in Keychain” option.

Returning to our hooked objection terminal, enter the following command to examine our stored data.

Finally, since the keychain dumper is executed from within the application context, it will only print out keychain items that can be accessed by the application and not the entire keychain of the iOS device.

It comprises text that has been taken from a text source, such as a webpage or a document, and includes special characters like emojis. Cycript can be used to access it.

With this, we conclude the “Sensitive Data Exposure in Local Storage” blog. The steps described here are used to examine and detect potential security risks in an iOS application during an iOS penetration test. We will be talking more about iOS apps and device security in upcoming blogs.

By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.

Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. With a combination of data-driven, research-based, and manual testing methodologies, we proudly deliver robust security solutions.

“Join us on our journey of growth and development by signing up for our comprehensive courses, if you want to excel in the field of cybersecurity.”