In the first blog post we published, “Exploiting iOS Local Storage with Corellium” we discussed the various areas where iOS applications potentially store data. If you haven’t read it already, I highly suggest looking through it to understand iOS application data storage better, along with some of the tools and techniques that can be utilized to identify potential information leakage.
In this follow-up blog post, we will take a deeper look at databases for iOS applications and how they work, along with ways we have identified that sensitive information can be missed when performing app security assessments.
We will use the intentionally vulnerable iOS application known as DVIA-2. Utilizing Corellium virtualized devices and the DVIA-2 application, we will thoroughly discuss iOS database storage and ensure that no potentially sensitive data is overlooked during mobile app penetration testing.
iOS applications employ local databases, often known as SQLite databases, to store and manage structured data. These databases are kept in the sandboxed environment of the application, which can be accessed with a jailbroken device. Mobile pentesters frequently target these local databases to harvest sensitive data, such as user passwords, private information, or application-specific data, as they can hold insightful information for examining the security posture of iOS applications.
As a refresher from the first blog post, the iOS data directory is stored in the following location:
/var/mobile/Containers/Data/Application/
Once you are here, there are unique IDs for every application. One way you can identify which ID is related to the application you want is based on the Last Modified column; using that date to match when you installed the application on the device can quickly help identify which ID folder you require.
Alternatively, a second option is to use a third-party tool (Objection). This runtime mobile exploration toolkit utilizes Frida to identify the complete data storage path for an iOS application.
If you are using Objection, the following command can be used to hook an application and then a follow-up command to pull the apps environment details:
Using the DVIA-2 application, we will focus on the core data local storage challenge, similar to what we did in the first blog.
Data entered within this challenge will be available in the following directory
<Application ID>/Library/Application Support/
In the Corellium files tab, you can navigate to the directory above after completing the app challenge to see the database that has been generated. Download the database locally to your machine and open it with a database browser (DB Browser is a good option if you don’t have one).
What do you notice?
There is no data within the database, as you see from the screenshot below:
So why is this happening after the data was entered within the application? That is the basis of this blog post, ensuring this concept is not carried over to a mobile pentest or assessment.
An SQLite database also has a .wal (write-ahead log) file associated with it. These write-ahead logs are the reason that when downloading just the SQLite file, you might not see all the data that has been entered. Let's look deeper into .wal files and how to avoid this issue.
Changes to the iOS database that haven't yet been written to the main SQLite file are kept in the .wal file. As updates may be grouped and published to the main SQLite file in a single transaction, this enables more effective writes to the database. It also implies that information that hasn't yet been written to the SQLite file might be included in the .wal file.
Downloading both the SQLite file and the .wal file is recommended if one plans to perform static analysis on an iOS mobile app. The .wal file must be downloaded to avoid missing important information that hasn't yet been entered into the iOS database. This is very important when examining applications that largely rely on the database and constantly write data to it.
With all that information, let's take a quick look at how to download the required files for the DVIA-2 exercise and ensure the data is there.
Navigate to the local data directory as we did at the start of the blog post:
/var/mobile/Containers/Data/Application/<Application ID>/Library/Application Support/
You should see files similar to what is shown below:
Select the SQLite database and the temporary files and click the Download button; this will download a ZIP archive containing all the files within one folder.
All the files should be within that ZIP archive; if you open the SQLite file when the write-ahead log is in the same folder, you will notice that all the data is then populated.
Identifying sensitive data within an iOS application is crucial to any assessment. While this is a simple concept, the importance is great, especially within the mobile appsec / pentest space. Remembering these fundamental concepts can help ensure that no data is missed and that a full assessment can be performed confidently. Take time regarding the security of your iOS applications.
Equip your security teams with unprecedented tools for both manual and automated testing, freeing up valuable engineering time and saving money. Discover the power of Corellium’s high-fidelity virtual devices and spin-up near limitless combinations of device and OS with one-click jailbreak/root access. Book a meeting today to see how we can streamline your processes and reduce costs.