
Timehop Security Incident, July 4th, 2018 - robbiet480
https://www.timehop.com/security
======
ariehkovler
There are more technical details of the attack here -
[https://www.timehop.com/security/technical](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.

------
peterwwillis
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."

~~~
haldean
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.

------
madrox
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.

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

~~~
torstenvl
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).

------
Yhippa
> 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.

~~~
mdekkers
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.

~~~
iancarroll
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.

------
lwf
> 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](https://twitter.com/jonrog1/status/1015984756037545984)

------
karmakaze
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.

------
robbiet480
More technical info is at
[https://www.timehop.com/security/technical](https://www.timehop.com/security/technical)

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

~~~
snowwolf
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

------
cal5k
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.

------
dawhizkid
Wow they're still around?

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

------
charleyma
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)...

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

