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

161–170 of 245 posts

Re: An update on our security incident

#161

Post by SilasX »

m463 wrote: post #55
djsumdog wrote: post #51

Earlier quoted context omitted.

Why do we even have 'high value' accounts on a centralized platform? Why isn't there a whitehouse.gov ActivityPub instance that no single admin can censor or subvert?

We will do that now. We will start the competitive bidding process, and we expect the RFP paperwork to be returned by October, 2021. After that, if there are no injunctions filed because of the bidding process, preliminary design documents will start being created. Preliminary design review will occur August 2022. ...

Considering that the Trump account had some security measures that protected it from being compromised in this attack, that seems pessimistic.

Re: An update on our security incident

#162

Post by pseudoramble »

Thorrez wrote: post #136
ngomez wrote: post #75

Earlier quoted context omitted.

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

Every time you login with a Yubikey you must tap it. It does not maintain its own session on the key or anything like that.

If the app maintains a session, then that depends on how long the app allows sessions/tokens to live for at that point. The Yubikey won't come into play until login is required again. So, I think you're getting at a different part of the security model at that point.

Re: An update on our security incident

#163

Post by Thorrez »

pseudoramble wrote: post #162
Thorrez wrote: post #136

Earlier quoted context omitted.

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

Every time you login with a Yubikey you must tap it. It does not maintain its own session on the key or anything like that. If the app maintains a session, then that depends on how long the app allows sessions/tokens to live for at that point. The Yubikey won't come into play until login is required again. So, I think you're getting at a different part of the security model at that point.

My point is that essentially all apps maintain a session and a remote desktop attack can make use of that session. So Yubikey doesn't really protect from remote desktop attacks.

Re: An update on our security incident

#164

Post by Thorrez »

fareesh wrote: post #158
Thorrez wrote: post #103

Earlier quoted context omitted.

If there's an XSS attack I don't consider that phishing.

Isn't it both? Phish first user, post to internal tool and xss attack second user.

Yeah I guess you're right, it could be like an exploit chain where 1 link in the chain is phishing to gain access to something and xss is the next link for lateral movement.

But I don't know what "The right kind of xss vulnerability would enable them to bypass 2fa too" means. If the attacker doesn't have 2FA I would think the attacker can't log in, thus meaning the first link of the chain has no purpose.

But I also think XSS in this case is not very likely. From interviews with the attackers it sounds like they're social engineering experts who hang out on social engineering forums, not XSS experts[1][2][3].

[1] https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-e...

[2] https://www.nytimes.com/2020/07/17/technology/twitter-hacker...

[3] https://krebsonsecurity.com/2020/07/twitter-hacking-for-prof...

Re: An update on our security incident

#165

Post by pseudoramble »

Thorrez wrote: post #163
pseudoramble wrote: post #162

Earlier quoted context omitted.

Every time you login with a Yubikey you must tap it. It does not maintain its own session on the key or anything like that. If the app maintains a session, then that depends on how long the app allows sessions/tokens to live for at that point. The Yubikey won't come into play until login is required again. So, I think you're getting at a different part of the security model at that point.

My point is that essentially all apps maintain a session and a remote desktop attack can make use of that session. So Yubikey doesn't really protect from remote desktop attacks.

Fair enough! I didn't comprehend the context well enough. Seems right though, the Yubikey won't protect sessions. At least I don't see any reason it would.

Re: An update on our security incident

#166

Post by ACS_Solver »

toyg wrote: post #150

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

I imagine that the limited damage the attackers did will help them evade being caught. Ultimately, they just stole some 100k$ in Bitcoin and that's it, so investigations by the FBI et al. will probably not go to great lengths to locate the hackers. On the other hand, attempts to blackmail someone like Tim Cook or Elon Musk would probably be riskier. For the same reason, I suspect the attackers may have intentionally avoided breaching or tweeting from Trump's account, too much risk of attracting serious FBI and Secret Service attention.

As it is, the only people who actually lost something are a bunch of Bitcoin owners that got scammed, and it's just not a big deal.

Re: An update on our security incident

#167

Post by TheAdamAndChe »

thaumasiotes wrote: post #119
_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.

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.

Re: An update on our security incident

#168

Post by m463 »

detaro wrote: post #142
lovecg wrote: post #123

Earlier quoted context omitted.

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.

I vaguely recall part of it was that you had to sign your timesheets. It's been a long time, and I'm pretty certain things have gotten better. It was harder for me as a young software guy out of college to accept 3-5% only of your time was coding.

Re: An update on our security incident

#169

Post by brown9-2 »

djsumdog wrote: post #51
dboreham wrote: post #2

No employee should have the power to subvert 130 high value accounts in a short time period.

Why do we even have 'high value' accounts on a centralized platform? Why isn't there a whitehouse.gov ActivityPub instance that no single admin can censor or subvert?

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.

Re: An update on our security incident

#170

Post by reportgunner »

_8j50 wrote: post #87
EE84M3i wrote: post #81

Earlier quoted context omitted.

What infosec people think $vendor email security solutions are going to solve phishing attacks? I was under the impression that the people that buy those solutions (like many security solutions) are primarily non-infosec people that want to paper over their real problem without fixing it. Granted, there is a place for some of these things temporarily while working to fix the actual problem, but that's a mitigation, n…

Nope, seasoned pros I respect think trainig+$vendor is good enough. If it isn't, blame the user or the vendor! There are shops where the goal is to have someone to blame when you get owned and there are rare shops where the goal is to do it right to catch/stop bad guys even if it means you get blamed (because management understand security is not absolute)

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