«

»

Aug 11

Print this Post

Lessons from Mat Honan’s ‘Epic Hacking’

In Wired magazine, technology reporter Mat Honan has given a heart-wrenching blow-by-blow of how his life was ruined in a matter of minutes by a hacker.  Frankly from the degree of exposure the hackers had obtained from him, the level of damage was far less than it might have been if the hackers were truly malicious toward him.  One hacker, who later identified himself to Mat Honan as ‘Phobia,’ apparently was only interested in obtaining his twitter handle in order to post a bunch of shocking messages and watch the resulting chaos.  Most of the damage was done to make it harder for Mat Honan to follow and stop him.  But in the process ‘Phobia’ also got complete access to his Amazon, Apple, and Gmail accounts and most likely could have used them to get access to electronic banking, brokerage, and e-commerce, destroying not just his digital life but also his financial life as well.

Out of humility, Mat tries to take some of the blame himself. First for not using Google’s double authintication method, but also for tying too many accounts together with a common login and password.  But that is exactly what Apple, Amazon, and others try as hard as possible to make you do.  The problem started with Google showing too much information without any authentication at all.  Google showed the alternate e-mail to the Gmail account, which revealed the existence of an AppleID account.  Why show that alternate e-mail to unverified persons at all?

It is significant that the hack never involved correctly providing a password or correctly answering a security question.  Everything security experts say about creating difficult to crack passwords, while still valid, was completely irrelevent.  The big flaw wasn’t with the data processing at all, but with the companies’ call center customer service policies.

Google’s account reset page, even before doing any validation, gave a good clue to the alternate e-mail address being with Apple.  Apple customer service would allow people who phoned in and provided their Apple e-mail account, their billing address and last four digits of their credit card to gain access (this has been changed after the story went public).  Access to Apple complete.

Although any pizza delivery guy will know your home address and last four digits of your credit card, the hacker in this case made two calls to the customer service department of another big name in computing: Amazon.  In the first call they provided the name on the account and billing address and were allowed to add an additional credit card number to the account.  The card number only has to be numerically valid. It is not checked to be a real account anywhere.  In the second call, providing the name, address, and credit card number added in the prior call allowed them access to add a new e-mail address to the account.  Then the Amazon website allowed the hacker to send a password reset message to the e-mail address they just added (Since the story broke Amazon has also changed their policies).

Logging into Amazon confirmed the mailing address and gave the last four digits of all the real credit cards associated with the account.  As said earlier, Apple Care at the time required only the billing address and last four digits of the credit card to open the account to the hacker.  Now access to both Amazon and Apple were complete.

Then the hacker returned to Google and requested the account reset information on the Gmail account sent to the alternate Apple account listed on the reset page.  Trifecta: Google, Amazon, and Apple complete. And since the Twitter account (and who knows how many others) were linked to the Google login, the hacker’s initial goal, having a ‘cool’ twitter handle for placing a bunch of mischievous tweets, was complete.

But to cover his tracks (and presumably demonstrate the extent of his hack) the hacker cleared the Gmail account, cleared the iCloud account of all contents, remotely reset and wiped the iPhone, and remotely wiped the MacBook.  These last three were the most painful to the victim because it meant that both the original and backups of many irreplacable photographs he had taken were eliminated.

Lessons:

  1. Companies need to seriously reconsider what is sufficient information to authenticate they are talking to the right person.  Is it something that a jilted ex-lover would know?  A vindictive sibling? Somebody who shared a bit too much of their life story on facebook?  Technology is making more and more of our information available, yet we seem to regard so little as being ‘proof’ that we are who we are.  The number of places where you could find out the home address of a person, one of the key items in these examples, could fill a whole article by itself. Even though Apple had a security question on file the answer to the security question was only one of several ways to verify identity and was allowed to be surpassed. Here’s an interesting thought:  Why not let the user decide what the security question should be;  Ask them:  What is a question only you know the answer to….. and the answer is…….
  2. A likely result of companies implementing the first lesson will be a greater reliance on security questions.  So come up with difficult to guess answers just like you would come up with difficult to guess passwords.   Is your favority color blue?  Blue is way too easy to guess.  Make your favorite color navy, or royal, or ultramarine, or skyblue!
  3. Don’t regard the cloud, by itself, as safe enough backup.  The cloud can, as happened in this case, be hacked.  The cloud can, as happened with Megaupload, be shut down or go out of business.  The cloud can be a fine component in a backup strategy, but your backups are incomplete until you have something that you can hold in your hand and restore even if the internet is down.
  4. Have some special purpose e-mail accounts.  So for example, a special purpose e-mail account used only as a secondary account reset would have never given away the presence of the Apple account and never would have allowed hacking the Apple account to give access to the Google account.
  5. Even if it is inconvenient, make sure that low level passwords do not provide access to high level functions.  For example having the account and password that I use to tweet also allow me to remotely wipe my phone and hard disk is a bad idea. I don’t want it to be that convenient!  If before I can remotely wipe my hard disk I have to go through a bunch of barriers that makes the opening sequence of Get Smart look mild by comparison, that is just fine with me.
  6. Consider the value of managing your own domain, or even your own cloud.  The hacker saw @gmail.com and @Me.com and knew that he was dealing with Google and Apple and exactly how they can be manipulated.  Part of tracking him down involved Mat Honan’s personal website.  I would guess that whoever is hosting honan.net also offers a few pop/smtp e-mail addresses in the price or for a tiny bit more.  So what if instead of seeing mhonan@gmail.com and mhonan@me.com, it instead showed mhonan@honan.net?  It would have meant that ‘Phobia’ would have had to call Mat Honan, convince Mat Honan that ‘Phobia’ was Mat Honan, and that Mat Honan needed to give ‘Phobia’ Mat Honan’s e-mail password so he could log in.  Yeah that would have worked so well.  If anybody needs to make a change to their @fulcrum.com account they are talking to me and I know the voice of every single person with a @fulcrum.com e-mail address.

About the author

Daniel Nolte

Architect, Network Administrator, Computer Forensics Administrator, Voiceovers. website,

Permanent link to this article: http://betweenthenumbers.net/2012/08/lessons-from-mat-honon-epic-hacking/

1 comment

  1. website

    I’ll right away clutch your rss as I can’t find your email subscription link or newsletter service. Do you have any? Please let me understand in order that I could subscribe. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*