Dealing with iCloud extortion

Share with your network!
A group of criminals is currently threatening to delete hundreds of millions of Apple iCloud accounts and lock users out of their devices unless Apple pays $70,000 ransom. Let's take a look at how serious this threat really is (not very), and what both individual users and enterprises can do to prevent this sort of attack. For the individual user, it is important to use dual factor authentication (2FA) on all accounts that support it. If you have an iCloud account, turn on 2FA right now, before you read any more of this article. It only takes a few moments. The instructions are here. Also, if you ever used the same password on your iCloud account and any other account, it would be a good idea to change that password now. All done? OK, let's continue. It's clear that the attackers who call themselves the "Turkish Crime Family", do have the credentials for some number of iCloud accounts, though it is probably far smaller than the hundreds of millions they are claiming. This was not a result of a data breach at Apple, but of other data breaches which may have exposed passwords which were reused on iCloud accounts using the same email address. (See http://www.pcworld.com/article/3184476/security/leaked-icloud-credentials-obtained-from-third-parties-apple-says.html) The Turkish Crime Family provided ZDNet with a sample of 70,000 accounts. ZDNet attempted to contact the owners of a random sample of a hundred of these accounts. In many cases the account no longer existed, but they were able get a response from twenty users, and twelve of them confirmed that the password was or had been valid. Interestingly, almost all of the accounts in the 70,000 sample came from the breach of the multiplayer game Evony in June of last year. This breach revealed 29 million email addresses with MD5 hashes of their passwords. It's normal practice salt passwords before hashing them - that is, add a couple of extra characters so that if the user has chosen a common word as a password the value to be hashed is not in the dictionary. Unfortunately Evony had not done this, so any hacker with this data dump could extract credentials for anyone who has used a password on one of the 'common password' lists. It seems that the hackers took the Evony data breach, extracted what passwords they could, cross referenced to other breaches such as Last.fm and Linkedin, and if the password was the same in multiple places and the email address matched an iCloud account, they assumed that the same password was used for the iCloud account. The Evony breach may have started out with 29 million email addresses, but as each stage in this process, many of those email addresses would have dropped out, so it's unlikely that they have even a million iCloud account credentials let alone hundreds of millions. Of course, they may have worked with other breaches apart from the Evony one, but still their claims seem wildly exaggerated. Apple has had a week now to respond to this threat, and has another week before the hackers are threatening to pull the trigger and start deleting accounts. Let's assume the worst, and that the hackers do have millions of accounts that they can delete. Apple has had plenty of time to take a full backup of all iCloud accounts, and put in a kill switch to block the account deletion process if they see a spike in activity. They probably won't even need that. Unless the hackers have an enormous botnet at their disposal, their activities will result in a lot of iCloud activity (especially failed login attempts) coming from a small number of IP addresses. All Apple has to do to minimize damage is automatically block IP addresses after a few failed login attempts or device locks. My guess is that the number of users impacted by this will be less than the number of people who accidentally drop their phone in water in a typical month. It seems that data breaches will continue to happen. The email address I have been using longest has been leaked no less than five times, by Linkedin, Adobe, myspace, QuinStreet, and most recently by the affiliate spammers River City Media. However, the severity of a breach varies a lot depending on the content of the data. Information enabling financial fraud such as credit card numbers or tax data is worse than just exposing an email address. Breaches that expose plain text passwords are worse than breaches that exposed hashed passwords which are worse than breaches that expose salted and hashed passwords. The bottom line for enterprises storing user data is make sure those passwords are salted and hashed, and encourage the use of 2FA and strong passwords. You can check if your email address has ever been exposed in a data breach. The chances are quite high that is has if you have been using it for a few years. Check at Troy Hunt's invaluable website https://haveibeenpwned.com/. Even if it hasn't there is still a chance that it may be at any time, and that your password may be compromised. For this reason it's important to limit the damage by not reusing the same password on multiple accounts. Of course, you now have to find a way of keeping track of all your different passwords. There are two common ways of doing this. Many security experts recommend using a password manager to generate strong passwords and keep track of them all. I have reservations about this approach as password managers represent a single point of failure. If someone compromises that password manager, they have access to all your accounts (or at least the ones that don't have 2FA turned on). I prefer the second approach, which is to use a simple rule based on the domain name to generate a unique password for each website. Here's an example:
  • Start with your favorite word: ferret
  • Pick your favorite number: 42
  • Since your number was 42, you'll capitalize the 4th and 2nd letters: fErRet. Mixtures of upper and lower case letters are harder to match by brute force than words that are all the same case.
  • Add a symbol: %fErRet
  • Count the number of letters in your domain name. For cloudmark.com it's 13
  • Add that to 42: 55.
  • Now add the 4th and 2nd letters in the domain name. For cloudmark.com that's u and l
  • Put it all together: 55ul%fErRet
Go ahead and make up your own rule, don't use this one, and please don't use 55ul%fErRet as a password. Just remember the principal that you mix variable stuff based on the domain name with a constant string that is hard to guess. One final note: many of those password recovery questions like mother's maiden name, high school, pet's name and so on can be derived from your social media profiles. Treat them as passwords, and add some extra characters based on the domain name in the same way.