Tag Archives: pentesting iphone apps

Penetration testing of iPhone Applications – Part 4

In the first part of the article, we have discussed about the iPhone application traffic analysis. Second part of the article covered the privacy issues and property list data storage. Third part covered in-depth analysis of the iOS keychain data storage. In this part we will take a look at different types of files stored/created in the application’s home directory and other insecure data storage locations.

Sqlite storage

Sqlite is a cross-platform C library that implements a self-contained, embeddable, zero-configuration SQL database engine. Sqlite database does not need a separate server process and the complete database with multiple tables, triggers, and views is contained in a single disk file. The Sqlite database offers all the standard SQL constructs, including Select, Insert, Update and Delete. As Sqlite is portable, reliable and  small, it is an excellent solution for persistent data storage on iOS devices.

Sqlite library that comes with iOS is a lightweight and powerful relational database engine that can be easily embedded into an application. The library provides fast access to the database records. As the complete database is operated as a single flat file, applications can create local database files and manage the tables & records very easily. In general, iOS applications use the Sqlite database to store large and complex data as it offers good memory usage and speed. Sqlite database that comes with iOS does not have a builtin support for encryption. So most of the iOS applications store lots of sensitive data in plain text format in Sqlite files. For example, to provide offline email access, Gmail iOS application stores all the emails in a Sqlite database file in plain text format.

Unencrypted sensitive information stored in a Sqlite file can be stolen easily upon gaining physical access to the device or from the device backup. Also, if an entry is deleted, Sqlite tags the record as deleted but not purge them. So in case if an application temporarily stores and removes the sensitive data from a Sqlite file, deleted data can be recovered easily by reading the Sqlite Write Ahead Log.

The Sqlite files can be created with or without any file extention. Most common extentions are .sqlitedb &.db. The below article explains, how to view Sqlite files and how to recover the deleted data from Sqlite files on the iPhone. For this exercise, I have created a demo application called CardInfoDemo. CardInfoDemo is a self signed application, so it can only be installed on a Jailbroken iPhone. The CardInfo demo application accepts any username & password, then collects the credit card details from the user and stores it in a Sqlite database. Database entries are deleted upon logout from the app.

Steps to install the CardInfo application:

1. Jailbreak the iPhone.
2. Download the CardInfoDemo,ipa file –  Download link.
On Windows, download the iPhone configuration utility – Download link.
Open the iPhone configuration utility and drag the CardInfoDemo.ipa file on to it.

iPhone configuration utility

5. Connect the iPhone to the windows machine using USB cable. Notice that the connected device is listed in the iPhone configuration utility. Select the device and navigate to Applications tab. It lists the already installed applications on the iPhone along with our CardInfo demo app. Cardinfo demo iOS app install

6. Click on Install button corresponding to the CardInfo application and it installs the CardInfo application on to the iPhone.

cardinfo ios demo app

Steps to view  CardInfo Sqlite files:

1. On the Jailbroken iPhone, install OpenSSH and Sqlite3 from Cydia.
On windows workstation, download Putty.
Connect the iPhone and the workstation to the same Wi-Fi network. Note: Wi-Fi is required to connect the iPhone over SSH. If the Wi-Fi connection is not available SSH into the iPhone over USB.
4Run Putty and SSH into the iPhone by typing the iPhone IP address, root as username and alpine as password.
Navigate to /var/mobile/Applications/ folder and identify the CardInfo application directory using ‘find . –name CardInfo’ command. On my iPhone CardInfo application is installed on the – /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/ directory. 

cardinfo directory

6. Navigate to the /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/ directory and notice CARDDATABASE.sqlite3 database file.

cardinfo sqlite file

7. Using sqlite3 command, view the CARDDATABASE.sqlite3 and notice that CARDINFO table is empty.

Note: Sqlite files can also be copied from the iPhone to a workstation over SSH and viewed using Sqlite data browser & Sqlite spy tools.

cardinfo sqlite before login

