There are more technical details of the attack here - <a href="https://www.timehop.com/security/technical" rel="nofollow">https://www.timehop.com/security/technical</a><p>"<i>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.</i>"<p>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.<p>Means a few things went wrong:<p>* 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).<p>* 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<p>* 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.<p>So well done to TimeHop for coming forward with such a full and clear explanation, but this was a very preventable attack.
Some thoughts:<p><i>"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."</i> - Good response! Don't try and do everything yourself. Pay someone to handle the important response stuff that you're not an expert on.<p><i>"We have no evidence that any accounts were accessed without authorization."</i> - Not so good: this just means they didn't <i>see</i> accounts being accessed. It may be more truthful to say "we have no way of knowing that someone did <i>not</i> access them."
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.<p>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.<p>Now if only we could get MFA by default on every service.
> 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.<p>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.
> 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.<p>Curious if related to the spike in "verification code" texts people have been reporting from AT&T et al, c.f. <a href="https://twitter.com/jonrog1/status/1015984756037545984" rel="nofollow">https://twitter.com/jonrog1/status/1015984756037545984</a>
You gotta appreciate the naming:<p>> 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...<p>> Some data was breached. These include names [...] numbers. This affects some 21 million of our users.<p>> To reiterate: none of your “memories” [...] were accessed.<p>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 <a href="https://www.timehop.com/security/technical" rel="nofollow">https://www.timehop.com/security/technical</a>
Is someone compiling a list of these? I'd love a spot to review everything, especially summarizing key "trends" and common attack vectors.
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.
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)...