Update: Solutions for iOS10 – Encrypted Backup Files, Cracking Passwords and Data Acquisition

Happy Friday everyone. After my post last week, I was in touch with several vendors about what was occurring, my thoughts and how they intended to fix the problem when it comes to accessing the backup file data. Since then, two vendors (Cellebrite and Elcomsoft) reached out with an updated solution. I tested these tools over the last two days and want to share my results. I used Cellebrite Physical Analyzer v 5.3.5.10 (soon to be released), Elcomsoft v6.10 and iTunes 12.5.1 as well as the previous iTunes version to be thorough.

What changed since the last blog?

First, if an iOS10 backup file was encrypted with iTunes, you do not need to assume you cannot get into that data. (This was the case in my previous blog. Even if the password was known, the tools were choking on the data).  If you can crack the password, Cellebrite’s UFED Physical Analyzer will properly decrypt this data. I bet you are now wondering how I cracked the encrypted iOS 10 backup files? I used  Elcomsoft Phone Breaker v 6.10.

Cracking an encrypted iOS10 backup file

I set three different passwords to test. The first was 0000 and Elcomsoft laughed at this and provided the password before I could even sit back in my chair to watch. I then updated iTunes and changed my password to “hank” – this password didn’t even take a full second to crack.

elcomsoft_cracked

Maybe their claims are true that they will crack a passcode the fastest due to a vulnerability they found in the hashing of the passcode.

http://thenextweb.com/insider/2016/09/23/researchers-say-ios-10-backups-can-cracked-2500-times-faster

 

 

 

 

 

 

I then set a more difficult password “Heather1” and backed up my data using iTunes. Elcomsoft is saying that there is 87 years remaining for a brute force attack, so I am not going to wait. What should you do here? Try a dictionary attack! It’s much more effective with passwords such as “Heather1” when compared to Brute Force. When I changed to dictionary attack, this password was crack in less than 1 second! As a side note, I relied on the English dictionary and did not create anything custom for this test.

encrypted-complex

So, we have the password, what about the encrypted databases?

I was able to successfully parse all of the iOS10 backup files that I created over the last two days, containing various backup passwords, as well as the ones that were created for my previous blog post. As long as Physical Analyzer had the password, the data was decrypted and parsed. Make sure you are using Physical Analyzer v5.3.5.10 or later (assuming you have tested and validated the latest versions).

When attempting an Advanced Logical in Physical Analyzer, the option to encrypt the backup is provided if the backup has not been encrypted via iTunes by the user. You should select this option. If not, you will not get the data protected by the keychain. I selected to Encrypt my backup as shown below.

pa-encrypt

As stated in my last post, this was not an option with iOS10. Cellebrite has fixed this issue and all of the data will be parsed and decrypted. Additionally, if you are prompted for the users iTunes backup file password (the one you cracked with Elcomsoft), Physical Analyzer will parse the data when the password is correctly entered whether you selected an Advanced Logical Extraction or to add an iTunes backup file into the tool for analysis.

pa-parsingbackup_encry

To be thorough, I tested the following in physical analyzer:

1. Added an encrypted backup with iTunes (older version) into Physical Analyzer with the Open Advanced option
2. Added an encrypted backup with iTunes (latest version)  into Physical Analyzer with the Open Advanced option
3. I removed the iTunes password from the iPhone and selected to Encrypt Backup during Advanced Logical Extraction
4. I reset the passcode in iTunes and then selected Advanced Logical Extraction. I was prompted for the user’s backup password.
pa-parsed_extraction-summary
The results – Physical Analyzer parsed the databases that I stated were encrypted in my previous test.! This is great news for those of us who use this tool to conduct smartphone forensics. And yes, I realize that I am out of space on my iPhone… I am waiting on my 128GB iPhone 7 to arrive. 🙂
Not only did it parse the databases, they are decrypted. These databases can be exported and put into other tools for parsing, merging and interpreting the data – something like Paul Sanderson’s SQLite Forensic Browser.  Below is a sample of my call history database.
call_history-not-encrypted
Now how to handle your analysis of iOS 10… not as easy
When we take the tools out of the equation, which is required to determine how the data got onto the phone, this process gets much harder. Below, you can see what Physical Analyzer is reporting for my location information. If you have heard my and Sarah Edwards endless presentation on location information, you are already aware that these iOS devices track a lot that we do and also track other things people do for us! What does that mean? If a friend tags you in a social media post, this data can show up on your device as a location you have visited – even if you haven’t been there. Why? Because you or something gave that app or browser permission to do this. What does this look like?
pa-parsed_extraction
In this example, I can tell you what is true and what is not. How – it’s my phone! If it weren’t, I better be prepared to manually look at databases and artifacts to piece this information back together. For example, that Facebook location is the lat/long for one of my friends on chat. I was not at that location. Mail Content, iPhone RecentLog, Map Searches, Map Suggestions and more all need to be verified by an examiner. The tool cannot do this for you. The tool also cannot pull location information from 3rd party applications that they do not parse.
Need to learn proper examination techniques – take FOR585 Advanced Smartphone Forensics. We teach you how to stand behind the evidence you put in your report.
Your tool can only get you so far. My concern in my first blog was that our tool couldn’t even get us beyond the first hurdle. Now that they have, are you prepared to defend your report or what the tool is telling you? Remember, these tools parse everything that is on the phone. It’s your job to determine how the data got there.
See you in class soon! FOR585.com/course

