Friday, January 13, 2017

Mobile Forensics Monkey Wrench: iOS 10.2 and Encryption




January 13, 2017

Mobile Forensics Monkey Wrench: iOS 10.2 and Encryption

It’s not secret to those involved in the study and practice of mobile forensics that Apple likes to throw us curve balls with almost every new iteration of the iOS operating system.  It turns out, iOS 10.2 is no different (released December 12, 2016).  A conversation began recently on the IACIS list serve and got me thinking about trying to problem solve and figure out a work-around, so I spent the past day or so trying to do just that.  (For those interested, I also wrote an article about the problem-solving aspect of digital forensics and you can read it here.)

The background is as follows:  When an i-Device user running iOS 10.2 connects the device to a computer, they are automatically prompted by iTunes for an encryption password:



When the option to encrypt is selected, a prompt is displayed for an encryption password, which may be entirely different from the device passcode or the iTunes account password:



This default encryption prompt becomes an issue for examiners due to the fact that users often don’t remember these passwords because in the age of cloud-driven storage and wireless *everything*, users don’t routinely connect their devices to a computer and therefore, don’t remember the encryption password.  This was the issue raised by another examiner on the list serve and it prompted many replies and potential work-arounds because when examiners attempt to analyze the extractions from these devices, they’re encrypted.  Pretty much game over.
(For additional background on this issue as was introduced in iOS 10.0.1, please refer to Heather Mahalik’s blog on the topic located here.)

Before iOS 10, I ran across this problem a few times with iOS devices.  My work-around then was to simply connect the device to a foreign computer (i.e., one that it had not been connected to previously) and de-select the encryption option and create another unencrypted backup, then pull the new backup into any number of commercial tools for analysis.  This doesn’t work any longer because when the device is connected to a foreign computer and encryption is de-selected, iTunes prompts for the encryption password for verification.  Darn the luck!

Methodology

For this testing, I used an iPhone 6, which we have on-hand for testing purposes.  The phone has a handful of iMessages, pictures, videos, Kik messages and some other data on it.  I updated the phone to iOS 10.2 and encrypted the backup on the Mac side of my forensic machine.  I then switched to the Windows side and attempted to create another backup by de-selecting the “Encrypt iPhone Backup” option, which is when I quickly learned that in all updated versions of iOS and iTunes, the encryption password is needed to complete this action:



Being that I know the encryption password, I entered it and created a new backup via iTunes on my local machine.  To be sure, unless you want to use a tool such as Elcomsoft to brute-force the password or attempt a dictionary attack based upon investigation and/or social engineering, you’ll need the encryption password to make this work.  But even having the password doesn’t get us too far with Cellebrite under the current version.

How Does UFED Handle This?

Cellebrite Universal Forensic Extraction Device (UFED) Physical Analyzer (PA) has heretofore been one of the best commercial tools for acquiring and analyzing iOS devices.  Indeed, you can use UFED PA to attempt a brute-force dictionary attack on these extractions if you have decent intelligence through additional investigation or social engineering by pointing UFED PA at a text file containing case-specific dictionary words:




In conducting this test and comparison, I used the latest version (as of this publication) of UFED PA, 5.4.7.5, which was released just 24 hours prior.  As you can see from the below image, even when the proper password is entered after an advanced logical extraction directly from the device, UFED PA still doesn’t parse the “analyzed data” into chats, web history, etc. like it used to with older versions of iOS:



That’s it.  That’s pretty much all we get.  When the “Backup” folder is expanded, we are presented with this:


The red arrow is used to illustrate that the listing of files keeps going.  Further inspection of these files indicates it would be a very lengthy, tedious process to try and located you sms.db, let alone DBs from many third-party apps which can be crucial in many cases.

My next step was to create an unencrypted backup through iTunes to see if that could be pulled into UFED PA and parsed a bit nicer.  It wasn’t.  We are presented with a file structure identical to that which is created by iTunes, with one folder with a long alphanumeric name and dozens of sub-folders, each with a shorter alphanumeric designation.  The only data that was automatically parsed in the backup was images, videos and device locations.  Again, combing through all of this for your crucial evidence and databases can be a time-waster, so what else can we do?  Try to use another tool!

How About IEF?