8. On the iPhone, open CardInfo application and login (works for any username and password).

cardinfo login

9.Enter credit card details and click on Save button. In the background, it saves the card details in the Sqlite database.

cardinfo - card details                    cardinfo - saved details

10. View CARDDATABASE.sqlite3 and notice that CARDINFO table contains the credit card details data.

cardinfo sqlite after save

11. Logout from the application on the iPhone. In the background, it deletes the data from the Sqlite database.

cardinfo logout

12. Now view CARDDATABASE.sqlite3 and notice that CARDINFO table is empty.

cardinfo sqlite after logout

Steps to recover the deleted data from CardInfo Sqlite file:

Sqlite database engine writes the data into Write Ahead Log before storing it in the actual database file, to recover from system failures. Upon every checkpoint or commit, the data in the WAL is written into the database file. So if an entry is deleted from the Sqlite database and there is no immediate commit query, we can easily recover the deleted data by reading the WAL. In case of iOS, strings command can be used to print the deleted data from a Sqlite file. In our case, running ‘strings CARDDATABASE.sqlite3’ command prints the deleted card details.

cardinfo sqlite recovered

In iOS, if an application uses the Sqlite database for temporary storage, there is always a possibility to recover the deleted temporary data from the database file.

For better security, use custom encryption while storing the sensitive data in Sqlite database. Also, before deleting a Sqlite record, overwrite that entry with junk data. So even if someone tries to recover the deleted data from the Sqlite file, they will not get the actual data. Use iOS data protection constants while creating the Sqlite files.


Most of the iOS applications do not want to prompt the user for login everytime. So they create persistent cookies and store them in cookies.binarycookies file on the application’s home directory.  During penetration test, investigate the cookies.binarycookies file for sensitive information and to find session mangement issues. Cookies.binarycookies is a binary file and the content is not in readable format. So I wrote a python script that can read the cookie file and display the content on the screen.

Steps to read the Cookies.binarycookies:

1. On Windows, download WinScp, Python &
Connect the iPhone and the workstation to the same Wi-Fi network.
Run WinScp and SSH into the iPhone by typing the iPhone IP address, root as username and alpine as password.
Navigate to the Library/Cookies folder in the application’s home directory.
Copy the Cookies.binarycookies file to the windows machine by dragging it.


6. On windows, open command prompt and run the below command to list the contents of cookies.binarycookies file.

Python [Cookies.binarycookies file path]

Below is the screenshot of cookies created by Facebook iOS Application.

facebook iOS cookie file

Keyboard Cache

In an effort to learn how user’s type, iOS devices utilize a feature called Auto Correction to populate a local keyboard cache on the device. The keyboard cache is designed to autocomplete the predictive common words. The problem with this feature is, it records everything that a user types in text fields. The cache keeps a list of approximately 600 words. The keyboard cache is located at Library/Keyboard/en_GB-dynamic-text.dat file. To view the Keyboard cache, copy the en_GB-dynamic-text.dat file to a computer over SSH and open the file using a Hex Editor. Below is the screenshot of a keyboard cache Hex view.

iOS keyboard cache

Keyboard Cache does not store the informtion typed in the fields which are marked as Secure. By default, passwords and strings with all digits (pins & credit cards) are marked as Secure. Hence the data typed in those fields does not store in the keyboard cache. But data typed in other text fields like username, security questions & answers might get stored in the keyboard cache. During a pentest clear the existing keyboard cache by navigating to iPhone Settings -> General -> Reset -> Reset Keyboard Dictionary (shown in the below image), then browse the application & enter data in text fields and anlyze whether the data is getting stored in the keyboard cache or not.

Clear iOS keyboard cache

During the application development, to disable auto complete for a text field, either mark it as secure (ex: mytextField.secureTextEntry = YES) or disable the autocomplete (mytextField.autocorrectionType = UITextAutocorrectionTypeNo;).

