Formulating and managing online identity and access control
A comprehensive collection of articles, videos and more, hand-picked by our editors
Many information security professionals believe that if a sophisticated fraudster chooses to target a high-value person within an organization as part of a spear phishing attack -- given today's security controls, processes and security awareness of how attacks occur -- the fraudster will succeed.
No matter how strong a password is … if a company has a weak password-reset process, hackers can compromise the system.
Unfortunately for CloudFlare Inc.'s CEO, this proved true. To briefly recap, CloudFlare uses Google Inc.'s Gmail accounts to get to Google Apps to manage customer data for CloudFlare's offerings. Through a series of preplanned actions, a fraudster gained control of the CEO's account to initiate the attack and successfully gained access to the information of one of CloudFlare’s customers. Without question, it was a worst-case scenario for any organization.
So how did this happen with security controls like two-factor authentication and strong passwords on email accounts in place, and the services of one of the largest cloud service providers in the world protecting this data? It all boils down to a few key mistakes in the user account security and password recovery processes. In this tip, we'll break down the attacker's steps and what might have been done to protect the data.
User account security: Mistakes and best practices
The fraudster's first step was to obtain the CEO's Gmail account information; this allowed him or her to gain control of not only his email, but also his Google Apps tools, simply by logging in. Apparently the CEO in question only had a single email address that was used for external communication as well as for accessing the Google Apps account. Because most corporate websites give the name of their executives on company websites, and since most organizations use an email address associated with an individual's name (i.e., firstname.lastname@example.org or email@example.com), sending out a few phishing emails addressed to variants of the executive's name is sufficient to determine his or her email address. That starts the process of gaining control of the account.
Listen to this as an MP3
Listen to How diligent user account security thwarts password recovery attacks as an MP3 here!
Spear phishing to identify email account names like this can be prevented through two actions. Since all enterprise messaging systems have "white pages" or directories of some sort, they don't require internal workers to know each other's email addresses. Thus a better security control is to use an email address that is not closely tied to the actual user's name. For example, using the worker's initials followed by four or five random numbers (i.e., firstname.lastname@example.org) would be nearly impossible to spear phish. For systems that use email addresses as credentials to access business data, like Google Apps, the second way to ensure a fraudster doesn't gain access is to use one email account for general email to the outside world, and a second, separate email account (or more) only for access to sensitive applications and data. Even in a cloud environment, having an email account name not associated with a person will prevent an outsider from discovering (and possibly compromising) the account. In the CloudFlare case, having an email account such as email@example.com and a separate account such as firstname.lastname@example.org for Google Apps access would have made it impossible for the fraudster to associate the Gmail account with the CEO.
How password recovery can go wrong
Once the fraudster figured out the CloudFlare CEO's Gmail account name, he contacted Google's customer support line to initiate a password reset. After weeks of attempts, the fraudster was able to convince Google's account-recovery system to add a fraudulent recovery email address that allowed the hacker to change the CEO's Gmail password and gain access to the account.
From the editors: More on user account security
Randall Gamby comments on separation of duties for internal user account controls.
No matter how strong a password is (in this case 20+ characters long, and highly random), if a company has a weak password-reset process, hackers can compromise the system merely by obtaining a user's personal details, bypassing the need to crack a strong password by simply getting it changed. For example, asking a single, easy-to-guess question to reset an account password is paramount to opening the account up to the public. With Facebook, LinkedIn and other casual and professional social media sites storing large amounts of personal data, employees must assume that most of the major attributes of their life stories are now available to the general public. Favorite pets, high school names, mother's maiden names and often much more for a large population of Internet users can be easily found online. This means that stronger means of identification, such as two-factor authentication or biometrics, will be required to protect changing Internet-facing account fields as companies expose more back-end business systems to the Internet or, as in the case with CloudFlare, use cloud services.
For most Internet-facing attacks, following these simple steps would mean the end of the story. But in the case of CloudFlare, the CEO's account was protected with two-factor authentication. This only goes to show that the fraudster was sophisticated, clever and determined. In order to reset the CEO's Gmail account, the fraudster had to have an electronic PIN number that was sent to the CEO's AT&T mobile account.
The attacker even found a way to surmount this challenge. According to incident investigators, the attacker is believed to have called AT&T and impersonated the CEO. While the attacker was unable to answer the CEO's account-verification security question, he was able to provide the customer support agent with the last four digits of the CEO's Social Security number. But, because the account was a corporate account, it should not have been linked to the CEO's SSN. This allowed the fraudster to have the CEO's voicemail redirected to a telephone number the fraudster controlled. Again by using personal information to gain access to an account -- in this case the CEO's mobile carrier -- the fraudster attacked the weakest link in the password-reset process. This shows the attacker's deeply rooted understanding of how the Google password-reset process works. In the wake of this event, AT&T and Google have changed their verification processes to hopefully make them more bulletproof.
The takeaway from these insights is the realization that fraudsters will go to extremes to break into high-value accounts. The common perception that a 16-year-old misdirected genius sitting in his mom and dad’s basement perpetuates such attacks is outdated. From this, and other recent online fraud events, it's obvious that there are counterculture organizations with the capabilities and means to perform well-thought-out, planned attacks on corporate America.
As companies architect their Internet authentication schemes, they must realize that the authentication process may extend beyond their control to their business partners and suppliers. How cloud partners, Internet providers, mobile ISPs and others manage and maintain password reset, account management and financial payment processes must be fully understood and weaknesses identified and corrected.
The good news from this incident is that Google and AT&T fully cooperated with CloudFlare as it investigated the attack, but even these large companies were unaware of their process flaws until CloudFlare approached them. Only by thinking of identity and access control as a complete ecosystem from the user to the Internet to the cloud, and beyond, can weaknesses be identified. Unfortunately, CloudFlare now understands the level of effort a fraudster will make to gain access to an account they want to infiltrate. The question is, does your company have a grasp on what the fraudsters will do to get to your data?
About the author:
Randall Gamby is the information security officer for the Medicaid Information Service Center of New York (MISCNY). MISCNY manages and maintains the largest state-run Medicaid claims data warehouse in the United States. Prior to this position he was the enterprise security architect for a Fortune 500 insurance and finance company. His experience also includes many years as an analyst for the Burton Group's security and risk management services group. He is a member of SearchSecurity.com's Ask the Expert panel, answering members' questions on enterprise identity and access management.