So now we have an advanced logical image in UFED PA (that is all but useless) and a backup through iTunes that is only slightly better when viewed through UFED PA.  Now, I profess that push-button tools are the end of true forensics.  Anyone who reads this blog knows that I firmly believe that you have to know and articulate where the data is located and how it got there.  But sometimes, certain tools can help point us in the right direction.  Enter Magnet Forensics’ Internet Evidence Finder (IEF, v. 6.8.4.3639).  IEF is widely accepted as one of the best and easiest tools on the market to use.  I love it for helping me out, for getting me a leg up on where I need to look, perhaps even with another tool.  So I decided to try and pull the iTunes backup into IEF, just to see what would happen. 

First, I selected the Mobile and iOS options in IEF:



Then, I selected “File Dump” to point IEF where I wanted it to look.   



The next decision is probably the most crucial to the process.  I selected the Windows file browser, then navigated to the (now exported) iTunes backup folder - the one with the very long alphanumeric name.  But then I drilled down to the sub-folders and files immediately under the parent file and selected all of them, including all of the .plist and .db files:



Next, I had to tell IEF what I wanted it to look for.  The data set isn’t large and I’d rather have too much data to sift through than not enough, so I just chose everything and selected “next”:



It’s important to note here that I conducted a subsequent test selecting “iOS Backups” ONLY and did not receive a favorable outcome.  Also, if the backup or device is encrypted, IEF will prompt for a password.
The processing took about 15 minutes.  Once it was finished, the data was parsed out as you would have expected pre-iOS 10.2:



I have highlighted the file path of the location of the sms.db in the above image because now, IEF has told us where to look in UFED PA or other tools.  Consequently, we can now switch back to UFED to examine and export the .DB files as necessary.  The below image shows what we find in UFED PA when we follow the file path indicated through IEF in the iTunes backup of the iPhone:



So to wrap it up, get your encryption password, create a backup using iTunes on a foreign machine and bring the backup into IEF to point in you the right direction.  From there, you can expand to UFED PA or another tool of your choosing, if necessary. 

Take-Aways

There are several important things to take-away from this experiment.  First, it has become vital in mobile forensics to have more than one tool at your disposal.  Having access to two or more tools can actually save you time and effort.  Imagine how tedious it would have been to sift through all of those folders (none of which contained a .db file extension by the way) to find the text messages or other pertinent data. 

Second, the problem-solving aspect of “boots on the ground” forensics, especially mobile forensics, cannot be ignored.  To make problem-solving a little easier, start to ask about encryption FIRST and save yourself some grief down the road. It’s also becoming apparent that we simply cannot rely on the pretty push-button features of many tools in the coming years, especially with regard to Apple and their iOS… and it’s only going to get more prevalent.

Finally, things are always changing.  Never forget that.  When I was conducting this testing and writing this article, I did so knowing full well that Cellebrite may push out a solution in the next week or two.  But until those updates happen, we all need to collaborate to find solutions to these issues, because just like no one tool can do it all, no single examiner can always do it all.

UPDATE: February 13, 2017

After this article was originally published, I was contacted by Ron Serber at Cellebrite.  We discussed the issues presented by UFED and it's parsing of the data in this test case and I happily sent him a copy of the UFED file and all extraction data.  He indicated at that time that UFED PA v. 6.0 would likely solve the issue(s).

UFED for PC and Physical Analyzer v. 6.0 was released on February 7th, 2017.  Shown below is the original, unencrypted extraction that was performed in UFED, nicely parsed out in v. 6.0.


While we all know that we still need to dive into the sqlite dbs and all the other relevant files in any given case, this update to UFED for PC and UFED PA has made the job a little bit easier.  Thanks to the great folks at Cellebrite for always working hard to solve problems that practitioners may encounter in the field!

Author:
Patrick J. Siewert
Principal Consultant
Professional Digital Forensic Consulting, LLC
Virginia DCJS #11-14869
Based in Richmond, Virginia
Available Globally


We Find the Truth for a Living!
Computer Forensics -- Mobile Forensics -- Specialized Investigation

About the Author:
Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia.  In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history.  Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor.
Twitter: @ProDigital4n6

Monday, January 2, 2017

Conducting an Electronic Investigation: A Case Study in Virginia Politics

January 2, 2017

Conducting an Electronic Investigation:
A Case Study in Virginia Politics

