This Blog explains the methods to analyze and investigate the potential security loopholes in an iOS application. In order to get an understanding of the things explained in this blog, going through the previous blogs is recommended in order to understand the structure of the 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 from the previous blogs. We will now go further and dump the same on our local machine.

Considering that we have compressed the local data storage of WordPress application to wordpress_locldata.zip in our local directory, we would now proceed further as shown in the screenshot.

Analyzing the Local Data Storage of the Application

We would now analyze the data directory of WordPress. 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’.

Searching for database files

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

you can also use regex too - for more easier optionsfind . -regex '.*\(db\|sqlite\|sqlite3\)$' more fancy way :-

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.

Search for more filesfind . -regex '.*\(txt\|json\|pdf\|doc\|docx\|ppt\|xls\|xslx\)$'

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 working 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, mobile number, email address, password, MPIN, the 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 this information from our log in the 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 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.