iOS Mobile Application Security – What Does Your Attack Surface Look Like?


Mark Rose

As of May 2023, there were 1.76 million apps and 460 thousand games on the Apple AppStore. Applications do not always have to financially cost the end user, in-fact, majority would not cost a single penny. So where is the compromise, how can applications be offered at no cost and expected to be secure; are all applications in the store to be trusted, what information would be accessible if an application were to be misconfigured or what behaviors could be carried out if a malicious application were to make its way onto the device?

Due to the absence of cost most users would not hesitate to install an application. This action would be taken without considering the impact on information exposure.

As mentioned in a previous piece, application interaction often occurs within the first 30 minutes of a user’s day. Interactions have been integrated into routine and will happen without much thought.

Developers and organisations strive to provide users with convenient and accessible functionality through applications. However, many developers fail to consider the potential security risks and organisations struggle to fully understand their security posture as a result.

As with the Android security principles, to understand attack surface, we first need to understand the structure of an iOS application:

iOS applications are a lot more complex than their Android counterparts. iOS applications do not have the ability to communicate directly with hardware. To carry out the communication, defined system interfaces or layers are used. These interfaces enable developers to write applications in a more efficient, and easier manner, to ensure application logic and functionality operates over various iOS versions and device types.

Interfaces are provided in the form of special packages called frameworks. The role of a framework is to supply a directory that holds dynamic shared libraries containing files, resources such as nib files, images, and a helper application to support libraries.

Layers contain frameworks that, as aforementioned, can be used to assist developers. There are four layers we need to be concerned about, summarised briefly below:

  1. Core Operating System Layer – Contains frameworks that could be used to leverage other existing technologies.
  2. Core Service Layer – Provides functionality including, but not limited to; in application purchases, access to contact lists, leveraging smart devices via homekit and location services.
  3. Media Layer – Used to provide graphics and audio.
  4. Cocoa Touch – Assists with user interaction with the application. The main functionality is user touch and motion, however, more exist.
iOS Mobile Application Security - attack surface - ios layered architecture

Figure 1 – iOS Layered Architecture

Application developers have various options on how to approach the development via different application types:

  • Native
  • Hybrid
  • Web Based

Native iOS applications are going to be the focus, with specific focus being placed on an application called Damn Vulnerable iOS App-v2(DVIA v2). The application is written in Swift, and as the name suggests, is vulnerable by design.

What is an application?

At a basic level, iOS applications are compressed into an .IPA file which is an archive containing the relevant application files. The application data can be retrieved by renaming the file to <something>.zip and then extracted in the usual manner. Once complete the contents would become visible and be ready for analysis.

iOS applications are uniquely sandboxed. By sandboxing it helps ensure that individual databases are used per application and segregation is occurring. By adopting this process, the chance of another application obtaining confidential information is reduced, however, not nullified.

The iOS application contains three containers:

  • Bundle Container – within this container all the application files are located in a designated folder when installed on the device. These will remain static in all resulting installations, on every iOS device, being identical. Important information would be located within this container and would help assist a threat actor in gaining a better understanding of potential attack surface.
  • Data Container – contains unique data that is cached to assist with the running of the application. The files within the Data container would be continually changing to help remember data such as who has authenticated, what point the user stopped interacting so progress could resume from there or what data has been stored. These files should remain on the device until the application is removed.
  • iCloud Container – Contains data stored within the iCloud that has been used by the application. If a user were to interact with one of these files on the application, subsequently, the data in iCloud should be updated to reflect these amendments.

Example Misconfigurations

When an iOS device has been compromised, a threat actor will look for target applications that would have the most financial gain, or greater chance of obtaining confidential data to carry out further attacks. Static assessment of files contained within the containers outlined above would occur along with dynamic analysis to identify an attack surface.

Threat actors, along with supporting API issues, would look to identify misconfigurations within the application logic such as, but not limited to

  • Jailbreak Detection Bypass – Jailbreak detection is often implemented on applications. Developers implement this to prevent threat actors leveraging further tools that could compromise confidential data or from reverse engineering the application. Despite this, there is often a way to bypass this protection exposing the complete attack surface.
  • Local Data Storage Misconfigurations – Local data storage contains application, and user, specific data. This data often relates to authenticated users, developers leaving in hardcoded credentials or excessive permissions. If exploited, the confidentiality of this information would be impacted in a negative manner and the integrity of data would also suffer negatively.
  • Touch/Face ID Bypass – Touch and Face ID can be used by application users to authenticate into the application, an example of this would be your banking application. If the protection were bypassed, the functionality behind would become accessible. This would result in impersonation of the user and funds being transferred to a threat actor-controlled account. Additionally, account details may be amended resulting in availability suffering along with confidentiality and integrity.
  • Phishing – Creating a phishing prompt that would attempt to compromise credential sets so that the associated account could be compromised.

