Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

6/4/2012
05:21 PM
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Google Apps Security Beat By CloudFlare Hackers

Google's Gmail password recovery routine allowed two-factor authentication to be bypassed.

New Chromebook: A Visual Tour
New Chromebook: A Visual Tour
(click image for larger view and for slideshow)
CloudFlare describes itself as a service that protects and accelerates any website, but even a company focused on security can be hacked. Last week, the company and its customer 4Chan, the infamous message board, was attacked by hacking group UGNazi.

While the hack was in place, visitors to 4Chan were redirected to a UGNazi Twitter account. The FBI last week reportedly arrested a hacker known as Cosmo, said to be the leader of the group, for the group's alleged involvement in the breach of billing company WHMCS last month.

One of the hacking group's Twitter accounts offers this response: "You can't arrest an idea." In a statement posted to Pastebin, UGNazi said 4Chan had been attacked for failing to adequately police pedophile content and discussions.

CloudFlare has decided to disclose as many details of the incident as possible to make its customers and the Internet community aware of potential vulnerabilities, CEO Matthew Prince said in a phone interview. He declined to comment on whether his company is working with law enforcement to investigate the attack, but given that UGNazi already has the attention of the FBI, such cooperation can be assumed.

On Friday, Prince published details of the attack. The incident is particularly troubling because the hacker managed to bypass two-factor authentication on CloudFlare's Google Apps For Business account through a flaw in the account recovery process.

Two-factor authentication for Google Apps requires that a user logs in with a password and also with a special access code, generated by a mobile phone app, or obtained from a pre-generated list. But the account recovery process for Google Apps omitted the access code requirement in certain circumstances.

"If an administrator account that was configured to send password reset instructions to a registered secondary email address was successfully recovered, 2-step verification would have been disabled in the process," a Google spokesperson explained in an emailed statement. "This could have led to abuse if their secondary email account was compromised through some other means. We resolved the issue last week to prevent further abuse."

[ Read 5 Flame Security Lessons For SMBs. ]

The secondary email account that was compromised happened to be Prince's personal Gmail account. Prince said that when CloudFlare established its Google Apps email address, he listed his own personal email address as a recovery address for CloudFlare Google Apps account. This allowed the hacker to abuse Google's password recovery process to have password reset information sent to Prince's personal account.

With the password reset information, the hacker was able to access CloudFlare's Google Apps administrative panel to initiate a separate password reset request for 4Chan's CloudFlare account. The hacker then changed the DNS settings for the 4Chan website, temporarily redirecting visitors to a UGNazi Twitter account.

Prince said that no other CloudFlare customers have been affected, though a review of the compromised email accounts revealed the presence of a number of customers' CloudFlare API keys. These keys have been changed to prevent abuse, which will require customers using software that requires an API key, like the CloudFlare WordPress plugin, to enter a new API key.

None of this would have happened had the hacker not first gained access to Prince's personal Gmail account, where the CloudFlare Google Apps account's password reset information was sent. Prince on Monday said that as a result of working with Google to investigate the incident, he now believes that the hacker compromised AT&T's voicemail system--either through social engineering or an undisclosed vulnerability--and redirected calls to his number to a new voicemail box. This allowed the hacker to obtain the Gmail account recovery code sent to the hacked voicemail box.

"The upshot is that if an attacker knows your phone number and your phone number is listed as a possible recovery method for your Google account then, at best, your Google account may only be as secure as your voicemail PIN," he wrote. "In this case, we believe AT&T was compromised, potentially through social engineering of their support staff, allowing the hacker to bypass even the security of the PIN."

Prince became aware that his personal Gmail account had been compromised within minutes of the unauthorized access. The hacker gained access to his account about 11:39am PT on Friday and two minutes later Prince received an email in his linked CloudFlare account stating that the password of his personal Gmail account had been reset. Thereafter, Prince and the hacker battled for control of the account, each trying to reset the account password. This happened 10 times in the space of 15 minutes, according to Prince, until the hacker succeeded in removing Prince's mobile phone and email address from the account recovery process.

Prince suggests that Google should consider adding additional controls to limit the removal of recovery email addresses following password resets. At the same time, he stresses that Google's security team was responsive and attentive to the incident and deserves praise for its handling of the situation.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
GR8Day
50%
50%
GR8Day,
User Rank: Apprentice
6/6/2012 | 12:39:38 PM
re: Google Apps Security Beat By CloudFlare Hackers
I understand your thought but when I am at home I don't want to do this every single time, so I have designated smartphone, Home PC as a trusted device and that allows me to enter without the text code. So using my land line to receive the one-time PIN is kind of stupid. When I need to receive the code is when I am not at home, thus the idea of sending it to my mobile phone. That and my mobile phone is more secure than my cordless phone which is my land line. But as you stated, activating the two-Factor Authentication technology where you can telesign into your account by entering a one-time PIN code, is a Gǣprerequisite to any system that wants to promote itself as being secureGǥ, and is worth the time it takes to set it up and have the confidence that your account won't get hacked and your personal information isn't up for grabs.
TextPower
50%
50%
TextPower,
User Rank: Strategist
6/5/2012 | 5:56:41 PM
re: Google Apps Security Beat By CloudFlare Hackers
Two-factor authentication (2FA) is, at this point, a prerequisite to any system that wants to promote itself as being secure. However, 2FA systems can be violated if not properly designed.

The flaw in many 2FA systems is that the information G whether by voice or SMS G to validate an account is frequently sent *to* the userGs mobile number. This is a fundamental error because of the very problems illustrated in the article (e.g., calls being forwarded) and the possibility of the mobile having been cloned.

A 2FA system that reverses the process is inherently more secure than any other system available. A system designed so that the verification code is shown in open text on the web page *instead* of a field into which data (the code) can be entered is a better design. The code displayed must then be sent by the mobile that is associated with that account for verification and ONLY if that mobile (not a clone or a spoofed number G neither will work) sends the code is verification completed.

2FA systems arenGt perfect but utilizing the unique device ID of a mobile by reversing the process as described here, combined with a code and a PIN, reduces the likelihood of intrusion to an infinitesimal level.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15820
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
CVE-2020-15821
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
CVE-2020-15823
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
CVE-2020-15824
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
CVE-2020-15825
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.