Category: Security

Apple is Making Progress

Apple’s new, relaxed NDA rules appear to allow me to talk about the iOS 8 betas. I will hold off on the deep technical details until the final release, as I see that Apple is striving to make a number of improvements to the overall security of their product. What I will say is that so far, things look quite promising. Shortly after my talk at HOPE/X, citing my paper, “Identifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices”, along with a proof of concept, Apple released Beta 5, and a number of the “high value forensic services” I’d outlined in my paper have now been disabled wirelessly, including the packet sniffer service that got many upset (note: we’ve known about the packet sniffer for years, but it was never disclosed to consumers that it was active outside of developer mode). Apple’s fixes are clearly still a work in progress, and not all of my security concerns have been addressed yet, but it does show that Apple does care about the security of their product, and likely wants to prevent their APIs from being abused by both malicious hackers and government. Given that a number of my threat models involved government spying, it feels good to know that Apple has taken my research seriously enough to address these concerns. Keep in mind, the threat model we’re dealing with also includes foreign governments, many of which have long histories of spying on our country’s diplomats. I’ve instructed a number of counter-forensics classes to diplomatic infosec personnel, and the threats of spying on data are very real for these people, to the degree that a lot of cloak-and-dagger goes into play on both sides, especially when visiting technologically hostile countries.

Read More

Apple’s Authentication Scheme and “Backdoors” Discussion

I’ve heard a number of people make an argument about Apple’s authentication front-ending the services I’ve described in my paper, including the “file relay” service, which has opened up a discussion about the technical definition of a backdoor. The primary concern I’m hearing, including from Apple, is that the user has to authenticate before having access to this service, which one would normally expect would preclude a service from being a backdoor by some (but not all) definitions. This is a valid point, and in fact I acknowledge this thoroughly in my paper. Let me explain, however, why this argument about authentication is more complicated and subtle than it seems.

Most authentication schemes are encapsulated from weakest to strongest, and are also isolated from one another; certain credentials get you into certain systems, but not into others. You may have a separate password for Twitter, Facebook, or other accounts, and they only interoperate if you’re using a single sign-on mechanism (for example, OAuth) to use that same set of credentials on other sites. If one gets stolen, then, only the services that are associated with those credentials can be accessed. Those authentication mechanisms are often protected with even stronger authentication systems. For example, your password might be stored on Apple’s keychain, which is protected with an encryption that is tied directly to your desktop password. Your entire disk might also be encrypted using full disk encryption, which protects the keychain (and all of your other data) with yet another (usually stronger) password. So you end up with a hierarchy of authentication mechanisms that get protected by stronger authentication mechanisms, and sometimes even stronger ones on top of that. Apple’s authentication scheme for iOS, however, is the opposite of this, where the strongest forms of authentication are protected by the weakest – creating a significant security problem in their design. The way Apple has designed the iOS authentication scheme is that the weakest forms of authentication have complete control to bypass the stronger forms of authentication. This allows services like file relay, which bypasses backup encryption, to be accessed with the weakest authentication mechanisms (PIN or pair record), when end-users are relying on the stronger “backup encryption password” to protect them.

Read More

Oxygen Forensics: Latest Forensics Tool to Exploit Apple’s “Diagnostic Service” to Bypass Encryption

While Apple’s claims may be that a key subject of my talk, “Identifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices” (com.apple.mobile.file_relay) is for diagnostics, a recent announcement from the makers of the fantastic Oxygen Forensics suite shows strong evidence that law enforcement forensics is continuing to take every legal technical option available to Read More

Roundup of iOS Backdoor (AKA “Diagnostic Service”) Related Tech Articles

There are a lot of terrible news articles out there, and a lot of terrible “journalists” who have either over-hyped my research, or dismissed it entirely. After ZDNet’s utterly horrible diatribe about my research, I posted a proof-of-concept to help further clarify that was and wasn’t possible. Unfortunately, the FUD has continued, and so I Read More

Dispelling Confusion and Myths: iOS Proof-of-Concept

Here’s my iOS Backdoor Proof-of-Concept:
http://youtu.be/z5ymf0UsEuw

When I originally gave my talk, it was to a small room of hackers at a hacker conference with a strong privacy theme. With two hours of content to fit into 45 minutes, I not only had no time to demo a POC, but felt that demonstrating a POC of the personal data you could extract from a locked iOS device might be construed as attempting to embarrass Apple or to be sensationalist. After the talk, I did ask a number of people that I know attended if they felt I was making any accusations or outrageous statements, and they told me no, that I presented the information and left it to the audience to draw conclusions. They also mentioned that I was very careful with my wording, so as not to attempt to alarm people. The paper itself was published in a reputable forensics journal, and was peer-reviewed, edited, and accepted as an academic paper. Both my paper and presentation made some very important security and privacy concerns known, and the last thing I wanted to do was to fuel the fire for conspiracy theorists who would interpret my talk as an accusation that Apple is working with NSA. The fact is, I’ve never said Apple was conspiring secretly with any government agency – that’s what some journalists have concluded, and with no evidence mind you. Apple might be, sure, but then again they also might not be. What I do know is that there are a number of laws requiring compliance with customer data, and that Apple has a very clearly defined public law enforcement process for extracting much the same data off of passcode-locked iPhones as the mechanisms I’ve discussed do. In this context, what I deem backdoors (which Apple claims are for their own use), attack points, and so on become – yes suspicious – but more importantly abuse-prone, and can and have been used by government agencies to acquire data from devices that they otherwise wouldn’t be able to access with forensics software. As this deals with our private data, this should all be very open to public scrutiny – but some of these mechanisms had never been disclosed by Apple until after my talk.

