In terms of service interruption and compromised sensitive information, the CloudFlare hack seems almost trivial, but the details of the attack are sobering reminders that password reset procedures are the Achilles’ Heel of many web-based services today, large and small.
Big Kudos to the CloudFlare’s CEO Matthew Prince for posting as much information as possible about what they know of the hack and posting about their work with all the other parties involved to fix the vulnerabilities that the attackers exploited. CloudFlare does everyone a public service by communicating the events as openly as they have.
Details of the CloudFlare Hack
They even included this handy infographic to help understand the events that transpired. Mr. Prince outlines four security flaws that made the CloudFlare attack possible. The first and foremost is that the attackers managed to hijack the Mr. Prince’s AT&T voice mail account and redirect messages destined for his voice mail to a fraudulent voice mail account controlled by the attackers.
Second, the CloudFlare hack was based on (surprise) the attackers exploiting weaknesses in the Google Apps password reset procedures. They managed to convince the Google Apps password reset procedure to leave a voice mail with an account reset PIN. But because the voice mail account had been hijacked, the attackers received the account reset PIN instead, which they used to try to take over the Prince’s email account.
Matthew Prince had enabled Google’s two-factor authentication mechanism, but apparently there was a flaw in that system with regard to password resets that enabled the attackers to bypass the two-factor authentication. If the two-factor authentication had been working properly. Mr. Prince would have started receiving authentication requests for transactions he did not initiate and the CloudFlare hack would have been prevented.
Lastly, there’s this event in the attack time line:
“CloudFlare BCCing transactional emails to some administrative accounts allowed the hacker to reset the password of a customer once the hacker had gained access to the administrative email account.”
When I first read this, I wondered if the CloudFlare hack has some insider assistance. Looking at the time line, it took the attacker about 12 minutes from the time Prince’s account was compromised to the time a customer account was compromised. At first I thought this might be an indication that the attacker knew about the administrative processes CloudFlare had in place to bcc: administrative accounts when a customer reset an account password. But it might also just have been an opportunistic attack. At minimum the attacker knew how to browse the control panels for Google Apps and recognized that this setting was something that could be exploited for the CloudFlare attack.
Give the short window of time that the attacker had control, and given that much of that time was actually spent by the attacker trying to maintain control of the accounts while CloudFlare worked to take them back, it’s not likely that the attacker got much in the way of high value information. Still, email accounts were compromised, so I don’t want to dismiss the CloudFlare hack too much.
The CloudFlare hack drew my attention because it’s based on vulnerabilities in password reset procedures which are a pet peeve of mine. But the CloudFlare attack is different than the usual password reset attack in that it’s not based on finding personal information from out of band sources. Instead, the CloudFlare hack is based on weaknesses in two separate authentication systems. AT&T’s and Goolge Apps.
I still maintain that the only secure way to protect the reset of an authentication credential is to protect it with a second, equally strong credential. In this case, CloudFlare’s Matthew Prince was trying to do the right thing. He’d set up two factor authentication which should have required that he be involved in the password reset procedure. But it failed. The second authentication was the authentication to access his voice mail. In principle, I think that’s a valid way to manage a password reset procedure. But if the voicemail system itself has been hijacked, all bets are off.
So I stick to my guns on the protect a password reset procedure with an authentication system that’s equally secure and equally strong. But the CloudFlare hack has added a a corollary now that says, “make sure these secondary authentication systems actually work and are being used.”