Along with the keyboard cache, when a user copies data from a textfield, iOS stores the data into a pasteboard (clipboard in other operating systems). The pasteboard is shared among all the application, so the information copied in one application can be accessed from other application by reading the pasteboard. If the application is dealing with senstive data, it is recommended to use private or application specific pasteboard.

Snapshot Storage

Pressing the iPhone home button shrinks the iOS application and moves it to the background with a nice effect. To create that shrinking effect, iOS takes a screenshot of the application and stores it in the Library/Caches/Snapshots folder in the respective application’s home directory. This might result in storing the user’s sensitive information on the device without user’s knowledge. Snapshots stored on the iPhone will automatically cleared after the device is rebooted.

Ex: Incase of Gmail iOS application, when a user press the iPhone home button after viewing the email, a snapshot of users’ email gets stored on the device without user’s knowledge. Below snapshot is captured after viewing a mail from the Citibank.

Gmail iOS App Snapshot Storage

During development, the application snapshot problem can be fixed in two ways.
1. Remove sensitive data or change the screen to blank before the applicationDidEnterBackground()
function returns.
2. Instead of hiding or removing sensitive data, application’s back grounding can be disabled altogether by setting the “Application does not run in background” property in the application’s Info.plist file.

File Cache

Along with plist files, sqlite files, binary cookies & snapshots, iOS applications can store other format files like pdf, xls, txt, etc. when viewed from the application. For example, in Yandex.Mail iPhone application, when a user views an attachment it gets stored on the device and remains on the device even after user logged out from the mail application. Applications which are storing temp files on the device, should clear those files upon logout/close for better security.  Below is the screenshot of Yandex.Mail attachement directory.

iOS Yandex Mail Attachement Storage

Error Logs

In general, iOS applications write data into logs for diagnostic and troubleshooting purpose. Also, during development, applictions developers commonly use NSLog for debugging purpose. These logs might include requests, responses, cookies, authentication tokens and other sensitive data. On the iPhone, data passed to the NSLog funciton is logged by Apple System Log (ASL) and the data remains on the log until the device is rebooted. Also, Error logs are not bounded by the application sandbox. Which means, error log generated by one application can read by other application. So if an application logs sensitive data, a malicious application can actively query for this data and send it to a remote server.

Error logs on the iPhone can be viewed directly using Console app. Console app is available in AppStore. Error logs can also be viewed using iPhone configuration utility or by syncing the device with iTunes and looking at CrashReporter folder.

For this exercise, I have created a demo application called CardInfoDemo. CardInfoDemo is a self signed application, so it can only be installed on a Jailbroken iPhone. The CardInfo demo application accepts any username & password, then collects the credit card details from the user and writes it into the error log.

Steps to view the error logs:

1. Install CardInfoDemo application on the iPhone.
2. On windows, install & open the iPhone Configuration Utility.
Connect the iPhone to the windows machine using USB cable. Notice that the connected device is listed in the iPhone configuration utility. Select the device and navigate to Console tab.
On the iPhone, open CardInfo application and login (works for any username and password).
Enter credit card details and click on Save button. In the background, it logs the card details.

CardInfoDemo iOS App

6. On the iPhone configuration utility console tab, you can notice the card details logged by the CardInfoDemo application.

iOS App Error log

For better security, do not log sensitive data. Also, remove debugging and troubleshooting logs from the application before publishing it.

Penetration Testing iPhone Applications is going to be covered in a series of articles. Below are the links for next articles. 

Part 5runtime analysis of iOS Applications.


1. Debunking NSLog Misconceptions
2. What’s in your iOS Image Cache ?
3. Hacking and Securing iOS Applications by Jonathan Zdziarski


Posted by on April 15, 2013 in iPhone


Tags: , , , , , , ,

Penetration testing of iPhone Applications – Part 2

In the first part of this article, we have discussed about the iPhone application traffic analysis. In this part, we will take a look at the privacy issues and the application local data storage.

Privacy Issues:

