I hope that everyone is keeping well, and welcome to this Article, which is a collaboration between myself and Lorie H (@lor1050). I’ve been so excited to release this article, and share it with the readers of the blog! And so, without further ado, let’s start with a little introduction…
Apple Mail - an application pre-installed on 2.2 Billion iPhones worldwide.
Apple Mail is a ‘stock’ application in iOS, and one could presume that the security of a pre-installed application would be an utmost priority, from both the perspectives of protecting user data from remote attackers - but also following Apple’s own guidelines pertaining to storing sensitive user data locally on the device in a secure fashion.
Myself and Lorie have condensed our research around the Apple Mail application to this article - let’s take a look at the details, beginning with the filesystem locations of the artifacts in question…
Resources & Blobs Directories – Application Storage -> Library -> Caches -> WebKit -> Network Cache
MFScreenshotService – Application Storage -> Tmp -> MFScreenshotService
Raw Mail - Partial Data – var -> mobile -> Library -> Mail -> MessageData
The ‘Resource’ Directory
The ‘Resources’ directory contains a plethora of files with uniquely-generated filenames, each containing the network ‘response headers’ to a network GET request to a remote mail server (in order to pull media assets for incoming emails). We can learn a few things from these response headers, including the full address of the specific media asset, and other sensitive data, we’ll explore in a moment!
Examining a randomly-selected file from this directory, we can immediately observe the ‘ResourceC’ string which is present in all files within the Resources directory.
We can use this to further our automations as we can understand and note the ‘ResourceC’ as a value in the file header differentiating it from other unrelated files.
After the ‘ResourceC’ string, we can observe a few empty bits directly followed by the full URL of the asset. Luckily for us, we also have some ‘unique’ data at the end of the full URL - 4 hex bytes ‘FFFFFFFF’
The request headers can also be observed in each document - There’s a few values of immediate interest…
- Date - This value will provide the timestamp (including time zone!) pertaining to when the image was cached on device
- Server Data - You’ll often find partial banner information pertaining to the ‘service’ which distributed the media. For example ‘Apache’ or ‘LiteSpeed Web Server’ - This information could allow for some assumptions to be made around the infrastructure of the network in question, should the sending device/server of the email be of interest (maybe the server that sent the media is no longer available or is an internal corporate server that’s not directly available).
- Possible EXIF/Associated Media Data - This could include information such as the ‘Last Modified Date’ of the asset, and EXIF data such as Photograph Location Data should this information be relevant.
Although pulling EXIF/Other Metadata using these sources might seem trivial as the data could be pulled directly from the image (if re-downloaded from the server) - it’s important to note that the media may no longer be externally available, and so having the local repository of information could prove invaluable.
Here’s an example I bumped into somewhere along the research process. Not only was the service information (including the software version) exposed, but also part of the internal IP address schema. We can figure a lot of information from just the resources data!
The ‘Blobs’ Directory
The ‘Blobs’ directory contains extensionless visual media. Contrary to my original thought, these files are not the media that could be pulled using the records within the ‘Resources’ directory.
I was also unable to match any file-names in ‘Blobs’ with the file-names within ‘Resources’, and couldn’t determine any correlation. So I can only assume the media was embedded in a different form within the email.
The media I have identified held in the Blobs directory includes…
As the files are extensionless and do not utilise any other obfuscation methods, we can simply check the file header manually and/or use the ‘file’ utility on a unix system to identify the original file-type.
The filename appears to be randomly generated, just like the files within the ‘resources’ directory - although this time we can observe the ‘-blob’ string appended to the end of the filename.
Generates extensionless PDFs upon a prompt to print (does not require print to start). The PDF is a full resolution reproduction of the e-mail message including non-moving assets. Basic information pertaining to the specific mail message is also included…
- From (contact name + email address)
- Date (full date-time, no time-zone)
- To (full email address + internal name)
The generated PDFs are not directly ‘accessible’ to the end user, and retained in the filesystem for an unknown amount of time. The generated PDFs are also available in the BFU device state, meaning it could be extracted post-reboot, prior to a passcode unlock.
If you’re new to the iDevice encryption states, I cover different states and their influence on your research here -> Taking The First Step - iOS Security & Forensics -P1 — James Duffy
Before we move on, i’d like to quickly note that I have not found any correlation between the generated filename of the PDF and the associated raw email message. The filename appears to be random for each time the user launches the iOS ‘Print’ view.
A note for consumer jailbreakers…
While it’s important to note that all iDevices vulnerable to checkm8 are at a risk of some form of data extraction, consumer jailbreakers are at risk for a couple of reasons (i’ll assume you installed a tweak from a package manager)…
The tweak developer (a potential attacker) has unrestricted access to the data on your device. As many, if not most online services send password reset emails and other authentication links via e-mail (sometimes vulnerable to re-use), it’s more than possible for the tweak developer to simply process the raw email contents stored on device (in a decrypted form) and parse out these sensitive links and post them to a remote server.
Granted, Apple isn’t obliged to consider jailbroken users, and could pretend checkm8 vulnerable devices do not exist - but I believe it should be a consideration in some capacity at least.
Maintaining sensitive data in a completely unencrypted form like the example above (MFScreenshotService) in a form that’s available before a device unlock (BFU) is not abiding by Apple’s own file protection guidelines… the irony.
That’s enough from me - I’ll now pass the virtual microphone to Lorie!
Partial Raw Mail Data
I went in search of previous public research in the area of Apple Mail.
I located an article “Identification and Analysis of Email and Contacts Artefacts on iOS and OS X” by Kenneth M. Ovens and Gordon Morison (2016). These authors were working with iOS 8, but they provided some useful information on the location of email artifacts, Interestingly, the paths have not changed much from iOS 8.
Ovens & Morison (2016) used Wireshark to confirm the protocol which Apple uses for E-Mail, which is the Internet Message Access Protocol (IMAP) over SSL. The authors state that “this allows for multiple clients to simultaneously connect to the same mailboxes to retrieve emails” (Ovens & Morison, pg, 4, 2016).
I utilized my iPhone 7 testing device running iOS 13.3.1 for research - the device is jailbroken using Checkra1n. I connected the Brian Thompson gmail account in the Apple email stock application. I did not add any new emails. Unfortunately this made the availability of cached raw partial mail data in BFU state unavailable. However, in analyzing a ffs dump I still was able to recover some interesting artifacts which surprised me. I followed the path private/var/mobile/mail.
As you can see under the mailID it is noted [Gmail], then folder Messages. I located a few important artifacts within the emlxpart files, Brian Thompson had set up a Google Voice account. Within two of the emlxpart files the Google Voice phone number provided as well as the forwarding phone number used to verify the account are located. I used CodeRunner to open the files.
As you can see there is also the associated Gmail account. The Thompson account had been set up to receive email notification of chats on the Google Voice account. While the sender of the chat is not listed the content of the chat is.
Also, the receipt for the purchase of a Google Play application was also located along with a timestamp.
In the stock Apple email application the user is provided the option of which email client they would like to use. It would behoove the examiner to check these files especially if the user is known to use gmail. I was very surprised to locate the Google Voice phone number as well as the forwarding phone number. The timestamp receipt for the Google application purchase is a nice tip as well.
It’s also possible to get the timestamps of these emails. There are two associated files with each entry. One file contains the timestamp information and the second contains the message content. The content is also in the timestamped file, but it is encrypted. It is understood by the Subject matter, which content is being referred to, See images below
I really hope you enjoyed learning a little more about Apple Mail from a forensic perspective, and I hope you learnt something new! I’ll be posting some more articles pertaining to Apple Stock Applications soon!