Opinion: Lessons learnt from high profile security breaches
InternetNZ policy analyst Dean Pemberton looks at how a Wired magazine reporter had his digital life erased
By Dean Pemberton, Wellington | Tuesday, 2 October, 2012
On Friday August 3 2012, Mat Honan, a reporter for Wired magazine, had his digital life erased after attackers were able to gain access to his Apple, Amazon, Gmail and Twitter accounts. Losing every photo from his daughter’s life was serious enough, but the true shock came from how easy the process was. It all started with someone knowing Honan’s personal domain name. From there, the escalation of steps was simple:
• Public ‘whois’ search: Having Honan’s personal domain name yielded a billing address.
• Amazon.com: Having a billing address yields a partial credit card number.
• Apple: Having a partial credit card number yields access to an AppleID and me.com email (via password reset functionality).
• iCloud: Having an AppleID yields the ability to remotely wipe Honan’s iPhone, iPad and MacBook laptop.
• Google: Having access to Honan’s me.com email account yields access to his Gmail account (again via the password reset functionality).
• Twitter: Having Gmail account access yields access to Honan’s Twitter account (via, you guessed it, password recovery again) that allowed the posting of hate speech.
• The attacker finally deleted Honan’s Gmail account including all its contents.
Honan’s personal electronic devices were wiped, all his personal emails were deleted and his name associated with hate speech on his Twitter account.
How did we get from a simple ‘whois’ lookup for a billing address to that? The answer… one tiny step at a time.
You can see that each step above relies on ‘having’ access to one piece of information to ‘yield’ another. The trick is to ensure that you are yielded something a little more important each time.
What are the common themes that appear in these types of attacks?
Security trust chains have weak links. In these cases, the attackers do not start off with access to their end goal. They are able to use the fact that each successive level of protection relies on the level below doing its job. Google would never dream of letting a Gmail user login with just their billing address, but in this case that’s effectively what was occurring in the above example. There were just a few more steps required in the middle.
Password reset procedures – why put a lock on the front door if the back door is wide open?
Organisations are often so concerned with reducing the impact to a customer from forgetting their password they sometimes trade away the overall security of the system. Attackers no longer have to attack high-security password algorithms; they just call the friendly customer support line and hand over a partial credit card number.
Collect all the little bits of information you need and then build up to the prize. The attacker’s end goals were built up with smaller wins along the way. In most cases these smaller wins yielded treasure that the protecting organisation didn’t consider significant. It wasn’t until near the end goal that it becomes clear what the true value of all the smaller pieces add up to.
So what can people and organisations do to ensure that they are neither susceptible to nor contributing to this sort of attack?
Evaluate your password recovery procedures. Both automated procedures and those via your customer support lines. It should be difficult to reset a user’s password. Issuing a password reset should be the exception, not the rule.
Evaluate your administration trust chains. Ensure that you’re not protecting valuable assets using lower security systems.
Evaluate your use of information for authentication. Examine how you utilise pieces of client information.
Are you using a credit card number as a means of authentication? A credit card is for making a purchase, not authenticating a user. Other organisations might not give it the same protection as you. Do you ask for someone’s birthdate as a means of authentication?
Do you know how many people have their birthdate on their Facebook profile? It’s not really information that only that person would know.
Above all, I hope that by learning from the experiences detailed here I’m not reading about you or your customers in the next attack report.
Pemberton is a technical policy analyst for InternetNZ