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

151–160 of 245 posts

Re: An update on our security incident

#151

Post by mikehollinger »

nevertoolate wrote: post #26
mikehollinger wrote: post #15

Earlier quoted context omitted.

I will freely admit that I fell for a phishing campaign. I’d just bought something on eBay (this was a while ago). I got an email about something in my account later that day that made it through my spam filters. I clicked on it, signed in, and then realized I’d done the deed. Nothing happened or was lost, but yes - it just takes one quick mistake.

I don’t get it. You know your ebay password?

This was 2008 - way before I’d discovered the value of a password manager.

Re: An update on our security incident

#152

Post by c00ls0sa »

csunbird wrote: post #128
extrapickles wrote: post #107

Earlier quoted context omitted.

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.

I feel like the power to reset emails and remove 2fa should be only held by a very small subset of customer support, with proper training.

I work in customer service supervising entry level employees. The amount of power they have at any given time is astounding and it's by sheer ignorance or benevolence that more isn't embezzled en masse or this information isn't used for personal gain. My entire team of newly trained staff have access to your bank account information, where and when your payment was posted by IP, and we can strip 2fa or mobile numbers at whim. This coupled with inexperienced agents often leaves multiple accounts compromised. Having a select few engineers who don't work weekends always helps. We don't train the agents to tell them that they could potentially ruin customers' weeks by pushing the wrong button and it happens way too often to be standard, but as long as investors are happy and banks are good to reverse charges with no penalties here we are. Tech companies are good to throw caution to the wind.

Re: An update on our security incident

#153

Post by c00ls0sa »

tdhoot wrote: post #111
londons_explore wrote: post #104

Earlier quoted context omitted.

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.

That can be prevented by restricting the software that can be installed on employee machines.

WFH has caused many companies to ease up on restrictions involving location, ip, and sometimes a broader need for software. Granted, nobody should be this easy to bamboozle, but I get why now more than ever this may have been an issue.

Re: An update on our security incident

#154

Post by tallanvor »

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…

Admin tools having the capability to change email and 2FA settings is a necessity, but Twitter clearly needs to greatly increase the security.

I don't know what all Twitter uses, but I know that many companies have various methods of authentication depending on how much damage can be done:

- Logging on using a username/password and 2FA is enough for some activities.

- More sensitive operations have to be done on hardware that has a certificate installed and backed by something like Windows Hello.

- Even more sensitive operations require a JIT account and a certificate stored on a separate hardware key such as a yubikey.

- Very sensitive work gets done on a secure device that is very locked down and can detect changes to the hardware that may suggest tampering.

- Some stuff simply isn't allowed to be done remotely, even with the above restrictions.

Obviously not every company needs such a complex setup, but for someone as high profile as Twitter, you'd expect more thought to be put into this.

Re: An update on our security incident

#157

Post by sah2ed »

Hikikomori wrote: post #147
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…

There's a lot you can do with vpn to make it more secure. On our vpn we require a non-exportable certificate in the tpm chip, normal user credentials, then we have a captive portal that forwards to our SSO that requires a yubikey.

Do you have a writeup describing your architecture in more detail?

Re: An update on our security incident

#158

Post by fareesh »

Thorrez wrote: post #103
fareesh wrote: post #44

Earlier quoted context omitted.

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.

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

Re: An update on our security incident

#159

Post by michaelt »

ameliaquining wrote: post #108
dpweb wrote: post #89

Earlier quoted context omitted.

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…

> How to do account recovery with 2FA in a consumer context is a complicated problem and I'm not aware of any good answers

I've always wondered why there isn't more use of time delays for this sort of thing.

If there was a notification e-mail and a 7-day wait, that would offer a fair chance for the real account holder to cancel the change. Not 100% - the user might be on holiday - but it would catch a lot, and hence decrease attackers' motivation. And while a 7-day wait is inconvenient, for services like Twitter and Steam losing access for a week isn't the end of the world.

Post reply on HN