TL;DR: Hacked Celebrity iCloud Accounts

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

Observations about the data:

1. Data from some accounts were consistent with a device backup. Given the circumstances, these were likely devices backed up to iCloud:

a. The file naming scheme of many files is consistent with the scheme used in iPhone backups

b. Video is not copied into iCloud via photo stream, but it is copied when backing up to iCloud

c. Some folder structures appeared to resemble third party application folders, and included Thumbs.db files as well as a redundant series of folder content.

d. Some media reports indicate some leaked photos had been deleted by the user, however device backups would not have removed a photo deleted off photo stream.

2. Some data hints at being harvested repeatedly over a period of time, for example the data mentioned in 1c.

3. The newest artifact was dated 8/17/2014. Many of the files contained a “Microsoft Windows Photo Viewer” exif section, indicating they were organized with this application on this date. The photo viewer application added these tags to the images.

4. Due to the diversity of the data’s file structure, exif information, and other metadata, it is believed that the data may have been individually collected by multiple parties, and consolidated / released by a single leaker.

5. Many accounts’ data had been sanitized to the degree that it could not be substantiated as having originated from iCloud; that does not mean that it wasn’t, only that based on the data itself, a determination could not be made with any reasonable level of confidence. Other account data remained in its rawest form and such a determination could be reasonably made.

Observations about the breach:

1. Apple has publicly stated that their iCloud systems were not compromised, however has indicated that usernames and passwords were attacked.

2. The iBrute tool was publicly released the night of the leaks, and reportedly addressed by Apple by early morning. The tool took advantage of a weakness in Apple’s FindMyiPhone APIs, which allowed it to avoid being rate limited while brute forcing passwords. It was initially thought that brute force may have been used to deduce passwords. Tim Cook later implied this was not the case, citing phishing attempts. He did not specify if this was the case with all compromised accounts, or only some.

3. Because iPhone backups are not normally accessible by logging into iCloud, and based on chatter on 4chan, it is reasonably theorized that the attacker used a (possibly pirated) commercial forensics tool by Elcomsoft to scrape each victim’s iCloud backup and other data from their accounts, after deducing their credentials. Software like this is necessary because iCloud does not normally give users direct access to backups and other low level content stored in their iCloud account.

4. The currently prevailing theory is that the accounts were first compromised by means of successful phishing attack (not ruling brute force out completely), then scraped with Elcomsoft Password Breaker, possibly repeatedly over a period of time.

5. There was initial discussion of iBrute as means to deduce passwords, rather than phishing. This technique is plausible, and could serve as a “drop in” replacement for “phishing” with all other pieces remaining the same, as it may pertain to other (unrelated) compromises, or possibly some of the celebrity compromises (as it is believed by some that certain accounts may have been compromised by different individuals)

Observations about Apple’s password policies:

1. In their press release, Apple publicly encouraged users to enable 2FA (2-factor authentication) to protect their accounts.

2. Apple’s knowledge base indicates that 2FA would not have applied to this case, because it only kicks in if a user attempts to make changes to an account, or purchase content.

3. Apple presently does not send an APNS, SMS, or email challenge code when restoring a device, or accessing iCloud content from a previously unknown network location. (iCloud device restore is also the technique used to scrape iCloud backup data)

4. Apple does not explain the details / caveats / implications of photo stream or iCloud backups to the consumer when set up, and the features are enabled by default, without any user notification that their data will be copied off the device to remote storage.

Initial Conclusions

Because the collection appears to be pieced together from different sources, it’s possible that multiple methods were used to deduce passwords. Weaker passwords (and/or possibly phishing) were likely the primary target in this series of compromises, however Apple could have managed their security policies in such a way that this breach could have been avoided or greatly reduced. Ensuring that proper rate limiting and account lockout was being enforced on all APIs would have dramatically reduced the possibility of successful brute force attacks, if brute forcing was used for any accounts. In the cases of both brute forcing and phishing, deploying a better version of two factor authentication, a challenge could have rendered this attack unsuccessful (for example, sending a secondary authentication code when a device is restored from the cloud, or if iCloud is accessed from a previously unseen network). Apple might also consider better educating users about the risks involved in use of photo stream and iCloud backups, and avoid having them turned on by default and without notification. Victims may not have even been aware their content was ever sent to iCloud, or still remained in it.

Apple’s Technical Response

On September 16, Apple rolled out new technical measures in a new and improved version of 2-factor authentication (referred to by Apple as 2-step validation). These new measures were designed specifically to address the celebrity attack that took place.

1. When 2FA is enabled on an account, the user must now authenticate with both a password and a challenge code.

2. The challenge code is sent to a phone number (via SMS) or an existing device (via APNS) already on file with Apple, of the user’s choosing.

3. The challenge code is required in order to access iCloud content from a web browser or from a previously unauthenticated device.

4. If none of the user’s devices are available, the user may opt to reset the account’s credentials using the iCloud recovery key given to the user when provisioning 2FA.

5. This new and improved implementation appears adequate in protecting users from stolen passwords, so long as the physical device itself is not also stolen with it; sufficiently enough so that it would have protected the accounts from this attack.

All users are encouraged to enable 2-step validation on their iCloud accounts, even if sensitive information is not intentionally stored in iCloud. Users should understand that phishing scammers may up their game and start phishing for these validation codes. Be sure you only provide this information on Apple websites.