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

101–110 of 245 posts

Re: An update on our security incident

#101

Post by geocar »

dpweb wrote: post #89
0xUser wrote: post #5

Source (with more details): https://blog.twitter.com/en_us/topics/company/2020/an-update... > The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all o…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

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.

Re: An update on our security incident

#102

Post by Thorrez »

monoideism wrote: post #88
zamalek wrote: post #29

Earlier quoted context omitted.

I haven't seen a form of phishing that hardware 2FA doesn't stop. Yes, it would have.

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.

Re: An update on our security incident

#103

Post by Thorrez »

fareesh wrote: post #44
zamalek wrote: post #29

Earlier quoted context omitted.

I haven't seen a form of phishing that hardware 2FA doesn't stop. Yes, it would have.

The way it is worded can also mean that there were XSS vulnerabilities in the internal tool since they are saying "gained information about how our processes work". I feel like that's a strange and vague thing to say. The right kind of xss vulnerability would enable them to bypass 2fa too, maybe steal backup codes even.

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

Re: An update on our security incident

#104

Post by londons_explore »

ma2rten wrote: post #84
andrew_ wrote: post #36

Earlier quoted context omitted.

I'd like to know more about these tools. That there's at least one which can bypass a user's 2FA settings without notification suggests that there are additional tools in the same vein.

Google requires its employees to use a security key for access to all internal systems including admin tools, source code and email. Every since google started enforcing this policy the number of successful phishing attacks has gone down to basically zero.

I believe the Twitter attack involved tricking a user into installing proxy software on their machine (to be in twitter's internal network).

If that is the case, that same proxy software could proxy the security key requests too.

Re: An update on our security incident

#105

Post by Thorrez »

zamalek wrote: post #29
ehsankia wrote: post #23

Earlier quoted context omitted.

Were the spear fishing attacked also used to get 2FA, or did these accounts not have 2FA? Would hardware based 2FA not have stopped this?

I haven't seen a form of phishing that hardware 2FA doesn't stop. Yes, it would have.

It does depend on whether the hardware 2FA is U2F (which stops phishing) or OTP[1] (which doesn't).

[1] http://www.tokenguard.com/RSA-SecurID-SID700.asp

Re: An update on our security incident

#106

Post by heinrichhartman »

What I find most problematic about the attac is the incident response by Twitter.

As people pointed out here, hijacking Twitter accounts can lead to big stock market crashes, mass panics ("bomb found at XXX") and maybe even military escalations.

Under this circumstances, leaving a platform with an unknown number of compromised accounts online, seems irresponsible to me. In such a case you must stop the bleeding ASAP, either by locking up "important" accounts (what they eventually did, after a few hours!) or taking the site offline.

Next time this happens, we might not be so lucky.

Re: An update on our security incident

#107

Post by extrapickles »

dpweb wrote: post #89
0xUser wrote: post #5

Source (with more details): https://blog.twitter.com/en_us/topics/company/2020/an-update... > The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all o…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

The admin tool was used to change the email on an account, then the attacker reset the password and got full access to the account. Apparently having 2FA enabled did not stop this attack (admin tool probably had the power to strip 2FA from accounts).

So while the tool did not directly have the ability to tweet, it effectively did.

Re: An update on our security incident

#108

Post by ameliaquining »

dpweb wrote: post #89
0xUser wrote: post #5

Source (with more details): https://blog.twitter.com/en_us/topics/company/2020/an-update... > The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all o…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

My uninformed guess is that there isn't a "tweet as this user" button (because obviously there's no legitimate use case for that), but there is a "change this user's email address" button (because you might need to do that in order to help someone who's locked out of their account), and if you can do that you can take over someone's account. Obviously something like this would be detected quickly, which makes it less scary in some ways than a "tweet as this user" button, but of course this particular attack did not seek to evade detection once it was launched.

Of course, some of the targeted users presumably had 2FA enabled. How to do account recovery with 2FA in a consumer context is a complicated problem and I'm not aware of any good answers, but there's certainly an argument that the protections in place there weren't adequate and I wouldn't be surprised to see them changing soon.

I would also hope that rank-and-file support staff can't change users' email addresses, and the attackers had to spear-phish one of a smallish number of people whom more complicated account-recovery cases are escalated to. But who knows if that's how it works.

Re: An update on our security incident

#109

Post by f2000 »

dpweb wrote: post #89
0xUser wrote: post #5

Source (with more details): https://blog.twitter.com/en_us/topics/company/2020/an-update... > The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all o…

No disrespect to those challenged with protecting such a huge target, but why do admin tools even have these capabilities? I could see needing to disable a user account or change some attributes, but why would an admin ever need to tweet from it? There shouldn't be tools with God privileges even for admins. Not surprising human error was involved in a breach this huge. So, how many people had access to this tool? Is…

I've coded/supported a number of admin tools for a number of large companies (banks, telcos, etc) so I'll take a stab at "why" First, god mode can be implemented cheap and fast. God mode also makes day to day support easy as admins/support staff can do just about everything fast and easy - so they typically love it and will often fight to keep it. More than once I have had managers turn down proposals to tighten up security because of the cost and false beliefs that because the tool is behind a firewall, better security is not needed. Taking a schedule and/or budget hit to implement tighter security is not going to get them a promotion or bonus. Sad but true. In the vast majority of cases I've seen, paying for security improvements becomes incentivized for managers after their company gets burned by a breach.

Also, admin tools are often "afterthoughts", there is usually a motley collection of them, and often considered as an expense/cost to be minimized and not a revenue generating asset that gets more budget and attention.

Re: An update on our security incident

#110

Post by dcow »

ThA0x2 wrote: post #53
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.

Another instance where zero-trust networking has utterly failed. Security comes in layers. That first layer of requiring a VPN can stop many types of attacks from happening. Next layer is requiring MFA for VPN access. Then for admin access, require MFA only from approved devices on the domain. Large banks and the DoD have been doing this for years. The "fail often and fail fast" crew are always reinventing the wheel…

? This definitely wasn’t a zero trust failure.
Post reply on HN