5 ms·

Timehop Security Incident, July 4th, 2018

75 points by robbiet480 8y ago

dawhizkid 8y ago
Wow they're still around?
- robbiet480 8y ago
  My dad is very proud of his 600+ day streak checking Timehop.
- dang 8y ago
  Please don't post unsubstantive comments or snark here.
charleyma 8y ago
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 8y ago
  What does this have to do with this attack? Timehop does not store any passwords, just access tokens.
robbiet480 8y ago
More technical info is at https://www.timehop.com/security/technical https://www.timehop.com/security/technical
madrox 8y ago
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 8y ago
  You don't need to use tokens to not have passwords leaked. Hashing has existed for a very long time.
  - deleted 8y ago
    [deleted]
  - torstenvl 8y ago
    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).
- cheeze 8y ago
  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.
  - tehwebguy 8y ago
    Yeah, we are all in big trouble when Plaid or Yodlee inevitably get hacked and millions of bank passwords leak.
peterwwillis 8y ago
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 8y ago
  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.
cal5k 8y ago
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.
Yhippa 8y ago
> 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.
- micaksica 8y ago
  > 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.
- mdekkers 8y ago
  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 8y ago
    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.
yRetsyM 8y ago
Is someone compiling a list of these? I'd love a spot to review everything, especially summarizing key "trends" and common attack vectors.
- fowl2 8y ago
  well there's https://haveibeenpwned.com/ https://haveibeenpwned.com/, but that only covers if the breach has also been leaked
- snowwolf 8y ago
  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
lwf 8y ago
> 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
ariehkovler 8y ago
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.
karmakaze 8y ago
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.

75 points by robbiet480 8y ago

dawhizkid 8y ago

Wow they're still around?

robbiet480 8y ago
My dad is very proud of his 600+ day streak checking Timehop.
dang 8y ago
Please don't post unsubstantive comments or snark here.

charleyma 8y ago

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 8y ago
What does this have to do with this attack? Timehop does not store any passwords, just access tokens.

robbiet480 8y ago

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

madrox 8y ago

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 8y ago
You don't need to use tokens to not have passwords leaked. Hashing has existed for a very long time.
- deleted 8y ago
  [deleted]
- torstenvl 8y ago
  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).
cheeze 8y ago
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.
- tehwebguy 8y ago
  Yeah, we are all in big trouble when Plaid or Yodlee inevitably get hacked and millions of bank passwords leak.

peterwwillis 8y ago

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 8y ago
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.

cal5k 8y ago

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.

Yhippa 8y ago

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

micaksica 8y ago
> 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.
mdekkers 8y ago
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 8y ago
  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.

yRetsyM 8y ago

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

fowl2 8y ago
well there's https://haveibeenpwned.com/ https://haveibeenpwned.com/, but that only covers if the breach has also been leaked
snowwolf 8y ago
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

lwf 8y ago

> 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

ariehkovler 8y ago

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.

karmakaze 8y ago

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.