Timehop Security Incident, July 4th, 2018 | Hacker News Reader

Timehop Security Incident, July 4th, 2018

timehop.com

75 pointsrobbiet48024 comments

There are more technical details of the attack here - https://www.timehop.com/security/technical

"On December 19, 2017 an authorized administrative user's credentials were used by an unauthorized user to log into our Cloud Computing Provider. This unauthorized user created a new administrative user account, and began conducting reconnaissance activities within our Cloud Computing Environment. For the next two days, and on one day in March, 2018, and one day in June, 2018, the unauthorized user logged in again and continued to conduct reconnaissance."

So someone logged into their Cloud Provider backend using a user/pass, created an admin account, and watched for 6 months before trying database extraction.

Means a few things went wrong:

* First, they had a guessable user/pass or, more likely, it was compromised some other way (social engineering, former employee, or it was in an email account that was itself compromised).

* Second, they had no 2FA on their cloud provider logins. Given that this login allows the creation of admin accounts, that's a pretty big oversight

* Third, they had an account with admin privileges running around for 6 months without anyone noticing. It kept its activity very limited, but a routine audit of all admin accounts would have found the new account. An alert that warned if a new admin account was created would have found it.

So well done to TimeHop for coming forward with such a full and clear explanation, but this was a very preventable attack.

Some thoughts:

"Once we recognized that there had been a data security incident, Timehop's CEO and COO contacted the Board of Directors and company technical advisors; informed federal law enforcement officials; and retained the services of a cyber security incident response company, a cyber security threat intelligence company; and a crisis communications company." - Good response! Don't try and do everything yourself. Pay someone to handle the important response stuff that you're not an expert on.

"We have no evidence that any accounts were accessed without authorization." - Not so good: this just means they didn't see accounts being accessed. It may be more truthful to say "we have no way of knowing that someone did not access them."

The "technical information" page says they contacted the social media services those keys were for, and the social media services confirmed the keys hasn't been used by anyone else.

The best part of this story is no passwords were compromised. Because Timehop deals with access tokens only, they were able to invalidate those access tokens to eliminate the risk to its users. They basically lost 21m customers by doing that, and props to them for doing the right thing.

Imagine if we still used the "enter your twitter password on our web site so we can look at your data!" anti-pattern. What a mess this would be.

Now if only we could get MFA by default on every service.

You don't need to use tokens to not have passwords leaked. Hashing has existed for a very long time.

The parent post refers to access credentials held by third parties. Password hashing is of no use here unless Twitter/Facebook/whoever implemented an API that permitted you to submit a hash of the password, which they could not do unless they didn't salt their own hashes (or publicly revealed all the salts, which is effectively the same thing).

I guess? I mean, token based auth is nothing new at this point. I think it would be more criminally negligent not to use token auth than it is a huge success story to use it.

Yeah, we are all in big trouble when Plaid or Yodlee inevitably get hacked and millions of bank passwords leak.

> The breach occurred because an access credential to our cloud computing environment was compromised. That cloud computing account had not been protected by multifactor authentication. We have now taken steps that include multifactor authentication to secure our authorization and access controls on all accounts.

Wow. Unbelievable that these companies take security for their prized assets way less seriously than I do. And I have much less at stake comparatively.

> Unbelievable that these companies take security for their prized assets way less seriously than I do.

A lot of engineering teams unfortunately see strong security as a hurdle to fast development, and/or security is put as a lower priority to feature development or other deadlines. A lot of business units see security as a cost sink and have the "there's only so much we can do to protect ourselves, if they want it they can get it" or "it won't happen to us" mentality.

On the other hand, some companies have security built deeply into their lifecycle, and really care.

What is more unbelievable is that the were able to create a new admin account on 17th December, which is the account that was used (from the tech report):

> On December 19, 2017 an authorized administrative user's credentials were used by an unauthorized user to log into our Cloud Computing Provider. This unauthorized user created a new administrative user account

They had 6 and a half months to spot this new admin account, and didn't. This is terrible security practice anyway you look at it, and in that context, their statement that "the attacker used an account without MFA" is disingenuous at best.

I think they're saying the initial compromised user didn't have MFA, not that the attacker's new account didn't.

But indeed, I almost thought this attacker was pretty competent (given the wait until the holiday) until I saw they made a completely new account and left it there for half a year.

> If you used a phone number for login, then Timehop would have had your phone number. It is recommended that you take additional security precautions with your cellular provider to ensure that your number cannot be ported.

Curious if related to the spike in "verification code" texts people have been reporting from AT&T et al, c.f. https://twitter.com/jonrog1/status/1015984756037545984

You gotta appreciate the naming:

> On July 4, 2018, Timehop experienced a network intrusion that led to a breach of some of your data. We learned of the breach while it was still in progress, and were able to interrupt it, but data was taken...

> Some data was breached. These include names [...] numbers. This affects some 21 million of our users.

> To reiterate: none of your “memories” [...] were accessed.

I don't know what TimeHop is or does, but we're not far off from when this will mean something very different.

More technical info is at https://www.timehop.com/security/technical

Is someone compiling a list of these? I'd love a spot to review everything, especially summarizing key "trends" and common attack vectors.

well there's https://haveibeenpwned.com/, but that only covers if the breach has also been leaked

Some of the recent attack vectors I can remember:

* An employee account was compromised - usually because they re-use their password and that password was exposed in an unrelated breach. And then failure to require 2 factor authentication for 'internal' accounts - (github organisations, aws, internal administration tools, etc.) - Timehop, Gentoo

* Failure to patch known vulnerabilities - Experian

* Running untrusted code client side (Webchat) - Ticketmaster (although unclear what the vulnerability was that allowed the compromised scripts to be uploaded to Inbenta)

* Unsecured database backups - Typeform (although it's unclear yet what the original compromise entailed)

* Data left 'accidentally' exposed publicly (no credentials required to access it) - Exactis

As with the Gentoo attack, it seems that proper 2FA might have prevented this from happening. Amazing that people aren't more paranoid about that.

Wow they're still around?

My dad is very proud of his 600+ day streak checking Timehop.

Please don't post unsubstantive comments or snark here.

Username + password is a huge attack vector, especially for services where users signup and eventually stop using or forget. I wish there was some obligation to reset password or require some form of MFA for applications that experience no usage on my account (especially if the service typically encourages continuous usage)...

What does this have to do with this attack? Timehop does not store any passwords, just access tokens.

Reply on news.ycombinator.com