Assisting Tools

Tools, as part of any job, are important as they will help identify, and leverage these misconfigurations. The tools discussed are only a small number of those available and would be adopted by threat actors and security consultants. These tools help perform the required actions in an easier manner and will be used to exploit the misconfigurations in DVIA-v2.

  • Frida – a dynamic code instrumental toolkit. Frida allows threat actors to inject JavaScript into applications to help bypass restrictions. Frida has an active community that uses Frida Codeshare to share snippets of code that help to bypass Jailbreak detection, SSL Pinning and Root detection for Android and IOS amongst other things.
  • Objection – a runtime mobile exploration toolkit that leverages Frida. Allows security professionals and threat actors to analyse target applications and helps assist with exporting confidential data, and bypassing protections.


Prior to using Frida, the device would need to be Jailbroken. Once Jailbroken the server will need to be launched, this could be achieved by installing the relevant files through the Cydia store or obtaining the version via their GitHub repository. Additionally, the client would need to be installed on the device the iOS device was connected to. Once on the devices, by default, Jailbroken devices allow for SSH, the networking details can be obtained via the settings page as such:

iOS Mobile Application Security - attack surface - Network settings iOS

Figure 2 – Network Settings iOS

Once obtained, it would be possible to SSH into the device:

iOS Mobile Application Security - attack surface

The credential set, by default, is root:alpine

After successfully initiating the connection, it would be possible to launch the Frida server:

iOS Mobile Application Security - attack surface - frida running

Figure 3 – Frida Running

To verify this, the following command could be run on the device the iPhone is connected to:

iOS Mobile Application Security - attack surface

This would result a list of applications and processes installed on the device being presented:

iOS Mobile Application Security - attack surface - applications installed

Figure 4 – Applications installed

If any issues are present, ensure that the client and server versions match.

Jailbreak Detection Bypass

Jailbreak detection is designed to prevent applications from running a device that has been Jailbroken. Simply, the code would be incorporated into the mobile application to identify potential indicators of a device being Jailbroken. Files associated with Cydia, as an example, would be searched for and if identified the application would not launch. The protection is often deployed on applications to prevent reverse engineering and data extraction as a threat actor would be able to perform actions a normal user would not be able to.

In this example we are going to bypass the Jailbreak detection on DVIA using Frida:

Initially, when interacting with Jailbreak Test 1 the following prompt was present:

iOS Mobile Application Security - attack surface - application detecting jailbreak

Figure 5 – Application Detecting Jailbreak

As aforementioned, Frida, along with Codeshare, can be used to bypass by running the following command:

iOS Mobile Application Security - attack surface

This will instruct Frida to inject code from codeshare to help bypass the detection. Once ran, interaction with the application would need to occur for the checks to be carried out. As below, the application is checking for common Jailbreak files. Despite this, the script was able to deceive the checks and bypassing successfully occurred:

iOS Mobile Application Security - attack surface - frida injecting code

Figure 6 – Frida injecting the code into the process

iOS Mobile Application Security - attack surface - application not jailbroken

Figure 7 – Application suggesting the application was not Jailbroken

Another method, using Objection, would also be possible to pursue if no script from Frida codeshare worked. Objection has a built-in bypass that was accessible. This could be executed by replicating the following:

iOS Mobile Application Security - attack surface
iOS Mobile Application Security - attack surface - objection jailbreak bypass

Figure 8 – Objection Jailbreak bypass

Objection would output the above when interaction occurred, however, despite it looking as if it failed due to the return values, the bypass was successful:

iOS Mobile Application Security - attack surface - application not jail broken

Figure 9 – Application suggesting the application was not Jailbroken

In addition to the built-in bypass, further features of Objection could be leveraged to craft an application specific bypass. To do this, further enumeration of the application would need to happen.

Enumeration of classes would be the first step:

