Today I’m going to be discussing my understanding of a few security concepts Apple have implemented in iOS – including how these concepts influence the user experience and the inevitable outcome for your personal data security. This article is focusing specifically on the encryption-state handling mechanisms within iOS (which handle in what situations data stored on your iOS device is stored in an encrypted or decrypted state). I find this subject especially interesting due to the consumer’s common perception that an iOS device has all user media data encrypted – contrary to my research which proves otherwise. It’s worth noting that not all of this is ‘unfound’. There are plenty of private agencies and individuals researching too! – I like to make my research public and develop open source solutions wherever ethically and legally possible!
Let’s begin to understand the encryption states relevant to iOS
Above, you’ll see a little table I’ve created that describes a few key features of both encryption states, specifically relevant to iPhone.
Firstly, let’s discuss the BFU state, which stands for Before First Unlock. It’s the state your iPhone will be in if you reboot and do not enter a passcode. In this state, consumers generally believe (rightly so) that all of their data is ‘fully encrypted’ and irrecoverable without the device passcode. We’ll talk more about the truth behind this later in the article.
Lastly, we have the AFU state. AFU stands for After First Unlock and describes a state where either the user passcode is known to the investigator, the device is post-unlock, or in situations where the device is locked but meets a variety of specific conditions.
In the AFU state, the SEP will allow for decryption of user media.
Sounds pretty fool-proof, right?
The SEP processor handling the data encryption process, there’s segregation between the user data and system volume, and various situations that will place the device from AFU to the BFU state.
Let’s think about the iOS user experience.
The iPhone unlocks incredibly fast upon boot which is great for the user experience, and looks amazing in the adverts! There’s also the fact that you’ll still retrieve notifications for your favourite applications in the BFU state.
Sounds great, right?
There’s a massive sacrifice in relation to device security happening in the background…
How is your iPhone unlocking so quickly if everything is encrypted, and how is your iPhone pulling application notifications prior to the first unlock? The user will have the same access level as the iPhone (if booted while exploited using checkm8).
If there’s no passcode entry for SEP to unlock the user media volume, how could this be possible? Is there an exploit for SEP? Some sort of magical ‘bypass’?
Well, the values in question were never encrypted to begin with. The iPhone holds various databases, caches and logs in a completely decrypted form.
Some could argue that it’s necessary for some values to be decrypted prior to the first unlock, such as the signed-in Apple ID, and potentially a thumbnail for installed wallet passes (prior to passcode entry the pass data would not be displayed).
While it’s true that some data is necessary for the basic functioning of a device in BFU, it’s important for us to focus on the sheer amount of data left in a decrypted state, and the extent that this fundamental platform insecurity can be exploited, and the data which can, in turn, be recovered with no knowledge of the user passcode.
We can begin to discover, parse, process and visualise data from a locked iPhone
How is your iPhone unlocking so quickly if everything is encrypted? How is your iPhone pulling these notifications for your apps prior to the first unlock? The iPhone will have the same access level as the user.
In a moment we’ll discover that anybody can dump the contents of their iPhone. The contents you’ll find, however, will depend on your ability to sift through data. Luckily for us, there are some steps we can take to automate both the discovery and presentation process! We’ll come back to that soon – anyway, back to the article…
If there’s no passcode entry in order for SEP to unlock the user media volume, how could data extractions be possible?
Well, the truth is that the values in question were never encrypted in the first place.
The iPhone holds various databases, caches and logs in a completely decrypted form. This means anyone with enough time (and a device compatible with the checkm8 exploit in order to start the SSH Daemon on device) could parse, process and visualise a partial data extraction from the device without a valid passcode.
Technology to facilitate/automate this process is largely private and undisclosed to the public. I felt that there should be an Open Source solution for such a task.
Although this presents a major ethical question due to potential misuse, I believe that a free Open Source solution will raise public understanding of such processes and be able to drive further interest and research in the field.
What can an attacker learn about me using my locked iPhone?
It’s a scary question, and unfortunately comes with a scary answer too…
The amount of data that can be accessed using various techniques in the BFU state, but is not limited to:
- Email Accounts on-device
- Social Account User IDs – SnapChat Logged In account name, for example.
- Conversation & Unique Contact IDs for some third party applications – including SnapChat and WhatsApp
- WiFi Access Points (Historical)
- Historical Location Data
- Partial User-Media Access
- Installed Applications & Basic Usage Data
- Much, much more! – this is just scratching the surface
I wonder how this looks in code?…
Above you’ll find an example of an ‘Artifact’ for ZPET in the form of a C ‘Struct’.
Artifacts are used widely across the forensic industry as a method of defining how a specific data-point can be identified/found in the filesystem. Artifacts can come in the form of a plethora of formats, including SQL Queries, commands and sometimes entire scripts if the particular data-point requires extensive parsing to reveal.
We talk about artifacts and how we can find them in a little more detail in my new book iOS Research & Exploration Volume I – where pre-order pricing is still available for a few more days.
From the artifact pictured above in the ZPET Module Extract, we can deduce that the file we’ll be parsing is com.apple.batterydata.cyclecount.plist. This target file contains hundreds of values which we’ll need to automate sifting through.
To demonstrate this, here’s an extract of the com.apple.batterydata.cyclecount.plist PLIST printed (it should appear below this text)
As an investigator, checking out each file in the filesystem will allow us to find what we need – eventually… but realistically, we only want to output the ‘specific value’ we’re looking for.
In the case of ZPET, we can specify the ‘sval’ meaning specific value. This is also known as the ‘Key’ when talking about the PLIST structure. Observing the plist structure, we can identify that our ‘Key’ will be Serial.
If you haven’t guessed, it’ll pull your battery serial number. Here’s an example of how that specific artifact will display in the ZPET Web Output:
If you’re interested in discovering new artifacts, I recommend that you check out my research automation project SPIDER, which is designed specifically to allow beginners to discover data within an iOS Filesystem Dump (you can acquire this dump from your own jailbroken device (or a device vulnerable to checkm8) using a free tool such as iPhone-rootFS-Tool on my GitHub).
I also encourage you to dump the filesystem in both BFU and AFU states, and compare your results! It’ll be a great learning experience and aid your understanding of ‘BFU vs AFU’.
I’ll be posting similar articles to this soon, which will go into more technical depth and work with iOS forensics on a deeper level.
A little conclusion & where to go from here
Thanks for reading! I try to keep my articles short and concise – today’s was a little longer than usual; I hope it was easy to follow! For extra reading, I recommend you dump your own iDevice using a tool of your choosing, take a look at the ZPET source code, and start creating your own ZPET modules.
Remember to make a pull request and let me know so I can share it via Twitter, too!
As always, take care and feel free to drop me a message on Twitter anytime at @J_Duffy01
—James
By James Duffy at 2020-08-31 11:52:02 Source ElcomSoft blog:
No comments:
Post a Comment