I was violated, digitally.

And I nearly lost my digital life.

Kapil Haresh
8 min readJul 26, 2016
Happier days working on my Mac (photo of me during a photoshoot for the Engineering faculty at Wollongong)

Update 31 July 2016: Fixed a typo, Sunday was July the 24th, 2016. Not July the 23rd. Apologies for that!

Update 28 July 2016: I’ve added a video demo of the flaw at the end of this article. You can check it out here too.

Hi there. My name is Kapil Haresh and if you don’t know me, I am a current CS grad student at uWaterloo, where I do cryptography, security and privacy (CrySP), software engineering and human-computer interaction. I was a CS undergrad from the University of Wollongong where I specialised in digital security and software engineering, making it into the limited admission Dean’s Scholar program, and my cryptography and network security subjects were with pretty decent (90%) averages on their own. TL;DR – I know a thing or two about security. And a couple of days back, I watched my entire digital life get violated and nearly wiped off the face of the earth.

That may be a bit of an exaggeration but honestly speaking, it was pretty much like that. Here’s a timeline of the attack, which took place on Sunday, July the 24rd 2016 (all times are in Eastern Standard):

That’s a pretty incidence matrix.

3.36 pm. I was scribbling out an incidence matrix for a perfect hash family table on the whiteboard, explaining how the incidence matrix should be built to my friends. The irony, this was a cryptography assignment for multicast encryption. Everything seemed fine, until a rather odd sound started playing on my iPhone. I was pretty sure it was on silent, but I was quite surprised to see that it said “Find My iPhone Alert” on the lock screen. That was odd.

3.37 pm. My iPhone’s lock screen changes. The screen dims, with the following message, “Hey why did you lock my iPhone haha. Call me at (123) 456–7890.”

This was when I realised what exactly was happening. My Apple ID had been compromised and the dimwit on the other end was probably trying to wipe all my Apple devices. Clearly he/she wasn’t very smart (but to my benefit), the adversary had decided to play the sound and kick the iPhone into Lost Mode before attempting to run the remote erase. Sounds familiar? Of course, this was exactly what happened in August of 2012, with Mat Honan’s massive hack. In his case it happened through a slightly different way, but the end goal was the same, wipe the devices and destroy the data.

3.36 PM, first Find My iPhone alert. Apple emails you back everytime you make a change with Find My iPhone.
3.37PM, second Find My iPhone alert.
3.37PM, Lost Mode enabled.

When you throw a device into Lost Mode, it immediately attempts to get the physical location of the device and shows it to the adversary.

3.37PM, adversary now knows where I am right at that moment. Cool.

3.38 PM. Naturally, I go into lockdown mode, and immediately take all my devices offline, to stop whatever else the adversary was planning to do. When I knew I was being targeted in the same way as the Mat Honan attack, I was expecting that they were definitely targeting to wipe my devices. True enough, I was able to confirm that they indeed attempted to wipe my iPhone and my Mac as well.

3.50 PM, I get back into iCloud and notice the pending erase request.

The point here was that because I managed to take all my devices offline, I was able to make sure all of them didn’t get their erase requests from the server. But this could have been worse, way worse.

After the 2012 Mat Honan attack, I decided to get 2 factor authentication (2FA) turned on for my Apple ID, to act as a safeguard. 2FA here was my friend to some extent, as in the case of iCloud, 2FA blocks any user attempting to login to your account to go any further than logging in and accessing Find My iPhone, Apple Pay and Apple Watch settings — I don’t have Apple Pay and an Apple Watch for now, so I am not sure as to the extent of access for those two, but with Find My iPhone, this form of 2FA doesn’t protect it. This was kind of understood — if you lose your iPhone, you can’t get the second factor of authentication to get in to lock your iPhone.

One of the benefits of having 2FA was that things like my Mail, Contacts, Calendar and other documents were locked away, and without my 2FA code that comes either through my trusted device (via the Find My iPhone service) or via a text message, there wasn’t any way to get that unless the trusted device or the device that received the text message was compromised as well. Also, there was no way for the adversary to reset the password as well without getting the 2nd authentication code.

2FA via iCloud

I was able to lock my account with a new password and got all the erase requests cancelled.

