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.
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.