Apple’s recent security announcement suggested that they no longer have the ability to dump your content from iOS 8 devices:

“On devices running iOS 8, your personal data such as photos, messages (including attachments), email, contacts, call history, iTunes content, notes, and reminders is placed under the protection of your passcode. Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it’s not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8.”

It looks like there are some glitches in this new encryption scheme, however, and some of the files being stored on your iOS 8 device are not getting encrypted in this way. If you copy files over to your device using iTunes’ “File Sharing” feature or sync videos that appear in the “Home Videos” section of iOS, these files are not getting placed under the protection of your passcode. Theoretically, Apple could dump these in Cupertino, if given your locked iPhone.

Continue reading “iOS 8 Protection Mode Bug: Some User Files At Risk of Exposure”

In a recent announcement, Apple stated that they no longer unlock iOS (8) devices for law enforcement.

“On devices running iOS 8, your personal data such as photos, messages (including attachments), email, contacts, call history, iTunes content, notes, and reminders is placed under the protection of your passcode. Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it’s not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8.”

This is a significantly pro-privacy (and courageous) posture Apple is taking with their devices, and while about seven years late, is more than welcome. In fact, I am very impressed with Apple’s latest efforts to beef up security all around, including iOS 8 and iCloud’s new 2FA. I believe Tim Cook to be genuine in his commitment to user privacy; perhaps I’m one of the few who can see just how gutsy this move with iOS 8 is.

It’s important to take a minute, however, to note that this does not mean that the police can’t get to your data. What Apple has done here is create for themselves plausible deniability in what they will do for law enforcement. If we take this statement at face value, what has likely happened in iOS 8 is that photos, messages, and other sensitive data, which was previously only encrypted with hardware-based keys, is now being encrypted with keys derived from a PIN or passcode. No doubt this does improve security for everyone, by marrying encryption to the PIN (something they ought to have been doing all along). While it’s technically possible to brute force a PIN code, that doesn’t mean it’s technically feasible, and thus lets Apple off the hook in terms of legal obligation. Add a complex passcode into the mix, and it gets even uglier, having to choose any of a number of dictionary style attacks to get into your encrypted data. By redesigning the file system in this fashion (if this is the case), Apple has afforded themselves the ability to say, “the phone’s data is encrypted with a PIN or passphrase, and so we’re not legally required to hack it for you guys, so go pound sand”. I am quite impressed, Mr. Cook! That took courage… but it does not mean that your data is beyond law enforcement’s reach.

Continue reading “Your iOS 8 Data is Not Beyond Law Enforcement’s Reach… Yet.”

I’ve recently updated my TL;DR regarding the recent celebrity iCloud hacks. I now summarize Apple’s latest changes to improve their 2-factor authentication (2FA) . Apple has implemented not just a band-aid, but a very good security solution to protect iCloud accounts, by completely reinventing their own 2-step validation (sorry, I couldn’t resist). As a result, users who have activated this feature will need to provide a one-time validation code in order to access their iCloud account from a web browser, or to provision iCloud from an iOS device. As my TL;DR suggests, this new technical measure would have prevented the celebrity iCloud hacks. So are Apple’s new techniques really secure, even in light of the very technically un-savvy users who fall victim to iCloud phishing attacks?

While Apple has done their part to improve the security of iCloud, less than savvy users can still screw it up. First of all, by not having the feature turned on in the first place. Apple’s two-step validation process is opt-in, and therefore it’s important to make sure that users know about and understand the benefits to enabling this feature. In my opinion, Apple should force users to have this feature on if they enable Photo Stream or iCloud Backups, as they are likely to keep sensitive content in the cloud without necessarily knowing it.

So you’re more savvy than that. You’ve already activated the new 2FA on your iCloud account. Are you truly safe from future phishing attacks?

Continue reading “Is Apple’s new 2FA Really Secure? (Answer: It’s Pretty Solid)”

After some preliminary testing, it appears that a number of vulnerabilities reported in my recent research paper and subsequent talk at HOPE/X have been addressed by Apple in iOS 8. The research outlined a number of risks for wireless remote surveillance, deep logical forensics, and other types of potential privacy intrusions fitting certain threat models such as high profile diplomats or celebrities, targeted surveillance, or similar threats.

Given that Apple has dropped the NDA for iOS 8, it appears that I can write freely about the improvements they’ve made to address the vulnerabilities I’ve outlined in my paper. Here’s a summary of what’s been fixed, what risks still remain, and some steps you can take to help protect the data on your device.

Continue reading “Apple Addresses iOS Surveillance and Forensics Vulnerabilities”

(This document will continue to evolve as more information becomes available)

Earlier this week, a number of compromised celebrity iCloud accounts were leaked onto the Internet. Initially, @SwiftOnSecurity was kind enough to post some metadata at my request for exif information on two of the accounts’ files, and I’ve since gathered much more information including directory structures, file naming schemes, additional timestamp data, and other information through private channels.

