iCloud Vulnerability Demonstrates Importance Of Rate Limiting For Cloud Security

There’s probably no one with access to the Internet who isn’t aware that the security of Apple’s iCloud platform was called into question recently. I’m not going discuss the appalling theft of private data that ensued, but I do want to look at a related issue: rate limiting. While we’re not entirely sure of the cause of the leak of celebrity’s private photos—the likely strategy was simple social engineering, research of publicly available information, and the exploitation of poor password choices—we do know that around the same time a vulnerability was discovered in iCloud that made life much easier for any potential hackers. It’s worth pointing out that I’m using iCloud as an example of the impact of this class of vulnerability rather than criticizing the service’s security generally; the problem can occur in almost any service and was recently the vector for a serious WordPress exploit too. The iBrute proof of concept used a vulnerability, which has since been fixed, in Apple’s Find My iPhone feature to brute force the service. That was only possible because Apple had failed to rate limit that particular API. If we could rely on users to choose complex, random passwords, no amount of brute forcing would be sufficient to break into an account in a practical amount of time, but we cannot rely on users to choose secure passwords. For a variety of social and psychological reasons, non-technically inclined people (and not a few people who should know better) fail to choose adequately complex passwords. And they choose passwords which are chosen by many other people. The combination of simplicity and non-randomness makes the life of hackers quite easy. They only need to try a limited set of the potential number of passwords—iBrute used the 500 most popular—and they have a high chance of hitting on the right one. This is why no cloud service API that requires user credentials should be left without a rate limit. Rate limiting restricts the number of requests that can be made with bad credentials or tokens in a particular period of time. Leaving APIs without a rate limit allows hackers to try any number of potential passwords in a short space of time, massively increasing the chances that they’ll hit on the right combination and bypass cloud security measures. There are a couple of ways of thinking about this issue: one which is common among security experts and others knowledgeable on the subject, and another, the naïve view, which is common among even technically educated people without security expertise (or empathy). The expert view says that the limitations of human psychology and behavior have to be taken into account by security systems: people will be negligent about their security —choosing bad passwords and so on—so the system has to account for that limitation by implementing rate limiting and other mechanisms. The naïve view is that people are responsible for their own poor choices and if they don’t choose good passwords they deserve what’s coming. We’ve seen quite a bit of this attitude over the last week or so. It’s not how user focused companies and service providers should think. It behoves service providers to make every effort possible to implement security precautions that account for their users and help to keep them safe. Image: Flickr/LadyDragonFlyCC