A week after the 4chan dump of celebrity nude photographs that originated from compromised iCloud accounts has produced — alongside the predictable celebrity-shaming and the more substantive privacy conversations — a piece of operationally useful technical detail about Apple's authentication infrastructure that I have been wanting to write down. Apple's statement on the second characterised the incident as "a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the internet" and explicitly denied a systemic iCloud breach. The honest reading of the technical evidence that has surfaced over the past week is that Apple is right about the no-systemic-breach part and wrong about the "all too common" framing — the attack chain is operationally specific to weaknesses in iCloud's authentication endpoints that should not have existed.
The technical chain, as far as it can be reconstructed from the public reporting and from the various scripts that have circulated on 4chan and on the more technical forums, runs like this. Apple's Find My iPhone API — the service that lets a user log in to find their lost iPhone — until last week had no rate limiting on authentication attempts. None. An attacker could, with a tool like the iBrute proof-of-concept that surfaced on GitHub on 30 August, run unlimited username/password guesses against the endpoint. Combined with the "Top 500 most common passwords" lists that are essentially public infrastructure at this point, plus a list of celebrity Apple ID email addresses (which were — and this is its own structural problem — guessable from public data sources), the brute-force ran successfully against an unknown number of accounts. Apple closed the rate-limiting gap on 1 September, two days after the dump. The fix should not have been needed in 2014; the absence of rate limiting on a critical authentication endpoint is exactly the kind of operational failure that the LinkedIn-shaped breaches of recent years should have made commonplace as a check.
The two-factor angle is the part that has produced the loudest practitioner reaction. Apple has had two-factor authentication on iCloud accounts since 2013, but it was disabled by default and required users to opt in, and — and this is the part Apple has been less willing to discuss publicly — even where users had enabled two-factor, it did not protect the iCloud backup or photo-stream data, only the account-management functions. A two-factor-enabled celebrity who had backed up their iPhone to iCloud was, on the public reporting, just as exposed to the brute-force chain as a non-two-factor user. The fix that Apple announced on 4 September will extend two-factor to cover the data endpoints; this is the right fix and it should have been the original implementation.
The wider point about consumer-platform authentication is one I have been making in the post-Snowden engagement-team material for some months. The major consumer-platform vendors have been treating authentication as a checkbox feature rather than as a security-engineering discipline. Find My iPhone shipped without rate limiting; iCloud's two-factor implementation had a coverage gap; the security questions used as account-recovery mechanisms remain trivially-guessable for any user whose biographical information is public. None of these are novel observations; the industry has been making them for a decade. The Celebgate dump is the public-spectacle moment that may finally produce the corrections the industry has been resisting.
For the engagement work, the post-iCloud conversation has been about consumer-grade authentication services that engagement clients use for non-trivial purposes. The clients with executive-level cloud-storage usage — which is most of the secondment portfolio — have been having the same conversation about whether iCloud is the appropriate storage location for sensitive material. The honest answer is that no consumer-cloud-storage service in 2014 has the authentication infrastructure I would consider adequate for sensitive material; the appropriate answer is on-premise storage or, where cloud is required, business-tier services with institutional authentication infrastructure rather than consumer-grade infrastructure.
For the Hedgehog SOC, the post-Celebgate detection-content additions have been around iCloud-related authentication patterns at the engagement clients — anomalous access to iCloud accounts associated with executive users, particularly from unusual geography, and any sign of brute-force-attempt patterns against organisationally-relevant Apple IDs. The detection signals are not subtle; the value is in having the analysts looking for them as part of routine monitoring rather than only after an incident is suspected.
The narrower point about user-experience trade-offs in security engineering is one I keep coming back to. Apple did not implement rate limiting on Find My iPhone because rate limiting produces user-experience friction — a user who has lost their phone and is panicking and entering their password slightly wrong does not want to be locked out for fifteen minutes after three attempts. The engineering trade-off was made in favour of usability, and the security cost did not become visible until the public-spectacle moment forced it to. The same pattern produces the credential-stuffing exposures, the security-question weaknesses, the password-recovery flow vulnerabilities. The structural answer is that the security-engineering community has not been good at articulating the cost of these usability trade-offs in language that platform product managers act on. Celebgate may help; or it may not. We will know within a year whether the major consumer platforms have substantively tightened their authentication infrastructure, or whether the next dump produces the same conversation.
The next post is probably Shellshock if the OpenSSL-shape vulnerability that has been quietly developing in the bash codebase produces the impact that some early analyses are suggesting it might, or whatever else surfaces. The pace of substantial vulnerability disclosure through 2014 has not been slower than 2013.