Read More

Apple Confirms “Backdoors”; Downplays Their Severity

Apple responded to allegations of hidden services running on iOS devices with this knowledge base article. In it, they outlined three of the big services that I outlined in my talk. So again, Apple has, in a traditional sense, admitted to having backdoors on the device specifically for their own use.

A backdoor simply means that it’s an undisclosed mechanism that bypasses some of the front end security to make access easier for whoever it was designed for (OWASP has a great presentation on backdoors, where they are defined like this). It’s an engineering term, not a Hollywood term. In the case of file relay (the biggest undisclosed service I’ve been barking about), backup encryption is being bypassed, as well as basic file system and sandbox permissions, and a separate interface is there to simply copy a number of different classes of files off the device upon request; something that iTunes (and end users) never even touch. In other words, this is completely separate from the normal interfaces on the device that end users talk to through iTunes or even Xcode. Some of the data Apple can get is data the user can’t even get off the device, such as the user’s photo album that’s synced from a desktop, screenshots of the user’s activity, geolocation data, and other privileged personal information that the device even protects from its own users from accessing. This weakens privacy by completely bypassing the end user backup encryption that consumers rely on to protect their data, and also gives the customer a false sense of security, believing their personal data is going to be encrypted if it ever comes off the device.

Read More

Slides from my HOPE/X Talk

Identifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices In addition to the slides, you may be interested in the journal paper published in the International Journal of Digital Forensics and Incident Response. Please note: they charge a small fee for all copies of their journal papers; I don’t actually make anything off of Read More

My Talk at HOPE X

I’ll be speaking at the HOPE (Hackers on Planet Earth) big X conference this year, July 18-20 in NYC. Below is a summary of my talk. It’s based on this published journal paper. Hope to see you there! Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices The iOS operating system has long Read More

Journal Paper Published

The International Journal of Digital Forensics and Incident Response has formally accepted and published my paper titled Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices. This paper is a compendium of services and mechanisms used by many law enforcement agencies and in open source, of modern forensic techniques to create a forensic Read More

Fingerprint Reader / PIN Bypass for Enterprises Built Into iOS 7

With iOS 7 and the new 5s come a few new security mechanisms, including a snazzy fingerprint reader and a built-in “trust” mechanism to help prevent juice jacking. Most people aren’t aware, however, that with so much new consumer security also come new bypasses in order to give enterprises access to corporate devices. These are in your phone’s firmware, whether it’s company owned or not, and their security mechanisms are likely also within the reach of others, such as government agencies or malicious hackers. One particular bypass appears to bypass both the passcode lock screen as well as the fingerprint locking mechanism, to grant enterprises access to their devices while locked. But at what cost to the overall security of consumer devices?

Read More

How Juice Jacking Works, and Why It’s a Threat

How ironic that only a week or two after writing an article about pair locking,  we would see this talk coming out of Black Hat 2013, demonstrating how juice jacking can be used to install malicious software. The talk is getting a lot of buzz with the media, but many security guys like myself are scratching our heads wondering why this is being considered “new” news. Granted, I can only make statements based on the abstract of the talk, but all signs seem to point to this as a regurgitation of the same type of juice jacking talks we saw at DefCon two years ago. Nevertheless, juice jacking is not only technically possible, but has been performed in the wild for a few years now. I have my own juice jacking rig, which I use for security research, and I have also retrofitted my iPad Mini with a custom forensics toolkit, capable of performing a number of similar attacks against iOS devices. Juice jacking may not be anything new, but it is definitely a serious consideration for potential high profile targets, as well as for those serious about data privacy.

Read More

iOS Counter Forensics: Encrypting SMS and Other Crypto-Hardening

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.

Read More

Introduction to iOS Binary Patching (Part 1)

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.

Read More

Your iOS device isn’t as encrypted as you think

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.

Read More

The Dark Art of iOS Application Hacking

I’ll be giving the talk, The Dark Art of iOS Application Hacking at Black Hat 2012 in Las Vegas this July. This workshop will cover many techniques we use to attack iOS applications, and has numerous applications in the security and government fields; everything from pen-testing to forensic hacking and surveillance for national security related Read More