Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on our security incident

blog.twitter.com

Post reply on HN
Print view View original

131–140 of 245 posts

Re: An update on our security incident

#131

Post by throwaway345346 »

dpweb wrote: post #89
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…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

Internal admin tools grow over time. They don't spring fully-formed into the modern company with all the correct access controls and auditing they ought to require at that point. They carry a lot of cruft from things that were needed early on and aren't needed anymore.

Furthermore, they're a classic cost center, not a lot of love or budget goes into reducing their tech debt, or bulwarking them up against a sophisticated adversary. Red teaming yourself full time is expensive and not profitable. What's the worst that happens from a breach like that? Well, Equifax is still going strong!

I recall being party to an amusing conversation at a major network services provider at a team meeting for people with access to such tools, to the effect of:

- Alright, we're modifying to lock down access to accounts related to . You will no longer be able to use on , only select supervisors will have that access.

%%% ah, okay, that makes sense

# uh, hey, regarding , which allows us to look up ? does that still work the same?

- Uh, yeah, it does.

# okay?

%%% ... silence ...

- Alright, next item!

To the best of my knowledge, that was never addressed. has audit logs. doesn't.

Re: An update on our security incident

#132

Post by bananaface »

bzb3 wrote: post #127
heinrichhartman wrote: post #106

What I find most problematic about the attac is the incident response by Twitter. As people pointed out here, hijacking Twitter accounts can lead to big stock market crashes, mass panics ("bomb found at XXX") and maybe even military escalations. Under this circumstances, leaving a platform with an unknown number of compromised accounts online, seems irresponsible to me. In such a case you must stop the bleeding ASAP,…

No. We need more things like these to happen so people lose trust on everything they read on the stupid internet. This was good. I hope it keeps happening.

If they'd taken the site offline then the event probably would have generated more publicity.

Re: An update on our security incident

#134

Post by Thorrez »

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

>There is too much focus on entry point of an attack,especially by news media.

That depends on what you mean by "entry point". If you define the entry point as a person, then yes don't focus on that. But if you define the entry point as phishable credentials, then focusing on that is good, it will prompt companies to switch to phishing-resistant credentials (U2F security keys).

Re: An update on our security incident

#135

Post by Thorrez »

_8j50 wrote: post #90
iKevinShah wrote: post #65

Earlier quoted context omitted.

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

That's the thing, you can't,not with the way current tech is. But you can read up about having good monitoring/detection and hardening on your endpoints. Microsoft for example recommenda privileged access workstations. If twitter's employees used a separate set of credentials and workstations for privileged twitter moderation than their regular account/machine used for email and day to day stuff I bet the attack wolf…

There are probably Twitter employees whose job it is to reset emails all day long. Having 2 separate computers and accounts, one for for resetting emails (which is done all day) and one for responding to email sounds like quite a burden on employees. How are they going to get the name of the account from one computer to the other? Copy and paste won't work. Retyping from one computer to the other surely will result in typos.

Re: An update on our security incident

#136

Post by Thorrez »

ngomez wrote: post #75
thdrdt wrote: post #56

Earlier quoted context omitted.

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 set…

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

How often is the tap needed? Is it needed on every action or 1/day or 1/month? It would stay valid via browser cookies valid for that period. If it's 1/day the employee might have tapped it in the morning, then went to lunch, then the attackers hit with the remote desktop attack.

Re: An update on our security incident

#137

Post by m463 »

lovecg wrote: post #123
m463 wrote: post #116

Earlier quoted context omitted.

Seriously I worked on projects subject to government scrutiny and it was ok, but you had to be the right kind of person. Account for your time in 6-minute increments. Milestones I recall off the top of my head were preliminary design, detailed design, 3-5% of your time coding, software integration, hardware software integration, acceptance. It was stable, predictable, and (to me) very soul-crushing.

None of that sounds “ok”... Technical question for you, how does this time tracking work in practice? Do you pause every 6 minutes and note what you’re doing? Or just roughly remember at the end of the hour/day?

You had to charge each project you worked on and record your time to .1 hour precision.

So recording 1.1 against project 3456 would charge that project for 1 hour and 6 minutes of your time.

You had to do the same thing for a dentist appointment. 1.0 hours for an "overhead project".

(I should mention this was years ago)

Also, lots of the people who worked there were ex-government employees and were fine with it, because software folks got to go home to their family every day at a predictable time, you would get training at regular intervals and although the pay wasn't super competitive it was a good job, indoors and in an air-conditioned office.

Re: An update on our security incident

#138

Post by onefuncman »

dpweb wrote: post #89
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…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

"Tweet As User" is the basis for almost all social media management tools and Twitter still doesn't have very fine-grained permissions grants. https://developer.twitter.com/en/docs/basics/apps/guides/app...

We had a running gag in our social media startup of tweeting "poop" from people who left their phones/computers unlocked ... someone did it to an employee that was logged in as a customer (corporate brand) context and that was the end of that 'joke'.

Re: An update on our security incident

#139

Post by chedabob »

csunbird wrote: post #128
extrapickles wrote: post #107

Earlier quoted context omitted.

The admin tool was used to change the email on an account, then the attacker reset the password and got full access to the account. Apparently having 2FA enabled did not stop this attack (admin tool probably had the power to strip 2FA from accounts). So while the tool did not directly have the ability to tweet, it effectively did.

I feel like the power to reset emails and remove 2fa should be only held by a very small subset of customer support, with proper training.

That seems like it was the case, but the attackers got access to lower privileged accounts and used them to find who had that access so they could target them.

Re: An update on our security incident

#140

Post by onefuncman »

Thorrez wrote: post #124
geocar wrote: post #101

Earlier quoted context omitted.

You have a need for a tool allows you to see the UI “as the user does” so you can respond to support requests and maybe someone thinks it’s easier to just copy the cookie. This isn’t the right way to do it, but given they work at Twitter I could imagine this isn’t the first big mistake they’ve made.

This sounds like speculation. Is there evidence that Twitter has a tool that allows employees to see the UI as the user does?

it's not copying the cookie, but there are absolutely third party UIs via a user's API key, it's not a huge leap of faith to assume Twitter has similar internally.
Post reply on HN