But herein lies the problems, which if addressed, could have prevented this attack or at least limit the potential damage. The lack of 2FA for Find My iPhone and the lack of pattern monitoring on Apple’s servers were two main reasons how this attack took place.

  1. Pattern monitoring
Legitimate login by me, on my (then new) MacBook
The adversary’s login — I did get an email detailing the login attempt

One of the things I did notice was that the login notification emails generally originate from the country you login from, especially in this day and age when Apple has a local division in most large, if not all countries. I noticed this as I was able to check on my older login notification emails that I received when I lived in Australia — in that case all of my notifications were addressed from Apple Pty Ltd, while my logins from Canada were addressed from Apple Canada Inc.

Email notification when I tried to login after the attack, once I had it contained

In this case, the adversary’s login attempt resulted in a login email from Ireland instead, which lead me to suspect they clearly were not in North America at least. Of course this could have beeen spoofed with the help of a VPN, but still the location change could have been detected as it would be an outlier from my regular logins from Canada. The other, clearer differentiation of the pattern was the part where the login was done on a Windows computer, instead of a Mac — which in my case, would have been quite an outlier as I normally use a Mac and can probably count the number of times I have logged in using a Windows computer. Ideally, at this point, it would have been reasonable to check if this was a legitimate login — for example, using one of the secondary accounts nominated in the Apple ID. Microsoft actually does this, if you attempt to use your Microsoft account on a new device or a device that isn’t normally used, it locks the account and gets you to confirm the login through your secondary accounts.

Microsoft got this bit right. I got this when I signed in on a new Mac.

2. Lack of 2FA for Find My iPhone

When you sign up for 2FA, Apple disables the secret questions/answers to reset the password — you need the recovery key instead to regain access if you forget the password.

I can see why Apple decided against using the same 2FA authentication for Find My iPhone — ideally you’d only use Find My iPhone when you lose your device, hence you’d not be able to access your text and on-device authentication. But for there to be no 2FA for Find My iPhone doesn’t quite add up.

But really, I can see how this could be fixed. Instead of having a one time code for Find My iPhone, it might be better to have a second layer of authentication in the form of a secret question/answer when accessing Find My iPhone if 2FA was on, which the legitimate user would know the answer for the question, just like in the case of a forgotten password. By nominating a number of question — answer pairs, it can be randomised too.

If such a thing existed, the adversary in this case would have not been able to go anything more than looking up the location, and ideally he/she won’t be able to play the alert sound or even conduct the remote erase.

What happens next? Well, to be fair, I have not had bad experiences with Apple’s security in the last 10 years of using their products, hence I would say I’m still pretty confident to use their products. But at the same time, the viability for such an attack to occur is quite scary, considering Apple is moving (like many others) to a cloud focussed future. My experience in this case wasn’t as bad as it could have been, I knew what to do and how to contain, and subsequently neutralise the attack as I know how Find My iPhone and iCloud works, but to the general population, which is a large proportion of Apple’s user base, this would have been a very different story.

I’ve never revealed this password and the password itself is pretty random, with capital letters, small letters and numbers, and never have I accidentally signed into a dodgy site. I’m going on the basis that the adversary successfully guessed the password somehow, but the important thing here is to reduce the damage should a password be obtained by the adversary. The thing is Apple also has to do this fast, I can’t imagine having my iPhone randomly wipe out while I’m on the road with CarPlay giving me driving directions or HomeKit controlling my home, especially considering in the next couple of years, we’d likely to see stronger CarPlay integration and HomeKit integration.

To the hackers — please get English classes. That was quite a pathetic Lost Mode message. Not as bad as the Oleg Pliss attack message in 2014, though interestingly, that attack could have been prevented as well if there was a second factor of authentication for Lost Mode, as the 2FA that everyone suggested to turn on doesn’t protect Find My iPhone as seen here.

UPDATE 28 July 2016: I’ve done a video demonstration of the vulnerability here. I used a temporary password in this case.

PS: If anyone is interested in talking to me about it, I’d be down to discuss about this via my current email, khvignes (at) uwaterloo (dot) ca, or via message on LinkedIn.

--

--

Kapil Haresh

CS Grad student at uWaterloo, looking at cryptography, security and privacy (CrySP), software engineering and human-computer interaction. CS @ uWollongong 2015