Early this week, news broke that Hackers were able to gain unauthorized access to the iCloud accounts of several celebrities. After getting access to the accounts, the attacker(s) leaked numerous private photos, including several nude and intimate photos. Law enforcement authorities are investigating the incident with Apple.
Following an internal investigation, Apple determined that the victims’ accounts were specifically targeted and that the attackers haven’t breached any of the company’s systems.
Apple claims that the hackers compromised the targeted accounts through an attack on usernames, passwords and security questions. However, experts believe that the attackers might have also leveraged an iCloud vulnerability (since patched) that could have been exploited for brute force attacks via the Find My Phone service.
Following the incident, Apple promised to ramp up iCloud security. The company plans on alerting users when attempts are made to change their passwords, when iCloud data is restored to unrecognized devices, and when someone logs in from a new iPhone or iPad. In addition, Apple wants to broaden the use of two-factor authentication and raise awareness among users.
Security industry experts have analyzed the attack and commented on the impact of the incident on Apple’s reputation, and provided recommendations on how to avoid such leaks in the future.
And the Feedback Begins…
Mike Janke, CEO and co-founder of Silent Circle:
“While leaked celebrity photos wouldn’t normally be our thing, Silent Circle, as a company, believes that privacy is a right. While it is easy to conclude that individuals should not take and share nude photos for fear of a leak, a significant change in behavior is not so easy to prescribe. If laws were broken to retrieve the images, criminals should be justly prosecuted for their crimes. But If we are going to blame the hackers here and bring jail-time into the equation, shouldn’t we have similar stances against Facebook, Google, Ad Companies, and freemium apps that don’t tell you about the troves of data they take? Where does crime start and where do ‘business practices’ begin?
Our most common forms of communication, telephone, emails, and text messages all give us a false security that most people blindly accept. Smartphones and digital applications have made it even easier to ‘feel’ secure without actually being secure. Perhaps the fault is on the technology. Perhaps the technology perpetuates the confidence in the security of our everyday communication tools when in fact they were never intended to be private or secure. Again, blaming the technology and not the creators and sellers of this technology is an empty argument.”
Simon Crosby, CTO and co-founder of Bromium:
“Apple will do the obvious – belatedly implementing 2-factor authentication for iCloud, and hopefully users will do the obvious – turning off the default iCloud settings on their devices. This will help, but ultimately Apple (like all cloud vendors) needs to encrypt customer data. Two layers of encryption are required: The first encrypts the data at rest using keys held by Apple – in case someone steals a hard drive. The second encrypts the data with keys unique to the subscriber. Data is only in the clear when accessed by a fully authenticated user.”
Dan Kaminsky, chief scientist and co-founder of White Ops:
“To fix this, Apple could have simply forced everyone to use two-factor verification for their accounts. It’s easy, and would have probably prevented all of this. Probably the only time ‘simply’, ‘easy’, and ‘two-factor verification’ have ever been seen in quite such proximity, outside of marketing materials anyway. Still, we have to do better. So-called ‘online brute-forcing’ – where you don’t have a database of passwords you want to crack, but instead have to interact with a server that does – is a far slower, and far noisier affair.
But noise doesn’t matter if nobody is listening. Authentication systems could probably do more to detect brute force attacks across large numbers of accounts. And given the wide variety of systems that interface with backend password stores, it’s foolish to expect them all to implement rate limiting correctly. Limits need to exist as close as possible to the actual store, independent of access method.
Many users like predictable passwords. Few users like their data being compromised. Which wins? Presently, the former. Perhaps this is the moment to shift that balance. Service providers (cloud and otherwise) are burying their heads in the sand and going with password policies that can only be called inertial. Defenders are using simple rules like ‘doesn’t have an uppercase letter’ and ‘not enough punctuation’ to block passwords while attackers are just straight up analyzing password dumps and figuring out the most likely passwords to attempt in any scenario.
Attackers are just way ahead. That has to change. Defenders have password dumps too now. It’s time we start outright blocking passwords common enough that they can be online brute forced, and it’s time we admit we know what they are. We’re not quite ready to start generating passwords for users, and post-password initiatives like Fido are still some of the hardest things we’re working on in all of computer engineering. But there’s some low hanging fruit, and it’s probably time to start addressing it. And we can’t avoid the elephant in the room any longer.”
David Maman, CTO and co-founder of GreenSQL:
“Unfortunately, these breaches are just going to keep getting worse until people start taking control of the information on their smartphones, PCs and other devices – and what is allowed to access that information, particularly apps and cloud services. Banks – in the physical world, for example – don’t just rely on security systems and armed guards; they have locked safes made of thick steel to keep our money safe. Data should be addressed the same way.
Databases powering cloud services can be an important last line of defense against breaches in this mobile and cloud-driven era, whether it’s masking what certain users or apps are able to access, in the event they are compromised, or enforcing logical access controls to stop brute-forcing log-in attempts and other suspicious behavior.
Companies and employees relying solely on static things like passwords and application firewalls to protect what they have in the cloud are like banks who keep their safes open, or made out of cardboard.”
Michael Sutton, VP of strategy for Zscaler:
“Whenever a story like this week’s ‘iCloud hack’ hits the headlines, it’s inevitably followed by an angry mob demonizing the cloud for reducing security. Let’s be clear about one thing – this was not a ‘cloud issue’. The breach that took place followed a very basic script that was in use by attackers long before ‘cloud’ was ever a buzz word. If we believe Apple, there was no compromise of the iCloud infrastructure, but instead, this was ‘a very targeted attack on user names, passwords and security questions’.
Translation – the hackers brute forced passwords and used Google to guess the answers to password reset questions. Such an attack could just have easily been conducted against your email account 20 years ago. Unfortunately, for celebrities (who should know better), the answers to password reset questions are a little easier to obtain. I’m pretty sure Google won’t tell you the name of my elementary school or my favorite color, but it will for JLaw.
So who’s to blame? Apple doesn’t get off scot free. Like any vendor, they must balance security and usability. It doesn’t benefit them to make a bullet proof product that no one wants to use, but in this case, they could certainly have gone further to protect customers. Their version of two factor authentication for iCloud (what they call ‘two-step verification’) is limited at best and only ties to account management and purchases. Additionally, we learned that leveraging the Find My iPhone API to brute force user passwords would completely bypass the password lockout controls implemented on the web form – a security 101 mistake. Fortunately, Apple has promised to address these issues.
Blame also lies with the end user. In the end it’s your data and you must take responsibility for it. Don’t want your nude photos stolen? Don’t store them on a digital medium. Anywhere. Don’t want your password guessed? Use one that’s unique and difficult to brute force. Better yet, use a password manager to avoid password reuse and implement two factor authentication when you can. In the end, the sky isn’t falling and vendors and end users alike should have learned a few valuable lessons from this tabloid worthy hack. JLaw – if you need some more security advice, I’m here for you.”
Chris Morales, practice manager at security testing and analysis firm NSS Labs:
“Apple has 2-factor but for whatever reason never implemented it as part of iCloud. Very surprising. Especially since it is part of their own recommendation. I’m sure it won’t be long until they do. To be more specific, 2-factor exists, but it does not protect backups or photos.
The problem is without 2-factor, this type of attack can still happen through the password recovery mechanisms no matter how strong the password is. Even worse, once the Apple login and password are known, the user just has to do a ‘restore’ to a device or software imitating a device and all the backup data and photo stream will be sent to the ‘user device’. Apple has not really come out on how they are addressing this. Their recommendation now seems inconclusive and the problem is still there. I’d like to think Apple will have something else to say very soon.
To add to that, Apple’s comments to media is the exact response I was expecting. Apple had to acknowledge the lack of auditing and access controls in place on the iCloud environment which was a huge oversight on their part. An attack this simple should have never had happened. It underlies key fundamental issues with security, a lack of proper implementation.”
Tal Klein, VP of strategy and marketing for Adallom:
“Instead of naked selfies, let’s consider the iCloud data as if it were information stored within a company’s Salesforce.com environment. Perhaps easier if made personal: How much privileged data exists in your enterprise Salesforce instance? Which users have access to that data? Can you empirically prove the entities with those users’ credentials are the users themselves? What kind of damage would your organization suffer if that data fell into the wrong hands?
After all, you can’t blame users for accidentally getting phished, but neither can you blame the service provider when it happens to them. In the cloud, as in life, there’s a lot of gray. Bad things happen to good people, but those actively invest in mitigating those risks are less likely to become prey.”
From Andrew Jaquith, CTO and SVP Cloud Strategy, SilverSky:
“I looked at the ‘ibrute’ code on GitHub also and concluded that this was a garden-variety brute-force attack. The code would lead you to conclude that the speculation about Apple not limiting the number of guesses when authenticating to Find My iPhone via JSON is correct. This is clearly meant to be used by applications and isn’t a browser interface screen.
More interestingly, the ‘fmipmobile.icloud.com’ host that the ibrute code authenticated against is found in 76 other GitHub projects. Pretty much every one of these are meant to allow programmers to query the location of an iPhone. So this authentication vector was clearly well-known to the broader programming community. It just so happened that some opportunistic hackers realized that it could be used to brute-force account passwords because it didn’t have effective lockout controls.
Pulling back to 10,000 feet: we can expect that this there will be other examples like this: exploiting (1) cloud service authentication APIs — meant to be used by programmers — that (2) have security controls that are less stringent than those that are user-facing. This iCloud hack is merely the highest profile example, but one can expect opportunists to look for weaknesses in every case where a mobile app or native touches a remote cloud service. iCloud, Google Play Services, and the various mobile app stores are all fair game, as well as many others.”
Marcus Ranum, senior strategist at Tenable Network Security:
“One thing that strikes me is that brute-forcing attacks against services are still working/still possible. It’s as if the idea of exponential backoff/retry times on bad logins hasn’t sunken in. Brute-forcing ought to be impossible in 2014, unless there’s an open path to an authentication service that is not correctly implemented.
Brute force attempts to log in are highly detectable. A user may make a few failed logins (5 to 10 in a minute) but never more than 1,000 or even 500. Systems that fail to push accounts to heightened security levels after more than 100 failed logins are not correctly implemented. System log analysis will quickly reveal that brute force attacks are in progress. I am not saying that we should expect massive cloud service providers to actually react to brute force attacks in real-time, but they ought to be aware of them and implement backoff/retry timers and heightened security levels.
Unfortunately, the uptake of two stage authentication is still woefully small, even though two stage authentications via an SMS code is very easy to implement and dramatically increases the difficulty of such attacks.”
Dov Yoran, CEO ThreatGRID:
“The iCloud compromise appears to take the usual path of blaming the vendor for the whole problem. Yes, Apple provides two-factor authentication for only a subset of the services like alerts on when a person’s account is accessed from a new device, or when a change is made to the security settings. And yes, they previously had a Find My iPhone vulnerability that could eventually lead to iCloud access. (Remember software and services will always have vulnerabilities, but according to the Apple statements that was not exploited in this compromise).
In this incident, however, the user should bear some of the accountability for the hack. According to Apple, the attacks were based on social engineering. It appears the attackers gained access to an account by guessing the user’s password or answering the ‘security questions’ both of which could have been obvious or easy to guess. Users need to avoid using the same passwords everywhere, using simple passwords, and simple questions. In the end there’s plenty of blame to Apple for not having 2-factor authentication turned on for all services and to the user for setting obvious passwords and answers that a stranger can guess. “
CEO of Intercede, Richard Parris:
“As we live more and more of our lives online, all our various digital identities need to be effectively protected – worryingly, it appears that this is not the case at the moment. We need so many passwords today, for social networking, email, online banking and a whole host of other things, that it’s not surprising consumers are taking shortcuts with automatic log ins (for apps) and easy to remember passwords. These solutions are increasingly not fit for purpose though – they do not offer proof of a person’s identity and are easily lost, stolen or hacked, leaving consumers at risk of identity theft.
It’s time for stronger authentication and more sophisticated forms of identity, but also for a more comprehensive, wider program of education for the general public highlighting the numerous, and largely unknown vulnerabilities inherent with mobile devices and the apps we use in our everyday lives. Whether this is an issue for the app developers, handset makers, regulatory bodies or even the government is a discussion for another day, but one thing is clear – consumers, celebrity or otherwise need to be educated more about the potential security risks posed by the devices in their pockets.”
Until Next Friday…Have a Great Weekend!
