Lessons from the Yahoo Hack

 
 

yahoo hack email security

Earlier this year, the U.S. Department of Justice indicted four Russian citizens for carrying out cyberattacks against Yahoo for the purposes of espionage and fraud. The indictment provides an interesting glimpse into how it took only a few attackers to breach one of the top web service providers, compromising an estimated one billion user accounts. What’s more, the vulnerabilities identified and exploited in the incident are not unique to Yahoo—other webmail providers like Gmail and Outlook share the same fundamental weaknesses. Therefore, understanding what happened may help other organizations improve their own email security practices.

Laying the Groundwork

The Yahoo indictment named four Russian nationals—two officers from Russia’s Federal Security Service (FSB), the successor organization to the KGB, and two hackers who were directed and paid by the FSB agents. The alleged goals of the attack were to gain access to the email accounts of a wide range of individuals, including Russian journalists, U.S. and Russian government officials, and employees of email, document storage and security providers. The hackers also made money through fraudulent use of credit card information accessed in the breach.

The attackers penetrated Yahoo’s systems from 2014 to 2016, likely through spear-phishing attacks in at least some instances. In such an attack, a user with access to Yahoo’s internal network receives what appears to be a legitimate message that invites them to click on a link, which then secretly installs malware on their computer. Presumably, the compromised computers ultimately provided the attackers with access to the Yahoo network.

Once into Yahoo’s network, they could retrieve technical information on the security systems. They copied the User Data Base (UDB), a centralized database of user information, and accessed Yahoo’s Account Management Tool (AMT), a program that manages user accounts. These ultimately allowed the attackers to spy on their targets.

Exploiting the Vulnerabilities

It is interesting to note that the attackers did not pursue the victims directly. Instead, they chose to target Yahoo cloud servers in order to penetrate their victims’ accounts since that was an easier and more damaging way to gain access to centralized information and systems. The attackers were able to take advantage of a number of weaknesses in Yahoo’s system:

Centralized storage of sensitive account information: The Yahoo UDB is a centralized database of all users’ account information that was stored on Yahoo’s servers. While passwords were encrypted, a lot of other personal information was not, including password challenge questions and answers. It was this other information that allowed the attackers to navigate Yahoo’s databases to find and compromise their targets.

It also included alternate email addresses that Yahoo could use to reach users. As these were often company email addresses, once the attackers had a copy of the UDB, they could search for the domain names of the companies where their targets worked. Sometimes the alternate email addresses included family members, who could also connect the attackers to their targets by association. Password challenge and response questions provided helpful hints in penetrating not only Yahoo, but other systems as well.

Centralized access tokens: In computing, a “nonce” is a number that is used only once to identify a unique element. When a user logs in to Yahoo, for example, the server sends the user’s browser a token based on a nonce, which is then stored locally on the browser.  The corresponding nonce is stored in the UDB. When a user connects to Yahoo later, their token is sent to the server and, if the token is consistent with the nonce in the UDB, the user does not have to log in again.

Using the nonce information stored in the UDB, the attackers were able to “mint” their own nonces, allowing them to access user data without having to log in with a password. Once they gained access to an account, they could read a user’s emails and any other personal information stored in the accounts. The attackers merely had to search an account for words like “password” or “MasterCard” in order to gain access to other email accounts or steal money, for example.

Administrator access: Almost every software system allows for privileged administrative accounts, which trusted individuals such as information technology administrators use to control the system. This kind of access can be very dangerous because administrative rights could let a hacker compromise the entire system.

In the Yahoo case, the attackers got into Yahoo’s centralized administrative program, the Account Management Tool. This allowed them to reset a user’s password and then, using a minted nonce, connect to Yahoo and change it, thus taking control of the user’s account.

Unencrypted user data: Web-based mail systems like Yahoo or Gmail can all access user data. This data is often “encrypted at rest,” which means that user messages are encrypted when they are stored on the server.

“Encryption at rest” is often misinterpreted as secure. In reality, email providers decrypt messages to scan them for advertising and searchability, and when users access their accounts. A hacker who has compromised the server can therefore “see” user messages as they are accessed. The indictment did not suggest that this happened in the Yahoo breach, but it cannot be ruled out either.

Logs: Yahoo maintains logs of activity that identify which users connected, what time they logged on and what messages they sent and received. As the attackers went about their business navigating the internal Yahoo systems, copying the UDB and running the AMT, logs were capturing their activities. A clever system manager might have inspected these logs and determined that Yahoo was under attack, but this did not happen for almost two years because the attackers removed their electronic footprints using a “log cleaner” program.

Passwords: Passwords are intended to serve as a security measure but, in reality, are a common source of vulnerability. Email providers assume that security is maintained by encrypting user passwords, but the Yahoo breach shows how even encrypted passwords can be compromised.

Once the hackers reset user passwords, they could not only access Yahoo messages, but log in to other accounts as well. In some cases, for example, Yahoo was the “recovery” email account for a Gmail account. Keep in mind that the attackers had also stolen password challenge questions and responses contained in the UDB and, presumably, many of the answers to these questions were common among a user’s multiple accounts.

Armed with this information, the attackers then penetrated certain Gmail accounts by logging in, answering the challenge questions, and responding to a confirmation email sent to the now-compromised Yahoo recovery account. Even though the Google and Yahoo passwords themselves were never revealed, the operations around them were compromised, and so the accounts were breached.

Improving Email Security

Email was designed decades ago, when security was not a high priority. As email moved to the web, security improved, but most web-based email systems still have huge vulnerabilities that, as the Yahoo incident shows, can be exploited by hackers.

Many of today’s email services simply do not provide adequate security. In order to better protect data, system developers need to assume the server will be compromised. Such systems use end-to-end encryption with no central points of attack to protect user data even when the server is breached. Some new mobile chat applications, such as WhatsApp, now use end-to-end encryption, as do many of the next-generation email and file-sharing apps that are coming to market. As these new email services are more widely deployed and adapted, vulnerabilities like those used to hack Yahoo may finally be neutralized.

 
Randy Battat

More articles by »

About the Author

Randy Battat is founder, president and CEO at PreVeil, an email security provider.

 
 
 

Leave a reply

required

required

optional