Live data from Hacker News

An update on our security incident

blog.twitter.com

221–230 of 245 posts

Re: An update on our security incident

#221

Earlier quoted context omitted.

Significant forms of phishing are stopped by U2F (as used by Yubikey and others), by crytographically binding your credential to the domain name , and only issuing an approval signature if the site matches. Obviously, this stops credential phishing. https://krebsonsecurity.com/2018/07/google-security-keys-neu... https://medium.com/@antonisikora/how-u2f-security-keys-can-e...

You and zamalek appear to be in agreement.

You're right - I misread the comment. I'd delete my comment if I could.

Re: An update on our security incident

#222

Earlier quoted context omitted.

I wish I knew why security does this character assassination routine with low-skill hacks. They clearly got in, bumbled attempt or not. Is it somehow helping everyone to know they fucked up? Whose expectations are we changing here?

Who is “security” here? In my experience, if you ask most working security professionals, they would agree that social engineering is by far their largest vulnerability. All the cryptography stuff is fun and cool but really the work is all about preventing phishing, so I don’t know any working security engineers who would call this a low-skill hack.

Its low skill because they appear to have been unprepared to take full advantage of their "hack".

Re: An update on our security incident

#224
post #219

Earlier quoted context omitted.

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.

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

Re: An update on our security incident

#225

Earlier quoted context omitted.

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

I'd say a typo rate is an acceptable tradeoff for air-gapping privileged access.

The typos themselves could be a vector for attack. The attacker asks for a reset for one account with a capital I and maybe gets a reset for a different account with a lowercase l.

Re: An update on our security incident

#226
post #200

Earlier quoted context omitted.

Even u2f isn't fool proof (exploitation and cookie theft techniques). Execution,privesc,lateral movement are things focus should be on. You can't control the facg that people need to use email and they will for for a phish,but you can control your authentication system, alerting system,etc...

> Even u2f isn't fool proof (exploitation and cookie theft techniques) What is "Exploitation" standing for here? Exploitation of... what? How and by who?

Browser exploitation using a phishing link. For a publicized example look at the coinbase attack last year or so.

Re: An update on our security incident

#227
post #207
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…

>That's what "zero tolerance" means: no excuses, not even "someone tricked me." That doesn't necessarily follow, as it depends on exactly what they have zero tolerance for. They say they have zero tolerance for "misuse of credentials." Misuse conceivably may not include insecure storage of credentials or accidentally exposing them, but only actively using them, eg logging in and using them for an inappropriate purpos…

> That doesn't necessarily follow, as it depends on exactly what they have zero tolerance for.

It does depend on that, you're right. "Zero tolerance" sounds so clear, it even has a number in there! But, nevertheless, one can rationalize just about any outcome by invoking it.

Specifically, any administrator who hasn't worked out a detailed meaning will have to crystalize their understanding when it comes time to apply the idea. This process of rationalizing will be different depending on the situation and their biases.

The supposedly clear policy becomes capricious or arbitrary. And if it's not arbitrary because they have some actual doctrine that can be consistently applied, then it would make more sense to use that doctrine.

> I'm not trying to split hairs or be a Twitter apologist here...

Splitting hairs is the raison d'etre of this site.

I'm not annoyed at Twitter specifically as they're hardly the inventors of the phrase. My issue is with concept itself, and the broader mindset that you see in legal concepts like strict liability.

> Intentional misuse of credentials is ultimately [in]subordination...

Well, intentional is your head-canon since they didn't use that word. But intent is useful to the discussion; let me explain why I don't think zero tolerance allows for intent and other mitigating factors.

The point of tolerance is that some harm is done, and the injured party is going to limit their response to it.

Law typically breaks it out as the action that caused the harm, the intent to cause that harm, and the certainty of your knowledge of the facts.

As soon as you bring intent into the equation, you're willing to tolerate a great deal of harm. Someone can get hurt in a car crash, and if it's clearly an accident, the injured party is generally not going to hold a grudge.

If there's sufficient uncertainty, we aren't even sure we can direct our response to the harm at the correct party. Then we're stuck tolerating it, or taking it out on some scapegoat. And I'd even argue that the fact that we inevitably have to tolerate some harm makes the concept of zero tolerance fundamentally contradictory.

Tolerance is what civilized people do in response to real life situations, and when they don't you get feuding and war. This isn't a new problem, the point of "an eye for an eye" in Mosaic law was to limit vengeance and vigilanteism with a doctrine of proportionality. Not surprisingly, people still didn't get it, which was why Christ revised it to "turn the other cheek."

Re: An update on our security incident

#228
post #226

Earlier quoted context omitted.

> Even u2f isn't fool proof (exploitation and cookie theft techniques) What is "Exploitation" standing for here? Exploitation of... what? How and by who?

Browser exploitation using a phishing link. For a publicized example look at the coinbase attack last year or so.

The one your thinking of is a malware attack right? The intended attack results in victims running malware from the attacker. So that's not "phishing" by any definition I recognise.

And even in that attack, the victim's long term credential is protected if they use FIDO authenticators - the bad guys can't use the authenticator without help from the legitimate user and they don't gain any enduring credentials.

So you need to do the attack live and then hope the victim not only doesn't realise you just infected them with malware, but conveniently signs into something at the moment you need a signature, for which you can hijack their expectation to press contact on the authenticator. Then you get one authentication. If you need another one, for any reason (timeout, subsequent operation asks to re-authenticate, anything) you have to do it again because you do not gain enduring credentials.

Re: An update on our security incident

#229
post #226

Earlier quoted context omitted.

Browser exploitation using a phishing link. For a publicized example look at the coinbase attack last year or so.

The one your thinking of is a malware attack right? The intended attack results in victims running malware from the attacker. So that's not "phishing" by any definition I recognise. And even in that attack, the victim's long term credential is protected if they use FIDO authenticators - the bad guys can't use the authenticator without help from the legitimate user and they don't gain any enduring credentials. So you…

The malware doesn't need to there "moment you need a signature". The malware can just grab an existing cookie or use an existing cookie. Sure it's not an enduring credential. But whether the malware is there at that moment or an hour later, it won't make much difference.

And this specific Twitter attack might not have needed enduring credentials. It seemed to happen over a short time period.

Re: An update on our security incident

#230
post #200

Earlier quoted context omitted.

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

Even u2f isn't fool proof (exploitation and cookie theft techniques). Execution,privesc,lateral movement are things focus should be on. You can't control the facg that people need to use email and they will for for a phish,but you can control your authentication system, alerting system,etc...

You're right about those. But malware can be blocked by blocking support people from installing any new software. Cookie theft is indeed tricky to stop, but it's much harder to pull off than regular credential phishing, so blocking regular credential phishing is still a good win. And there are techniques to stop cookie theft (binding them to a non-bearer-token, such as channel ID, token binding, TLS client cert, IP address).
Post reply on HN