Now that you are well acquainted with the iOS development environment and simulators, and have coded your first application as well, it is time to learn about penetration testing for iOS applications. Penetration testing for mobile applications can be broadly classified into four categories, as we saw in the previous recipe:
Mobile application traffic-related attacks Mobile device storage-related attacks
Mobile application source code-related attacks
Attacks involving mobile OS features used by mobile applications
Getting ready
We have to set up a lab for iOS pentesting, which should be sufficiently well equipped to be able to conduct testing for test cases that fall into the four categories listed previously.
To get going, we need a minimum of the following tools. The list is not very different from Android, but includes some specific tools:
iOS simulators
Xcode iExplorer
One or two iPhones or iPads (jailbroken)
Proxy tools such as Charles, Burp Suite, and Fiddler A Wi-Fi network
Tools such as SQLite browser, text editors, XML viewers, and plist editors A data cable
Tools such as otool and classdump
How to do it…
Let's look at each of these tools:
iOS simulators
We will use iOS Simulators to run iOS applications where we have the application code available to us. In such cases, testing can be conducted from just one MacBook with all the tools installed (no need for Wi-Fi or mobile handsets).
Xcode
Xcode is the IDE for iOS applications. It is not only helpful for reviewing the source code of an iOS application, but also comes in handy in terms of viewing certain files, which open in Xcode only.
iExplorer
iExplorer can be downloaded on a MacBook from the Apple App Store. A Windows version of this can also be downloaded when working with iPhones or iPads connected to a Windows machine via a data cable.
iExplorer, like Windows Explorer, helps to navigate the filesystem. It can be used to explore, read files, and steal data from iOS devices.
One or two iPhones or iPads (jailbroken)
A jailbroken iOS device comes in handy. The applications installed on these devices can be pentested from the device itself, eliminating the requirement for Simulators.
Proxy tools such as Charles, Burp Suite, and Fiddler
Various proxy tools can be downloaded from their websites. These are quite straightforward and there are guides and help forums about them as well.
The installation of such tools is outside the scope of this book, but we will cover the configuration of them for mobile applications.
Here are links to the most common proxy tools:
h t t p : / / p o r t s w i g g e r . n e t / b u r p / d o w n l o a d . h t m l h t t p : / / w w w . c h a r l e s p r o x y . c o m / d o w n l o a d / h t t p : / / w w w . t e l e r i k . c o m / d o w n l o a d / f i d d l e r A Wi-Fi network
We need a Wi-Fi network to intercept Wi-Fi traffic. We will later set up a proxy for a mobile device to a laptop running a proxy tool, with both on the same Wi-Fi network.
Either you can use a Wi-Fi router to set up your personal Wi-Fi network, or you can use one of the free tools available to create a hotspot from your laptop. In our experience, it is sometimes difficult to work with the latter option, so we prefer using the former.
Tools such as SQLite browser, text editors, XML viewers, and plist editors These are additional tools for reading the data extracted from phones. Again these are free to download, or you may already have them.
plist files are used in iOS applications to store data, and plist editors are useful in reading such files.
A data cable
It is also important to own a data cable. Later, we will use it to connect to the phone in order to read data and conduct attacks that originate via USB.
Tools such as otool and classdump
These tools are decompilation tools for iOS applications.
How it works…
With the tools ready in our pentesting lab, let's see how we can link the penetration testing use cases to different categories while using these tools:
Mobile application traffic-related attacks: This is where a Wi-Fi network and proxy tools are going to come in handy. A laptop with a Charles or Burp proxy installed is connected to Wi-Fi. An iOS device running the application is directed to the laptop proxy, using the proxy configuration on the device. Since both the laptop and the mobile device are on the same Wi-Fi network, application traffic is routed via the Charles or Burp proxy tool. This setup does not require a MacBook (any other laptop will do), but an iOS device is needed.
Another possibility is that we can use a MacBook but not an iOS device. In this case, we will run the application via Xcode and the Simulator. The proxy is set to localhost on the MacBook, where we are running a proxy tool such as Burp or Charles.
Effectively, both approaches make application traffic readable and editable via proxy tools, and we can conduct various attacks, which will be seen in another chapter.
Mobile device storage-related attacks: We have a data cable to connect the iPhone or iPad to the laptop. We can use the iExplorer tool on the laptop to read and steal files and other data.
Mobile application source code-related attacks: We discussed the otool and classdump tools. Only a limited decompilation is possible in the case of iOS applications, and these tools can help only up to a certain point. This will be covered in detail in one of the later chapters.
There's more…
Attacks involving mobile OS features used by mobile applications
This is the most complicated category and becomes further complicated in the case of the iOS platform. There are various iOS features that applications interact with, such as screenshot backgrounding, Bluetooth, NFC, and so on. The interaction of these features with the application, along with the insecure implementation of these features in the application, results in vulnerabilities. A popular example is the screenshot backgrounding vulnerability in iOS applications.