Cloudflare Attack Post Mortem; Apparent Google Apps/Gmail Vulnerability
blog.cloudflare.com
blog.cloudflare.com
tl;dr; Hacker used social engineering to add a secondary recovery email address to the victims Google account.
2-factor wasn't even enabled on the victims personal account but the hacker didn't need a 2-factor code to reset the password on the victims company account.
From the article:
Google reports that they discovered a "subtle flaw affecting not 2-step verification itself, but the account recovery flow for some accounts. We've now blocked that attack vector to prevent further abuse."
Don't commingle business and personal accounts.
This is a security bug that was exploited. It should not be possible to reset a password without the 2-factor auth code, period. If that is possible, then that the 2 factor auth is broken.
-disclaimer: I am the founder of Authy.com.
Boy, its nice they get that privilege. I love gmail, but god help me the day I lose access to my account- I can only imagine the support whack-a-mole us mortals would have to go through to get any resolution.
Anyone remember the "thomas monopoly" story from a while back where gmail disabled the guy for weeks with no comment and the dude had to contact every person in the world to get someone to look at it? (And then they reinstated his account)
They got great support, because they have a name. Any normal Gmail user would receive five automated reply emails from Goog, at most.
I'd love to move my email somewhere else, but there is not really any alternative.
"We have senior contacts at Google who we worked with"
Saying "senior contacts" seems to indicate that they have specific high level people that they personally know who were able to escalate beyond what the response would be for a typical user.
And yes, realistically, a larger service like CloudFlare is going to get more attention than any individual. It might seem unfair to the individual, but overall, it's in everyone's interest when a situation like this arises.
Unfortunately, there really isn't a great alternative. The next best thing I've found is to just run your own mail server, which is pretty obnoxious if you have any non-technical users to support. Kerio is the thing which most Mac shops I know use (since people want directory services and the other stuff you can't easily implement just from open source). Yet, there's better search on server on gmail than from iOS to IMAP (i.e. Kerio), so that's a sacrifice.
I kind of hate Google for being the Craigslist of email -- a crappy product at $50/yr which sets the maximum price people are willing to pay below the point where anyone can offer a less crappy product. More like $250-$500/yr/mailbox would be a supportable price for real email.
For me, the answer to what justifies a cost for email is deliverability. Of course, having recipients receive your email promptly, and receiving theirs promptly. But more importantly, receiving next to zero spam in my actual inbox, and misclassifying absolutely zero ham in my spam folder.
The only solution I've found that accomplishes this at any price is GMail / Google Apps.
Not only does it easily keep 12 - 18 year old email addresses that have been on usenet spam free, it happily handled over 3000 spam per second per box while letting through valid emails for sex.com. The owners could actually use their addresses on Google Apps. They hadn't been able to on email systems costing 4 and even 5 figures. Refreshing the spam label while seeing the inbox stay empty, day after day and month after month, was astonishing.
It's a slow UI (I often see 20-30 second page loading times on a fast network, over SSL), the support on the free tier is horrible (i.e. non-existent), the $50/user/yr support is below what I'd want for a company to rely on it (it's ok as second or third tier support for your in-house people, I guess, but not great frontline support for non-technical users when traveling).
The real killer, though, is lack of the enhanced features Exchange offers for directory, scheduling, etc. I always hated people who depended on those kind of things, but once I started using them, it made life annoying to not have them. Google Calendar and Google Contacts are feature-incomplete and often buggy (syncing to devices, other than maybe Android phones), especially when you have multiple calendars, sharing, etc.
It's all fine for individual users, but for a group of 5-25+ people (startup, pe fund, etc.), using google apps often sucks.
1: You can remove 2 factor auth without having to enter the auth code. So if your computer gets a virus, someone can just remove 2 factor auth via your browser
2: The "app specific passwords" are full on backdoors. If one of your app specific passwords gets hijacked, someone can login to your gmail with it and then remove the 2 factor auth pass (See above)
* http://productforums.google.com/forum/#!category-topic/mobil...
Google does want people to use OAuth instead of app-specific passwords as much as possible, but sometimes that's not possible or just isn't done. Then you at least get some security from not posting the same password to a million places.
Real security against compromise of the device you're using to access a service, whether the 2nd factor is a hardware token or generated from a seed stored on an android/ios device, would require making every significant action, not just logins, re-prompt for a token. I haven't seen many systems that do that, because it harms usability.
I'm not disputing that there are cases where RSA tokens or other hardware solutions make sense, but the physical burden of more than a few hardware tokens would be too much for normal people, even if cost were no object. 2-factor totp/hotp oath auth is far better than 1-factor auth, and presents minimal annoyance to people who already have their smartphone with them 24/7. It can be deployed on every saas website with minimal additional burden to users.
A compromised android/ios device that you use to login to services is, as outlined above, pretty close to game over even if you have a separate hardware token. An attacker may not be able to maintain access, but the account information and various settings can be compromised in an instant. 2-factor of any sort pretty much solves the password reuse problem, and also the problem with individual service passwords getting compromised somehow in a way other than an ongoing compromise of the user's machine(s).
That's quite the attack.
Stupid internet drama indeed.
I really hate the recovery options. I don't know what they are there. If I forgot my password, my recovery e-mail, I don't want to answer questions to be sure it was me. Who knows how this exactly worked, but it sure seems to be a problem with that logic.
all CloudFlare.com accounts use two-factor authentication. We are still working with Google to understand how the hacker was able to reset the password without providing a valid two-factor authentication token.
The other issue, that seemed to be glossed over, was that they were BCCing password reset emails to a compromisable account for support/debugging purposes. I understand the desire to be aware of fradulent submissions early, but we, as an industry, should be treating password reset emails (and tokens) like passwords. Do not store them in plain text.
I appreciate CloudFlare's transparency on this, but feel they missed an opportunity to address a flaw that probably exists in a large number of other apps.
Since they were using their own domain name, that's likely what they were on.
Nobody is necessarily lying.
Domain Name: UGNAZI.COM
Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Name Server: LEE.NS.CLOUDFLARE.COM
Name Server: RUTH.NS.CLOUDFLARE.COM
Status: clientTransferProhibited
Updated Date: 29-may-2012
Creation Date: 22-jan-2012
Expiration Date: 22-jan-2013Dozens, if not hundreds, of hacker and malware related sites use Cloudflare to mask their origin and essentially use the other shared sites as hostages. If you block one of the malicious sites then you also end up blocking legitimate sites, and since Cloudflare goes out of their way to not take down sites (even those hosting malicious programs- including the drive by exploits that install them) it makes it very difficult to trace the malware back to it's source or actually take it down and stop people from getting infected.
Then it becomes trivial to block a single IP, since it is assigned to a single customer you won't have any collateral damage!
If you do happen to have a report then please feel free to actually send it our way with specific details.
In fact, we respond to every single report that we receive.
I find it a bit strange to lump a hosting provider together with terrorists accomplices.
News report about CloudFare and Lulzsec: http://www.it-networks.org/2012/03/01/how-cloudflare-kept-lu...
Because your saying that you "observe" that a company who supported a certain group of hackers, got hacked back by someone we don't even know (maybe UGNazi, but who knows for sure). And then you look at it as if it was "funny" saying something like "see, no honor between thieves".
But... there's no point. Yeah because they got hacked like any other company could have been to get access to some of their clients data. And it's not like if what they did for LulzSec was to protect themselves of those sort of attacks. It's totally unrealistic to think that just by "helping" a group of hacker they would be totally immune against attacks from other groups. Imagine if Google also had helped a pair of hackers guys, would you except that the others hackers, decide, for honor, to not attack Gmail anymore ?
[1]: http://www.codinghorror.com/blog/2012/04/make-your-email-hac...