Happy New Year!  2017 has already started off with a proverbial “bang” in our home state of Virginia with a story in the political world which directly relates to the field of digital forensics and electronic investigation.  Two Republican candidates for Lieutenant Governor, Jill Vogel and Bryce Reeves, are now embroiled in a scandal which is detailed in The Washington Post and the conservative blog, The Bull Elephant, which are also linked below:

The Washington Post: (click here)


In a nutshell, an email was sent from a Gmail account allegedly accusing Reeves of having an affair with an aide.  Court records indicate the email detailing the affair were sent from Vogel’s home IP address,  she claims that she (or others close to her) was/were “hacked” and the damaging personal email had nothing to do with her campaign.  There is already a civil matter filed which deals with the email and the investigation is ongoing.

What I find in reading the blog comments and online postings of those who may be interested in this story is the lack of knowledge about what can be proved vs. what cannot be proved and that is what we’ll explore here.  As a matter of full disclosure, I have met Reeves, although I doubt he remembers.  We have mutual friends and acquaintances in various areas of the practice of law and in public service.  I have not met Vogel. I have also offered the assistance of Pro Digital Consulting in this case in one or more public forums.

Potential Areas of Evidence

So how does an investigator go about proving or disproving that emails were sent from a particular device at a specific location?  There are a number of potentially relevant pieces of information and evidence which can help lead us to a reasonable conclusion.  The evidence can be from a larger entity, such as the email provider or internet service provider (ISP) and can be drilled down to a single user, depending on the specific makeup of the network in use.  So here’s what we’d be looking for, in order of increasing specificity:

IP Connection Records

IP or Internet Protocol addresses are similar to a telephone number for your computer or other web-connected devices. Every subscriber on the internet is issued an IP address for a location and the IP address is what reaches out via your internet service provider (i.e., Verizon, Comcast, Cox Cable, etc.) or ISP to the larger internet.  In the most basic terms, a single subscriber is issued an IP address by the ISP to a specific location, such as a home or office, and that IP address is shared internally between individual users on the internal network through a wireless or other router.  The router also issues IP addresses to each device that is connected on the internal or private network, but those private IP addresses can be manipulated, depending on the knowledge of the private network administrator.



Of key importance with this information is the correct day and time of the connection of interest.  IP addresses are sometimes static (not changing) and sometimes dynamic (changes often).  Additionally, while the connection of interest may have been made in Virginia, the ISP may be located in California, so standardizing the time zone in the subpoena request is also very important.  One larger piece of evidence which appears to already exist in this case is the subpoena return to the ISP, which allegedly details that the IP address issued at the specific date and time that the email in question was sent was issued to Vogel’s home address.  However, a twist comes in when we add that her neighbor allegedly shared an internet connection with the Vogels via an unsecured wireless router (or routers).  More on that later.

Records from the Email Provider

The crux of this case is the email, which Ms. Vogel claims she did not send, nor did anyone related to her campaign.  Therefore, it is crucial to get as much information about this email as possible.  Emails are nothing more than text messages sent with more detail (i.e., metadata) and with more “digital breadcrumbs” associated with them.  Every email provider is a little different, but generally speaking, they all log incoming and outgoing dates & times, IP addresses and other metadata that can be useful in the email header.  However, as is widely known, certain email providers anonymize their IP addresses, which makes tracking down the sender slightly more difficult, but not impossible.

All emails contain headers, which contain this vital information and metadata.  While you may not see them, they’re there.  It’s how each ISP and their servers log the activity as a virtual Post Office for each email you send.  The original email(s) in question in this case should be preserved as evidence, both in print and digitally, as a matter of best practice.  What we often see is an email that is submitted as evidence for analysis or investigation that has been forwarded once, twice, three times… You get the idea.  The best evidence in any case is the original evidence, or at least as close as we can get to it.  Evidence that has been passed from hand to hand to hand only degrades in its value and impact in the overall investigation. 

The headers in the email(s) in question will tell us when it was sent, who sent it (the sending account), from what IP address it was sent and so on.  From there, subpoenas for additional information may be submitted to the email provider for account holder information, which will include the creation date and time of the account and most often, the IP address that was captured at the time the account was created, as well as potential other information, such as a phone number in this specific case, which is most often used to verify the account belongs to a person.  Then, a subsequent subpoena may be issued for the subscriber information for the IP address that was used to create the fictitious or anonymous email account and the owner of the phone number used for verification.  Of course, if cause can be shown, the court may be petitioned for an order to the email provider also releasing the content of all emails present on the account, which can also be very valuable and contain additional metadata (IP addresses, other email addresses, etc.) that may prove useful.