iOS Mobile Application Security - attack surface

The term could be altered to search for a specified value, as Jailbreak detection was being looked at, the searched term used was jail.

Executing the command resulted in the following classes being revealed:

iOS Mobile Application Security - attack surface - jailbreak classes identified

Figure 10 – Jailbreak classes identified

  • JailbreakDetection
  • JailbreakDetectionViewController

Once methods were located, classes would need to be enumerated by watching the class. This could be achieved by specifying the method and interacting with the application:

iOS Mobile Application Security - attack surface

Whilst interacting with the application the isJailbroken method would be revealed as the method assisting with the identification of the device being Jailbroken:

iOS Mobile Application Security - attack surface - method located from class

Figure 11 – Method located from class

Throughout interaction with the application, the Jailbreak Test 2 returns the following:

iOS Mobile Application Security - attack surface - method monitoring catching jailbreak

Figure 12 – Method monitoring shows method catching the Jailbreak

Monitoring of the method now needs to occur with the return value being dumped:

iOS Mobile Application Security - attack surface

Monitoring of the method now needs to occur with the return value being dumped:

iOS Mobile Application Security - attack surface - method monitoring return value of exit

Figure 13 – Method monitoring for Return Value of exit

The value was 0x1 suggesting an error point, this was telling the application that the device was Jailbroken. As such, the method would need to be manipulated to alter the Return Value:

iOS Mobile Application Security - attack surface
iOS Mobile Application Security - attack surface - return value 0x0

Figure 14 – Return value being set to 0x0

Following this, Jailbreak Test 2 could be run, and the following output would be present in Objection highlighting that the Return Value was overridden:

iOS Mobile Application Security - attack surface - altering return value

Figure 15 – Altering Return Value

The application would no longer be able to identify the device as Jailbroken:

iOS Mobile Application Security - attack surface - jailbreak bypass

Figure 16 – Jailbreak bypass occuring

Bypass could also be achieved in a different manner within Objection, the process would be similar by identifying where the detection was occurring then issuing the following command to generate a simple script that could be passed to Frida:

iOS Mobile Application Security - attack surface
iOS Mobile Application Security - attack surface - simple script generated

Figure 17 – Simple script generated

This script would need to be saved, in this instance it was named JBBypass.js, however, amendments would need to happen as this was not telling the application the device was not Jailbroken.

The following changes to the script would be required:

iOS Mobile Application Security - attack surface

Once done, the script would need to be passed to Frida and  user interaction with Jailbreak Test 2:

iOS Mobile Application Security - attack surface - bypassing with script from objection

Figure 18 – Bypassing using Frida with script from Objection

The device would now show as not jailbroken as the return value retval had been set to 0.

iOS Mobile Application Security - attack surface - jailbreak bypass with custom script

Figure 19 – Jailbreak bypass with custom script

Exploitation of WebViews

WebViews are similar across both Android and iOS, they enable a developer to incorporate web applications into their mobile applications. Despite this, when used, web application vulnerabilities are introduced. As such, if injection points were to be identified it may be possible to extract data from supporting databases or phish application users for credential sets.

To exploit this a threat actor would attempt to inject benign payloads across the application to identify broken application logic. Within DIVA-v2  webviews are present, so how would this be approached to carry broken application logic?

The first step would be to identify the vulnerability. There are multiple resources that could assist with the manual identification such as HTML tags or characters to verify  if a 500 HTTP Status code would be returned from the web application. The focal point would be HMTL tags, as visually, it would be able to determine whether these have functioned as intended.

The following payload was injected into the webview:

iOS Mobile Application Security - attack surface

If these tags were rendered, there would be a chance for cross site scripting (XSS). Once submitted, the application would present the output in the following manner:

iOS Mobile Application Security - attack surface - html tags functioning

Figure 20 – HTML tags functioning

As the tags are being rendered the next step would be to leverage this into a functioning cross-site scripting payload. There are numerous resources out there to assist with this, a great resource would be PortSwigger’s XSS cheat sheet.

The payload used would need to be altered so that unwanted actions occur impacting application users rather than altering the format of their content:

iOS Mobile Application Security - attack surface

This would cause the application to request resource x, and as it was not present, an alert box with 1 would be returned:

iOS Mobile Application Security - attack surface - alert 1 inside application

