The hacking of Mat Honan is a masterclass in insecurity, with many lessons to be learned for everyone concerned, from outside observers to the companies involved, and of course, for Honan himself.
To recap: Mat Honan, a US-based technology journalist, had his digital life turned inside-out when hackers seized control of his accounts with iCloud, Amazon, Twitter, and Google, remote-wiped his iPad, iPhone and Macbook, and destroyed his data.
Why? Because he has a cool Twitter handle (@mat) and they wanted it.
The hack was sophisticated and lengthy. The attackers knew the weak points in several online services, and chained together attacks one at a time. It shouldn't be seen as lucky that Honan's persona was vulnerable to this specific series of attacks: if other services had been involved, it's likely they would have fallen too. The attackers were well armed with options.
Everyone involved made critical mistakes, and they are errors which other users and services are making on a routine basis. It's a shame Honan suffered the attack, but it does highlight some key points we can use to improve our security, whether we are providers or users of cloud services.
There are a few key angles to cover here, before we get to the intimate details of Honan's incident.
First, no passwords were attacked in this episode. In fact, very little technology was involved at all - the attackers used social engineering to exploit systemic weaknesses in a series of unrelated services. Users are constantly reminded of the need for strong passwords, and we criticise organisations which fail to securely hash, salt and store passwords, and which suffer leaks. But Honan's digital life was torn apart without a single password being cracked.
Second, relying on the cloud is highly risky. A lot can go wrong with cloud services - network disruption, bankruptcy...the list is endless. The relevant point here is that tight integration between cloud services means that security flaws compound one another, and allow single-point attacks to become much broader and more damaging. Data in the cloud, with no local backup, can't be considered safe. And no, the local version which syncs to the cloud doesn't count.
Third, cloud providers are terrible at security. This was a clever hack, yes, and hindsight is always 20/20, but really, you'd expect a lot better from Amazon and Apple. Not a week goes by without us reporting some cloud service exposing passwords or losing a user database. Yahoo? Formspring? Dropbox? Blizzard? Sony? When you're choosing a cloud provider to bet your business on, it's hard to tell good security practice from bad, and you can't judge by size either: plenty of very large and ostensibly respectable organisations have had some very embarrassing online breaches.
Fourth, cloud users are awful at security too. Ignorance may be an excuse, but the reality is that our deeply interconnected use of cloud services is dreadfully vulnerable. I know dozens of very savvy IT people who merrily gave up their Facebook and Twitter passwords to aggregator services without a second thought (thankfully, those services have moved to less insecure authentication APIs now). Right now, most cloud users are sitting ducks. The convenience we embrace in having a new smartphone automagically connect to all our services, is an open door to an attacker who needs find only one chink to launch an attack against an entire ecosystem.
Honan's hack
The attackers used a clever sequence of flaws to crack Honan's digital life. Here's how it went down, how it might have been prevented, and who was at fault:
Attack 1: Reconnaissance
The attackers, wanting Honan's @mat Twitter handle, look up his Twitter account and find his personal details, including his Gmail address. They initiated a password recovery at Gmail, and thereby discover a secondary @me.com e-mail address. Knowing a technique to attack the me.com address, they shift attention to that.
Mistake: Using Google's two-factor authentication tools would have alerted Honan that something was amiss, by sending him a confirmation code by SMS or phone call. If you use a Google profile as a central hub (especially if you're an Android user), this should be a no-brainer.
Fault: Honan. Possibly Google, if you're feeling uncharitable, for not promoting the two-factor option better.
Attack 2: Going home
The attackers look up Honan's billing address online. There are many ways to do this, but in Honan's case it was the address his personal Web domain honan.net was registered to (the address is actually published on that homepage, too).
Mistake: In the Web economy, the physical address is the last bastion of privacy. It's worth keeping secret for other reasons: there are too many tales of vigilante justice gone wrong or mean-spirited pranks. Honan could have registered his domain through a registrar which would not reveal his address, but realistically, his address would probably have been available elsewhere.
Fault: Honan's, if it's a fault at all. Secrecy is not a reliable security mechanism, though. You'll see this again with Honan's credit card.
Attack 3: Groundwork at Amazon
Armed with a user name and billing address, the attackers contacted Amazon and asked to add a credit card number to Honan's account. That seems innocuous enough: adding a new payment method doesn't seem like it would harm anyone, does it?
Mistake: There are plenty of reasons not to accept a credit card with no additional confirmation. It could be a stolen card, with attackers intending to intercept deliveries to an innocent party's address. It could be a Joe Job, intended to frame a victim for using a stolen card. It could be a lot of things, and Amazon should have been stricter about adding the card. It wasn't even a real card number - just a randomly generated number which matched the correct pattern. A quick check against Visa (or whoever it claimed to be) would have established its lack of authenticity.
Fault: Amazon.
Attack 4: The first account falls
The attackers hung up and called Amazon again, and asked to reset the account password. They knew the billing address and a credit card number associated with the account (the one they just added!) and so were trusted. The password was reset, and Honan's life began to unravel.
Mistake: Amazon should have far more stringent security measures in place for account resets. They could, for example, have required knowledge of a credit card which had actually been used for transactions, or knowledge of historic purchases. (Ordinarily, Amazon users can reset their passwords by requesting a reset link by e-mail, the same as many other services, but as you'll see, that method is also flawed.)
Fault: Amazon.
Attack 5: From Amazon to Apple
With access to Honan's Amazon account, the attackers could see a key piece of data: the last four digits of another, valid, credit card. The entire Amazon hack was solely to retrieve that data, knowing it could be used elsewhere.
That's not Amazon's fault: the card number isn't particularly secret, nor useful in isolation. The attackers could probably have retrieved Honan's card number in other ways if they had needed to. Armed with the card number and the other contact details, the attackers called Apple and asked for a new password for Honan's .me e-mail account. The Apple support agent accepted the last four digits of the credit card number as proof of his identity, and created a temporary password.
This was the moment it all unravelled - with control of the e-mail account, every other service would fall in turn.
Mistake: There are so many ways Apple could verify identity, but the support process required none of them. This was a best-practice failure of the first order. They might as well have relied on knowing the user's middle name, date of birth, or any other easy-to-find factoid.
Fault: Apple.
Attack 6: we'll e-mail you a link...
With a temporary password to access to Honan's .Me e-mail account, the attackers requested password resets for his other services - Apple, Google, Twitter.
Mistake: About that two-factor authentication. It's super-convenient to be able to regain access to a service with nothing more than an e-mail and a Web link, but that does make the e-mail account incredibly high-value for an attacker. Doubly so in the modern world: the smartphone and tablet era is all about connected devices, so anyone who has access to one of your connected devices may well have access to your primary e-mail account and, from there, to the rest of your online life.
There are really two obvious missing steps here: users should do whatever they can to secure the e-mail account they use for registering services. And services could offer better tools to identify intrusion: an SMS notification that an account reset is in progress, for example, possibly with a confirmation code to complete the reset or a process to halt the reset.
Cloud service providers are learning about security the hard way, and so are their users. As we move more and more of our lives to the cloud, the attack surface area is growing and the risk is ballooning. We - both the industry and the users - need to grow up fast.
Fault: Everyone.
Attack 7: Wipeout
With access to Honan's Apple ID, the attackers now wiped his accounts and his Apple devices to prevent him accessing accounts. It was a stalling action only, but it resulted in him losing valuable data forever.
Mistake: Relying solely on cloud backups or cloud storage is very risky behaviour. Too much can go wrong. If Honan had had a backup of his data on a USB drive, the disaster could have been averted.
Fault: Honan.
Attack 8: Twitter endgame
Finally, the attackers had what they wanted: access to the @mat Twitter account, and virtual lockout on Mat Honan's devices and accounts to ensure they would not be evicted quickly. Of course, Honan eventually regained access to his online accounts, including Twitter, and the attackers were removed, but they had had their laughs, and the damage was done.
Gizmodo's Twitter account, linked to Honan's, was also abused.
Mistake: Twitter could have stronger reset procedures, but the Gizmodo part throws up a further issue: Twitter provides a lot of great tools for companies, such as Gizmodo, to make use of the service, but would do well to offer better granularity in granting access.
Fault: Twitter.
Everyone got it wrong
Let's recap: everyone in the value chain made mistakes. The service providers (Amazon and Apple) should have been more stringent with their security practices, and the user (Honan) should have used available security tools, segregated his data better, and kept backups.
Amazon and Apple aren't isolated examples of companies struggling to secure cloud services, and to provide customer-friendly support without compromising security practice. And Honan, while no na"ive newbie, was no less secure than millions of other users. He relied on the services to protect him, and paid the price.
Some see this as inevitable: a phase any computing paradigm needs to suffer through. Many years ago, we saw rapid widespread adoption of insecure PC technology, and the modern IT security industry exists because of it. The race to deploy and develop personal computing continued despite the known vulnerabilities - the productivity gains were overwhelming - and so we suffered viruses, browser hacks, OS flaws, and the rest. It was, quite literally, a field day for hackers. It took decades to improve PC security and move to a phase where desktop users are, in general, relatively well protected against basic attacks while still gaining those productivity benefits.
Cloud- and mobile computing appear to be following the same growth path, with the same growing pains. We're racing to deploy devices and services because they are revolutionising our workplaces and our lives, but we are doing so with security as an afterthought, if it's a thought at all.
Many cloud services are insecure by design. First mover advantage is very real, and services are built with deliberate or implicit ignorance of security, to speed up development or to facilitate deployment. The current rash of password leaks is just one symptom of an industry which needs many more wake-up calls like this one before it moves to the next phase, where users have the benefits of the products, without compromising security and privacy.
What can you do?
If you are a cloud consumer, take advantage of security tools like two-factor authentication and strong password generators. Don't rely on the cloud, especially for backup. Assume that cloud providers are not secure, and plan accordingly.
If you're in the cloud business, listen to your security people. Pentest your applications, interfaces, internal processes and partners. Apply security best practices to development, data, and processes, even if that means you ship a few days later or have to defer a cool new feature. Make security a selling point, not an afterthought.
And both sides should discriminate based on security and privacy: if a Web service authenticates against your Facebook account, read the description and ask whether it really needs all that access. Does that new mobile app really need all those permissions to do its job? Does that clever plugin or third-party Web service have access to data it shouldn't? Are your ecosystem partners following best practice? Are they audited?
One thing is certain: we can expect more incidents in the months ahead. Cloud security is only at the start of a long, rocky road.
Share