Interrogation of the Internal Private Router

As discussed earlier, once the ISP issues an IP address to a subscriber, that individual (or company) then needs to use a private router to allow individual users to access the internet.  That router issues private IP addresses to each device internally, the records of which are logged in the router itself.  Typically (and all routers are different), the router will log the date and time of last connection for each device, the name of the device (e.g., ProDigital-PC or Patrick’s iPhone), the MAC address of the device, the internal IP address that was issued to that device and the status of the router – be it open or secure access. 

So what’s the MAC address?  The MAC is the Media Access Control, an internal unique identifier assigned to network interface devices for communications.  “Unique” in this case means, unit-specific.  In other words, every device connected to the network has its own MAC address and they cannot be duplicated.  There are also ways to break down the MAC address and determine the device manufacturer and potentially other items of interest.

By connecting to the internal private routers, all connection records become available to us and can be preserved as evidence.  So what’s the catch?  The data is almost always volatile.  In other words, if you remove the power source from the routers, this data is erased and reset.  It’s extremely valuable, especially when investigating claims of hacking or unauthorized access on a private network, so any thorough investigation needs attempt to capture this data by going go on-site as soon as possible and before the router is removed from power, there is a power outage or some other happenstance that will make this data disappear. 

Due diligence also dictates that an investigator go on-site to determine the range and status of the allegedly open wireless connections for themselves.  Could an unknown third part have driven into the Vogel’s neighbor’s driveway to “tap” into the router without their knowledge?  There’s one sure way to find out – try to do it yourself!

The Specific Device(s)

One comment on an online forum I read with regard to this case stated “IP addresses do not equal an individual.”  Very true!  In fact, there are documented cases where investigations of criminal suspects based solely upon an IP address have yielded such errors as search warrants being executed on the wrong residence and later discovery that criminal suspects were “stealing” access to open wireless connections to facilitate their crimes.  This is why the best and most specific piece of evidence in any case is the actual device upon which the alleged activity was conducted.  In this case, it appears to be the iPhone belonging to Ms. Vogel’s husband.  However, none of the evidence cited here exists in a vacuum.  The reason all of the subpoenas and connection records and router logs are important is they serve to verify the source of the evidence in question (emails). 



By capturing the router logs and comparing that data to the internal MAC address and issued IP address(es) of the specific device(s) in question, we start to tie all of the electronic evidence together to then put an actual person behind the device – the one responsible.  The value of forensic data acquisition and analysis on the devices in question can also not be overlooked.  In this case example, the analysis of the email records would need to be conducted manually, as iPhone email records are not currently available through a mobile forensic data extraction. However, a forensic extraction should still be performed as it may yield other information, data and evidence that may be useful.  Connected email accounts, web history, deleted apps of interest and potentially recoverable information from app databases may all prove valuable pieces of evidence in an investigation such as this.  Key word searches can also be conducted for key terms such as the anonymous/sending email address, terms contained in the original email and other specific text that can point to the originating device.

Conclusions

Every investigation is different and invariably, they all take left turns at some point.  The overview of specific areas of available evidence listed here is not exhaustive, but is designed to provide a blueprint of what is available and what should be done in order to conduct a thorough investigation and determine who is or is not responsible in cases involving matters where professional reputation and survival, as well as personal integrity and public appearance, may be at stake.  It’s easy to throw down the claim that one has been “hacked”, but quite another to undertake the proper steps to prove or disprove that claim in a manner which is acceptable in a court of law. 

As a wise man once said upon his acquittal on serious criminal charges “Great!  Now where do I go to get my reputation back?”  While a complete investigation may reveal that Vogel and her campaign had nothing to do with these emails, it seems clear that several people’s personal and professional reputations may be at stake here… and that’s the best motivation to want to find the truth.


Author:
Patrick J. Siewert
Principal Consultant
Professional Digital Forensic Consulting, LLC
Virginia DCJS #11-14869
Based in Richmond, Virginia
Available Globally


We Find the Truth for a Living!
Computer Forensics -- Mobile Forensics -- Specialized Investigation

About the Author:
Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia.  In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history.  Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor.
Twitter: @ProDigital4n6