Figure 21 – Alert 1 inside application

This instance of XSS was reflected, as such, the impact would be lowered because of the payload was only executing for the user of the application. Despite this, if an application were to store and request data for multiple users within the same organisation, or cross tenant without appropriate authorisation controls, this issue could impact in a negative manner.

An example could be to create a payload that logs keystrokes back to an attacker-controlled server. This would require an XSS script that is beyond what will be discussed, however, to create a prompt the following payload could be used:

iOS Mobile Application Security - attack surface

This payload leverages the string.fromCharCode method to use ASCII for characters, this could be used to bypass XSS detection checks.

Once submitted, the prompt below was present:

iOS Mobile Application Security - attack surface - prompt for password

Figure 22 – Prompt for passwords

Leveraging Pasteboard

The pasteboard in iOS is like the clipboard in Windows. The pasteboard stores the last data that has been copied or is being copied if the process is being monitored. This could be particularly useful to threat actors as often users use password managers, or set complex passwords, for their user accounts. As a result of this, it would be easier for them to copy the data so it could be submitted for authentication.

If a threat actor were able to compromise a device, they would be able to inject into an application process and read the data that has been stored in the pasteboard. Often developers and organisations accept this risk as it is a usability vs security issue. Despite this, sensitive, and confidential information could be revealed.

Using Objection, it would be possible to monitor the clipboard to see what has been copied. The following could be run to monitor the process:

iOS Mobile Application Security - attack surface

Once started monitoring will commence and anything copied would be outputted as such:

iOS Mobile Application Security - pasteboard monitoring obtaining password

Figure 23 – Pasteboard monitoring obtaining a password

As such, it would be possible to obtain the users super secure password, this could be used to carry out password spraying attacks against potential accounts. Due to this, there had been a loss of confidentiality along with the chance of impacting integrity and availability if a valid credential set were obtained.

Bypass Touch/Face ID

Touch and Face ID was introduced by Apple as an additional way to authenticate into the device. Users prior to this would be required to type in their passcode every time they wished to access their devices. As such, it was a huge step towards further enhancing their devices usability. Since their implementation, many application developers now allow their users to enter a biometric of choice to authenticate into their applications.

With this in mind, if not implemented correctly, it would be possible to bypass these restrictions tricking the application into believing successful authentication had been carried out. This puts the data behind at risk.

Examples of these include mobile banking applications. If the banks developers were not implementing their protections appropriately, users who have their device compromised would risk their accounts being tampered with and money transferred to threat actor-controlled accounts. As such, there is a large associated risk.

To demonstrate the possibility of  bypass , the Objection tool was used once more. As the device used only had Touch ID. The following command could be issued once the application was hooked:

iOS Mobile Application Security - attack surface

Interaction with the Touch/Face ID section within DVIA-v2 would need to occur, either of the options could be selected and this would successfully bypass the protection:

1. Select either option
2. Use any finger on the reader

iOS Mobile Application Security - attack surface - finger prompt

Figure 24 – Finger prompt

3. Will respond saying that the fingerprint failed

iOS Mobile Application Security - attack surface - failure of authentication

Figure 25 – Failure of authentication

4. Press Cancel
5. Repeat The process
6. Authentication would be successful

iOS Mobile Application Security - attack surface - protection bypass

Figure 26 – Protection bypass

The output from Objection would be as illustrated below:

iOS Mobile Application Security - attack surface - objection assisting the bypass

Figure 27 – Objection assisting the bypass

As above, the initial response for the biometric was false, however, as the application was hooked by Objection and injected with the bypass the response was altered to be true instead. This resulted in a successful authentication.

Local Files

Local files are application specific and will relate to the user who carries out the interaction. As such, the information that could be obtained would result in the confidentiality, integrity and availability of their account being hindered.

On iOS there are numerous files that could be interrogated to see if sensitive information were present from users, a small selection of these files have been selected:


Property List Files (Plist) are XML structured text files containing configuration information regarding the application. Plist files contents can contain sensitive information and it is important to assess the files to understand what data is being saved as this would be accessible. Unlike Android, when permissions are set, a description of why is required.

Within Plist files various data is contained such as bundle name and identifiers which would be used to assess the application for misconfigurations and permissions to enable the application access to specific device components.

If configured to be storing application users’ data it would be possible to retrieve this using objection:

iOS Mobile Application Security - attack surface

This would then result in the confidential data being exposed.

iOS Mobile Application Security - attack surface - information within the user infor plist

Figure 28 – Information within the user infor plist

Depending on what is revealed, this information could be used to carry out further attacks such as password spraying, phishing, or impersonating  users. These attacks could further impact  the confidentiality, availability or integrity of the account and its associated data.


NSUserDefaults is a class that allows interaction with the system. The file is used to help remember how users have customised their application such as if your playlist was in shuffled mode, how you want to measure something by remembering the unit or what theme was used on the application. These are stored by the application by assigning values to parameters within the user’s default database.

If misconfigurations are present on what data is being stored, these files may reveal confidential information.

To obtain this information the following would be used:

iOS Mobile Application Security - attack surface
iOS Mobile Application Security - attack surface - nsuserdefaults

Figure 29 – Nsuserdefaults  revealing sensitive information


KeyChain assists with the storing, and management of credential sets. Think of when a login form is presented on an iOS device, it is possible to fill the data via the press of a button. These interaction happen through the keychain. Data could be retrieved from the KeyChain using Objection with the following command:

iOS Mobile Application Security - attack surface
iOS Mobile Application Security - attack surface - keychain revealing data

Figure 30 – Keychain revealing data

Side Channel Data Leakage

Side channel data leakage can be described as accidental, or unintended, leakage of data. This occurs via misconfigurations that are often overlooked when developers are securing their application in a different place. A threat actor could obtain confidential information that could be used to carry out further attacks.

Entities that would come under scrutiny would include device logs, app screenshots when changing views, paste board and cookies as an example.


Often mobile applications incorporate webviews or have supporting API, or locally stored the values. As such, authentication would rely on cookies to help improve the user experience, because who wants to have to insert their password every time they open an application. As such, they could be stored insecurely and not have best practice flags set.

If flags are not set, it opens the values up to attack and increases the chance of compromising the confidentiality of the information. Objection could be used to see what cookies are present within the hooked application by running the following command:

iOS Mobile Application Security - attack surface

After running, the users credential set would become visible, and it is evident that the best practice flags had not been set due to the false value assigned to the Secure and HTTPOnly values in the table.

iOS Mobile Application Security - attack surface - cookies returning credential set

Figure 31 – Cookeis returning credential set

These values prevent the transmission of the data over any connection that is not SSL/TLS and deny any technology that is not HTTP or HTTPS from accessing the cookies.

To demonstrate that these credentials were valid, it would be possible to input them into the application and the following message was returned:

iOS Mobile Application Security - attack surface - cookies returning credential set

Figure 32 – Authenticating using credentials in cookies


When device users switch between applications a screenshot of what was previously on the application is often visible. By default, the screenshot would be saved in the following directory:

iOS Mobile Application Security - attack surface

These snapshots could be obtained via a threat actor who had compromised the device or viewed by someone shoulder surfing. If the information is confidential, it should be handled in the appropriate manner. Again, think of a banking application, when these are backgrounded and applications switched, they are either blurred, or replaced by an image. This demonstrates a mature approach to security as the information is protected.

In this instance, the application was not using something like BlurKit or other appropriate mechanisms to secure the information. As such, the user’s security question answer could be revealed. This information would then be stored on the device in local storage to be retrieved at a later date, or shoulder surfed.

iOS Mobile Application Security - attack surface - screenshots with changing views

Figure 33 – Screenshots when changing views

Like Android, there are numerous attack paths and vectors a threat actor could look to leverage, many of these not discussed in this article. Throughout, a basic understanding of iOS and application structure was obtained along with some potential vulnerabilities demonstrated. These vulnerabilities are examples of what a threat actor would look to exploit.

By carrying out a penetration test, risks would be identified prior to exploitation in a production environment. A penetration test would help improve the application security posture and assist with the prevention of reputational damage or confidentiality of information which in turn would protect user safety.

Rounding back to the initial point, how confident are you with your application’s security posture, do you believe that the best, and most secure, version of it is being presented to your clients, and are you aware of the available attack surface? If the answer is no to any of these, or if you would like an assessment to reassure you, contact Pentest Ltd to help you improve your application security posture and demonstrate mature approaches to security.

Looking for more than just a test provider?

Get in touch with our team and find out how our tailored services can provide you with the information security confidence you need.