Live data from Hacker News

An update on our security incident

blog.twitter.com

231–240 of 245 posts

Re: An update on our security incident

#231
post #19

Earlier quoted context omitted.

What if the attackers phish the VPN credentials too? Does Zero Trust imply phishing-resistant credentials? What Twitter needed was phishing-resistant credentials (security keys, aka U2F).

Zero Trust != VPN. Zero Trust means that the network is not what determines trust. Consider this: * You go to your office, connect to the network * Now you have access to internal services, by virtue of being on the network In a Zero Trust network it does not matter what network you are on. Trust is handed out individually, based on the identity/ role of the user and the context of their session (is their os patched?…

How does the site know the user's OS is patched? The User Agent? How about whether security tools are running?

The attacker can surely use a patched OS. Are the security tools secret? If not, then the attacker can run the security tools too.

Re: An update on our security incident

#232

Earlier quoted context omitted.

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.

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

Re: An update on our security incident

#233
post #83

Earlier quoted context omitted.

U2F are safe against simple phishing, but sophisticated attacks can include 2-factor input.

U2F protects against that because the signature is tied to the hostname. The browser reads the hostname. The browser is infallible when it reads the hostname, unlike a human.

Oops, I didn’t realise U2F was different to 2FA.

I guess you would need to ring someone up pretending to be tech support and convince them to disclose the private key.

Re: An update on our security incident

#234
post #185

Earlier quoted context omitted.

Well in the end we are all just human. We can't expect to blame things on each thing a human does to human.

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.

Re: An update on our security incident

#235
post #205

Earlier quoted context omitted.

Because the general public has no clue what ActivityPub is or the desire to learn how to consume feeds from dozen of instances when they could just download a single app onto their smartphone where all the celebrities already are.

> general public has no clue what ActivityPub is The general public doesn't need to know anything about the underlying standards. Does a salesperson care about how SMTP works in order to send and receive emails from their customers?

How do you propose people consume 100s of different ActivityPub feeds without learning the details of how to configure an app to do so, while also staying away from a centralized platform to make it easy to consume the feeds?

Re: An update on our security incident

#236

Earlier quoted context omitted.

Speaking from experience at a major infosec company, the impression I got internally was "we offer phishing tests, but we don't recommend them, because phishing succeeds 100% of the time". So I'm confused by the idea "even infosec people think training will stop this".

I disagree. There are services that regularly send fake phishing emails on a regular basis. If they click a link or fail to flag enough emails, their boss gets notified that more training is necessary. At the bank that I see this used at, the employees are far less trusting of emails and such. Training works if it's done right.

Training does work to reduce the amount of succesful untargeted attacks. For spear-phishing it's hit and miss on how good the attack is, but a good enough attack will work against almost anyone. As someone that sees really well crafted phish, I can tell you I myself will fall for a good phish. It has to do with eliminating the element of surprise, if I didn't expect the email I will assume it's a phish. But if rapport is built and the subject is something very specific only a few people are privy to then my guard will be lowered. Business email compromise comes to mind, they just reply to an existing thread with a link to a trusted site like onedrive

Re: An update on our security incident

#237

Earlier quoted context omitted.

Zero Trust != VPN. Zero Trust means that the network is not what determines trust. Consider this: * You go to your office, connect to the network * Now you have access to internal services, by virtue of being on the network In a Zero Trust network it does not matter what network you are on. Trust is handed out individually, based on the identity/ role of the user and the context of their session (is their os patched?…

How does the site know the user's OS is patched? The User Agent? How about whether security tools are running? The attacker can surely use a patched OS. Are the security tools secret? If not, then the attacker can run the security tools too.

> How does the site know the user's OS is patched? The User Agent?

User agent is a great place for a version 0, sure. 99% of your assets aren't compromised, so worrying about a bypass isn't important to most of them. For a v0 just knowing that most of your boxes are patched is a huge win.

Of course you'll want client certificates on devices, or some sort of TPM, which is how Chromebooks work. The attacker having a box is not enough - identity is a key principal of zero trust networks.

Re: An update on our security incident

#238

Earlier quoted context omitted.

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.

Sounds like that's a font selection issue for the admins - there are good choices of font that are unambiguous, they've been linked here.

Re: An update on our security incident

#239

Earlier quoted context omitted.

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.

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.

Re: An update on our security incident

#240
post #233

Earlier quoted context omitted.

U2F protects against that because the signature is tied to the hostname. The browser reads the hostname. The browser is infallible when it reads the hostname, unlike a human.

Oops, I didn’t realise U2F was different to 2FA. I guess you would need to ring someone up pretending to be tech support and convince them to disclose the private key.

The private key is embedded in the hardware key, there's no way to extract it without an advanced attack involving tearing apart the key.

But a practical attack along the lines of what you mentioned would be to ring someone up and convince them to disclose their cookie. Check out[1] in which the victim disclosed their cookie without the attacker even asking for it.

[1] https://hackerone.com/reports/745324

Post reply on HN