A glimpse of iOS 10 from a smartphone forensic perspective

I immediately installed and started using iOS 10.0.1 when the full release was available. For this testing, I used my non-jailbroken iPhone 6S and iTunes 12.4.2.4 with the addition of free and commerical tools. My intention is to share my initial thoughts on what is different in iOS 10 and what to expect when you see a device running this version. For more in depth details, analysis tips and tricks on iOS, refer to for585.com/course.

I expected major artifact location changes in iOS 10.  I based this assumption on the fact that iOS 7 to iOS 8 was drastic in artifact changes. Nothing really changed when we upgraded to iOS 9, so I assumed… I’m happy to report that upon my initial research, I haven’t found drastic changes for most files of interest. I plan to keep digging here, just to be sure. As capabilities increase, we know that log files and usage artifacts are left on the device. These need to be researched further.

One major change I have noticed is with the structure of the iOS device backup. Below is an example of the new file structure.

backup_structure

A few things of interest:

  1. The Manifest.mbdb is now a SQLite database file – Manifest.db
  2. Instead of seeing all of files or “strings of letters” representing backup file contents, you now have folders containing these files, as shown above in the boxed area.

Once I had my backup, I starting digging through the files and panicked!  Everything of interest appeared to be encrypted. This includes simple things like contacts, call logs, SMS and locations pulled from Apple maps.  I frantically sent a Tweet seeing if this is what others were seeing and heard nothing. My tools all flopped. After the panic subsided, I decided to launch iTunes and take a look at my settings. Here is what I saw… The pesky box to Encrypt iPhone backup was checked even though I have been backing up to iCloud for as long as I can remember. Good think I remembered the password.

itunes_issue

I was confused by this for several reasons. One, most of the commercial tools prompt you to enter a backup password and decode the data when this setting is enabled. Also, encrypting a backup and knowing the password provides us additional access to data – not blocks us from it!  What could be going wrong? Could it be examiner error? Next, I did what most examiners would do and attempted to force my tools to parse this image. I launched UFED Physical Analyzer, IEF and BlackLight and entered the password (don’t worry, my passwords are much stronger than this, but I used a “dummy” one for this example.)

ufed-pw_prompt

To my surprise, all of the databases of interest were still encrypted even after I asked the tool to decrypt my data with the correct passcode. To my dismay, nothing of interest was parsed, other than the Info.plist and Manifest.plist files. Even the Manifest.db was encrypted. Below you can see that the file system was parsed and accessible, but the databases and files of interest were encrypted, so this isn’t very helpful.

encrypted_backup

(Once opened, the History.db looked like this)

encrypted_safari

So now what? If you know the user’s backup password or can crack it, the password can be removed in iTunes. I tried this and then backed my phone up again.

First, I launched iTunes and unchecked the box for Encrypt iPhone Backup. I correctly entered my password.

itunes1

The encryption was removed.

itunes2

When I loaded this unencrypted version of my iOS backup file into forensic tools, some crashed, but I did have success in others.  The first think I noticed was that the Manifest.db was no longer encrypted.

manifest

This gave me hope. I started examining the files that were previously encrypted within the iOS backup and found that they too, were accessible. Below, the CallHistory.storedata shows my call logs. When I initially created my backup, this file, like the Safari History.db, was encrypted!

callhistory

I have reported these issues and concerns to the vendors and they are working on the issue. Here are some things they provided me in the meantime.

  1. Do not update to the latest version of iTunes if you are creating backups as forensic images. It causes issues.
  2. Do not select to “Encrypt” the backup in Physical Analyzer when obtaining an Advanced Logical Extraction. That too will render your data encrypted.
  3. Hope that the user never used iTunes encryption!

If you come across an encrypted iOS backup file, try to crack it. Personally, I rely on Elcomsoft tools to handle this.  If you crack the password, you will manually have to remove the iTunes restriction and back the data up again until the tools adapt to handle iOS 10 backup file encryption.

In the meantime, practice on your own device and sign up for FOR585 Advanced Smartphone Forensics, where we cover topics like bypassing encryption and cover the cool artifacts of iOS. Happy iOS hunting!

for585.com/course

GASF