Live data from Hacker News

An update on our security incident

blog.twitter.com

91–100 of 308 posts

Re: An update on our security incident

#91
post #4

I wish they mentioned what kind of social engineering attack it was. It could be a case study for any such incidents in the future. P.S. I feel bad for the employees who were manipulated to give away the info.

I want to know how they social engineered an employee at a 2FA-enabled company into bypassing 2FA. Was the employee able to disable 2FA for their own account? Was the employee social engineered into adding someone else's 2FA key to their account? Did the employee read a 2FA code to the attacker, and that somehow enabled all the evil things the attacker did, without any additional checks or 2FA codes? Did the attacker…

Stolen access token after 2fa had been entered.

Re: An update on our security incident

#92

Earlier quoted context omitted.

>none of the eight were Verified accounts. That just raises more questions for me! It would make sense if an attacker was trying to pull the data of some celebs/VIPs as an attempt to hopefully strike gold. But for them to do it on some non-verified account? That makes it seem like these specific individuals may have been targeted. If the attackers were just randomly picking accounts to download, I can't imagine them…

Someone pointed out that it could be targeted at activists...

That is exactly my worry the moment I saw they were not verified. Nation state could drop a grand per account and get data on 8 activists no problem.

Re: An update on our security incident

#93
post #49

> 2FA compromised This is why sending or generating a OTP, that the user types in, is not secure. The user can be tricked into handing the OTP over the phone. Even the O365 system isn't secure (because the user can be told which number to tap over the phone). The only secure authentication these days is a non-communicable possession: Yubikey or similar. This reflects *very poorly on Twitter opsec.

The issue is that even if you use a yubikey, there has to be a way to recover the account if the yubikey is lost damaged. This means that someone has to have the ability to reset the 2fa of an account, meaning that if someone can convince the support person that has that ability, they can change the 2fa.

Re: An update on our security incident

#94

Earlier quoted context omitted.

I want to know how they social engineered an employee at a 2FA-enabled company into bypassing 2FA. Was the employee able to disable 2FA for their own account? Was the employee social engineered into adding someone else's 2FA key to their account? Did the employee read a 2FA code to the attacker, and that somehow enabled all the evil things the attacker did, without any additional checks or 2FA codes? Did the attacker…

Too lazy to provide a link (sorry) but KrebsOnSecurity had some screenshots of a forum user offering up access to internal tooling. The access may have been deliberately sold, not necessarily coerced.

Here's the Krebs link, who claims to have identified the exact hacker behind it:

https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-e...

Vice Motherboard interviewed the hacker, who claims the Twitter employee was paid to hack the accounts for them:

https://www.vice.com/en_us/article/jgxd3d/twitter-insider-ac...

Re: An update on our security incident

#95

Earlier quoted context omitted.

Someone pointed out that it could be targeted at activists...

That is exactly my worry the moment I saw they were not verified. Nation state could drop a grand per account and get data on 8 activists no problem.

Not $8k right? $1k per hacked account - which would thousands + the narrow targets?

Re: An update on our security incident

#96

Earlier quoted context omitted.

That's kind of a cynical take. I parsed that statement as saying: > did the attackers see any of my private information? For the vast majority of people [who we previously mentioned were affected by this hack], we believe the answer is, no.

There is no indication that the accounts whose data was accessed were the accounts which tweeted the crypto scam. Therefore, I'm not sure that's a straightforward explanation.

They say the attackers reset passwords on the accounts. Any competent engineering team would have a complete list of those events in logs

Re: An update on our security incident

#97

How did they manipulate their employees? that's the most important part don't you think?

In an interview with the hacker by Vice Motherboard, they claimed they had an employee on the inside doing all the work, and they just paid the employee to do it:

https://www.vice.com/en_us/article/jgxd3d/twitter-insider-ac...

Re: An update on our security incident

#98
post #49

> 2FA compromised This is why sending or generating a OTP, that the user types in, is not secure. The user can be tricked into handing the OTP over the phone. Even the O365 system isn't secure (because the user can be told which number to tap over the phone). The only secure authentication these days is a non-communicable possession: Yubikey or similar. This reflects *very poorly on Twitter opsec.

This is specifically bad if that 2FA was via SMS and as the attackers are supposedly notorious for such SIM-swap attacks[1].

I'm not telling TOTP or hardware tokens are invulnerable, even SecurID was compromised[2]. But having SMS as only means of 2FA is not even trying to be secure IMO, especially in India where everything from our Unique ID to Bank Accounts are dependent upon SMS OTP.

I've been asking the Banks to implement TOTP in vain.

[1]https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-e...

[2]https://arstechnica.com/information-technology/2011/06/rsa-f...

Re: An update on our security incident

#99

>For up to eight of the Twitter accounts involved, the attackers took the additional step of downloading the account’s information through our “Your Twitter Data” tool. Yikes. Pretty much a confirmation of the speculation that the hackers would have access to Twitter DMs. Question is, which accounts? edit: For reference, here's what's included in the "Your Twitter Data" tool [0]. There's some other info that may be o…

> There is a lot speculation about the identity of these 8 accounts. We will only disclose this to the impacted accounts, however to address some of the speculation: none of the eight were Verified accounts.[0] [0]: https://twitter.com/TwitterSupport/status/128433914877449830...

I wonder how many high-profile celebrities and other people with verified public accounts also keep private duplicate ones?

Maybe that's going too far down the rabbit hole but I'm really curious now.

Re: An update on our security incident

#100

Earlier quoted context omitted.

> There is a lot speculation about the identity of these 8 accounts. We will only disclose this to the impacted accounts, however to address some of the speculation: none of the eight were Verified accounts.[0] [0]: https://twitter.com/TwitterSupport/status/128433914877449830...

>none of the eight were Verified accounts. That just raises more questions for me! It would make sense if an attacker was trying to pull the data of some celebs/VIPs as an attempt to hopefully strike gold. But for them to do it on some non-verified account? That makes it seem like these specific individuals may have been targeted. If the attackers were just randomly picking accounts to download, I can't imagine them…

This is by far the most eyebrow-raising part of the update. To take over such a large number of verified accounts and then run a download on only eight non-verified ones seems almost impossible to have been anything other than targeted.

The original idea that the bitcoin scam was a diversion starts to look more plausible in this light, but in the absence of any information about the downloaded accounts, there’s really no way to guess what their value may have been and to whom.

Alternately, to throw cold water on the above, maybe the process to kick off a download for verified accounts has extra safeguards and the eight non-verified were simply tests to try to determine why the verified downloads weren’t working.

Post reply on HN