An update on our security incident • Hacker News Board

Re: An update on our security incident

#141

Post by Thorrez » Fri, Jul 31, 2020, 8:26 AM UTC

MAGZine wrote: post #58

Osiris wrote: post #50

Earlier quoted context omitted.

I work for a crypto currency company and it was the first time in my career that I was issued a YubiKey (I once had an RSA 2fa token for vpn access). It took some getting used to but now I just keep in on my keychain and I always have it with me. I need it for SSO, git, VPN, and basically all internal services. They aren't sufficient by themselves however, they don't protect from is malicious internal employees.

Preparing for malicious internal employees seems to me like preparing for "the big one," in the northwest. Do a cursory amount of preparation. Outside of basic measures, you're probably doing more harm to the business than good. The likelihood of internal malicious attackers is very low in the grand scheme of things, and the attack surface is huge. Most companies are going to be compromised by outside attackers—its t…

Well Twitter did indeed have malicious internal employees.

https://www.washingtonpost.com/national-security/former-twit...

If you're hit by a paywall:

https://web.archive.org/web/20200717083254/https://www.washi...

Re: An update on our security incident

#142

Post by detaro » Fri, Jul 31, 2020, 8:29 AM UTC

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?

That's what time tracking software is made for. No need to pause, "just" remember to switch the software if you change tasks/projects.

Re: An update on our security incident

#143

Post by geocar » Fri, Jul 31, 2020, 8:34 AM UTC

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?

The question was interpreted as “why do admin tools have these features” on account of that was in the first sentence, and not, as you may have imagined, a request for a twitter employee to explain all of their tools, or a request for a twitter employee to justify creating these tools.

Re: An update on our security incident

#144

Post by Thorrez » Fri, Jul 31, 2020, 8:34 AM UTC

TwoBit wrote: post #31

bawolff wrote: post #14

Earlier quoted context omitted.

That would probably not work well during the pandemic...

It could with an appropriately secured private VPN.

The VPN credentials could be phished. Of course appropriately-secured might mean U2F, in which case it likely would have prevented the attack. But they also could have used U2F without a VPN, and that also would have likely prevented the attack. So the VPN isn't really a benefit.

Re: An update on our security incident

#145

Post by Thorrez » Fri, Jul 31, 2020, 8:37 AM UTC

IncRnd wrote: post #80

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.

I don't believe there was a tool allowing support personnel to pose as users. I believe the tool allows support personnel to reset emails on accounts. Then the attackers used did password resets on the accounts then logged into the accounts and tweeted.

Re: An update on our security incident

#146

Post by Thorrez » Fri, Jul 31, 2020, 8:40 AM UTC

idoh wrote: post #37

bawolff wrote: post #18

Earlier quoted context omitted.

Training that is notorious for being ineffective in practise and usually more about box ticking. Assuming that none of your employees fall for phising, much less targeted phising, is woefully unrealistic. Especially at twitter's scale. Assuming humans won't do stupid things 100% of the time is never an effective security control.

Where I work there is training software that is somewhat effective at preventing phising - it actually sends out phising emails itself. Then employees who fall for it are given extra training (in a no fault sort of way).

Yep, I think that's a good thing. But I also think most employees will still fall for real phishing emails some of the time.

Re: An update on our security incident

#147

Post by Hikikomori » Fri, Jul 31, 2020, 8:41 AM UTC

whoisjuan wrote: post #17

nodesocket wrote: post #6

Earlier quoted context omitted.

Why are internal employee tools publically accessible? Minimum they should require VPN access, but really go further with Zero Trust.

AFIK, in a Zero Trust Architecture a VPN is considered a perimeter and therefore it becomes a vector of attack to access systems of authoritative decision. Many security researchers have already established that the benefits of a VPN especially in the modern distributed world are marginal at best. Basically, yes a VPN makes you a tiny bit safer but it also adds a lot of networking complexity and adds more friction to…

There's a lot you can do with vpn to make it more secure.

On our vpn we require a non-exportable certificate in the tpm chip, normal user credentials, then we have a captive portal that forwards to our SSO that requires a yubikey.

Re: An update on our security incident

#148

Post by Thorrez » Fri, Jul 31, 2020, 8:44 AM UTC

onefuncman wrote: post #140

Thorrez wrote: post #124

Earlier quoted context omitted.

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.

A tool that allows an employee to access a user's API key? That sounds like a bad idea, especially if that tool is accessible to support personnel.

Re: An update on our security incident

#149

Post by toyg » Fri, Jul 31, 2020, 8:45 AM UTC

chedabob wrote: post #139

csunbird wrote: post #128

Earlier quoted context omitted.

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.

The key being "proper training". Those few god-level admins should be drilled enough to defeat a phone-phishing campaign. In fact, they should probably have custom procedures to look after their own credentials.

Re: An update on our security incident

#150

Post by toyg » Fri, Jul 31, 2020, 8:58 AM UTC

> the attackers targeted 130 Twitter accounts, ultimately Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7

So much effort for so little gain... With proper preparation (i.e. a simple app ready to download everything from an account), they could have made out with the whole data of 130 accounts, silently, before tweeting the hopeless scam message. Instead, this seems like a mostly-manual effort, done in haste.

Just dumb thieves pulling off the scam of their life, or cover for a targeted attack of one or two of those 7 they actually siphoned properly? I hope US authorities will figure stuff out beyond the usual "it was a Chinese/Russian/Eastern European gang", which is just code for "fuck knows".