Every iPhone has an associated unique device Identifier derived from a set of hardware attributes called UDID. UDID is burned into the device and one cannot remove or change it. However, it can be spoofed with the help of tools like UDID Faker.

UDID of a latest iPhone is computed with the formula given below –
UDID = SHA1(Serial Number + ECID + LOWERCASE (WiFi Address) + LOWERCASE(Bluetooth Address))

UDID is exposed to application developers through an API which would allow them to access the UDID of an iPhone without requiring the device owner’s permission. The code snippet shown below is used to collect the UDID of a device, later which can used to track the user’s behavior.

NSString *uniqueIdentifier = [device uniqueIdentifier]

Current research shows that, with the help of UDID, it is possible to observe the user’s browsing patterns and trace out the user’s geo location. As it is possible to locate the user’s exact location with the help of a device UDID, it became a big privacy concern. More possible attacks are documented in Eric Smith-iPhone application privacy issues whitepaper. Eric research shows that 68% of applications silently send UDIDs to the servers on the internet. Perfect example for a serious privacy security breach is social gaming network called Openfient. Openfient collected device UDID’s and misused them by linking it to a real world user identities (like email address, geo locations latitude & longitude, Facebook profile picture) and making them available for public access, resulting in a serious privacy breach. More details about this security breach are documented at this link.

While penetration testing, observe the network traffic for UDID transmission. UDID in the network traffic indicates that the application is collecting the device identifier or might be sending it to a third party analytic companies to track the user’s behaviour. In iOS 5, Apple has deprecated the API that gives access to the UDID and probably it will remove the API completely in future iOS releases. Development best practice is to not to use the API that collects the device UDIDs as it breaches the privacy of user’s. If the developers want to keep track of the user’s behaviour, create a unique identifier specific to the application instead of using UDID. The disadvantage with the application specific identifier is that it can only identifies an installation instance of the application and it does not identify the device.

Apart from UDID, applications may transmit personal identifiable information like age, name, address and location details to third party analytic companies. Transmitting personal identifiable information to third party companies without the user’s knowledge also violates the users privacy. So, during penetration testing carefully observe the network traffic for the transmission of any important data.

