An update on our security incident • Hacker News Board

Re: An update on our security incident

#241

Post by fulafel » Sun, Aug 02, 2020, 6:17 AM UTC

ytdytvhxgydvhh wrote: post #196

ben509 wrote: post #186

> We have zero tolerance for misuse of credentials or tools, actively monitor for misuse, regularly audit permissions, and take immediate action if anyone accesses account information without a valid business reason. Okay, so who has been fired? That's what "zero tolerance" means: no excuses, not even "someone tricked me." And no punishment but the maximum. Anything less would involve some degree of tolerance, and wh…

It’s like when motorcyclists say “safety first” about wearing a helmet and other protective gear. If they really put safety first, they’d choose a safer form of transportation. They mean “given that I’m going to engage in this risky activity, I’m going to try to make this activity as safe as possible”. In this case “zero tolerance” is short for something like, “except for understandable slip-ups that aren’t fully you…

It's pretty meaningless on motorcycle too. Even aviation with their culture and checklists isn't that.

Re: An update on our security incident

#242

Post by tialaramex » Sun, Aug 02, 2020, 9:58 AM UTC

Thorrez wrote: post #239

tialaramex wrote: post #232

Earlier quoted context omitted.

If stealing a cookie is all you needed then FIDO isn't relevant to the picture at all.

You were mentioning an attacker trying to steal a touch from the FIDO device using malware. My point was that's pointless because cookie theft is easier and gives the attacker the same thing.

If the attacker wants a cookie, then stealing a cookie gets them the cookie, but it is not necessarily the case that the attacker only wants a cookie.

Nothing compels Twitter to design their user administration tool so that it says "Oh you have a cookie well then it's fine for you to change Elon Musk's email address and switch off his 2FA".

For example it's perfectly easy to have a "Confirm" step for a privileged operation that requires WebAuthn authentication. But if you're the attacker that means a cookie doesn't help you.

Re: An update on our security incident

#243

Post by _8j50 » Sun, Aug 02, 2020, 2:56 PM UTC

reportgunner wrote: post #234

_8j50 wrote: post #185

Earlier quoted context omitted.

I agree,but tell that to the people that fire employees for failing phishing tests

If they fire for one failed test, they need to understand that people learn from mistakes. If they fire for repeated failed test, perhaps the person who is failing is not very well suited for a role where you have to resist phishing.

That's exactly how they think and it's b.s.! The whole point of this comment thread is that most people will fall for a phish if the phish is good enough.

Re: An update on our security incident

#244

Post by whoisjuan » Sun, Aug 02, 2020, 7:13 PM UTC

gsich wrote: post #117

whoisjuan wrote: post #17

Earlier quoted context omitted.

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…

>Many security researchers have already established that the benefits of a VPN especially in the modern distributed world are marginal at best. Yes, with the (wrong) assumption that after you have connected to a VPN, all other services are free for the taking, without any further authentication.

I have worked at companies that used VPNs. After you authenticated and logged with the VPN you had access to several resources with no further authentication. Granted I would always use the company issued computer so I don't know if there was another non-transparent authentication in the background but overall seemed that just being within the network was enough to access things.

Re: An update on our security incident

#245

Post by IncRnd » Wed, Aug 12, 2020, 12:09 PM UTC

Thorrez wrote: post #224

IncRnd wrote: post #219

Earlier quoted context omitted.

I didn't see that in the page for this article. But, that's a good point. The specific text is, "Using the credentials of employees with access to these tools, the attackers targeted 130 Twitter accounts, ultimately Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7." So, this doesn't say what actually happened. If it was employees posing as users in order to post, that is an permis…

>separate issue with 2fa that would be expected on these accounts. I believe the tool also allowed deleting 2FA from the account. > But because the attackers were able to change the email address tied to the @6 account and disable multi-factor authentication, https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-e...

In other words, there was a tool that allowed posing as users.