Continue reading “TL;DR: Hacked Celebrity iCloud Accounts”

I received word from the editor-in-chief that the author of an accepted paper has permission to publish it on his website, and so I am now making my research available to anyone who wishes to read it. The following paper, “Identifying back doors, attack points, and surveillance mechanisms in iOS devices” first appeared published in The International Journal of Digital Forensics and Incident Response in March 2014’s publication. The Editor-in-Chief is Eoghan Casey, with the Information Security Institute, John Hopkins University, Maryland. The editorial board consists of researchers from Google, Microsoft, LG, The Mitre Corporation, and a number of universities. This paper was the basis for my talk at the HOPE/X conference in NYC in July 2014. Please enjoy.

Zdziarski-iOS-DI-2014

Security firm Stroz Friedberg has published findings validating the technical claims of my latest research, by independently reproducing them against iOS 7 and iOS 8 Beta 4 (NOTE: as I mentioned, Apple has already begun addressing these issues in Beta 5). Interestingly, the firm has also published an open-source proof of concept tool named unTRUST to allow users to remove pairing records from their iOS devices without wiping the device. I haven’t yet had a chance to test it, but this is most certainly good news. It also demonstrates that there is enough of a security threat that such proof-of-concept tools have come into existence.

I’m just learning of this paper myself and had not been previously contacted by the firm; and I think that is a good practice in validating someone else’s research – to evaluate and reproduce it independently. Whereas journalism, on the other hand, should always involve reaching out to the researcher to make sure people get their facts straight.

Direct link to the published paper can be found at the link below:
http://www.strozfriedberg.com/wp-content/uploads/2014/08/SFWP_MitigatingPairingRecordRisks_08112014.pdf

A few days after I gave a talk at the HOPE/X conference titled, “Identifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices”, ZDNet published what their senior editor has described privately to me as an opinion piece, however passed it off as a factual article in an attempt to make headlines at my expense. Now that things have had time to settle down, I’ve taken the time to calmly write up a post-mortem describing what actually happened as well as some behind-the-scenes details that may shed some light on the drama we’ve seen from ZDNet and one of its writers over the past couple of weeks. Let me say first that this is the last time I will address this matter, and have no desire to continue to discuss it, or engage with ZDNet or their writer. In fact, I haven’t engaged with either parties since this all transpired a week or so after my talk, in spite of repeated attempts to bait me with more personal attacks and false claims of harassment.

At HOPE/X, I gave a very carefully-worded talk describing a number of “high value forensic services” that had not been disclosed by Apple to the consumer (some not even to developers), such as the com.apple.mobile.file_relay service, which I admitted to the audience as having “no better word for” to describe than as a “backdoor” to bypass the consumer’s backup encryption on iOS devices; this doesn’t necessarily mean a nefarious backdoor, but can simply be an engineering backdoor, like how supervisor passwords or other mechanisms work – a simple bypass to make things convenient. A number of news agencies reached out to me, and I took time to explain to each journalist that this was nothing to panic about, as the threat models were very limited (specifically geared towards law enforcement forensics and potentially foreign espionage). Also, that I did not believe there was any conspiracy here by Apple. Reporters from ARS Technica, Reuters, The Register, Tom’s Guide, InfoSec Institute, and a number of others spoke to me and got all the time they wanted. You can see that these journalists each published relatively balanced and non-alarmist stories; even The Register, who prides themselves on outlandish headlines, if you read their story, was actually quite level headed about the matter. A number of other news agencies, who had not reached out to me, published sensationalist stories with crazy claims of an NSA conspiracy, secret backdoors, and other ridiculous nonsense. I tried very hard to throw cold water on those ideas both in my talk and in big letters on my first blog entry, with”DON’T PANIC” and instructions for journalists.

ZDNet was among the news agencies that had initially published a sensationalist story without approaching me first for questions.

Continue reading “A Post-Mortem on ZDNet’s Smear Campaign”

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.

Continue reading “Apple is Making Progress”

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.

Continue reading “Apple’s Authentication Scheme and “Backdoors” Discussion”

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 them to acquire data. Whether Apple really does use file relay for diagnostics or not, we may never know, but the service is most definitely being used for other purposes, many of which raise some serious privacy concerns.

To give you an idea of how this “diagnostic service” is being used to bypass security in iOS devices, have a look at their latest press release. At the very top, you will a see a service not unlike that of many other commercial forensics tools that have similar functionality:

It’s very clear from reading this description that they’re describing the file_relay service here, which serves no end-user purpose, and was not disclosed by Apple in any way until after my talk. This key service, as I’ve explained, bypasses the backup encryption that end-users and large enterprises (via MDM’s “force encrypted backups” mechanism) can set to protect data from being dumped in clear text from their device. You can read my research for actual threat models and caveats to this, so as not to rush to panic.