Ex: Pandora application was used to transmit user’s age and zip code to a third party analytic company ( in clear text. For the applications which require the user’s geo location (ex: check-in services) to serve the content, it is always recommended to use the least degree of accuracy necessary. This can be achieved with the help of accuracy constants defined in core location framework (ex: CLLocationAccuracy kCLLocationAccuracyNearestTenMeters).

In iOS 6, Apple removed the API that gives access to UDID and introduced a new advertising identifier as an alternative of UDID to track the user’s behaviour.

Local data storage:

Mobile applications store the data locally on the device to maintain essential information across the application execution or for a better performance or for an offline access. Also, developers use the local device storage to store information such as user preferences and application configurations. As device theft is becoming the increasing concern, especially in the enterprise, insecure local storage is considered to be Top 1 risk in mobile application threats. Recent survey conducted by Viaforensics revealed that 76 percent of mobile applications are storing user’s information on the device. 10 percent of them are even storing the plain text passwords on the phone.

Sensitive information stored on the iPhone can be obtained by attackers in several ways. Few of them are listed below –

  • From Backups
    When an iPhone is connected to iTunes, iTunes automatically takes a backup of everything on the device. Upon backup, sensitive files will also end up on the workstation. So an attacker who gets access to the workstation can read the sensitive information from the stored backup files.
  • Physical access to the device
    People lose their phones and phones get stolen very easily. In both the cases, attacker will get physical access to the device and read the sensitive information stored on the phone. Passcode set to the device will not protect the information as it is possible to brute force the iPhone simple passcode within 20 minutes. To know more details about iPhone passcode bypass go through the iPhone Forensics article.
  • Malware
    Leveraging a security weakness in iOS may allow an attacker to design a malware which can steal the files on the iPhone remotely. Practical attacks are demonstrated by Eric Monti in his presentation on iPhone Rootkit? There’s an App for That! .

iPhone Application directory structure:

In iOS, applications are treated as a bundle represented within a directory. The bundle groups all the application resources, binaries and other related files into a directory. In iPhone, applications are executed within a jailed environment (sandbox or seatbelt) with mobile user privileges. Unlike Android UID based segregation, iOS applications runs as one user. Apple says The sandbox is a set of fine-grained controls limiting an application’s access to files, preferences, network resources, hardware, and so on. Each application has access to the contents of its own sandbox but cannot access other applications’ sandboxes. When an application is first installed on a device, the system creates the application’s home directory, sets up some key subdirectories, and sets up the security privileges for the sandbox. A sandbox is a restricted environment that prevents applications from accessing unauthorized resources however upon iPhone JailBreak sandbox protection gets disabled.

When an application is installed on the iPhone, it creates a directory with an unique identifier under /var/mobile/Applications directory. Everything that is required for an application to execute will be contained in the created home directory. Typical iPhone application home directory structure is listed below.

File structure of iPhone applications

In iPhone, applications might store the information in any of the locations listed below.

  • Plist files
  • Keychain
  • Application’s home directory
  • Cache
  • Logs

Plist files:

Property List is a structured binary formatted file which contains the essential configuration of a bundle executable in nested key value pairs. Plist files are used to store the user preferences and the configuration information of an application. For example, Gaming applications usually store game levels and game scores in the Plist files. In general, applications store the Plist files under [Application’s Home Directory]/documents/preferences folder. Plist can either be in XML format or in binary format. As XML files are not the most efficient means of storage, most of the applications use binary formatted Plist files. Binary formatted data stored in the Plist files can be easily viewed or modified using Plist editors (ex: plutil). Plist editors convert the binary formatted data into an XML formatted data, later it can be edited easily. Plist files are primarily designed to store the user preferences & application configuration, however the applications may use Plist files to store clear text usernames, passwords and session related information. So while penetration testing view all the Plist files available under application’s home directory and look for sensitive information like usernames, passwords, user’s personal information and session cookies, etc… Developers can assign any extension to the Plist files. A Plist file can be easily identified by looking at the file contents using cat command. The content of a Plist file starts with bplist’.

Along with the sensitive information storage, application may also take authentication & authorization decisions based on the values stored in Plist files. For example, if you notice a Plist entry like admin=0 during penetration testing, change the admin key value to 1 and open the application. If the application does not validate the user input properly and takes the authorization decision based on the Plist entry, you may log into the application as an administrator. Development best practice is to not to store any sensitive information in Plist files. Also do not take authentication & authorization decisions based on the information stored in Plist files. Plist files contain user controlled input and it should be validated properly like any other user input.

WordPress iPhone application used to store clear text username and password in a Plist file. The video below here demonstrates the WordPress vulnerability. This vulnerability was reported by SANS and WordPress fixed it immediately.

Plist files can be viewed and modified easily on both the JailBroken and non JailBroken iPhones. The examples listed below illustrate the various ways of editing Plist files on the both JailBroken and non JailBroken devices.

Tampering Plist files on a non JailBroken iPhone: 

On a non JailBroken iPhone, Plist files can be viewed & modified using tools like iExplorer and iBackupBot.

Modifying Plist entries with iExplorer
iExplorer (formerly iPhone Explorer) gives access to the iPhone in disk mode and allows browsing all the folders on the iPhone directly.

Stick Cricket iPhone game is used for the demo.

iPhone stick cricket game

Stick Cricket iPhone game stores the game score in a Plist file under application’s home directory. As the application is storing the game score locally in a Plist file, it can be altered by editing the Plist file.

Screenshot shown below displays the actual score before the Plist modification.

 StickCriket actual score before hacking the score

Steps shown below will demonstrate the usage of iExplorer tool to modify the game scores stored in the Plist file –

1. On your workstation download and install iExplorer.
2. Connect the iPhone to the workstation over USB.
3. In iExplorer, browse to Apps->com.sticksports.stickcricket folder.

iExplorer - Browse files on iPhone over USB

4. Navigate to stick cricket Library->Preferences folder.

 iExplorer - Explore iPhone over USB

5. Copy com.sticksports.stickcricket.Plist file to the workstation by dragging it to the desktop.
6. On the workstation open the Plist file using a Plist editor and modify the yourBest5Overs key value.

 iPhone stickcricket plist

For this demo, I have modified the value to 180 from 30 and saved the Plist file.

Modify iPhone game scores - changing stickcricket score in plist

7. From iExplorer, delete the com.sticksports.stickcricket.Plist on the iPhone and drag the newly saved file onto the iPhone.
8. In iPhone, terminate the Stick Cricket application and reopen it.  The Stick Cricket welcome screen now displays the modified score as shown in the screenshot below.

iPhone hack - modify stick cricket score

StrickCriket game score video is available at – Hacking iPhone Game Scores

Modifying Plist entries with iBackupBot
When the iPhone is connected to a computer, iTunes take a backup of everything on the phone including configuration files (Plist files). iBackupBot tool can be used to view and modify the Plist file entries on the iPhone backup and restore the modified backup onto the iPhone..

Steps shown below will demonstrate the use of iBackupBot tool to modify the game scores stored in the Plist file –

1. Connect the iPhone to the workstation over USB cable.
2. On Workstation, open iTunes and take a backup of the iPhone.
3. Close iTunes.
4. Open iBackupBot. It automatically identifies the existing backups and displays the files inside the backup to the user.
5. Click on Stick Cricket and open /Library/Preferences/com.sticksports.stickcricket.Plist file.

ibackupbot to read plist files from backups

6. Modify the score stored in the Plist file.
7. Click on Export icon to save the modified Plist file.
8. Click the restore icon in iBackupBot toolbar. It will restore the iPhone with the modified backup. Now on iPhone, reopening the Stick Cricket game will display the modified score.

Tampering Plist Files on a JailBroken iPhone:

On a JailBroken iPhone, Plist files can be viewed & modified using tools like plutil and iFile. Both these tools can be downloaded from Cydia (packages – com.eric.tool & iFile). iFile would allow to modify the Plist files directly on the iPhone.

The iPhone camera application is used for the demo. In iOS camera application, Apple has hidden the panorama mode feature and planned to include this feature in future iOS versions. Panorama mode basically allows the users to take continuous photos while panning the camera from left to right. Apple stored the panorama mode switch in a Plist file. iOS hackers Conard & Chpwn exposed the panorama mode in iOS 5 by modifying an entry in file.

Screenshot shown below displays the list of options available in the iPhone camera application.

iPhone camera toggle to turn off panorama

Steps shown below will demonstrate the usage of plutil tool to change the panorama switch stored in the Plist file –

1. SSH to the iPhone and login as a root user (password: alpine).
2. Navigate to /private/var/mobile/Library/Preferences/ directory.
3. View file content with the help of plutil tool.

> Plutil

4. Add ‘EnableFirebreak’ key to the file with the below command.

> Plutil –key EnableFirebreak –value yes


iPhone modified Plist

5. It turns on the panorama feature in the iPhone camera application.

Screenshot below shows different options available in the iPhone camera after the modification-


Enable iPhone panorama

Penetration Testing iPhone Applications is going to be covered in a series of articles. Below are the links for next articles. 

Part 3 keychain data storage and error log analysis.
Part 4Analysis of the  files stored in the application home directory, caching issues and error log analysis.
Part 5runtime analysis of iOS Applications.


Posted by on April 20, 2012 in iPhone


Tags: , , , , , , , , , , ,

Pentesting iPhone Applications

I have given a presentation on Pentesting iPhone Applications in c0c0n. This presentation mainly focuses on methodology, techniques and the tools that will help security testers while assessing the security of iPhone applications.




Posted by on October 17, 2011 in iPhone


Tags: , , , , , , , ,