The iOS operating system contains a number of services and back doors that most leading commercial forensic imaging tools do not currently exploit. These provide enhanced levels of decrypted information from the device. Because of this, one is is able to skirt around iTunes’ Backup Encryption feature, and acquire clear text copies of much of the user file system. I have put together a free tool for law enforcement which uses these techniques to perform an “enhanced interrogation” of an iOS device, which can yield much more forensic data than existing logical techniques.
See http://iosresearch.org for more information.
July 22 2013, Boston MA: iOS Advanced Forensic Investigation L-1
Join us as Jonathan Zdziarski, author, forensic scientist and iOS expert, leads your organization’s law enforcement or security professionals through the delicate process of recovering and processing evidence stored on these devices. This advanced, one-day course will guide your investigators, hands on, through imaging and electronic discovery of iPhone and iPad devices, demonstrating physical and logical acquisition techniques. Attendees will receive a special law enforcement forensics guide and access to the tools used in the field by thousands of law enforcement agencies world wide. All tools and classroom content will be provided to attendees on a USB stick so students can learn and explore hands-on. This course has undergone numerous transformations to make it continually one of the best iOS forensics courses available.
Registration Link and More Information:
Hosted by US Dept. of State Diplomatic Security Service, Boston Field Office
Given the vast amount of loose knowledge now out there in the community, and the increasing number of commercial tools available to conduct both law enforcement and private sector acquisition of an iOS device, I’ve decided to make my law enforcement guide, “iOS Forensic Investigative Methods” freely available to all. The manual contains a lot of useful low-level information about the iPhone and the different artifacts commonly found while performing a forensic analysis. Chapter 3 requires a set of tools to actually image the device (which are not presently available to the public), however there are a number of commercial and open source tools that can be substituted here to acquire a disk image. Anyone with a little experience should be able to figure out by now how to get a copy of their own device’s disk. There is plenty of knowledge in this manual to teach you the basics of where to find information, such as various caches and other data, on the device, and what kind of evidence to look for when conducting investigations. It may also give the informal geek a peek down the rabbit hole to see just what kind of data is stored by your device. I decided to release this for the betterment of technical knowledge in the community, so enjoy!
PDF: iOS Forensic Investigative Methods
Upon hearing that Joshua Tree had recently been vandalized, I wanted to post some photos of this beautiful area from my trip to the Palm Springs / Palm Desert area last year. Joshua Tree is an entire world of its own; the unique trees (which inspired many Dr. Seuss illustrations) combined with the rustic structures and formations make you feel like you’re in another country. My wife and I spent a day out in Joshua Tree as part of a long week and a half trip across Palm Springs (to give expert testimony in a homicide case), Death Valley, Vegas (to speak at Black Hat 2012), Valley of Fire, the Grand Canyon, and many placed in-between. At Joshua Tree, we got to experience a fantastic sunset and happened to meet a film crew making a clothing commercial with a gorgeous old Cadillac. It was a great experience.
While a few of these photos were processed (or double processed) for a surrealistic landscape view, nearly all of the golden hour photos are SOOC, without any editing needed whatsoever. The light is so amazingly soft in Joshua Tree at sunset that I couldn’t do any justice to many of these photos by editing them.
As I explained in a recent blog post, your iOS device isn’t as encrypted as you think. In fact, nearly everything except for your email database and keychain can (and often is) recovered by Apple under subpoena (your device is either sent to or flown to Cupertino, and a copy of its hard drive contents are provided to law enforcement). Depending on your device model, a number of existing forensic imaging tools can also be used to scrape data off of your device, some of which are pirated in the wild. Lastly, a number of jailbreak and hacking tools, and private exploits can get access to your device even if it is protected with a passcode or a PIN. The only thing protecting your data on the device is the tiny sliver of encryption that is applied to your email database and keychain. This encryption (unlike the encryption used on the rest of the file system) makes use of your PIN or passphrase to encrypt the data in such a way that it is not accessible until you first enter it upon a reboot. Because nearly every working forensics or hacking tool for iOS 6 requires a reboot in order to hijack the phone, your email database file and keychain are “reasonably” secure using this better form of encryption.
While I’ve made remarks in the past that Apple should incorporate a complex boot passphrase into their iOS full disk encryption, like they do with File Vault, it’s fallen on deaf ears, and we will just have to wait for Apple to add real security into their products. It’s also beyond me why Apple decided that your email was the only information a consumer should find “valuable” enough to encrypt. Well, since Apple doesn’t have your security in mind, I do… and I’ve put together something you can do to protect the remaining files on your device. This technique will let you turn on the same type of encryption used on your email index for other files on the device. The bad news is that you have to jailbreak your phone to do it, which reduces the overall security of the device. The good news is that the trade-off might be worth it. When you jailbreak, not only can unsigned code run on the device, but App Store applications running inside the sandbox will have access to much more personal data they previously didn’t have access to, due to certain sandbox patches that are required in order to make the jailbreak work. This makes me feel uneasy, given the amount of spyware that’s already been found in the App Store… so you’ll need to be careful what you install if you’re going to jailbreak. The upside is that , by protecting other files on your device with Data-Protection encryption, forensic recovery will be highly unlikely without knowledge of (or brute forcing) your passphrase. Files protected this way are married to your passphrase, and so even with physical possession of your device, it’s unlikely they’d be recoverable.
Part of my job as a forensic scientist is to hack applications. When working some high profile cases, it’s not always that simple to extract data right off of the file system; this is especially true if the data is encrypted or obfuscated in some way. In such cases, it’s sometimes easier to clone the file system of a device and perform what some would call “forensic hacking”; there are often many flaws within an application that can be exploited to convince the application to unroll its own data. We also perform a number of red-team pen-tests for financial/banking, government, and other customers working with sensitive data, where we (under contract) attack the application (and sometimes the servers) in an attempt to test the system’s overall security. More often than not, we find serious vulnerabilities in the applications we test. In the time I’ve spent doing this, I’ve seen a number of applications whose encryption implementations have been riddled with holes, allowing me to attack the implementation rather than the encryption itself (which is much harder).
There are a number of different ways to manipulate an iOS application. I wrote about some of them in my last book, Hacking and Securing iOS Applications . The most popular (and expedient) method involves using tools such as Cycript or a debugger to manipulate the Objective-C runtime, which I demonstrated in my talk at Black Hat 2012 (slides). This is very easy to do, as the entire runtime funnels through only a handful of runtime C functions. It’s quite simple to hijack an application’s program flow, create your own objects, or invoke methods within an application. Often times, tinkering with the runtime is more than enough to get what you want out of an application. The worst example of security I demonstrated in my book was one application that simply decrypted and loaded all of its data with a single call to an application’s login function, [ OneSafeAppDelegate userIsLogged: ]. Manipulating the runtime will only get you so far, though. Tools like Cycript only work well at a method level. If you’re trying to override some logic inside of a method, you’ll need to resort to a debugger. Debugging an application gives you more control, but is also an interactive process; you’ll need to repeat your process every time you want to manipulate the application (or write some fancy scripts to do it). Developers are also getting a little trickier today in implementing jailbreak detection and counter-debugging techniques, meaning you’ll have to fight through some additional layers just to get into the application.
This is where binary patching comes in handy. One of the benefits to binary patching is that the changes to the application logic can be made permanent within the binary. By changing the program code itself, you’re effectively rewriting the application. It also lets you get down to a machine instruction level and manipulate registers, arguments, comparison operations, and other granular logic. Binary patching has been used historically to break applications’ anti-piracy mechanisms, but is also quite useful in the fields of forensic research as well as penetration testing. If I can find a way to patch an application to give me access to certain evidence that it wouldn’t before, then I can copy that binary back to the original device (if necessary) to extract a copy of the evidence for a case, or provide the investigator with a device that has a permanently modified version of the application they can use for a specific purpose. For our pen-testing clients, I can provide a copy of their own modified binary, accompanied by a report demonstrating how their application was compromised, and how they can strengthen the security for what will hopefully be a more solid production release.
Nescaline (my popular NES emulator for iOS) is now both free and open source. You can download and build the entire project here: https://github.com/jzdziarski/nescaline/. I have recently made some additions to Nescaline, such as implementing a better 6502 core for non-commercial use, and have been gradually reworking core components of the emulator core as well to improve graphics and sound.
Nescaline made a brief debut in the App Store a few years ago, where it was available for about one hour before Apple decided to pull it. Since then, I’ve been fighting to try and get the application back in the App Store, but none of the concessions I had offered were apparently good enough for Apple, even though they are well aware that many other emulators are being sold in the App Store. I’ve been meaning to release this open source for a while now, but the UI code is relatively old, and slightly buggy. I haven’t had the time to rework the UI, so I’m just releasing it as is. It works well, however, and if you have a developer license, should be able to build it and install it on your favorite iOS device. Enjoy!
Many governments (including our own, here in the US) would have its citizens believe that privacy is a switch (that is, you either reasonably expect it, or you don’t). This has been demonstrated in many legal tests, and abused in many circumstances ranging from spying on electronic mail, to drones in our airspace monitoring the movements of private citizens. But privacy doesn’t work like a switch – at least it shouldn’t for a country that recognizes that privacy is an inherent right. In fact, privacy, like other components to security, works in layers. While the legal system might have us believe that privacy is switched off the moment we step outside, the intent of our Constitution’s Fourth Amendment (and our basic right, with or without it hard-coded into the Constitution) suggest otherwise; in fact, the Fourth Amendment was designed in part to protect the citizen in public. If our society can be convinced that privacy is a switch, however, then a government can make the case for flipping off that switch in any circumstance they want. Because no-one can ever practice perfect security, it’s easier for a government to simply draw a line at our front door. The right to privacy in public is one that is being very quickly stripped from our society by politicians and lawyers. Our current legal process for dealing with privacy misses one core component which adds dimension to privacy, and that is scope. Scope of privacy is present in many forms of logic that we naturally express as humans. Everything from computer programs to our natural technique for conveying third grade secrets (by cupping our hands over our mouth) demonstrates that we have a natural expectation of scope in privacy.
This should help clear up the common misconception that data is encrypted and secured in iOS. While it’s true that iOS does sport an encrypted file system, that file system is virtually always unlocked from the moment the operating system boots up, as the OS (and your applications) need access to it. Even when the device is locked with your PIN or passphrase, the encrypted file system is readable to the operating system – what this means is that your data is NOT encrypted using an encryption that depends on your password – at least for the most part. Apple adds a second layer of encryption on top of this file system called Data-Protection. Apple’s Data-Protection encryption has the ability to protect a file while the device is locked by encrypting it with a key that is only available when you’ve entered your PIN or passphrase. While a PIN can be brute forced, a passphrase is much stronger.
So what’s the problem? Well, as of even the latest versions of iOS, the only files protected with this secondary encryption is your mail index, the keychain itself, and third party application files specifically tagged (by the developer) as protected with Data-Protection. Virtually everything else (your contacts, SMS, spotlight cache, photos, and so on) remain unprotected. To demonstrate this, I’ve put together a small recipe you can run on your own jailbroken device to bypass the lock screen. You can then use the GUI to browse through all of the data on the device, without ever providing your PIN. The only thing you’ll not be able to access are the files I’ve just mentioned. This lock screen bypass isn’t really a vulnerability in and of itself; it’s just one of many ways I can demonstrate to you that you don’t need a passphrase to view a vast majority if the data on your phone.
I decided to take a hiatus from social networking last year. After considering the number of systems my Twitter feed goes through, and how many support vector machines are mining everything I say to discover my favorite ice cream flavor, copy off every photo I ever post, or determine whether or not I am a terrorist in 140 characters or less, combined with the number of psychotic women I’ve known from my past, and the Internet community’s general inability to understand what a personal website is all about, I figured I needed a vacation from my some 4,200 followers. I was glad to also dump years worth of tweets that any stalker type might happen to decide they’d like to sift through to give self-pleasure to themselves. My rules for personal details have evolved over the past several years I’ve had a Twitter account as well, and so rather than review some 6,000 tweets, I figured I might as well whack the whole bunch. Closing my account provided an enormous release of stress and burden.