How did the TimeHop data breach happen?

Compromise of an employee's credentials, lack of multi-factor authentication, and weak insider threat analysis all played a factor in the recent TimeHop data breach in which 21 million user accounts were compromised.

TimeHop data breach
Thinkstock

In July 2018, TimeHop, in a very transparent manner, discussed the breach of their service which affected approximately 21 million records, some of which included personal identifying information (PII) such as name, email, phone number, and date of birth, while others contained variants.

Reviewing the sequence of events, we see that a trusted insider placed the company’s data at risk when their employee credentials were used by a third-party to log into TimeHop’s Cloud Computing Environment. 

How the intruder obtained the employee’s log-in credentials is unknown.

What is known is that the protocol to access the TimeHop cloud environment apparently did not require additional authentication (MFA) and that the compromised employee’s access was sufficient to create additional user accounts with administrative access.

Timeline of the data breach

The intruder, over the course of three days in mid-December 2017, created accounts with attendant API access keys and tested the API while conducting reconnaissance of the environment.

The intruder stepped away, knowing they now had access to TimeHop via the compromised employee’s credentials and the account created uniquely for the intruder.

In late March and early April 2018, the intruder returned and conducted additional reconnaissance and noted the existence of an unpopulated user data database created by the compromised employee.

Time passes, and in late June 2018, the intruder discovered during another entry into the network that the previously created database was now populated with PII.

On July 4, 2018, the intruder returned and began harvesting the database, using internal commands to collect and collate the information. TimeHop notes in their explanation of the events that the intruder was “continually checking alarms and monitors” and over the course of about 45 minutes, the information was captured by the intruder.

About 2.5 hours after the intruder’s positive action, the TimeHop engineers discovered that the database is outside the firewall, protected only by a password. 

The next day, July 5, the intruder inexplicably returned, using the compromised employee’s credentials and listed the Cloud Computing Environment users and then logged out.

Timehop’s overview of the breach includes a compromised data table, which is provided below for clarity.

timhop data breach TimeHop

We still don’t know how the employee’s credentials were obtained. 

Threat Stack’s senior infrastructure security engineer, Pat Cable, offered the following observations:

“TimeHop’s breach is an example of the security risk that employees, both current and former, can pose to any organization with poor cloud security hygiene. Many security incidents are going to involve some form of credential theft — so it’s important for IT staff and engineers to understand not only where data is stored but who is accessing and exporting it. Businesses issue thousands of credentials to employees and contractors making it more important than ever for them to improve access management by setting up systems for temporary credential generation and multi-factor authentication.”

Cybersecurity 101

The bottom line, as noted by Cable, insiders can facilitate compromise of customer data through negligence and lack of good cyber practices. It is taught in Cyber 101 that credentials and multifactor authentication need to be unique to each instance. 

Similarly, checks and balances need to be in place when creating databases that contain customer data. It’s one thing to lose company data; it’s a different kettle of fish to lose one’s customer’s data. The compromise affected most of the users of the TimeHop service; the creation of the database that contained this data apparently did not have a second set of eyes review the creation and configuration. 

Additionally, a question concerning time and place of access of the intruder needs to be delved into more thoroughly in the company's after-action review. TimeHop determined the user as logging in as their employee from the Netherlands. Was the compromised employee located in the Netherlands? Did TimeHop have a point of presence in the Netherlands. Did the location, the Netherlands, set off an anomaly alarm?

Anomalous activity within the network identified by the collection and collation of disparate datasets is what gives the information security teams a fighting chance when a user’s credentials are being used by an unauthorized third party.

In this instance, the trusted insider’s only offense was their credentials had been harvested and exploited. The damage, however, remains significant, even if unintentional.

SUBSCRIBE! Get the best of CSO delivered to your email inbox.