With every new release of its iOS operating system, Apple introduces new security features that harden more and more the mobile devices produced by Cupertino. As direct consequence of that forensics becomes harder, particularly the acquisition phase. And this remained true also with the latest version, iOS9, which has been released in September 2015 and is supported starting from iPhone4S and iPad 2 models.
Our fellows, Pasquale Stirparo and Mattia Epifani, wrote a practical hands-on guide to acquire and analyze iOS devices with the latest forensic techniques and tools: Learning iOS Forensics
We are happy to present their book through the following insights.
You mentioned the acquisition phase is particularly affected by the new iOS releases. What are the options available with iOS9?
The most affected type of acquisition is the physical (also called bit-to-bit), which is not feasible anymore for iOS9 devices, except if they are already jailbroken or for devices up to iPhone4 (which do not support iOS9). Generally, this has always been the ideal type of forensic acquisition because it is the exact representation of the original media and it has the benefit of allowing the forensic analyst to perform activities such as file carving, in order to retrieve deleted files. However, this would be unfeasible with iOS devices anyway, since Apple encrypts by default each file with a unique key that is deleted with the file itself.
The second option is to perform a backup acquisition via iTunes or any other software that makes use of iTunes libraries. The ability to obtain a backup will, however, depend on different scenarios that the forensic practitioner may be presented with at the time of seizure such as:
- The device is switched off and locked with a passcode
- The device is switched on and locked
- The device is switched on and unlocked, but it has a passcode set in place
- The device is either switched on or off but no passcode is in place.
In the first scenario the only information available will be the generic one about the device such as Device class (iPhone, iPad, iPod), Device name, Device colour, hardware model, iOS version, Unique Device ID (UDID) and Wi-Fi MAC Address, since at the moment there are no known techniques to bypass the passcode.
In the second scenario, the only way to get a backup is by finding a lockdown certificate from a computer the device has previously paired with, such as the computer of the device’s owner. Such certificate can then be copied to the acquisition workstation within the same folder and used to get a backup of the target device. Moreover, it is important to keep device switched on and powered on, this hold true any time a device is found switched on either locked or not.
The third scenario is tricky and lucky at the same time. Lucky because finding a device unlocked is not common, tricky because it requires extreme caution and speed from the analyst to perform few crucial steps. First and foremost, the device needs to be secured by isolating it from any type of network connection. This is possible by placing it in “Airplane Mode”. The next step is to check whether the device has the automatic locking of the screen set, and in case disable it from the menu. After those two simple but fundamental precaution measures, it is finally possible to connect the phone to a forensic workstation and perform the iTunes backup.
The fourth scenario is the easiest one, since it is always possible to get a backup of the phone.
The other acquisition option available is to use the AFC protocol to extract files individually, which is supported both by classic mobile forensics software andby device management software like iFunBox.Starting from iOS 8.3 the information that you can get are really reduced because Apple activated a sort of sandbox for each application that doesn’t allow to get data by using this protocol.
A third option is to get data from iCloud, if in use by the device owner. In this case you need to know the iCloud user credentials (username and password) or search for an authentication token in a computer with the same account configured in iCloud Control Panel software.
At the moment, a backup acquisition remains the most common and comprehensive type that an analyst may get with modern iOS devices.
iTunes backup is quite valuable, but they can also be encrypted right? What should the approach be in such cases?
Indeed even if the analyst is able to extract a backup, the user may have set a password and therefore the resulted backup will be encrypted. In this case, performing an acquisition via AFC protocol is always advisable even when a backup is possible because the data extracted are always in clear text.
If the backup is encrypted may be very difficult if not impossible to access the data once extracted. In such case the only approach left is to try to break the encryption password. Obviously, the success of the attack depends on the complexity of the password and on how many attempts per second the analyst is able to perform. What can be also useful is trying to build a custom wordlist for the user. Moreover, if the user of the device has an Apple computer, it may be possible to try to extract the backup password from the computer Keychain.
Finally, if the attempted attack on the password of the backup fails, it is in any case possible to view the list of files inside the backup with their metadata, analysing the file manifest.mbdb that is in cleartext even when the backup is encrypted. Other information generated by the backup and always in clear text even in the case of encrypted backup is present in the Info.plist, Manifest.plist and Status.plist files.
Is there any other type of valuable information that can be extracted from an iDevice?
There is one more type of information that can be acquired and which we are currently investigating further: it’s the device Crash Logs.
The original purpose of the iOS Crash Logs is to provide developers with indicators relating to problems generated by their apps. However, those information can be very useful also during a forensic analysis since can help to recreate a timeline of events contained in the log, therefore helping in understanding the activities of both operating system and applications (they may contain information from applications which have been already uninstalled from the device at the time of the acquisition). An interesting example is about the Crash Log files generated by Apple’s Mail app, which contains among other information the names of attachments received via e-mail, the date the email has been received, the email account related to it, etc. This information becomes even more interesting when considering that the emails are not included in the backup and cannot be accessed with the AFC protocol, but only on jailbroken devices.
