An update on our security incident • Hacker News Board

Re: An update on our security incident

#71

Post by AnonC » Fri, Jul 31, 2020, 5:57 AM UTC

iKevinShah wrote: post #66

Sorry if I am taking this on a tanget, but in one of the HN threads regarding this exact security incident, it was recommended that this is why something called as "Blast Radius" needs to be implemented. Anyone here with any literature / sessions one could go through for a good gist of things with respect to Blast Radius?

I did a quick search on Algolia for HN (hn.algolia.com) and found several comments in this thread and threads related to the recent Cloudflare incident. This could be a starting point in your quest. [1] I don’t have a blog post or article or documentation though.

[1]: https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...

Re: An update on our security incident

#72

Post by berkes » Fri, Jul 31, 2020, 6:05 AM UTC

fareesh wrote: post #44

zamalek wrote: post #29

Earlier quoted context omitted.

I haven't seen a form of phishing that hardware 2FA doesn't stop. Yes, it would have.

The way it is worded can also mean that there were XSS vulnerabilities in the internal tool since they are saying "gained information about how our processes work". I feel like that's a strange and vague thing to say. The right kind of xss vulnerability would enable them to bypass 2fa too, maybe steal backup codes even.

I understood that line as 'saw names, contact detail, positions and permissions of employees'

Re: An update on our security incident

#73

Post by cmelbye » Fri, Jul 31, 2020, 6:09 AM UTC

spullara wrote: post #63

andrew_ wrote: post #36

Earlier quoted context omitted.

I'd like to know more about these tools. That there's at least one which can bypass a user's 2FA settings without notification suggests that there are additional tools in the same vein.

Every network has to have tools to do that. How else will they enforce the laws they are required to enforce?

Those legal requests aren’t serviced with a password reset in order to log into the account. It seems more likely that there’s an internal tool to help people who have lost their second factor, but that’s just a guess.

Re: An update on our security incident

#74

Post by praveen9920 » Fri, Jul 31, 2020, 6:10 AM UTC

> We will be slower to respond to account support needs

So, they limited the account support access to smaller trusted team. This I can understand but it might also cause the delay in identifying such attack, if it happens today.

Re: An update on our security incident

#75

Post by ngomez » Fri, Jul 31, 2020, 6:10 AM UTC

thdrdt wrote: post #56

iamleppert wrote: post #11

They should require hardware security devices (dongles). Really Twitter should be ashamed of their poor internal security.

It depends on the attack. For example if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data. But yes. As far as I know Google and Facebook require them. Also Google sometimes require permission of an other co-worker to access data.

>if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data

It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.

I would hope Twitter already had this kind of setup, but their blog posts about this are all targeted at a more general audience, so I doubt we'll get that kind of detail anytime soon.

Re: An update on our security incident

#76

Post by sudhirj » Fri, Jul 31, 2020, 6:10 AM UTC

iKevinShah wrote: post #65

_8j50 wrote: post #40

As someone who works to stop these, the most frustrating part is how even infosec people thik enough training or $vendor's email security solution will stop this. It's like boy scouts that think they will stop navy seals. There is too much focus on entry point of an attack,especially by news media.

Hey, Any good literature which you'd recommend to read to avoid something like this?

I keep trying to read and understand the attacks that have all happened so far... after you understand the vectors that are currently in use, hopefully it'll stoke your imagination to see how you might attack other systems and make up new vectors. All the current attack write-ups will usually link to vulnerabilities as well. See HackerOne disclosures, Google Project Zero or the "How I hacked X" disclosures you see on HN.

I don't think published textbooks are very useful — attackers also have access to them, and if the attack has been written down it'll likely be encoded into a firewall software or security process rulebook already (though it might still work for smaller companies lagging behind on the curve).

Re: An update on our security incident

#77

Post by [deleted] » Fri, Jul 31, 2020, 6:12 AM UTC

spullara wrote: post #63

andrew_ wrote: post #36

Earlier quoted context omitted.

I'd like to know more about these tools. That there's at least one which can bypass a user's 2FA settings without notification suggests that there are additional tools in the same vein.

Every network has to have tools to do that. How else will they enforce the laws they are required to enforce?

[deleted]

Re: An update on our security incident

#78

Post by [deleted] » Fri, Jul 31, 2020, 6:14 AM UTC

ehsankia wrote: post #23

0xUser wrote: post #5

Source (with more details): https://blog.twitter.com/en_us/topics/company/2020/an-update... > The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all o…

Were the spear fishing attacked also used to get 2FA, or did these accounts not have 2FA? Would hardware based 2FA not have stopped this?

[deleted]

Re: An update on our security incident

#79

Post by vaxman » Fri, Jul 31, 2020, 6:16 AM UTC

djsumdog wrote: post #51

dboreham wrote: post #2

No employee should have the power to subvert 130 high value accounts in a short time period.

Why do we even have 'high value' accounts on a centralized platform? Why isn't there a whitehouse.gov ActivityPub instance that no single admin can censor or subvert?

This. Just as surely as email, texts and tweets are now admissible in contract law and as we can sign documents online that are binding, we need a national realtime information-streaming infrastructure --text and URLs today, multimedia in the future...all over the (hopefully) secure domestic 5G network. Set the standard, setup a court system for inevitable violators, regulate the gateways allow everyone to connect.

Re: An update on our security incident

#80

Post by IncRnd » Fri, Jul 31, 2020, 6:20 AM UTC

Account access is one thing, yes, and a hardware 2FA key can help with that.

But - what is the reason to allow support personnel to pose as specific users and send tweets from their accounts? There is more than a security issue here. There is a complete security breakdown.