Oxygen, just like many other forensics tools, is widely used by government, law enforcement, military, and intelligence communities. Certainly, nobody can fault any of these software manufacturers for taking advantage of such services to bypass security features in mobile devices like the iPhone. They’re not the only ones either; a number of other commercial vendors do the same thing, and will continue to until Apple closes off the hole.

If Apple was not aware that their self-dubbed “diagnostics service” was being exploited in this fashion, they are now. It is my hope that they will close their service off completely, or cause it to respect backup encryption in future versions of iOS.

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 thought it would make sense to help provide readers with some middle-of-the-road, and easy-to-understand technical links that would help make sense of everything.

End users rely on backup encryption to protect the data on their phone in the event that someone either obtains physical access to an unlocked phone, or access to their computer. Enterprises rely heavily on the “force encrypted backups” MDM policy Apple provides to protect corporate trade secrets and other confidential information stored on employee phones. Having a backdoor to bypass this encryption can be very dangerous for both individuals and businesses. Additionally, the wireless component of this allows for remote and persistent monitoring, making this a potentially long term and stealth threat.

Here’s a list of the technology articles I’ve found useful at explaining my talk and slides. While there may be a few slight technical inaccuracies here or there, these are all “good reads” that overall do a good job.

New Backdoors Discovered in iOS? An Interview With iOS Developet and Digital Forensics Expert Jonathan Zdziarski
Kim Crawley, InfoSec Institute

iOS Lockdown Diagnostic Services (TL;DR)
Dino Dai Zovi, Co-Author “iOS Hacker’s Handbook”

Surveillance Mechanisms in iOS Devices – Don’t Panic but… Do Read This
Elissa Shevinsky, CEO of Glimpse

Apple iPhones allow extraction of deep personal data, researcher finds
Reuters / Joseph Menn

Is Apple’s iOS Backdoor Not a Backdoor
Wall Street Cheat Sheet / Nathaniel Arnold

iOS slurp ware brouhaha: It’s for diagnostics, honest, says Apple
The Register / Iain Thomson

Apple Snuck Backdoor Surveillance Tools Into Their (i.e. Your) iOS*
Matthew Phelan, Gawker
* The headline is sensational, as per usual, but the article itself is quite balanced

I’ve also recently posted a pastebin dump of all the personal data I was able to wirelessly retrieve off of my personal iPhone running 7.1.2 using this service to bypass backup encryption, and with “iTunes Sync” turned off.

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.

Continue reading “Dispelling Confusion and Myths: iOS Proof-of-Concept”

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.

Continue reading “Apple Confirms “Backdoors”; Downplays Their Severity”

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 that, but it does support the journal. I’ve had to TEMPORARILY MOVE MY PDF because it was getting nailed with requests. My apologies.

Mirror: https://pentest.com/ios_backdoors_attack_points_surveillance_mechanisms.pdf

DON’T PANIC

Before the journalists blow this way out of proportion, this was a talk I gave to a room full of hackers explaining that while we were sleeping, this is how some features in iOS have evolved over the PAST FEW YEARS, and of course a number of companies have taken advantage of some of the capabilities. I have NOT accused Apple of working with NSA, however I suspect (based on released documents) that some of these services MAY have been used by NSA to collect data on potential targets. I am not suggesting some grand conspiracy; there are, however, some services running in iOS that shouldn’t be there, that were intentionally added by Apple as part of the firmware, and that bypass backup encryption while copying more of your personal data than ever should come off the phone for the average consumer. I think at the very least, this warrants an explanation and disclosure to the some 600 million customers out there running iOS devices. At the same time, this is NOT a zero day and NOT some widespread security emergency. My paranoia level is tweaked, but not going crazy. My hope is that Apple will correct the problem. Nothing less, nothing more. I want these services off my phone. They don’t belong there.

With that said, enjoy the slides and the paper; I think it’s solid academic quality research.

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 been a subject of interest among the forensics and law enforcement communities. With a large base of interest among consumers, it has become the target of many hackers and criminals alike, with many celebrity thefts of data raising awareness of personal privacy. Recent revelations exposed the use (or abuse) of operating system features in the surveillance of targeted individuals by the NSA, of whom some subjects appear to be American citizens. This talk identifies the most probable techniques that were used, based on the descriptions provided by the media, as well as today’s possible techniques that could be exploited in the future, based on what may be back doors, bypass switches, general weaknesses, or surveillance mechanisms intended for enterprise use in current release versions of iOS. More importantly, several services and mechanisms will be identified that can be abused by a government agency or malicious party to extract intelligence on a subject, including services that may, in fact, be back doors introduced by the manufacturer. A number of techniques will also be examined in order to harden the operating system against attempted espionage, including counter-forensics techniques.
Speakers: Jonathan Zdziarski